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.

Practice

1. What is the main purpose of the EFK stack in Kubernetes?

easy

A. To collect, store, and visualize logs from all pods centrally

B. To manage Kubernetes cluster networking

C. To automate deployment of applications

D. To monitor CPU and memory usage only

Solution

1. Step 1: Understand EFK components

   The EFK stack consists of Fluentd (log collector), Elasticsearch (log storage), and Kibana (log viewer).

2. Step 2: Identify the main goal

   Its main goal is to centralize logs from all Kubernetes pods for easier troubleshooting and monitoring.

3. Final Answer:

   To collect, store, and visualize logs from all pods centrally -> Option A

4. Quick Check:

   EFK = Centralized logging [OK]

Hint: EFK means Fluentd, Elasticsearch, Kibana for logs [OK]

Common Mistakes:

• Confusing EFK with monitoring CPU/memory
• Thinking EFK manages networking
• Assuming EFK automates deployments

2. Which Kubernetes resource is typically used to deploy Fluentd as a log collector in the EFK stack?

easy

A. ServiceAccount

B. DaemonSet

C. Deployment

D. ConfigMap

Solution

1. Step 1: Understand Fluentd deployment needs

   Fluentd must run on every node to collect logs from all pods on that node.

2. Step 2: Choose correct Kubernetes resource

   DaemonSet ensures one pod per node, perfect for log collectors like Fluentd.

3. Final Answer:

   DaemonSet -> Option B

4. Quick Check:

   Fluentd runs as DaemonSet [OK]

Hint: DaemonSet runs pods on all nodes [OK]

Common Mistakes:

• Using Deployment which may not run on all nodes
• Confusing ConfigMap with deployment type
• Thinking ServiceAccount deploys pods

3. Given this Fluentd config snippet in Kubernetes:

match ** {
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
}

What is the main effect of this configuration?

medium

A. Fluentd sends all logs to Elasticsearch service at port 9200

B. Fluentd collects logs only from pods named elasticsearch

C. Fluentd stores logs locally on each node

D. Fluentd forwards logs to Kibana directly

Solution

1. Step 1: Analyze Fluentd match directive

   The match ** means all logs are matched and processed by this output plugin.

2. Step 2: Understand output plugin settings

   @type elasticsearch with host and port means logs are sent to Elasticsearch service at that address.

3. Final Answer:

   Fluentd sends all logs to Elasticsearch service at port 9200 -> Option A

4. Quick Check:

   match ** + elasticsearch output = send all logs to ES [OK]

Hint: match ** means all logs sent to Elasticsearch [OK]

Common Mistakes:

• Thinking logs go directly to Kibana
• Assuming logs are stored locally
• Confusing match pattern with pod names

4. You deployed the EFK stack but Kibana shows no logs. Which of these is the most likely cause?

medium

A. Kibana is configured to use wrong Elasticsearch URL

B. Elasticsearch service port is set to 8080 instead of 9200

C. All of the above

D. Fluentd DaemonSet is not running on nodes

Solution

1. Step 1: Check Fluentd status

   If Fluentd pods are not running, logs won't be collected or sent.

2. Step 2: Verify Elasticsearch connectivity

   Wrong port on Elasticsearch service means Fluentd can't send logs properly.

3. Step 3: Confirm Kibana configuration

   If Kibana points to wrong Elasticsearch URL, it can't display logs.

4. Final Answer:

   All of the above -> Option C

5. Quick Check:

   Any broken link in EFK stops logs [OK]

Hint: Check Fluentd, Elasticsearch port, Kibana URL [OK]

Common Mistakes:

• Checking only one component
• Ignoring service port mismatch
• Assuming Kibana auto-fixes URLs

5. You want to filter out logs from Kubernetes system namespaces (like kube-system and default) before sending to Elasticsearch in Fluentd. Which configuration snippet achieves this?

hard

A. filter ** {
@type grep

key kubernetes.namespace_name
pattern ^kube-system$

}

B. filter ** {
@type record_transformer
remove_keys kubernetes.namespace_name
}

C. filter ** {
@type grep

key kubernetes.namespace_name
pattern ^kube-system$

}

D. filter ** {
@type grep

key kubernetes.namespace_name
pattern ^(kube-system|default)$

}

Solution

1. Step 1: Understand filtering with Fluentd grep plugin

   The grep plugin can exclude logs matching certain patterns using blocks.

2. Step 2: Identify namespaces to exclude

   We want to exclude system namespaces like kube-system and default, so pattern must match both.

3. Step 3: Compare options

   filter ** {
     @type grep
     
       key kubernetes.namespace_name
       pattern ^(kube-system|default)$
     
   }

   excludes both kube-system and default namespaces correctly; others exclude only one or do wrong action.

4. Final Answer:

   filter ** { @type grep key kubernetes.namespace_name pattern ^(kube-system|default)$ } -> Option D

5. Quick Check:

   Exclude system namespaces with grep exclude pattern [OK]

Hint: Use grep exclude with regex for system namespaces [OK]

Common Mistakes:

• Excluding only one namespace
• Using include instead of exclude
• Removing keys instead of filtering logs