Observabilidad

La observabilidad es poder ver qué está haciendo un producto en marcha, a través de sus registros, sus métricas y sus trazas. En Airframe, un equipo la obtiene sin construir nada: las señales de su producto viajan a un único stack de Grafana Cloud, y sus paneles y sus reglas de alerta salen de su entrada en el catálogo. Esta página sigue una señal desde una aplicación hasta Grafana, y luego enumera lo que recibe cada producto.

Un único stack de Grafana Cloud

Grafana Cloud es un servicio alojado para registros, métricas, trazas, paneles y alertas. Airframe usa un solo stack de él, llamado projectairframe, para toda la organización y no uno por dominio, para que una solicitud que cruza dos dominios se pueda seguir de punta a punta. El entorno del que viene una señal es una etiqueta, no un stack aparte.

El nivel gratuito de Grafana Cloud permite exactamente un stack, así que se creó a mano en el portal de Grafana durante el arranque. Todo lo que hay dentro es código: la raíz de Grafana del repositorio operations crea los equipos, las carpetas y sus permisos, y suma al stack y a sus equipos a cada persona del catálogo que tiene un nombre de usuario de Grafana.

El camino de una señal

Una aplicación no sabe nada de adónde va su telemetría. Escribe sus registros como líneas JSON en su salida estándar, envía trazas y métricas por OTLP, el protocolo de OpenTelemetry, a la dirección que le da la plataforma, y nunca tiene una credencial de Grafana. Todo lo que hay entre la aplicación y Grafana es de la plataforma.

Las trazas y las métricas van directo a la puerta de enlace OTLP de la edición. Con cada lote, el servicio presenta un token de identidad de corta duración que lo nombra, y la puerta de enlace admite solo a quienes se le indicó que acepte.
Los registros hacen un camino más largo. Cloud Run los captura en Cloud Logging, un sink en el proyecto del producto los manda a un tema de Pub/Sub que hace de buffer, y el buffer los empuja a la puerta de enlace de registros de la edición.
Los eventos del navegador, como errores y tiempos de página, van a /_telemetry en el propio nombre de host del producto, detrás del inicio de sesión único, y el servicio los reenvía con su identidad.
Las métricas de los recursos de la nube, como la CPU de una instancia de Cloud SQL, las lee de Cloud Monitoring de Google una pequeña instancia recolectora por edición, que las envía por la puerta de enlace OTLP.

Las puertas de enlace ejecutan Grafana Alloy, el recolector de telemetría de Grafana, sobre Cloud Run: un par por edición, una para OTLP y otra para registros, porque un servicio de Cloud Run expone un solo puerto. Bajan a cero. Descartan credenciales y ruido, revisan las etiquetas de cada señal y reenvían a Grafana con el token de solo escritura de la edición, la única credencial de Grafana de ese lado. Un producto no necesita configurar nada: su dirección de la puerta de enlace llega en la salida Ready de su fábrica de proyectos, y los módulos del golden path se la pasan a cada servicio.

Etiquetas que dicen de dónde vino una señal

Dos etiquetas se verifican en cada señal. La etiqueta env es el entorno: prod, np, sandbox, eph-<iid> para la vista previa de un merge request, o platform. La puerta de enlace OTLP lo conserva solo cuando es válido para su propia edición y reemplaza un valor faltante o ajeno por unknown; la puerta de enlace de registros conserva uno válido y, si no, le da a la línea el de su perímetro, así que solo las entradas de auditoría quedan en unknown. Las dos marcan la edición como perimeter. De dónde viene: la puerta de enlace OTLP lo toma de deployment.environment.name o de deployment.environment cuando el recurso no trae env, y el módulo de Cloud Run del golden path fija este último en cada servicio. El agente de la plataforma lo fija en cada serie que recoge, a partir del proyecto y, en no producción, del nombre del servicio de Cloud Run (sandbox o eph-<iid>). La puerta de enlace de registros reduce el del perímetro de la misma manera y a las líneas de un proyecto de la plataforma les da platform. Las propias tareas programadas de la plataforma declaran platform en su recurso, así que sus series llevan env="platform"; el informe de costos guarda el entorno del proyecto al que pertenece un costo en una etiqueta aparte, project_env. Las series del informe de deriva siguen llegando como unknown hasta la próxima versión de la plataforma, que trae el componente que lo declara.

Las demás etiquetas dependen del camino de la señal. El módulo de Cloud Run del golden path les da a las trazas y las métricas de un servicio su nombre de servicio, su dominio y su entorno, como los atributos de OpenTelemetry service.name, service.namespace y deployment.environment. El agente de la plataforma etiqueta las métricas de recursos de la nube de cada proyecto de producto con facturación con product, la ruta del producto, y domain, su recorrido y su dominio. La puerta de enlace de registros conserva el proyecto, el servicio, el tipo de recurso y la severidad de cada línea de registro. Las señales de una aplicación no llevan ninguna etiqueta de equipo ni de criticidad.

Lo que recibe cada producto

La raíz de Grafana corre en la cadena de reconciliadores después de cada merge en el catálogo. A partir de la entrada de cada producto, crea:

una carpeta para el producto, que su equipo puede editar y que cada miembro puede ver;
tres paneles: el del servicio (solicitudes, errores, latencia, instancias, recursos), el de SLO, u objetivo de nivel de servicio, para sus metas de confiabilidad, y el de costos, con lo que va del mes y la previsión frente a monthly_budget, naranja al 80 por ciento y rojo al 100. Los paneles del servicio y de SLO abren en prod, y su primer filtro, env, cambia el entorno;
reglas de alerta básicas, con umbrales tomados del campo slo de la entrada: el presupuesto de errores que se consume rápido o despacio, más de 2 por ciento de errores del servidor, una latencia por encima del objetivo o del doble, Cloud SQL cerca de sus límites, mensajes de Pub/Sub que esperan más de diez minutos y un tema de mensajes fallidos que no está vacío. Juzgan solo producción, y una serie que falta no es una alerta.

Las alertas se enrutan por la etiqueta del equipo al punto de contacto del equipo, que manda un correo a los miembros del equipo que tienen una cuenta de Grafana, y un aviso urgente se repite cada cuatro horas hasta que se resuelve. Grafana Cloud acepta solo las direcciones de sus propios miembros, y hoy esos miembros son las propias cuentas del mantenedor, así que las alertas de cada equipo le llegan al mantenedor.

Los paneles de costos leen la exportación de facturación, que un trabajo diario convierte en métricas; la página de FinOps sigue ese presupuesto.

Los paneles propios de un producto

Un equipo que quiere más que los tres paneles los escribe como código en su propio repositorio: una llamada al módulo grafana-dashboard del golden path en la raíz infra/grafana del producto, con los paneles en Terraform o un panel exportado desde la interfaz de Grafana.

Esa raíz no tiene ninguna credencial de Grafana. Corre con la identidad de apply de producción del producto, en el entorno de GitLab grafana, y escribe cada panel como un archivo bajo el prefijo propio del producto en un bucket. La raíz de Grafana de la plataforma lee el bucket y ubica cada panel en la carpeta del producto, con la etiqueta product-owned. El repositorio es la versión de referencia: un panel cambiado solo en la interfaz de Grafana se sobrescribe en la siguiente reconciliación, así que un equipo lo exporta a su raíz para conservarlo.

Las vistas previas y el sandbox también se observan

Las vistas previas y el sandbox envían por la puerta de enlace de no producción como todo lo demás. Llevan su propio env, para que quien revisa vea la vista previa de un merge request en los mismos paneles al elegir eph-<iid>: el golden path fija deployment.environment con ese valor en el servicio de la vista previa, la puerta de enlace OTLP lo toma como env, y el agente de la plataforma y la puerta de enlace de registros lo derivan del nombre del servicio. Las reglas de alerta seleccionan solo producción, así que las vistas previas y el sandbox nunca avisan a nadie.

Lo propio de la plataforma

Los trabajos programados de la plataforma, como la detección de deriva, el recolector de vistas previas y los informes de costos y de cobertura, envían sus propias métricas. Una carpeta de la plataforma tiene el panel general, los costos de la plataforma y las medidas de entrega, y sus reglas mandan un correo al punto de contacto de la plataforma, por ejemplo cuando un pipeline programado no informó en un día. La compuerta tiene una verificación de disponibilidad propia: una verificación HTTP de Synthetic Monitoring de Grafana Cloud consulta su dirección /health cada 60 segundos desde dos sondas, y una regla avisa a la plataforma cuando más de una sonda falla durante dos minutos, o cuando la verificación no informa nada (aplicada). Un segundo grupo de reglas vigila las entradas de auditoría que un sink estrecho en la carpeta envía a Loki, como un intento de crear una clave, un rechazo de una política o una concesión (límites de confianza). Hoy esa dirección también es la propia cuenta del mantenedor; la dirección del grupo del equipo de plataforma la reemplaza cuando sea miembro del stack.

Diseñado, no construido

Las guardias (diseñadas). La herramienta de guardias e incidentes de Grafana tendría un calendario y una cadena de escalamiento por equipo, construidos a partir del bloque de guardias del equipo en el catálogo. Hoy una alerta es un correo.
El agente de operaciones y el agente de auditoría (diseñados). El primero investigaría una alerta en el nivel que permite el campo agentic_ops de la entrada; el segundo buscaría en toda la organización desperdicios y recursos huérfanos. Hoy ninguno de los dos existe.
Equipo y criticidad en las señales de una aplicación (diseñados). Sus trazas, métricas y registros no llevan ninguna etiqueta así.
El resto de las reglas básicas (diseñadas). Las reglas básicas también incluyen Cloud Run en su máximo de instancias, reinicios o falta de memoria, y una verificación de contratos bloqueada en main; la raíz de Grafana todavía no crea estas reglas.
Las verificaciones de disponibilidad de los productos (diseñadas). Las verificaciones de disponibilidad a través del nombre de host de producción de cada producto son la próxima versión de la raíz de telemetría. Hoy solo la compuerta tiene una (arriba).
Las reglas de alerta y los objetivos propios de un producto (diseñados). Los módulos grafana-alert y grafana-slo los publicarían como grafana-dashboard publica paneles; mientras tanto, las reglas básicas cubren las alertas.

El costo permanente es de unos USD 7 al mes por la instancia recolectora de no producción; la de producción entra en la cuota siempre gratuita de Google, las puertas de enlace bajan a cero y Grafana se queda en su nivel gratuito.

Dónde está

En el repositorio operations:

En el repositorio golden-path:

modules/grafana-dashboard/: el panel propio de un producto como código

En el repositorio landing-zone:

docs/guides/observability.md: la guía de observabilidad