# Observe the service and its users

Taiga Learning · Worksheet
https://taiga.training/en/lessons/observability/

Use fictional or approved information. Do not put secrets in this worksheet.

## Learning objectives
- Choose telemetry that answers a specific operational question.
- Distinguish a service symptom from an internal cause.
- Protect telemetry and detect missing or stale evidence.

## Exercise
For the fictional export in this lesson, define one SLI, one actionable alert, three allowed telemetry fields, and two prohibited fields. State how you would detect a broken telemetry pipeline.

## Your response
- Scenario and scope:
- Assumptions and open questions:
- Proposed answer or decision, with reasons:

## Verify your response
| Claim or criterion | Evidence or test | Result or gap | Owner |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Next action
- Action, owner, and date:
- When will you review this response?

## Principle to retain
Observability makes service behavior explainable. Useful telemetry connects user impact to an investigation without exposing unnecessary data.

## Sources
- [OpenTelemetry: Observability primer](https://opentelemetry.io/docs/concepts/observability-primer/)
- [OpenTelemetry: Handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/)
- [Google SRE: Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/)
- [Taiga docs: Monitoring](https://docs.tai.ga/operate/monitoring/)

This worksheet supports learning. Completing it does not itself authorize a production change.