01 / PURPOSE
The problem it solves.
Detect service and infrastructure problems, retain useful measurements and build dashboards whose scope can grow with the environment.
02 / THE FLOW
How the pieces connect.
- STEP 01Checks & discovery
- STEP 02Groups & tags
- STEP 03Dashboards
- STEP 04Investigation
03 / WALKTHROUGH
From intention to operation.
- 01
Collect a meaningful signal
Choose the signal for the question: host availability, resource pressure or an application response. Infrastructure and service checks answer different questions.
- 02
Classify at the source
Use groups, tags and discovery so that aggregate views can include new members without hand-editing lists of hosts.
- 03
Present a useful overview
Keep status cards easy to scan. Use colour for state and reserve detailed metrics for the investigation view.
- 04
Follow the symptom
Start with the affected service, inspect related measurements and correlate with logs where the available sources allow it.
04 / DESIGN DECISIONS
The reasoning behind it.
Why dynamic dashboards?
Selections based on classification are easier to maintain as services change. A dedicated service panel can still have a specific target.
Why check the service URL?
A running host or container does not prove that a user can reach the application. HTTP checks add a different layer of evidence.
05 / A CLOSER LOOK
A small, concrete example.
This illustrative example explains the structure. It is not an export of the lab configuration or a complete deployment recipe.
# Illustrative classification, not a live inventory
service: example-web
role: application
environment: test
checks:
- expected-http-response
- response-time
- host-resource-pressure