Observability

A running Intropy System is observable through OpenTelemetry. The framework itself emits a trace for every run — a Pipeline.<name> root span with Step.<StepName> children — along with metrics and structured logs correlated to the active trace, and exports all three signals over OTLP. Wiring a Component’s host to an exporter is a build-side task, covered in Configure telemetry.

Where the exporter points is deployment configuration, and the deploy path carries it: the manifests rendered for an environment set the OTLP endpoint in each workload’s environment (the local cluster render, for example, points it at the host machine’s collector port).

Because the export is standard OTLP, you can point it at whatever OpenTelemetry-compatible backend you already operate. For teams that don’t have one, intropy.run wires up a reference stack: Grafana for dashboards, Tempo for traces, Loki for logs, and Prometheus for metrics. It is the default, and it is optional: nothing in the framework or the deployment model depends on it.

Planned pages

The how-to pages for day-two operations are planned but not yet written:

• Find a failing run — from “something is wrong” to the exact Component, trace, and payload.
• Read a Component trace — what each span means, how Dapr-mediated calls show up, where to find idempotency keys.
• Build a System dashboard — the reference Grafana dashboard layout for a System (throughput, error rate, lag).
• Alerting — alert rules for System health, and where alerts should land.

The dashboard and alerting pages will assume the reference stack; the trace and failing-run pages apply to any OTLP backend.