Skip to content

Monitoring

Monitoring and Observability

hetida designer supports opentelemetry observability / monitoring via logfire against custom backends.

To activate it, set the environment variable HD_OTEL_VIA_LOGFIRE_ACTIVE to true for backend and runtime containers. This will among others instrument httpx, asgi, and logging. Furthermore several custom spans are provided for the transformation excecution process.

You can then use opentelemtry environment variables like OTEL_EXPORTER_OTLP_ENDPOINT to configure the otel collector / backend to which spans, metrics and logs will be sent. We recommend to also set at least OTEL_SERVICE_NAME to hetida-designer-backend or hetida-designer-runtime. As an example the docker-compose-dev setup has telemetry activated and comes with a Grafana Stack Single Container service.

The export is configured by logfire only: FastAPI's own automatic export configuration (FASTAPI_OTEL_AUTO_CONFIGURE) is deactivated if HD_OTEL_VIA_LOGFIRE_ACTIVE is true, since it would send every span a second time.

Exceptions

Exceptions are recorded as span events named exception with the standard OpenTelemetry attributes exception.type, exception.message and exception.stacktrace: on the span they escape from, and for logs with a traceback (e.g. about errors during an execution) on the log span.

Additionally, every recorded exception gets attributes describing its root cause, i.e. the innermost exception of the chain shown in the traceback (raise ... from ... or raised during handling of another exception). For example errors in component code are recorded as UnexpectedComponentException with the generic message "Unexpected error from user code.", while the actual error is its root cause. For exceptions without such a chain, these attributes describe the exception itself.

Attribute Description
hetida_designer.exception.root_cause.type fully qualified exception type, like exception.type
hetida_designer.exception.root_cause.message exception message
hetida_designer.exception.root_cause.code.file.path file where it was raised. For component code CODE OF COMPONENT <name> (<version tag>) UUID <id>
hetida_designer.exception.root_cause.code.function.name fully qualified name of the function where it was raised
hetida_designer.exception.root_cause.code.line.number line number where it was raised

These attributes can be used in queries, e.g. in TraceQL of Grafana Tempo: { event.hetida_designer.exception.root_cause.type = "ValueError" }.

Tracebacks cut off in Grafana Tempo

Grafana Tempo truncates attribute values longer than 2048 bytes by default. This cuts off the tracebacks of exceptions recorded in spans (exception.stacktrace), and with them their most relevant part, the end. The root cause attributes described above are short enough not to be affected and the complete traceback is contained in the log output (see below). Raise the limit via max_attribute_bytes in the distributor section of the Tempo configuration, e.g. to 16384.

Linking logs and traces

If telemetry is activated, the JSON log output contains the trace context of the span active during logging in the fields trace_id, span_id and trace_flags, as specified by OpenTelemetry for JSON logs. The log span created by logfire for the log message is a child of this span.

If you collect the log output, e.g. with Grafana Loki, you can link logs and traces via the trace id. For Grafana see Trace to logs. Like all fields, e.g. exception containing the traceback, they can be renamed via the environment variable LOG_FIELDS_TO_RENAME, a JSON object mapping field names to new names (replacing the default mapping).

Importan Note

logfire handles log messages as spans of duration 0 and will not send them as classical logs!