Centralized logging (EFK stack) in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Check Elasticsearch Pod Status

You run the command kubectl get pods -n logging to check the status of Elasticsearch pods in your EFK stack. What is the expected output if Elasticsearch is running correctly?

Kubernetes

kubectl get pods -n logging

A

NAME                      READY   STATUS    RESTARTS   AGE
elasticsearch-0           1/1     Completed   0          10m

B

NAME                      READY   STATUS    RESTARTS   AGE
elasticsearch-0           1/1     Running   0          10m

C

NAME                      READY   STATUS    RESTARTS   AGE
elasticsearch-0           1/1     Pending   0          10m

D

NAME                      READY   STATUS    RESTARTS   AGE
elasticsearch-0           0/1     CrashLoopBackOff   3          10m

💡 Hint

Look for pods with STATUS as Running and READY as full.

A healthy Elasticsearch pod in Kubernetes shows STATUS as Running and READY as 1/1. Other statuses indicate issues or incomplete startup.

❓ Configuration

intermediate

Fluentd Configuration for Kubernetes Logs

Which Fluentd configuration snippet correctly collects logs from all Kubernetes pods and sends them to Elasticsearch in the EFK stack?

A

<source>
  @type tail
  path /var/log/containers/*.log
  pos_file /var/log/fluentd-containers.log.pos
  tag kubernetes.*
  format json
</source>
<match kubernetes.**>
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
  logstash_format true
</match>

B

<source>
  @type syslog
  port 5140
</source>
<match **>
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
</match>

C

<source>
  @type tail
  path /var/log/messages
  pos_file /var/log/fluentd-messages.log.pos
  tag system
  format none
</source>
<match system>
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
</match>

D

<source>
  @type tail
  path /var/log/containers/*.log
  pos_file /var/log/fluentd-containers.log.pos
  tag kubernetes.*
  format none
</source>
<match kubernetes.**>
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
</match>

💡 Hint

Look for JSON log format and correct path for Kubernetes container logs.

Option A correctly tails Kubernetes container logs in JSON format and sends them to Elasticsearch with logstash formatting enabled. Other options either use wrong input sources or formats.

❓ Troubleshoot

advanced

Kibana Dashboard Not Showing Logs

You notice Kibana dashboards are empty even though Elasticsearch and Fluentd pods are running. Which is the most likely cause?

A Fluentd is not able to connect to Elasticsearch due to wrong service name or port.

B Elasticsearch index is corrupted and needs manual deletion.

C Kibana pod is in CrashLoopBackOff state due to insufficient memory.

D Kubernetes nodes are not labeled correctly for Fluentd to run.

💡 Hint

Check Fluentd logs for connection errors to Elasticsearch.

If Fluentd cannot send logs to Elasticsearch, Kibana will have no data to display. Wrong service name or port in Fluentd config is a common cause.

🔀 Workflow

advanced

Steps to Upgrade EFK Stack Components

What is the correct order of steps to safely upgrade Elasticsearch, Fluentd, and Kibana in a Kubernetes EFK stack?

A 3,1,2,4,5

B 2,1,3,4,5

C 1,3,2,4,5

D 1,2,3,4,5

💡 Hint

Start with safely handling Elasticsearch pods before upgrading Fluentd and Kibana.

Elasticsearch upgrade requires careful node handling first. Then Fluentd and Kibana can be upgraded safely. Finally, nodes are uncordoned and cluster health checked.

✅ Best Practice

expert

Optimizing Elasticsearch Index Management

Which Elasticsearch index management strategy is best to keep the EFK stack performant and storage efficient?

A Manually delete indices weekly using kubectl exec into Elasticsearch pod.

B Keep all logs in a single large index to simplify queries and avoid overhead.

C Use index lifecycle management (ILM) to rollover indices and delete old data automatically.

D Disable index sharding to reduce resource usage on small clusters.

💡 Hint

Automate index rollover and deletion to maintain cluster health.

ILM automates index rollover and deletion based on policies, improving performance and storage use. Other options cause risks or inefficiencies.