Grafana, Prometheus, Loki, Alertmanager, One Small-Team Stack
Pull-quote: “The components of great observability have been free for years. What small teams lack is not software. It is the platform team that composes it.”
Why this matters
A small engineering team running a fleet of services faces an uncomfortable arithmetic. The fleet needs metrics, logs, alerting, dashboards, and endpoint probing, the same as any large platform’s fleet does, because outages do not scale down politely for headcount. But the standard paths to observability both cost more than the team can pay: assembling the open-source stack by hand is a multi-week platform project that then needs an owner, and vendor SaaS meters by ingestion until the monitoring bill competes with the infrastructure it monitors. Most teams resolve the tension by under-instrumenting and finding out about incidents from their users.
The composition is the product
The four components that dominate open-source observability each do one job well, and none of them works alone.
| Component | Job | What it needs from the others |
|---|---|---|
| Prometheus | Metrics collection and storage | Something to visualize it, something to route its alerts |
| Loki | Log aggregation | A collector shipping logs in, a dashboard querying them |
| Grafana | Dashboards over both | Data sources wired and provisioned |
| Alertmanager | Alert routing and grouping | Rules evaluating upstream, receivers configured |
None of the individual installs is hard. The project is the wiring: data sources, scrape configurations, log collection, probing, alert rules, and dashboards that query metrics and logs together. That wiring is undifferentiated work, identical at every company that does it, which is exactly the kind of work that should ship as a composed artifact rather than be re-derived by every team. DevOps Monitor, an open-source observability stack, takes that approach: Grafana, Prometheus, Loki, and Alertmanager composed and configured as one deployable unit, with blackbox endpoint probing and read-only log collection via Promtail pre-wired.
Deploy the stack, point the fleet at it
Your fleet Composed stack (one deployable unit)
────────── ────────────────────────────────────
service A ──┐ metrics scraped Prometheus ──► alert rules ──► Alertmanager
service B ──┼──────────────────► │ │
service C ──┘ logs collected Loki ◄── Promtail routed
│ ──────────────────► │ notifications
│ endpoints probed Grafana: dashboards querying
└──────────────────────────► metrics and logs togetherThe multi-application design is the part that pays off over time. The stack is built to observe a fleet, so adding an application is a configuration entry, a scrape target and a log path, not a new monitoring build. The tenth service costs what the second did: minutes.
Metrics and logs, one click apart
The design choice worth calling out is that dashboards query both Prometheus and Loki, so an alert and the log lines behind it live one click apart. Anyone who has debugged an incident across a metrics tool and a separate log tool knows the tax: two query languages, two time selectors, and a correlation performed by eye across browser tabs. Putting both behind one dashboard turns “the error rate spiked at 14:32” and “here is what the service logged at 14:32” into the same investigation. For a small team without a dedicated on-call rotation, shortening that path is the difference between a five-minute diagnosis and a lost evening.
Closing
Small teams should inherit the observability posture that large platform teams assemble by hand, and inheritance is the right word: the components are proven, the composition is known, and none of it needs to be re-derived per company. Deploy the stack, point your services at it, and the fleet appears on dashboards with alert rules already evaluating. The stack is open source. Big-team visibility, small-team effort.