Fitz vs OpenTelemetry: observability en FastAPI (Python)

Fitz reduce la observability en FastAPI a dos decoradores y una variable de entorno, mientras que el stack tradicional de OpenTelemetry para observability en FastAPI con Python pide 6 paquetes pip y unas 60 líneas de configuración. Los dos exportan traces, métricas y logs, pero el esfuerzo de setup no se parece en nada. Esta comparación sale de una nota de Martin Palopoli publicada el 30 de junio de 2026.

La observability es la capacidad de entender qué pasa dentro de una aplicación a partir de sus señales externas: traces (el recorrido de un request), métricas (números agregados como latencia y cantidad de errores) y logs (registros de eventos). En FastAPI con Python, tenerla completa significa conectar esos tres pilares para responder qué endpoint está lento y por qué falló un request puntual a las 3 de la mañana.

¿Por qué necesitás traces, métricas y logs juntos?

Ponele que tu app crece y el cliente quiere tres cosas: saber qué endpoint está lento, cuántos requests fallaron en la última hora y por qué un usuario específico vio un error de madrugada. Cada pregunta la responde un pilar distinto.

• Traces: te muestran el camino completo de un request, span por span, para encontrar dónde se fue el tiempo.
• Métricas: son los números agregados (latencia p95, tasa de error) que alimentan tus dashboards de Prometheus y las alertas.
• Logs: son el detalle fino, el evento puntual con contexto que ni el trace ni la métrica te dan.

Con uno solo no alcanza. La métrica te dice que hay errores, pero no cuáles. El log te muestra el error, pero no en qué punto del recorrido pasó. En 2026 la respuesta de la industria para unir los tres es OpenTelemetry. El problema es cuánto trabajo cuesta armarlo.

¿Cuánto setup pide OpenTelemetry en FastAPI?

Bastante. Para observability completa en FastAPI con Python, la nota lista seis paquetes que terminás pegoteando en casi toda app “production-ready”:

• opentelemetry-distro[otlp]: el núcleo del SDK y el exporter.
• opentelemetry-instrumentation-fastapi: instrumenta los spans HTTP automáticamente.
• opentelemetry-instrumentation-sqlalchemy: traza las queries a la base.
• opentelemetry-instrumentation-requests: traza las llamadas HTTP salientes.
• opentelemetry-exporter-otlp-proto-grpc: exporta por gRPC al backend.
• prometheus-fastapi-instrumentator: expone las métricas para Prometheus.

Después vienen las ~60 líneas: configurar el TracerProvider, el MeterProvider, el PeriodicExportingMetricReader, llamar al FastAPIInstrumentor y al SQLAlchemyInstrumentor, y armar los logs estructurados con structlog y sus seis procesadores. ¿Y para que un log muestre el trace_id del span actual? Ahí sumás un processor propio. Nada imposible, pero es plomería, y la plomería no documentada es la que te rompe en producción.

Si querés ver el patrón armado de punta a punta, el repo blueswen/fastapi-observability muestra el stack completo con Tempo, Loki y Prometheus, y el instrumentator de Prometheus es el que hace el laburo de métricas.

¿Qué es Fitz y cómo simplifica la observability con dos decoradores?

Fitz es un enfoque declarativo para observability donde el wiring entre logs, spans y métricas ya viene resuelto. En vez de configurar providers a mano, anotás tus funciones async.

• @trace(name="..."): crea un span custom sobre la función, sin tocar el SDK.
• @metric(name="..."): registra counters e histogramas de esa función.
• @server(8080, prometheus=true): levanta el server y expone Prometheus en un solo lugar.

Sumás la variable OTEL_EXPORTER_OTLP_ENDPOINT y listo. Los spans HTTP se auto-instrumentan, los custom salen del decorador, y el trace_id ya viaja hacia los logs sin que escribas un processor. La idea es simple: desde el decorador, todo queda conectado. Eso sí, “todo” tiene asteriscos que vemos más abajo.

OpenTelemetry vs Fitz en FastAPI: comparativa técnica

Aspecto	OpenTelemetry	Fitz
Setup inicial	6 paquetes pip + ~60 líneas	2 decoradores + 1 env var
Spans HTTP	Auto (instrumentador FastAPI)	Auto
Spans custom	Manual con el SDK	@trace
Métricas Prometheus	prometheus-fastapi-instrumentator	@metric + @server(prometheus=true)
trace_id en logs	Processor custom en structlog	Automático (task-local)
Redacción de secretos	Manual	Secret integrado
Madurez y flexibilidad	Alta, estándar de facto	Limitada (herramienta joven)

Fitz gana en simplicidad sin discusión. OpenTelemetry gana en madurez, ecosistema y control fino. La elección depende de qué te duele más: las líneas de config o los límites de una herramienta joven. Te puede servir nuestra cobertura de integrando observabilidad en pipelines.

¿Cómo correlacionar el trace_id entre logs y spans?

Acá viene lo bueno. ¿De qué sirve un log si no sabés a qué request pertenece? De poco. El trace_id es lo que te deja saltar del log al trace y reconstruir el error del usuario de las 3 AM.

En OpenTelemetry lo resolvés con un processor custom (algo tipo inject_trace_context) que mete el trace_id activo en cada línea de structlog. En Fitz sale automático vía almacenamiento task-local: el decorador ya sabe en qué span estás y estampa el id solo. En la práctica, buscás el error 500 por user_id en tus logs, copiás el trace_id y lo pegás en Grafana o Jaeger para ver el recorrido completo.

¿Cómo redactar secretos automáticamente en los logs?

Ponele que logueás el objeto request para debuggear y, sin querer, mandás el header Authorization con el token del usuario a tu backend de logs. Ese token queda ahí, indexado, buscable. Un lindo problema de compliance.

En OpenTelemetry la redacción es manual: te toca acordarte de filtrar passwords, API keys y JWT antes de loguearlos. Fitz trae un tipo Secret que oculta el valor en el Display y en la serialización JSON. Para ver el valor real necesitás llamar a .expose(), que queda explícito y auditable en code review. La diferencia es filosófica: uno confía en tu memoria, el otro te obliga a ser explícito cuando exponés algo sensible. Para más detalles técnicos, mirá monitorear tus deployments CI/CD.

¿Con qué backends funciona y dónde lo desplegás?

Los dos hablan el protocolo OTLP, así que configurás el destino con variables de entorno estándar:

• OTEL_EXPORTER_OTLP_ENDPOINT: a dónde mandás las señales.
• OTEL_SERVICE_NAME: el nombre de tu servicio en el backend.
• OTEL_TRACES_SAMPLER_ARG: por ejemplo 0.1 para samplear el 10% (head-based).
• OTEL_EXPORTER_OTLP_HEADERS: para pasar tokens de autenticación del backend.

Con eso apuntás a Jaeger, Tempo, Honeycomb, Datadog, New Relic o Grafana Cloud sin cambiar el código. Si querés un tablero listo, está el dashboard 16110 de Grafana para FastAPI. Y donde corras la app, un VPS o un servidor en donweb.com o el cloud que uses, alcanza con setear el endpoint OTLP y las señales viajan solas.

Qué está confirmado y qué queda pendiente en Fitz (2026)

Fitz, presentada el 30 de junio de 2026, es una herramienta joven y conviene mirar la letra chica antes de casarte con la herramienta.

• Confirmado: setup en dos decoradores más un env var, trace_id auto-correlacionado entre logs y spans, y redacción de secretos con el tipo Secret.
• Pendiente: los logs todavía no se envían al signal OTel del backend (queda para la iteración iter2.b).
• Pendiente: las métricas todavía no pushean a backends OTel.
• Pendiente: solo hay sampling head-based, sin decisión tail-based.
• Pendiente: no hay profiling continuo (nada de pyroscope ni pprof) y la auto-instrumentación de base de datos es limitada.

Traducido: Fitz es golazo para prototipar y para apps donde el trace-first alcanza, pero si dependés de que las métricas lleguen ya mismo a tu backend OTel, OpenTelemetry sigue siendo la apuesta segura (aburrida, sí, pero segura).

Errores comunes al configurar observability en FastAPI

• Loguear el request entero sin filtrar: te llevás tokens y passwords a los logs. Redactá con un tipo tipo Secret o filtrá a mano antes de loguear.
• Olvidar el trace_id en los logs: sin correlación, tus logs y tus traces viven en universos separados y el debug se vuelve adivinanza.
• Samplear al 100% en producción: te comés el costo del backend y la latencia del export. Empezá con OTEL_TRACES_SAMPLER_ARG=0.1 y ajustá.
• Creer que Fitz ya pushea todo: todavía los logs y las métricas no llegan al backend OTel. Verificá antes de asumir cobertura completa.

Preguntas Frecuentes

¿Cómo agrego tracing y métricas Prometheus a FastAPI?

Con OpenTelemetry instalás seis paquetes pip (incluido prometheus-fastapi-instrumentator) y configurás TracerProvider, MeterProvider y los instrumentadores en unas 60 líneas. Con Fitz alcanza con los decoradores @trace y @metric más @server(8080, prometheus=true). Lo explicamos a fondo en con asistentes de código para instrumentación.

¿Qué ventaja tiene Fitz sobre OpenTelemetry?

La simplicidad: reduce el setup a dos decoradores y una variable de entorno, correlaciona el trace_id automáticamente y redacta secretos por defecto. OpenTelemetry pide configuración manual para lo mismo, pero es más maduro y flexible.

¿Cómo correlaciono logs con traces usando trace_id?

En OpenTelemetry agregás un processor custom en structlog que inyecta el trace_id activo en cada log. En Fitz es automático vía task-local storage, así que buscás el error por user_id y saltás directo al trace en Grafana o Jaeger.

¿Cuánto setup requiere la observability completa en FastAPI?

Con OpenTelemetry, 6 paquetes pip más ~60 líneas de configuración y glue manual entre logs, spans y métricas. Con Fitz, dos decoradores y un env var. La diferencia de esfuerzo inicial es grande.

¿Cómo redacto secretos automáticamente en los logs?

Fitz trae un tipo Secret que oculta el valor en el Display y en la serialización JSON; para verlo hay que llamar a .expose(), que queda auditable en code review. En OpenTelemetry la redacción la hacés manualmente antes de loguear.

Conclusión

Lo que cambió es la barrera de entrada. Tener traces, métricas y logs correlacionados en FastAPI dejó de ser un ejercicio de 60 líneas y seis paquetes: Fitz lo baja a dos decoradores, con trace_id automático y secretos redactados de fábrica. Importa porque muchas apps abandonan la observability por fricción de setup, no por falta de ganas.

Ahora bien, Fitz es una herramienta joven y todavía no pushea logs ni métricas a los backends OTel. Si arrancás un proyecto nuevo y querés observability rápida, probá Fitz. Si ya vivís en un backend OTel y necesitás que las métricas lleguen hoy, quedate en OpenTelemetry y automatizá el glue. Elegí por tu caso, no por la moda.

Fuentes

• Martin Palopoli en dev.to – Tracing, métricas Prometheus y logs con dos decoradores: Fitz vs OpenTelemetry
• blueswen/fastapi-observability – Stack completo de observability en FastAPI
• prometheus-fastapi-instrumentator – Instrumentador de métricas Prometheus
• Grafana – Dashboard 16110 para FastAPI Observability
• SigNoz – Guía de OpenTelemetry con FastAPI