# Observability and audit (/docs/foundation/observability-and-audit)



Foundation provides a shared telemetry pipeline for infrastructure, AI, and Data workloads.

## Signal paths [#signal-paths]

| Signal  | Collection and routing                                                                                      | Storage and use                   |
| ------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------- |
| Metrics | Prometheus-compatible scraping, including KServe workloads, plus application OTLP through the Alloy gateway | Prometheus and Grafana dashboards |
| Logs    | Pod standard output and error through per-node Alloy; application OTLP logs through the Alloy gateway       | Loki and Grafana exploration      |
| Traces  | Application OTLP through the Alloy gateway                                                                  | Tempo and Grafana exploration     |

## Tenant-aware logs [#tenant-aware-logs]

The per-node Alloy collector parses each pod-log body as JSON. When the body contains a non-empty top-level `tenant_id`, Alloy uses that value as the Loki tenant for that entry. It removes the temporary stream label before forwarding the log to avoid adding tenant cardinality to the Loki index.

Entries without a parseable `tenant_id`, including non-JSON application and infrastructure logs, use the `platform` Loki tenant. Logs received by the Alloy OTLP gateway also use `platform`; tenant-specific routing is not configured on the OTLP log path in 1.3.0.

This is a collector contract, not an assertion that every component emits tenant-scoped JSON. An application that requires tenant-specific pod-log routing must write structured JSON to standard output or error and include the server-authorized tenant UUID as the top-level `tenant_id`. Access to each Loki tenant must still be restricted at the query layer.

## OpenTelemetry gateway [#opentelemetry-gateway]

BullSequana AI 1.3.0 uses a dedicated Alloy gateway with OTLP/gRPC and OTLP/HTTP receivers. The BSQAI API and MCP Gateway export application telemetry directly. Tempo exports its own operational telemetry to the gateway.

The gateway sends traces to Tempo, converts metrics for Prometheus remote write, and forwards logs to Loki under the `platform` tenant. KServe controller and model-workload metrics reach the same metrics path through Prometheus scraping; the platform does not configure KServe workloads as general-purpose OTLP trace or log emitters.

## Operating pattern [#operating-pattern]

Metrics show service health and capacity, logs explain component behavior, and traces connect work across services. Grafana provides the common exploration surface. MLflow retains a separate GenAI-specific trace path where model and prompt analysis is required.