DEV Community: Ashadul Mridha

Why Your Application Needs Observability: Building a Self-Hosted Observability Pipeline with the LGTM Stack (Loki, Grafana, Tempo, Mimir)

Ashadul Mridha — Fri, 10 Jul 2026 12:53:37 +0000

Understanding Observability with the LGTM Stack

From "what happened last night?" to "here's exactly what happened and why" — in under 5 minutes

Introduction
What Is Observability?
The Three Pillars of Observability
- Metrics
- Logs
- Traces
Why You Need All Three Together
The LGTM Stack
Architecture: How It All Fits Together
OpenTelemetry: The Instrumentation Standard
The OTel Collector: The Brain of the Pipeline
Loki: Log Aggregation
Tempo: Distributed Tracing
Mimir: Metrics at Scale
Grafana: Connecting the Dots
Conclusion

Introduction

Let me tell you a story that probably sounds familiar.

It's 2 AM on a Sunday. Your API is slow. Users are complaining. But you're not at your desk — you're in a Sleeping, or just living your life. You have no idea it's even happening.

The next morning you walk into the office and your boss meets you at the door.

"Hey, the API was really slow yesterday around 2 AM. What happened?"

And you're stuck. Completely stuck. You pull up the server logs — it's a wall of unformatted text. Maybe the issue already fixed itself. Maybe the container restarted overnight and the logs are gone. You weren't there, and your system left no trail.

So you say the thing every developer dreads saying: "I don't know. I'll look into it."

Now imagine the exact same situation — but this time you have observability set up.

You open your dashboard, set the time range to yesterday 2 AM, and within two minutes you can see everything. Response times spiked to 4 seconds. The database connection pool got exhausted. And it started the exact moment a scheduled batch job kicked off and hammered the DB with hundreds of queries at once.

You have a graph. You have traces. You have the exact log line that caused it.

You walk back to your boss with your laptop: "Here's what happened and here's the fix."

That's observability. Your system tells its own story — even when you're not watching.

That's what this blog is about. I'll walk you through what observability actually means, the three types of data that make it work, and the LGTM stack — an open-source toolset that brings it all together beautifully.

No prior knowledge needed. Let's start from zero.

What Is Observability?

At its core, observability is the ability to understand what's happening inside your system just by looking at what it's putting out — without having to poke around, add new code, or redeploy anything.

The word comes from control engineering. A system is "observable" if you can figure out its internal state purely from its outputs. Applied to software, the question is:

Based on what my system is emitting right now — its logs, its metrics, its traces — can I answer any question about what it's doing?

If yes, your system is observable. If you're flying blind, it's not.

Observability Is Not the Same as Monitoring

People use these words interchangeably, but they mean different things.

Monitoring is about watching for things you already know could go wrong. You set a threshold — "alert me if error rate goes above 5%" — and you wait. It's reactive. It only catches known problems.

Observability is about being able to investigate anything, including things you never anticipated. It's not just "is something broken?" — it's "what broke, why, when, and who was affected?"

	Monitoring	Observability
Question it answers	"Is it working?"	"Why is it broken?"
Approach	Pre-defined alerts and dashboards	Open-ended investigation
Good for	Known failure modes	Unknown, unexpected problems
Limitation	Can't help with surprises	Requires instrumentation upfront

Think of it this way: monitoring is a smoke alarm. Observability is having a camera, floor plan, and fire inspector — so you can figure out exactly where the fire started and why.

You need both. But monitoring alone will leave you helpless when something you didn't expect goes wrong. And in production, the unexpected is the norm.

When Does Observability Really Matter?

Short answer: as soon as your system is more complex than a single script running on one machine.

But let's be honest — if you have a personal project with 10 users, basic console.log probably works fine. The pain hits when the system grows. Here's how to recognize the tipping point:

Scenario 1: A user reports "the checkout is broken"
You check your logs. You see the request hit your API. No error. But the order never went through. Where did it break? The payment service? The inventory check? The email queue? Without observability, you're grep-ing through logs across 4 services, hoping to piece together what happened. With observability, you pull up one trace and see the full picture in seconds.

Scenario 2: A background job fails silently at 3 AM
No alert fires. No user complains immediately. Hours later you notice thousands of emails weren't sent. You have no idea when it broke, which jobs were affected, or what the error was — because the container restarted and took the logs with it. Observability would have caught the spike in job failures the moment it started.

Scenario 3: Your API looks healthy, but users are angry
Average response time: 120ms. P99 response time: 8 seconds. Your averages are lying to you. A small percentage of users are hitting a slow database query, but it's buried in the noise. Metrics with proper histograms surface this immediately.

Here's a quick rule of thumb:

If your system has...	You need...
1 service, <100 users	Basic logging is fine
Multiple services	Distributed tracing
Background workers / queues	Metrics + alerting
Containers (Docker/K8s)	Centralized log aggregation
External APIs / third parties	Error rate tracking
Any paying users	All of the above

The bottom line: observability isn't about being fancy. It's about being able to answer "what is broken, where, and why" without waking up four engineers at 2 AM to find out.

The Three Pillars of Observability

There are three types of data that together give you a complete picture of your system. Each one answers a different kind of question. Miss any one of them and you'll have blind spots.

┌──────────────────────────────────────────────────────┐
│                   OBSERVABILITY                      │
│                                                      │
│   ┌──────────┐    ┌──────────┐    ┌──────────────┐  │
│   │ METRICS  │    │  LOGS    │    │   TRACES     │  │
│   │          │    │          │    │              │  │
│   │ "What?"  │    │  "What   │    │ "Where and   │  │
│   │          │    │happened?"│    │   when?"     │  │
│   └──────────┘    └──────────┘    └──────────────┘  │
└──────────────────────────────────────────────────────┘

1. Metrics

Metrics are numbers that your system continuously measures and records over time. Things like:

How many requests per second is my API handling right now?
What's the 95th percentile response time over the last hour?
How many payment failures happened in the last 5 minutes?

Think of metrics like the dashboard in your car — you glance at it and immediately know your speed, fuel level, and engine temperature without having to pop the hood. Metrics are cheap to store, fast to query, and perfect for alerts.

Types of Metrics

Type	What it is	Example
Counter	A number that only goes up	Total requests, total errors
Histogram	Distribution of values across ranges	Response times, order amounts
Gauge	A snapshot value that can go up or down	Active DB connections, memory usage
UpDownCounter	Like a counter but can decrease too	Active background jobs in the queue

The RED Method — A Simple Starting Point

If you don't know where to start with metrics, use RED. It stands for three things every HTTP service should track:

Rate — how many requests per second?
Errors — what percentage of requests are failing?
Duration — how long are requests taking?

Track these per endpoint and over time, and you've got a solid foundation. You'll immediately see when something starts degrading — even before users start complaining.

Don't Stop at Infrastructure Metrics

CPU usage and memory matter, but they don't tell the whole story. Business metrics are often more useful:

Infrastructure:  http_request_duration_p99 > 2s    ← okay, something's slow
Business:        payments_failed_total + 340        ← 340 payments are failing!

The infrastructure metric tells you there's a problem. The business metric tells you how bad it actually is. Add both.

Checking CPU and RAM Right Now

Here's what actually checking infrastructure health looks like in practice. These PromQL queries run in Grafana against Mimir:

# CPU usage % — how much of the CPU is your process consuming right now?
rate(process_cpu_seconds_total[1m]) * 100

# Memory used in MB — how much RAM is the Node process holding?
process_resident_memory_bytes / 1024 / 1024

# Host-level memory usage % — what fraction of the server's RAM is in use?
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

The first two come from the OTel SDK automatically for any Node.js process. The third (node_memory_*) comes from the hostmetrics receiver in the OTel Collector — the one that scrapes the machine itself. Once that receiver is enabled, you get CPU, memory, disk, and network for free without writing a line of application code.

So yes: run those three queries in Grafana and you can see exactly how your CPU and RAM are doing right now.

2. Logs

Logs are text records of specific things that happened in your system, with timestamps. They answer the "what exactly happened?" questions:

What was the error message at 02:34 AM?
What was in the request body when it failed?
Did the retry succeed on the second attempt or the third?

Logs are the most familiar tool — every developer has used them. But there's a big difference between logs that are actually useful and logs that just make you feel like you're doing something.

Structured Logs vs. Plain Text Logs

Most people start with plain text logs. They look like this:

[2026-04-13 02:34:11] ERROR Payment failed for order ORD-12345

This is fine for reading manually. But at scale, when you're sifting through millions of log lines across multiple services, it's nearly useless. You can't filter by order ID. You can't group by error type. You're back to guessing.

Structured logs fix this. Instead of a sentence, you write a JSON object with consistent fields:

{
  "timestamp": "2026-04-13T02:34:11.000Z",
  "level": "error",
  "service": "payment-service",
  "correlationId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "orderId": "ORD-12345",
  "message": "Payment gateway timeout",
  "attempt": 2,
  "durationMs": 2001
}

Now you can query: show me all errors for order ORD-12345 across every service, sorted by time. One query. Done.

Correlation IDs — The Glue Between Services

Here's a problem you'll run into quickly in any multi-service system. A single user request might create 20 log entries across 4 different services. Without something connecting them, those entries look completely unrelated.

The solution is a correlation ID — a unique identifier that gets created at the very start of a request and passed along to every service and background job it touches.

User sends request → ID generated: "f47ac10b"

  auth-service     → {"correlationId": "f47ac10b", "message": "Token validated"}
  order-service    → {"correlationId": "f47ac10b", "message": "Order created"}
  payment-worker   → {"correlationId": "f47ac10b", "message": "Payment gateway timeout"}
  notification-svc → {"correlationId": "f47ac10b", "message": "Email queued"}

Now finding everything related to that one user's request is a single filter: correlationId = "f47ac10b". It's a simple idea with an enormous payoff.

3. Traces

Traces are the most powerful and also the least understood of the three pillars. Let me explain it simply.

When a user makes a request to your API, it doesn't just go to one place. It might:

Hit your API server
Query the database
Call an external payment API
Push a job to a background queue
Have a worker pick up that job and do more things

A trace records all of that as one connected picture. You can see every step, how long each one took, and exactly how they're related.

Here's what a trace actually looks like:

POST /orders  [total: 412ms]
├── validate user token        [12ms]
├── fetch product from DB      [22ms]
├── check inventory level      [47ms]
├── calculate price with tax   [8ms]
├── write order to database    [31ms]
├── push payment job to queue  [12ms]
└── push notification to queue [9ms]

Each line is called a span — a single named operation with a start time and duration. They all share the same trace ID, so you know they belong together.

Quick Glossary

Trace — the full journey of one request from start to finish
Span — one specific operation within that journey
Trace ID — a unique ID that ties all the spans together
Parent span — the operation that triggered another (e.g., the HTTP request that triggered the DB query)

The Real Power: Following a Request Across Services

Here's where traces get really valuable. When a background worker picks up the payment job later, it can continue the same trace. So the full picture looks like:

POST /orders  [412ms]
└── payment-worker: process job  [1.8s]
    ├── call payment gateway     [1.7s]  ← here's your problem
    └── update order status      [40ms]

Without traces, you'd know something was slow. With traces, you know exactly what was slow and by how much — even across async boundaries that are invisible to logs and metrics.

Why You Need All Three Together

Here's the thing: each pillar alone is useful, but none of them is enough on its own.

Metrics tell you something is wrong. They don't tell you why.

Logs tell you what happened. They don't tell you where in the call chain it started.

Traces show you the flow. They don't always show you the context and details.

When you combine all three around the same event, you get the full picture:

Step 1 — METRICS: alert fires
  "payment failure rate > 20% in the last 5 minutes"

Step 2 — TRACES: find the broken requests
  All failing orders have a payment-gateway span with status = TIMEOUT
  Duration: 2001ms — they're hitting the 2-second ceiling every time

Step 3 — LOGS: find out why
  Filter by that trace's correlationId
  "Payment gateway connection refused — attempt 3 of 3"
  "All retries exhausted. Marking order as payment_failed."

Root cause: the payment gateway API is unreachable
Impact: 47 orders failed in the last 5 minutes

Metrics caught it. Traces located it. Logs explained it. No SSH. No guessing. No "I'll have to look into it."

That's the goal.

The LGTM Stack

Now let's talk about the tools. LGTM is an open-source observability stack where each letter stands for one tool, each designed for one signal type:

Letter	Tool	What It Does	Query Language
L	Loki	Stores and searches logs	LogQL
G	Grafana	Dashboards, alerts, and visualization	—
T	Tempo	Stores and searches distributed traces	TraceQL
M	Mimir	Stores metrics (Prometheus-compatible)	PromQL

All four are open-source projects from Grafana Labs, and they're designed to talk to each other out of the box — especially inside Grafana.

On top of these four, there's one more piece that makes the whole thing work: the OpenTelemetry Collector. It sits between your application and the stack, receives all your telemetry, and routes it to the right place.

Why This Stack Over Paid Alternatives?

There are great paid observability platforms — Datadog, New Relic, Dynatrace. They're excellent. But they come with trade-offs:

Cost — at scale, these services can be surprisingly expensive
Vendor lock-in — your instrumentation is tied to their SDK
Data control — your logs and traces live on their servers

The LGTM stack gives you everything a paid platform does, completely self-hosted, with no per-seat or per-GB pricing. The trade-off is that you have to run it yourself. But with Docker Compose or Kubernetes, that's much easier than it sounds.

Architecture: How It All Fits Together

Here's the full data flow from your application all the way to the dashboards:

┌──────────────────────────────────────────────────────────────┐
│                    Your Backend Application                  │
│                                                              │
│  ┌─────────────┐  ┌────────────────┐  ┌──────────────────┐  │
│  │   Logger    │  │ Metrics Client │  │   Tracing SDK    │  │
│  │ (structured │  │  (counters,    │  │  (auto + manual  │  │
│  │    JSON)    │  │  histograms)   │  │    spans)        │  │
│  └──────┬──────┘  └───────┬────────┘  └────────┬─────────┘  │
│         └─────────────────┴────────────────────┘            │
│                           │                                  │
│              OTLP (OpenTelemetry Protocol)                   │
└───────────────────────────┼──────────────────────────────────┘
                            │
                            ▼
┌──────────────────────────────────────────────────────────────┐
│                  OpenTelemetry Collector                     │
│                                                              │
│  Receive → Process (batch, filter, enrich) → Export          │
│                                                              │
│    Logs    ────────────────────────────────► Loki            │
│    Metrics ────────────────────────────────► Mimir           │
│    Traces  ────────────────────────────────► Tempo           │
└──────────────────────────────────────────────────────────────┘
                │                  │                 │
                ▼                  ▼                 ▼
          ┌──────────┐      ┌──────────┐      ┌──────────┐
          │   Loki   │      │  Mimir   │      │  Tempo   │
          │  (Logs)  │      │(Metrics) │      │ (Traces) │
          │  LogQL   │      │  PromQL  │      │ TraceQL  │
          └────┬─────┘      └────┬─────┘      └────┬─────┘
               └────────────────┼─────────────────┘
                                │
                                ▼
               ┌─────────────────────────────┐
               │           Grafana            │
               │                             │
               │  Dashboards · Alerts        │
               │  Trace Explorer             │
               │  Log Explorer               │
               │  Cross-signal correlation   │
               └─────────────────────────────┘

The core idea here is your application only talks to one place — the Collector. It doesn't need to know about Loki, Mimir, or Tempo. The Collector handles the routing.

OpenTelemetry: The Instrumentation Standard

Before getting into each LGTM component, there's one thing worth understanding first: OpenTelemetry.

OpenTelemetry (OTel for short) is an open-source framework that gives you a standard, vendor-neutral way to instrument your application. It was created by merging two earlier projects (OpenCensus and OpenTracing) and is now backed by the CNCF with adoption across pretty much every major company and cloud provider.

What does it actually give you?

APIs — standard interfaces for emitting logs, metrics, and traces from your code
SDKs — implementations for Node.js, Python, Java, Go, .NET, Ruby, and more
Auto-instrumentation — it can automatically patch popular libraries with zero code changes
OTLP — a standard wire protocol for sending telemetry data to any backend

Instrument once, change backends freely. Your instrumentation is permanent. Your backend is swappable.

Auto-Instrumentation Is a Game Changer

One of my favourite things about OTel is auto-instrumentation. For most popular frameworks and libraries, OTel can automatically create spans and collect metrics without you writing a single line of tracing code:

Library	What you get automatically
HTTP server	Span for every incoming request, status code, duration
HTTP client	Span for every outgoing request with URL and status
PostgreSQL / MySQL	Span for every query with the SQL statement
Redis	Span for every command
Express / NestJS / FastAPI	Route handler spans, middleware spans
BullMQ / Kafka	Job processing spans

For a typical backend, auto-instrumentation alone covers about 80% of what you need. You only add manual spans for the business logic that the framework can't see on its own.

The OTel Collector: The Brain of the Pipeline

The OpenTelemetry Collector is a standalone service that receives all the telemetry from your application and routes it to the right storage backend.

Your App  ──OTLP──►  OTel Collector  ──────►  Loki / Tempo / Mimir

Why Not Just Send Directly to Each Backend?

You could skip the Collector and have your app send logs directly to Loki, traces directly to Tempo, and metrics directly to Mimir. It would work. But you'd lose a lot.

With the Collector in the middle:

Your app has one endpoint to worry about — the Collector handles the rest
You can batch data before sending, which is much more efficient
You can filter, sample, or transform data in one place without touching your app
You can add backends, remove backends, or change routing without redeploying your service

It's a small operational overhead that pays for itself quickly.

How the Collector Is Configured: Receivers → Processors → Exporters

The Collector works as a pipeline in three stages:

Receivers          Processors         Exporters
─────────          ──────────         ─────────
OTLP (gRPC)  ──►  Batch        ──►  Loki    (logs)
OTLP (HTTP)  ──►  Filter       ──►  Tempo   (traces)
Host Metrics ──►  Attributes   ──►  Mimir   (metrics)

Receivers are how data gets in. The otlp receiver accepts data from your app over gRPC or HTTP. There's also a hostmetrics receiver that automatically scrapes CPU, memory, disk, and network stats from the host machine — you get infrastructure metrics without writing a single line of application code.

Processors sit in the middle and can transform data before it goes out. The most common is batch, which groups records together for efficient transmission. You can also add processors to sample traces (so you don't store every single one), redact sensitive fields like passwords, or enrich data with extra metadata.

Exporters are how data gets out. Each backend has its own exporter configured with the right protocol — logs to Loki, metrics to Mimir, traces to Tempo.

Loki: Log Aggregation

Loki is where your logs live. It's built by Grafana Labs with one guiding philosophy: index labels, not log content.

What Makes Loki Different

If you've used Elasticsearch before, you're used to the idea that every word in every log line gets indexed. This makes searches very fast but also makes storage very expensive at scale. Indexing millions of log lines burns a lot of disk and RAM.

Loki takes a fundamentally different approach:

It only indexes labels — a small set of key-value pairs like service=payment-service, level=error
The actual log content is stored compressed and unindexed
When you query by content, Loki scans only the compressed chunks that match your labels

The result? Loki is dramatically cheaper to operate than Elasticsearch, while still being fast enough for the most common queries you'll actually run.

LogQL — Loki's Query Language

LogQL lets you filter logs by labels and content. For example, to find all error logs for a specific order:

{service="payment-service"} | json | orderId="ORD-12345"

One Thing to Get Right: Label Cardinality

Good labels are low cardinality — service, level, environment. Never use user_id or request_id as labels. High-cardinality labels blow up Loki's index and kill performance. If you need to search by something unique like a correlation ID, put it in the log body — not as a label.

Tempo: Distributed Tracing

Tempo is where your traces live. It's purpose-built for storing and querying distributed traces at high volume.

How Tempo Stores Traces

Tempo is optimized for ingestion — it can take in a huge volume of spans without slowing down. Traces are stored as compressed blocks on disk. You can configure retention to control how long they're kept.

Finding a Trace

The simplest way: paste a trace ID. When your app includes the trace ID in its response headers (which OTel does by default), you grab it, open Tempo in Grafana, and paste it in. You instantly see the full trace — every span, every timing, every attribute.

TraceQL — Searching Traces Like a Pro

What if you don't have a specific trace ID? TraceQL lets you search by the shape and attributes of traces:

# Find traces where the payment service had an error
{ span.service.name = "payment-service" && status = error }

This is incredibly useful for finding the outliers — the slow requests, the error-producing requests — without knowing their trace IDs in advance.

Bonus: Automatic Metrics from Traces

Tempo has a built-in metrics generator that reads your trace data and automatically derives RED metrics (rate, error rate, duration) and writes them to Mimir. This means you get latency percentile graphs and error rates for free, derived directly from real trace data.

It also generates a service graph — a visual map of which services talk to which, built automatically from your spans. This is fantastic for understanding how your system is actually wired together, especially in larger architectures.

Mimir: Metrics at Scale

Mimir is where your metrics live. It's a Prometheus-compatible metrics backend that's built to scale horizontally.

Isn't Prometheus Enough?

Prometheus is great for getting started, and a lot of teams run it happily in production. But it has some real limitations as you grow:

All storage is local — if the machine dies, your metrics history might go with it
Long-term retention gets expensive because Prometheus keeps everything in memory-mapped files
High-cardinality metrics (lots of unique label combinations) can push Prometheus to its memory limits

Mimir solves all of these with a distributed architecture. The best part? It's 100% PromQL compatible. Every query you've written for Prometheus works unchanged in Mimir. Every Grafana dashboard you've built works without modification.

PromQL — Querying Metrics

PromQL is the query language for Prometheus-compatible metrics. Once you understand the rate() pattern, most of what you need falls naturally into place:

# 95th percentile response time
histogram_quantile(0.95, sum by (le) (rate(http_server_request_duration_bucket[5m])))

For infrastructure, the hostmetrics receiver in the OTel Collector automatically scrapes CPU, memory, disk, and network from the host — no application code needed:

# Host-level memory usage %
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

Grafana: Connecting the Dots

Grafana is the front door to everything. It connects to Loki, Tempo, and Mimir as datasources and gives you one unified place to explore, visualize, and alert on all of your observability data.

But Grafana is more than just a dashboard tool. The feature that really sets it apart is cross-signal correlation — the ability to jump between signals with a single click.

How Cross-Signal Correlation Works

When you configure Grafana's datasources properly, it links everything together:

A log entry that contains a traceId gets a clickable button → click it, jump straight to that trace in Tempo
A trace in Tempo has a "Logs" button → click it, Loki opens pre-filtered to that trace's time window and service
Tempo's trace view can also show derived metrics from Mimir alongside the timeline

This sounds small. It's not. It means you can start your investigation anywhere — a metric alert, a slow trace, a single error log — and navigate to the full picture in three clicks.

What a Real Investigation Looks Like in Grafana

Let me walk through the boss scenario from the beginning — but now with Grafana:

You arrive at work. Boss says: "API was slow yesterday at 2 PM."

Step 1 — Open Grafana, set time range to yesterday 2 PM - 3 PM
  → Metrics dashboard shows: response time spike to 4.2s starting at 14:07
  → Error rate: 0% — so nothing crashed, just slow

Step 2 — Switch to Traces, filter by time range, sort by duration
  → Top slow traces: all on GET /products
  → Open one — the DB query span is 3.8s out of 4.2s total

Step 3 — Click "Logs" on that trace
  → Loki opens, filtered to that trace's correlationId
  → "Slow query detected: 3821ms — SELECT * FROM products WHERE..."
  → "Auto-vacuum running on products table"

Root cause: PostgreSQL auto-vacuum ran during peak hours and locked the table.
Fix: Schedule auto-vacuum for off-peak hours.

You have graphs, traces, and logs. You have a root cause. You have a fix. Your boss is happy.

No SSH. No grepping. No guessing.

Conclusion

Let me come back to where we started.

You walk into the office. Your boss asks what happened at 2 PM yesterday. Before, you had nothing. Now, you open Grafana, spend two minutes clicking through metrics → traces → logs, and you hand your boss a complete picture with a root cause and a fix.

That's the real value of observability. It's not about fancy tools or complex architectures. It's about making sure your system leaves a trail — so that when something goes wrong (and something always goes wrong), you can figure out what happened without being there when it happened.

The LGTM stack gives you everything you need to build that:

Loki stores your logs efficiently and makes them searchable
Grafana brings everything together in one UI with built-in signal correlation
Tempo captures complete traces across every service and async worker
Mimir stores your metrics at any scale with full Prometheus compatibility
OpenTelemetry provides vendor-neutral instrumentation — instrument once, stay flexible forever

And here's the thing: you don't have to build all of this at once.

Start with structured logs. Add JSON formatting and a correlation ID to your requests. That alone will make debugging dramatically easier.

Then add metrics. Track the RED method — rate, errors, duration — for your most important endpoints. Set up an alert.

Then add tracing. Once you have logs and metrics, traces fill in the last gaps — showing you exactly what path each request took.

Each step builds on the last. Each step makes your system a little less of a black box. And once you've traced your first real production bug from alert to root cause in under 5 minutes, I promise you'll never want to go back to grepping log files at 2 AM.

Stack versions: Loki 3.4.2 · Grafana 11.6.0 · Tempo 2.6.1 · Mimir 2.14.0 · OpenTelemetry Collector 0.120.0 · OpenTelemetry SDK 0.213.0

Claude Code: সম্পূর্ণ বাংলা গাইড

Ashadul Mridha — Fri, 16 Jan 2026 18:13:43 +0000

Terminal খুলে natural language-এ instruction দিলেই যদি আপনার project setup হয়ে যায়, test run হয়, deployment ready হয় - এমন experience চাইলে Claude Code একবার দেখতে পারেন।

Claude Code নিয়ে অনেকেই শুনেছেন, কিন্তু Agents, Skills, Hooks, Slash Command কী, Plugins আর MCP আসলে কীভাবে কাজ করে - এই basic জিনিসগুলো পরিষ্কার না থাকলে এটার আসল power বোঝা মুশকিল।

এই পোস্টে Claude Code-এর core concepts গুলো simple ভাবে explain করব - যেন আপনি বুঝতে পারেন এটা দিয়ে আসলে কী কী করা সম্ভব, আর কীভাবে এটা আপনার কাজে লাগাতে পারবেন।

[Agents]
[Skills]
[Hooks]
[Slash Commands]
[Plugins]
[File Structure]
[Quick Reference]

Agents

Agents কী?

Agents বলতে মূলত Claude-এর এমন কিছু সহকারীকে বোঝায়, যাদের প্রত্যেকটা নির্দিষ্ট একটা কাজের জন্য ব্যবহার করা হয়। বড় কোনো প্রজেক্ট একা একটানা সামলানো অনেক সময় কঠিন হয়ে যায়। তাই প্রজেক্টকে ছোট ছোট অংশে ভাগ করে নেওয়া হয়, আর সেই অংশগুলো আলাদা আলাদা Agent দেখাশোনা করে।

সুবিধা:

কাজগুলো আরও গুছিয়ে করা যায়
একসাথে একাধিক কাজ এগোয়
ভুল কম হয় এবং output quality ভালো হয়

বাস্তব উদাহরণ

ধরুন আপনি একটা Full Stack ইকমার্সের অ্যাপ্লিকেশন বানাচ্ছেন। এখানে আপনি বিভিন্ন agent তৈরি করতে পারেন:

Frontend Development এর জন্য:

# .claude/agents/frontend-agent.md

You are a frontend development specialist focused on React and modern UI/UX.

## Your Responsibilities
- Build responsive React components
- Implement state management
- Ensure accessibility standards
- Optimize performance

## Technologies
- React 18+
- Tailwind CSS
- React Query
- TypeScript

Backend Development এর জন্য:

# .claude/agents/backend-agent.md

You are a backend development expert specializing in Node.js and Express.

## Your Responsibilities
- Design RESTful APIs
- Database schema design
- Authentication & Authorization
- Error handling and logging

## Technologies
- Node.js
- Express.js
- PostgreSQL
- JWT Authentication

API Design এর জন্য:

# .claude/agents/api-designer-agent.md

You are an API design specialist.

## Your Responsibilities
- Design RESTful endpoints
- Define request/response structures
- Plan versioning strategy
- Document API specifications

## Guidelines
- Follow REST principles
- Use proper HTTP methods
- Implement pagination
- Version APIs properly

Code Review এর জন্য:

# .claude/agents/code-reviewer-agent.md

You are a code quality expert.

## Your Responsibilities
- Review code for best practices
- Check for security vulnerabilities
- Ensure consistent coding style
- Suggest optimizations

## Focus Areas
- Code readability
- Performance issues
- Security concerns
- Test coverage

Agents কীভাবে কাজ করে?

Claude Code দুইভাবে agents ব্যবহার করে:

Automatic Mode: Claude অটোমেটিক বুঝে নেয় কোন agent দরকার
Manual Mode: আপনি @agent-name দিয়ে সরাসরি একটা নির্দিষ্ট agent কে কল করতে পারেন

উদাহরণ:

আপনি: @frontend-agent Create a user profile component
আপনি: @backend-agent Design an API for user authentication

Skills

Skills কী?

Skills হলো Claude-এর জন্য best practices, domain-specific knowledge, এবং structured workflows। এটা agents-দের কাজ করার জন্য একটা নির্দেশিকা বা গাইডবুক হিসেবে কাজ করে। কাজের প্রয়োজন অনুসারে Claude অটোমেটিক এই skills পড়ে এবং apply করে।

Skills vs Agents এর পার্থক্য

সহজ ভাষায়:

Agents = কাজ করার জন্য বিশেষায়িত সহকারী
Skills = সেই সহকারীকে কীভাবে কাজ করতে হবে তার জন্য knowledge বা guideline দেয়।

একটা উদাহরণ দিলে ব্যাপারটা আরও পরিষ্কার হবে:

backend-agent হলো রাঁধুনি (যে রান্না করবে)
rest-api-best-practices skill হলো রেসিপি বই (যেখানে লেখা আছে কীভাবে রান্না করতে হবে)

বাস্তব উদাহরণ

REST API Design Skill:

# .claude/skills/rest-api-best-practices.md

# REST API Design Guidelines

## URL Structure
- Use nouns, not verbs: `/users` not `/getUsers`
- Use plural form: `/products` not `/product`
- Nested resources: `/users/{id}/orders`
- Keep URLs simple and intuitive

## HTTP Methods
- **GET**: Retrieve data (no side effects)
- **POST**: Create new resource
- **PUT**: Update entire resource
- **PATCH**: Partial update
- **DELETE**: Remove resource

## Response Status Codes
- **200 OK**: Successful GET, PUT, PATCH
- **201 Created**: Successful POST
- **204 No Content**: Successful DELETE
- **400 Bad Request**: Invalid input
- **401 Unauthorized**: Authentication required
- **403 Forbidden**: No permission
- **404 Not Found**: Resource doesn't exist
- **500 Internal Server Error**: Server error

## Response Structure
Always return consistent JSON:

{
  "success": true,
  "data": {...},
  "message": "Operation successful",
  "timestamp": "2024-01-15T10:30:00Z"
}

## Pagination

{
  "data": [...],
  "pagination": {
    "page": 1,
    "limit": 20,
    "total": 100,
    "totalPages": 5
  }
}

Database Schema Design Skill:

# .claude/skills/database-design.md

# Database Design Principles

## Naming Conventions
- **Tables**: plural, snake_case (e.g., `user_profiles`, `order_items`)
- **Columns**: snake_case (e.g., `first_name`, `created_at`)
- **Primary Key**: Always use `id`
- **Foreign Key**: `{table}_id` (e.g., `user_id`, `product_id`)
- **Junction Tables**: `{table1}_{table2}` (e.g., `users_roles`)

## Data Types Best Practices
- **IDs**: BIGINT UNSIGNED AUTO_INCREMENT
- **Strings**: VARCHAR(255) for short text, TEXT for long content
- **Dates**: TIMESTAMP (includes timezone)
- **Money**: DECIMAL(10, 2)
- **Boolean**: TINYINT(1) or BOOLEAN

## Essential Columns
Every table should have:

id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

## Indexing Rules
- Always index foreign keys
- Index columns used in WHERE, JOIN, ORDER BY
- Composite index for multi-column queries
- Don't over-index (slows down INSERT/UPDATE)

## Relationships
- **One-to-Many**: Foreign key in the "many" table
- **Many-to-Many**: Use junction table
- **One-to-One**: Foreign key with UNIQUE constraint

Security Best Practices Skill:

# .claude/skills/security-guidelines.md

# Security Best Practices

## Authentication
- Use bcrypt for password hashing (min 10 rounds)
- Implement JWT with short expiry (15-30 minutes)
- Use refresh tokens for long sessions
- Enable rate limiting on login endpoints

## Data Validation
- Always validate user input
- Sanitize data before database queries
- Use parameterized queries (prevent SQL injection)
- Validate file uploads (type, size, content)

## API Security
- Always use HTTPS in production
- Implement CORS properly
- Use API keys for service-to-service communication
- Rate limit all endpoints

## Sensitive Data
- Never log passwords or tokens
- Encrypt sensitive data at rest
- Use environment variables for secrets
- Never commit .env files to git

Agent কীভাবে Skills ব্যবহার করে

# .claude/agents/backend-agent.md

You are a backend development specialist.

## Skills to Apply
When working, always reference and follow these skills:
- rest-api-best-practices
- database-design
- security-guidelines

## Instructions
1. Before designing any API, review REST API best practices
2. For database work, follow the database design skill
3. Always check security guidelines before implementing auth

এভাবে agent-রা skills থেকে knowledge নিয়ে আরও ভালোভাবে কাজ করতে পারে।

Hooks - Lifecycle Automation

Hooks কী?

Hooks হলো custom bash script যেগুলো Claude Code-এর নির্দিষ্ট lifecycle event-এ অটোমেটিক trigger হয়। এর মাধ্যমে আপনি repetitive কাজগুলো অটোমেট করে ফেলতে পারেন।

Available Lifecycle Events

Claude Code এর মূল কয়েকটি event:

sessionStart - যখন Claude Code session শুরু হয়
sessionEnd - যখন session শেষ হয়
stop - যখন Claude response দেওয়া বন্ধ করে
beforeCommand - কোনো command execute হওয়ার আগে
afterCommand - কোনো command execute হওয়ার পরে

বাস্তব উদাহরণ

Example 1: Auto Code Formatting (stop event)

কোড লেখার পর ম্যানুয়ালি ফরম্যাট করা বিরক্তিকর। এই hook দিয়ে Claude যখনই code লেখা শেষ করবে, automatically prettier run হবে:

# .claude/hooks/format-on-stop.sh
#!/bin/bash

echo "Formatting code..."

# Format JavaScript/TypeScript files
npx prettier --write "src/**/*.{js,jsx,ts,tsx,json,css,md}"

# Format Python files
black src/

echo "✓ Code formatting complete!"

Example 2: Auto Git Commit (sessionEnd event)

Session শেষে automatically changes commit করুন:

# .claude/hooks/auto-commit.sh
#!/bin/bash

# Check if there are any changes
if [[ -n $(git status -s) ]]; then
    echo "Auto-committing changes..."

    # Add all changes
    git add .

    # Create commit with timestamp
    timestamp=$(date "+%Y-%m-%d %H:%M:%S")
    git commit -m "Auto-commit: Claude Code session ended at $timestamp"

    echo "✓ Changes committed successfully!"
else
    echo "No changes to commit"
fi

Example 3: Test Runner (afterCommand event)

কোড লেখার পর automatically tests run করুন:

# .claude/hooks/run-tests.sh
#!/bin/bash

echo "Running tests..."

# Run Jest tests
if [ -f "package.json" ] && grep -q "jest" package.json; then
    npm test -- --passWithNoTests
fi

# Run pytest
if [ -f "pytest.ini" ] || [ -d "tests" ]; then
    pytest -v
fi

echo "✓ Tests complete!"

Hooks Setup করা

.claude/hooks/ folder তৈরি করুন
Bash script লিখুন (.sh extension সহ)
Script-কে executable করুন:

chmod +x .claude/hooks/format-on-stop.sh

Slash Commands - দ্রুত কাজের Shortcut

Slash Commands কী?

Slash commands হলো repetitive কাজ দ্রুত করার শর্টকাট। একবার define করে ফেললে বারবার একই instruction দিতে হয় না। শুধু / টাইপ করলেই সব available commands দেখা যায়।

কখন Slash Commands ব্যবহার করবেন?

যখন একই ধরনের code বারবার লিখতে হয়
যখন একটা নির্দিষ্ট pattern follow করতে হয়
যখন boilerplate code তৈরি করতে হয়
যখন complex workflow একটা command-এ execute করতে চান

বাস্তব উদাহরণ

Example 1: React Component Generator

# .claude/commands/create-component.md

# Create React Component

Generate a complete React component with the following structure:

## Files to Create

1. **Component File**: `src/components/{ComponentName}/{ComponentName}.jsx`
2. **Styles**: `src/components/{ComponentName}/{ComponentName}.module.css`
3. **Test File**: `src/components/{ComponentName}/__tests__/{ComponentName}.test.jsx`
4. **Storybook**: `src/components/{ComponentName}/{ComponentName}.stories.jsx`

## Component Template

import React from 'react';
import PropTypes from 'prop-types';
import styles from './{ComponentName}.module.css';

/**
 * {ComponentName} component description
 */
const {ComponentName} = ({ title, children, className = '' }) => {
  return (
    <div className={`${styles.container} ${className}`}>
      <h2 className={styles.title}>{title}</h2>
      <div className={styles.content}>{children}</div>
    </div>
  );
};

{ComponentName}.propTypes = {
  title: PropTypes.string.isRequired,
  children: PropTypes.node,
  className: PropTypes.string,
};

export default {ComponentName};

## CSS Template

.container {
  padding: 1rem;
  border-radius: 8px;
  background-color: #ffffff;
}

.title {
  font-size: 1.5rem;
  font-weight: 600;
  margin-bottom: 0.5rem;
}

.content {
  font-size: 1rem;
  color: #333333;
}

## Test Template

import { render, screen } from '@testing-library/react';
import {ComponentName} from '../{ComponentName}';

describe('{ComponentName}', () => {
  it('renders correctly', () => {
    render(<{ComponentName} title="Test Title">Test Content</{ComponentName}>);
    expect(screen.getByText('Test Title')).toBeInTheDocument();
  });
});

## Prompt
Ask the user for the component name and create all files accordingly.

ব্যবহার:

/create-component Button
/create-component UserProfile

Example 2: Express API Endpoint Creator

# .claude/commands/create-api-endpoint.md

# Create Express API Endpoint

Generate a complete API endpoint with the following structure:

## Files to Create

1. **Route**: `src/routes/{resource}.routes.js`
2. **Controller**: `src/controllers/{resource}.controller.js`
3. **Validation**: `src/middlewares/{resource}.validation.js`
4. **Test**: `src/tests/{resource}.test.js`

## Route Template

const express = require('express');
const router = express.Router();
const {resourceCamelCase}Controller = require('../controllers/{resource}.controller');
const validate = require('../middlewares/{resource}.validation');

// GET all
router.get('/', {resourceCamelCase}Controller.getAll);

// GET by ID
router.get('/:id', {resourceCamelCase}Controller.getById);

// POST create
router.post('/', validate.create, {resourceCamelCase}Controller.create);

// PUT update
router.put('/:id', validate.update, {resourceCamelCase}Controller.update);

// DELETE
router.delete('/:id', {resourceCamelCase}Controller.delete);

module.exports = router;

## Controller Template

const asyncHandler = require('../utils/asyncHandler');
const ApiResponse = require('../utils/ApiResponse');
const ApiError = require('../utils/ApiError');

// @desc    Get all {resources}
// @route   GET /api/{resources}
// @access  Public
exports.getAll = asyncHandler(async (req, res) => {
  // Implementation here
  res.status(200).json(new ApiResponse(200, [], 'Retrieved successfully'));
});

// @desc    Get {resource} by ID
// @route   GET /api/{resources}/:id
// @access  Public
exports.getById = asyncHandler(async (req, res) => {
  const { id } = req.params;
  // Implementation here
  res.status(200).json(new ApiResponse(200, {}, 'Retrieved successfully'));
});

// @desc    Create new {resource}
// @route   POST /api/{resources}
// @access  Private
exports.create = asyncHandler(async (req, res) => {
  // Implementation here
  res.status(201).json(new ApiResponse(201, {}, 'Created successfully'));
});

// @desc    Update {resource}
// @route   PUT /api/{resources}/:id
// @access  Private
exports.update = asyncHandler(async (req, res) => {
  const { id } = req.params;
  // Implementation here
  res.status(200).json(new ApiResponse(200, {}, 'Updated successfully'));
});

// @desc    Delete {resource}
// @route   DELETE /api/{resources}/:id
// @access  Private
exports.delete = asyncHandler(async (req, res) => {
  const { id } = req.params;
  // Implementation here
  res.status(200).json(new ApiResponse(200, null, 'Deleted successfully'));
});

## Validation Template

const { body, param } = require('express-validator');
const validate = require('../middlewares/validate');

exports.create = validate([
  body('name').notEmpty().withMessage('Name is required'),
  // Add more validations
]);

exports.update = validate([
  param('id').isInt().withMessage('Invalid ID'),
  body('name').optional().notEmpty(),
  // Add more validations
]);

## Prompt
Ask for:
1. Resource name (singular, e.g., "user", "product")
2. Fields for validation
3. Authentication requirements

ব্যবহার:

/create-api-endpoint user
/create-api-endpoint product

ব্যবহার:

/create-migration users
/create-migration products

Plugins - Ready-made Configuration

Plugins কী?

Plugins হলো ready made ও ভ্যালিডেট - Claude Code configuration bundle, যা নির্দিষ্ট workflow বা use case অনুযায়ী অপটিমাইজ করা থাকে। এগুলো সরাসরি install করে অতিরিক্ত custom configuration ছাড়াই ব্যবহার করা যায়। একটা plugin install করলে তার সাথে থাকা agents, skills, hooks, এবং commands সব একসাথে আপনার project এ যুক্ত হয়ে যায়।

Plugins কেন ব্যবহার করবেন?

১. সময় বাঁচায়

নিজে থেকে agents, skills, hooks তৈরি করতে অনেক সময় লাগে। Plugin install করলে সব ready-made পেয়ে যাবেন।

২. Community-tested

হাজারো developer এই plugins ব্যবহার করেছে এবং improve করেছে। তাই quality নিয়ে নিশ্চিন্ত থাকতে পারেন।

৩. Best Practices

Industry standard best practices follow করা হয় plugin-গুলোতে।

৪. Consistent Workflow

Team-এর সবাই same plugin ব্যবহার করলে একই workflow follow হয়, collaboration সহজ হয়।

Claude Plugin Marketplace

Claude-এর official plugin marketplace থেকে বিভিন্ন ধরনের plugin পাওয়া যায়:

Popular Plugins:

1. GitHub Plugin

Git operations সহজ করে
Pull Request management
Issue tracking
Code review automation
Branch management

2. Notion Plugin

Documentation automatically sync হয়
Meeting notes তৈরি
Task management
Knowledge base update

3. Docker Plugin

Container management
Dockerfile generation
Docker Compose setup
Container debugging

4. Testing Plugin

Automated test generation
Coverage report
Test runner integration
Mock data generation

*5. Database Plugin *

Migration management
Query optimization
Schema visualization
Seed data generation

Plugin এ কী কী থাকে?

একটা plugin-এ সাধারণত এই structure থাকে:

github-plugin/
├── agents/
│   ├── git-expert-agent.md
│   ├── pr-reviewer-agent.md
│   └── issue-manager-agent.md
├── skills/
│   ├── git-workflow.md
│   ├── commit-message-guidelines.md
│   └── branch-naming-conventions.md
├── hooks/
│   ├── pre-commit-check.sh
│   ├── post-commit-push.sh
│   └── branch-protection.sh
└── commands/
    ├── create-pr.md
    ├── review-code.md
    └── create-issue.md

Plugin কীভাবে Install করবেন?

Method 1: Claude Code CLI

claude plugin install github
claude plugin install notion
claude plugin install docker

Method 2: Manual Installation

Plugin repository থেকে download করুন
.claude/plugins/ folder-এ রাখুন
Claude Code restart করুন

Plugin কীভাবে Configure করবেন?

প্রতিটা plugin-এর একটা config file থাকে:

# .claude/plugins/github/config.yml

enabled: true

agents:
  - git-expert-agent
  - pr-reviewer-agent

skills:
  - git-workflow
  - commit-message-guidelines

hooks:
  sessionStart:
    - check-git-status
  beforeCommand:
    - validate-branch

commands:
  - create-pr
  - review-code

Custom Plugin তৈরি করা

আপনি চাইলে নিজের plugin ও তৈরি করতে পারেন এবং team-এর সাথে share করতে পারেন:

my-company-plugin/
├── README.md
├── plugin.yml (metadata)
├── agents/
│   └── company-standards-agent.md
├── skills/
│   └── company-coding-standards.md
├── hooks/
│   └── company-workflow.sh
└── commands/
    └── create-ticket.md

plugin.yml:

name: my-company-plugin
version: 1.0.0
description: Company-specific development standards
author: Your Team
dependencies:
  - github
  - testing

Plugin Best Practices

১. শুধু প্রয়োজনীয় Plugin Enable করুন

অনেক plugin একসাথে enable করলে performance কমতে পারে।

২. Regular Update করুন

claude plugin update --all

৩. Plugin Documentation পড়ুন

প্রতিটা plugin-এর নিজস্ব features এবং commands আছে। Install করার পর documentation check করুন।

৪. Team-এ Same Plugins ব্যবহার করুন

এতে সবার কাছে same workflow থাকবে।

Plugin vs Manual Setup - কখন কোনটা?

Plugin ব্যবহার করুন যখন:

Standard workflow follow করতে চান
দ্রুত setup করতে চান
Community-tested solution চান
Team collaboration গুরুত্বপূর্ণ

Manual Setup করুন যখন:

Very specific requirements আছে
Company-specific workflow আছে
Full control চান
Learning purpose-এ কাজ করছেন

File Structure - সব একসাথে

Project-Specific Configuration

আপনার specific project-এর জন্য:

my-ecommerce-app/
├── src/
├── tests/
└── .claude/
    ├── agents/
    │   ├── frontend-agent.md
    │   ├── backend-agent.md
    │   ├── api-designer-agent.md
    │   └── code-reviewer-agent.md
    │
    ├── skills/
    │   ├── rest-api-best-practices.md
    │   ├── database-design.md
    │   ├── security-guidelines.md
    │   └── react-patterns.md
    │
    ├── hooks/
    │   ├── format-on-stop.sh
    │   ├── auto-commit.sh
    │   ├── check-dependencies.sh
    │   └── run-tests.sh
    │
    ├── commands/
    │   ├── create-component.md
    │   ├── create-api-endpoint.md
    │   └── create-migration.md
    │
    └── plugins/
        ├── github/
        └── testing/

Global Configuration

সব project-এ যা common থাকবে:

~/.config/claude/
├── agents/
│   ├── general-coding-agent.md
│   └── documentation-agent.md
│
├── skills/
│   ├── clean-code-principles.md
│   └── git-best-practices.md
│
├── hooks/
│   └── global-formatter.sh
│
└── commands/
    └── common-commands.md

Quick Reference

আপনার সুবিধার জন্য একটা quick reference table:

Feature	কী করে	কখন Trigger হয়	File Location	উদাহরণ
Agents	নির্দিষ্ট কাজের বিশেষজ্ঞ	`@agent-name` বা auto	`.claude/agents/*.md`	`@backend-agent`
Skills	Knowledge & guidelines	Auto (যখন প্রয়োজন)	`.claude/skills/*.md`	`rest-api-best-practices.md`
Hooks	Lifecycle automation	Event-based	`.claude/hooks/*.sh`	`sessionStart`, `stop`
Commands	দ্রুত কাজের shortcut	`/command-name`	`.claude/commands/*.md`	`/create-component`
Plugins	Ready-made config bundle	Manual install	Marketplace / `.claude/plugins/`	`claude plugin install github`

🎯 শেষ কথা

Claude Code একটা অসাধারণ শক্তিশালী টুল যা আপনার development workflow কে সম্পূর্ণ বদলে দিতে পারে। Agents, Skills, Hooks, Slash Commands, এবং Plugins - এই পাঁচটা ফিচার একসাথে ব্যবহার করলে আপনি:

দ্রুত এবং গুছিয়ে কাজ করতে পারবেন
Repetitive কাজগুলো automate করে ফেলতে পারবেন
Best practices maintain করতে পারবেন
Team collaboration improve হবে
Code quality অনেক ভালো হবে

শুরুতে একটু সময় নিয়ে setup করুন, তারপর দেখবেন কাজের গতি কতটা বেড়ে গেছে!

পরবর্তী পদক্ষেপ

একটা simple agent দিয়ে শুরু করুন
১-২টা useful skill তৈরি করুন
প্রয়োজনীয় hooks setup করুন
Frequently used কাজের জন্য slash commands বানান
Popular plugins explore করুন

Happy Coding!

আপনার মতামত জানান

কোনো প্রশ্ন বা feedback থাকলে কমেন্টে জানাতে পারেন। এছাড়া আপনার নিজের তৈরি agents, skills বা plugins শেয়ার করতে পারেন!

🔗 Connect with me:

GitHub: [https://github.com/ashadul-mridha]
LinkedIn: [https://www.linkedin.com/in/ashadulmridha/]

ClaudeCode #AI #Productivity #Programming #DevTools #Automation #Bengali #BanglaContent

3 Git features that changed how I work (and you probably aren't using them)

Ashadul Mridha — Fri, 16 Jan 2026 09:59:03 +0000

So I've been using Git for years, but honestly? I was just doing the basic add, commit, push routine. Then I discovered these three features and they genuinely made my workflow so much smoother.

1. Git Submodules - because copy-pasting code is exhausting

Here's the thing - I had this auth library that I needed in like 5 different microservices. First, I was literally copy-pasting it everywhere. Nightmare to maintain. One bug fix meant updating 5 repos manually.

Then I learned about submodules. Basically, you can include one Git repo inside another. Now I have a shared repo with common utilities, and all my projects reference it as a submodule. When I update the auth logic? Just run git submodule update in each project and boom, everyone's on the latest version.

Yeah, there's a learning curve, but it beats manually syncing code across projects.

2. Cherry-pick - for when you need THAT specific commit

This one's a lifesaver. You know when you fix a bug in one branch but need that same fix in another branch? Without merging the entire thing?

Last week I was working on a big feature branch. Production went down because of some API timeout issue. I quickly switched to main, fixed it, committed. But now my feature branch has the same bug. Instead of merging everything or fixing it again, I just cherry-picked that one commit:

git cherry-pick <commit-hash>

Saves so much time and keeps the history clean.

3. Git Stash - your work-in-progress safety net

Okay this is probably the one I use most often. Picture this: you're halfway through implementing something, code's messy, nothing's working yet. Then your team lead pings you - "urgent bug in production, need you to check it out NOW."

You can't commit half-baked code. But you also can't lose your work. That's where stash comes in:

git stash              # saves your current mess
git checkout main      # switch branches safely
# fix the urgent stuff
git checkout feature   # back to your branch
git stash pop          # and your work is right there

I probably stash stuff 3-4 times a day. It's become muscle memory at this point.

Quick tip: If you're learning these, start with stash. It's the easiest and you'll use it constantly. Cherry-pick is next. Submodules are powerful but you might not need them unless you're dealing with shared code across multiple projects.

DEV Community: Ashadul Mridha

Why Your Application Needs Observability: Building a Self-Hosted Observability Pipeline with the LGTM Stack (Loki, Grafana, Tempo, Mimir)

Understanding Observability with the LGTM Stack

Table of Contents

Introduction

What Is Observability?

Observability Is Not the Same as Monitoring

When Does Observability Really Matter?

The Three Pillars of Observability

1. Metrics

Types of Metrics

The RED Method — A Simple Starting Point

Don't Stop at Infrastructure Metrics

Checking CPU and RAM Right Now

2. Logs

Structured Logs vs. Plain Text Logs

Correlation IDs — The Glue Between Services

3. Traces

Quick Glossary

The Real Power: Following a Request Across Services

Why You Need All Three Together

The LGTM Stack

Why This Stack Over Paid Alternatives?

Architecture: How It All Fits Together

OpenTelemetry: The Instrumentation Standard

Auto-Instrumentation Is a Game Changer

The OTel Collector: The Brain of the Pipeline

Why Not Just Send Directly to Each Backend?

How the Collector Is Configured: Receivers → Processors → Exporters

Loki: Log Aggregation

What Makes Loki Different

LogQL — Loki's Query Language

One Thing to Get Right: Label Cardinality

Tempo: Distributed Tracing

How Tempo Stores Traces

Finding a Trace

TraceQL — Searching Traces Like a Pro

Bonus: Automatic Metrics from Traces

Mimir: Metrics at Scale

Isn't Prometheus Enough?

PromQL — Querying Metrics

Grafana: Connecting the Dots

How Cross-Signal Correlation Works

What a Real Investigation Looks Like in Grafana

Conclusion

Claude Code: সম্পূর্ণ বাংলা গাইড

Table of Contents

Agents

Agents কী?

বাস্তব উদাহরণ

Agents কীভাবে কাজ করে?

Skills

Skills কী?

Skills vs Agents এর পার্থক্য

বাস্তব উদাহরণ

Agent কীভাবে Skills ব্যবহার করে

Hooks - Lifecycle Automation

Hooks কী?

Available Lifecycle Events

বাস্তব উদাহরণ

Hooks Setup করা

Slash Commands - দ্রুত কাজের Shortcut

Slash Commands কী?

কখন Slash Commands ব্যবহার করবেন?

বাস্তব উদাহরণ

Plugins - Ready-made Configuration

Plugins কী?

Plugins কেন ব্যবহার করবেন?

১. সময় বাঁচায়

২. Community-tested

৩. Best Practices

৪. Consistent Workflow

Claude Plugin Marketplace

Popular Plugins:

Plugin এ কী কী থাকে?

Plugin কীভাবে Install করবেন?

Method 1: Claude Code CLI

Method 2: Manual Installation

Plugin কীভাবে Configure করবেন?

Custom Plugin তৈরি করা