A service is running, but users say it is slow. You need evidence from inside the system to see what is happening. Observability combines measurements and events that help you investigate behavior instead of guessing from a single health indicator.

Metrics show numbers over time, logs record events, and traces connect the steps of a request. OpenTelemetry provides APIs and tools for producing and moving these signals. Begin with a specific question, such as which dependency delayed a request, then collect the information needed to answer it.

Try it in a lab

Instrument a small local request path with a success count, a failure count and a latency measurement. Trigger a known failure and connect its signal to the relevant application log.

Check your understanding

Explain what each signal can and cannot show. Record labels or attributes, their expected cardinality and how sensitive values are excluded.

Before you start

Do not put tokens, user payloads or unbounded identifiers into telemetry. Set collection and retention choices deliberately.

Read the official guide

Use the OpenTelemetry observability primer for concepts, then choose your language from the API and SDK documentation for instrumentation setup and prerequisites. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.

Sources & further reading

  1. Primary learning documentation
  2. OpenTelemetry language APIs and SDK documentation

Spotted something that needs another look?

Help improve this page →