Dashboards and Alerts
Build the everyday dashboard with one row per golden signal, add an alert on api ERROR log lines, and trigger it on purpose to watch it fire.
Build the everyday dashboard with one row per golden signal, add an alert on api ERROR log lines, and trigger it on purpose to watch it fire.
How a team watches a live system every day, using the four golden signals, one always-on dashboard per system and a few well-chosen alerts.
What comes after this module, from traces and long-term metrics to a hosted Grafana, real servers, alert routing and dashboards as code.
Watching systems every day and during a load test, with Grafana, Alloy, Prometheus and Loki against the Pizza Playground.
What to watch on the server while a load test runs, how to take a baseline first, and how to line up the load tool's timeline with Grafana.
What monitoring is, the four steps every setup has, the two kinds of signal (metrics and logs) and why it matters, before any tool.
Reading a finished run in LoadLitmus - metrics, HTML reports, comparisons, exports and auto-analysis - plus live monitoring through InfluxDB.
Walk through the Alloy config block by block, start Alloy with the right mounts, and check that container metrics and logs reach Prometheus and Loki.
Start Grafana on port 3001, log in, connect the Prometheus and Loki data sources, and check both in Explore.
Start Loki in Docker on the playground network and check that it is ready to receive container logs.
Start Prometheus in Docker next to the Pizza Playground, give it a small config, and check that it is ready and scraping itself.
The four tools used here (Alloy, Prometheus, Loki, Grafana), what each one does, how data moves between them and what we can see without changing the app.
Send k6 results to Prometheus, put them on one Grafana dashboard next to the server, and read cause and effect during a load test.
The signals a tester cannot see from outside the app, why they matter in a load test, and how to ask the developers for them.