ELK Stack for Microservices: Centralized Logging Made Simple

Muhammed Rishad Karappa

3 min read

·

Sep 14, 2026

--

Listen

Share

When I started working with microservices, one problem became obvious:

Debugging was getting harder.

In a monolithic application, logs are usually in one place. But in a microservices architecture, a single request can pass through multiple services:

Client
  ↓
API Gateway
  ↓
Auth Service
  ↓
Work Service
  ↓
Payment Service
  ↓
Notification Service

If something fails, checking every service separately can quickly become difficult.

This is where the ELK Stack becomes useful.

What is ELK Stack?

ELK stands for:

• Elasticsearch — stores and searches logs
• Logstash — collects and processes logs
• Kibana — visualizes and analyzes logs

The basic flow is:

Microservices
     ↓
  Logstash
     ↓
Elasticsearch
     ↓
   Kibana

Instead of checking logs from every service individually, we can search all of them from one place.

How I Used ELK in WorkBee

In my WorkBee project, I built a microservices-based local work marketplace.

The system contains services such as:

API Gateway
     │
     ├── Auth Service
     ├── Work Service
     ├── Communication Service
     ├── Notification Service
     └── Payment Service

Each service produces its own logs.

I configured Logstash, Elasticsearch, and Kibana to centralize these logs.

For example, a structured log might look like:

{
  "service": "payment-service",
  "level": "error",
  "event": "payment_failed",
  "workId": "123",
  "paymentId": "456"
}

Now I can search by:

service
level
event
workId
paymentId

This is much easier than manually searching through Docker logs.

Why Structured Logging Matters

A simple log like:

Payment failed

doesn’t give us much context.

A structured log gives us useful information:

{
  "service": "payment-service",
  "event": "payment_failed",
  "workId": "123",
  "paymentId": "456"
}

This makes debugging and filtering much easier.

It is especially useful in microservices because we need to understand which service performed what action and when.

Debugging with Centralized Logs

Imagine a work creation request goes through several services:

Gateway
   ↓
Auth
   ↓
Work
   ↓
Notification

If the notification doesn’t arrive, instead of checking each container manually, I can search using the workId.

I might see:

Gateway - Request received
Auth - User authenticated
Work - Work created
Notification - Event received
Notification - Email provider failed

Now I can quickly identify where the problem happened.

That’s one of the biggest benefits of centralized logging.

What I Learned

Working with ELK in a microservices project taught me a few important things:

1. Centralized logs save debugging time

As the number of services increases, manually checking individual logs becomes difficult.

2. Logs should contain context

Include useful information such as:

service
event
userId
workId
paymentId
timestamp

3. Never log sensitive information

Avoid putting passwords, OTPs, JWT tokens, or payment information into logs.

4. Observability should be part of system design

Logging isn’t something that should only be added after an application starts having problems.

For distributed systems, good logging should be considered from the beginning.

Final Thoughts

Building WorkBee helped me understand that microservices are not only about splitting an application into multiple services.

We also need to think about how we monitor, debug, and understand those services.

ELK provides a practical way to bring distributed logs into one place:

Logstash → Elasticsearch → Kibana

For me, the biggest takeaway is:

A distributed system without good observability can become very difficult to understand.

That’s why centralized logging is an important part of building reliable microservices.