Observing Traefik lets you follow what the proxy receives, forwards and returns as errors. Logs describe individual requests; metrics aggregate behavior over time. This lesson explains how to read these signals, how they complement one another and why monitoring endpoints must remain private.
What you will learn
These objectives follow the path from observing a request to identifying an incident and reporting it.
- Distinguish logs, metrics and traces.
- Interpret a JSON access-log line.
- Explain how Prometheus collects Traefik metrics.
- Understand why an alert must fire on a verifiable signal.
- Keep the monitoring network separate from public traffic.
Which signals complement Traefik monitoring?
Observability uses three complementary signals, logs, metrics and traces, that Traefik can produce or forward. Each answers a different question; combining them avoids confusing a one-off symptom with a trend or a cause in another service.
| Pillar | What it answers | Typical backend |
|---|---|---|
| Logs | What happened to this request? | Loki, ELK |
| Metrics | How many, how fast, what error rate? | Prometheus |
| Traces | Where was time spent along the chain? | Tempo, Jaeger |
To correlate these signals, see signal correlation (in French) and the OpenTelemetry standard (in French).
What do access logs reveal?
Access logs record requests that pass through the proxy. JSON format makes each field identifiable by name, which helps collection tools filter and aggregate data. During an investigation, correlate the requested host, HTTP status, duration and destination service. Avoid recording sensitive data that may appear in paths or headers.
A filter reduces log volume, but it can also remove a signal needed for diagnosis. Base exclusions on an observed need and check that anomalous requests remain visible.
How does Prometheus collect Traefik metrics?
Traefik exposes Prometheus metrics on a dedicated endpoint. Prometheus collects them at regular intervals. The proxy must be reachable from the collector, not from the Internet: put the endpoint on a separate interface or monitoring network, and check that it is not published by the public entry point.
In Prometheus, the target state shows whether collection works. An active target does not prove that the proxy is serving applications correctly; it only confirms that Prometheus can read the metrics. Metrics describe counts, durations and service states over time. Prometheus collects labeled series, allowing you to compare responses by entrypoint, router or backend. To understand an incident, compare aggregated values with access logs and service health.
The collection endpoint reveals infrastructure information and should only be available to the authorized collector. Keeping it separate from public traffic limits exposure and prevents external clients from querying the metrics. To visualize series, see Grafana (in French).
When are traces useful?
Traces connect the stages of a request across several services. They help locate a delay or error when logs and metrics show a symptom but not its origin. OpenTelemetry standardizes collecting and transmitting these signals; OTLP is one of the transport protocols it uses. See OpenTelemetry (in French) and the OpenTelemetry Collector (in French).
How do you build a useful alert?
A useful alert describes an actionable symptom and relies on an observable measurement. 5xx responses indicate a server-side problem, but the cause may be in Traefik, the backend or the network path. Choose the threshold and duration to avoid waking an operator for an isolated error while still detecting a persistent failure.
A useful alert names the affected service. It reports an observable condition and suggests a first action. Do not choose a threshold only to make notifications disappear: it should represent the point at which the symptom threatens users. A pending duration reduces alerts for brief events but delays detection. Assign an owner and a diagnostic procedure, then test the alert with a controlled incident. An alert with no expected action adds noise; an alert that has never been tested may remain silent during an incident.
How do you diagnose an incident with these signals?
Observability speeds diagnosis when each signal is connected to a specific question. Start by placing the symptom in time and identifying the services affected. Metrics show whether error volume or latency is changing; logs provide details about the affected requests. If several services are involved, traces can help locate the stage that is waiting or failing. One source alone can mislead: healthy collection does not prove that the backend responds, and a logged error does not identify its cause by itself. Correlate the signals before changing configuration.
| Question | Where to look |
|---|---|
| A spike in server errors? | Response codes in logs and Prometheus series |
| Unusual latency? | Request duration, then traces if configured |
| A route does not respond? | Proxy logs and observed configuration |
| Application unavailable? | Backend logs and health metrics |
Practice
The exercise asks you to enable filtered JSON access logs, make local metrics collectible, then configure an alert that reacts to a real 5xx response. The lab provides environment-specific details.
Key points
Signals help when they form a readable diagnostic path from the affected request to the action to take.
- Logs describe individual requests; metrics reveal trends.
- Active Prometheus collection does not prove that applications are healthy.
- Keep monitoring endpoints away from public traffic.
- An alert should report an observable symptom and trigger a diagnostic process.
Knowledge check
The quiz covers the key distinctions between logs, metrics, traces and alerts.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Troubleshoot a Traefik entry point: 404, 502, 504, certificates and redirects
A new full quiz with random questions
Work again only on the questions you missed