Table of Contents

Observability & telemetry

In one line: see inside a live engine — gated telemetry (zero cost when off), distributed tracing, OpenTelemetry metrics, and health checks — without paying for what you don't turn on.

Typhon's instrumentation is gated: ~200 hierarchical flags (JSON / env-driven) guard every emission point, and when a flag is off the guard is JIT-eliminated to nothing — you pay only for the signal you enable. On top of that sit four consumer-facing surfaces: distributed tracing via the .NET Activity API with OpenTelemetry-semantic attributes; metrics export projecting the engine's resource graph and per-archetype ECS health as standard OTel instruments; framework-agnostic health checks (ITyphonHealthCheck → Healthy / Degraded / Unhealthy); and threshold alerting that raises Warning / Critical as resource metrics cross bounds.

This page doesn't reproduce the individual flags. The telemetry flags reference lists every gate — all ~224, each with its config key, default, and effect — generated from source and shipped with a copy-paste typhon.telemetry.json template; the gating page explains the model (how flags resolve, parent-implies-children, JIT elimination). For metrics, the per-domain named-metrics catalog groups the ~40 planned fixed-name OTel instruments by domain — a design target, not yet wired to an exporter.

How it relates

  • DatabaseEngine — what you observe; telemetry is configured on it.
  • Errors & failures — health checks and alerts turn failure signals into operational state.
  • Tick — per-tick telemetry (durations, overrun) is a primary signal source.
  • Profiler — the other consumer of the same gates: a higher-throughput, non-OTel pipeline for deep-dive tracing.
  • Resources & budgets — the utilization tree these metrics and health checks project.

In the API

Learn & use

Edit this page