Observe for better diagnosis
How do you build monitoring that detects relevant incidents and allows their causes to be verified?
3500 € per session, excl. VAT
In short
In two days, totalling 14 hours excluding breaks, design an observability prototype combining metrics, logs, traces and alerts. Generative AI supports the preparation of configurations and procedures, which are always verified in an isolated environment. You leave with a tested solution, quality measurements and a plan for a controlled pilot.
Why this training?
Technical dashboards are not enough to explain a failed booking. Linking user-facing symptoms, dependencies and telemetry makes it possible to distinguish between saturation, an application error and a lack of data collection. AI speeds up the writing of queries, configurations and procedures, but may suggest non-existent fields or arbitrary thresholds. Each suggestion is checked against the available data, documentation and test results. Running case study: The fictitious organisation Dalmorie Billetterie operates an online booking system: interface, API and database. Intermittent slowdowns and simulated payment errors must be detected without multiplying unnecessary alerts. Application at work: Propose a pilot on a non-critical service: an identified owner, validated access permissions, an authorised failure scenario, an alert review and a decision on whether to continue based on measurements.
Objectives of this training
- Map the dependencies of a critical user journey
- Define service indicators and their targets
- Instrument a prototype with metrics, logs and traces
- Configure alerts linked to a response procedure
- Measure detection and document the pilot's limitations
Who is it for and what are the prerequisites?
Roles and tasks concerned
- Operations, DevOps and service reliability engineers
- Lead developers and product technical leads
Prior skills
- Be able to run a test application and modify its configuration.
- Understand HTTP, application logs and system metrics.
- Be able to formulate a structured request to an AI assistant.
What you will work on
Scope the critical journey
Objective: Define the scope of the service being observed. Monitoring, observability, dependencies and user impact.
Define measurable commitments
Objective: Develop actionable indicators. SLI, SLO, latency, availability and error budget.
Design data collection
Objective: Organise controlled telemetry. Metrics, logs, traces; cardinality, sampling, retention and access.
Instrument the prototype
Objective: Emit signals that can be correlated. Correlation identifiers, context propagation and masking.
Validate the received data
Objective: Identify data collection defects. Timestamping, missing fields, duplicates and collector interruption.
Build diagnostic views
Objective: Link symptoms and dependencies. Service, saturation and error views, and navigation to traces.
Tune the alerts
Objective: Limit notifications that lead to no action. Thresholds, time windows, grouping, routing and absence of data.
Prepare the response
Objective: Make every alert actionable. Checks, hypotheses, escalation and rollback.
Test detection
Objective: Measure the limitations of the solution. Controlled injection of latency, errors and loss of data collection.
Organise the pilot
Objective: Set conditions for a controlled expansion. Responsibilities, data collection overhead, security and stopping criteria.
What you take away
- Telemetry architecture and data collection contract
- Configured prototype with a dashboard and alerts
- Response procedures and test report
- Pilot plan with responsibilities and stopping conditions
Method and assessment
- Short instructional inputs followed by immediate practice on the case study used throughout.
- Individual work followed by work in pairs, with peer review of the outputs.
- Facilitated group review: what works, what needs correcting and what remains a human decision.
- Preparation: Prepare an isolated environment with an application, data collection and visualisation authorised by the organisation. Provide fictitious or anonymised data; exclude secrets, tokens and personal data from exchanges with the AI.
Observable criteria: The indicators specify the formula, time window, source and objective. ; A simulated request is located in the correlated logs and traces. ; Each injected fault produces a recorded result, including the detection time. ; Each alert has a recipient, a justification and a procedure. ; Generated configurations are validated without exposing secrets..
Frequently asked questions
Is a particular platform mandatory?
No, the selected stack must be authorised and available before the session.
Does the AI analyse production logs?
The exercises use only fictitious or anonymised data, with no secrets.
Will the solution be made production-ready?
No: the outcome is a tested prototype and a pilot plan.
How should alerts be assessed?
Through simulated faults, observed detection times, missed incidents and unnecessary notifications.
Last updated: