01 / PURPOSE
The problem it solves.
Complement monitoring with searchable operating-system and application events. Elastic and Fleet were tested in UAT and then promoted into a dedicated production environment. The documented rollout was completed after its earlier deferrals; source-level coverage still needs its own evidence.
02 / THE FLOW
How the pieces connect.
- STEP 01OS & container events
- STEP 02Elastic Agent
- STEP 03Elasticsearch
- STEP 04Kibana
03 / WALKTHROUGH
From intention to operation.
- 01
Identify the question and source
Decide which events help investigate a failure. System authentication, operating-system events and application logs have different formats and access requirements.
- 02
Collect with context
Preserve timestamps and source identity in the private operational platform. Public examples use neutral labels and synthetic events.
- 03
Search and correlate
Narrow the time window, inspect relevant fields and compare events with monitoring signals. Missing events can also indicate missing collection.
- 04
Control retention and access
Treat logs as potentially sensitive data. Balance storage, access and investigation needs instead of retaining everything indefinitely.
04 / DESIGN DECISIONS
The reasoning behind it.
Why keep monitoring and logs?
Monitoring detects symptoms; event details help investigate causes. Both depend on the quality and coverage of their sources.
Does every event go through Logstash?
No. The documented Fleet-managed path sends directly to Elasticsearch. Fleet manages the policies. The initial Docker-history cutoff and seven-day retention are separate controls; the production service guide explains them.
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.
{
"service.name": "example-web",
"event.kind": "event",
"log.level": "info",
"message": "Synthetic example: request completed"
}