01 / THE ROLE
In this lab.
Zabbix collects infrastructure measurements and service checks and presents them through lab dashboards. Groups, tags and discovery drive aggregate selections so that new members can appear without maintaining fixed host lists in every panel. Its database is PostgreSQL.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Checks & discovery
- STEP 02Groups & tags
- STEP 03Triggers & dashboards
- STEP 04Investigation & alerts
03 / How it works
How it works.
Host availability, resource metrics and an application HTTP check answer different questions. For a web service, the lab’s onboarding rule calls for the production URL, expected response and identity, latency and relevant TLS checks. Trigger behaviour and the dashboard’s scope are configured separately from the data collection.
04 / Persistent data & recovery
Persistent data & recovery.
Persistent monitoring configuration and history reside in the database alongside deployment configuration and secure integration settings. Decide which history is needed for recovery and which configuration must be reproducible. Dashboard exports alone do not recreate every collection and notification dependency.
05 / How to check it
How to check it.
Inspect recent values and timestamps, trigger state, discovery membership and an end-to-end test notification where appropriate. Missing data is distinct from a measured failure. An old green value should not be treated as current evidence.
06 / Decisions & limits
Decisions & limits.
Dynamic selection reduces maintenance, but relies on consistent source classification. A dedicated component panel can still have a specific target. I keep detailed measurements available while summary cards communicate state without unnecessary numeric clutter.