Backend de observabilidad

El bloque de observabilidad (metrics, logs, traces, topology, monitors, rum y synthetics) puede servirlo Datadog, Grafana Cloud o SigNoz. Los tres declaran las mismas operaciones del catálogo, con nombres neutros respecto al proveedor.

Esa neutralidad es lo que hace que un segundo backend cueste “escribir un connector” en vez de “reescribir el diagnóstico”. Y también es lo que los hace mutuamente excluyentes.

RUNNER_OBSERVABILITY=datadog   # default
RUNNER_OBSERVABILITY=grafana
RUNNER_OBSERVABILITY=signoz
RUNNER_OBSERVABILITY=none      # tenant without observability

La elección es explícita, no inferida

El runner no elige el provider mirando qué credencial está presente. Es deliberado: inferir produciría un “mi Datadog dejó de responder” sin causa visible en la configuración.

datadog es el valor por defecto, así que todo runner existente se comporta igual sin tocar nada.

Datadog

RUNNER_CONNECTORS=real
DD_API_KEY=…
DD_APP_KEY=…
# DD_SITE=datadoghq.com   # optional: datadoghq.eu / us3 / us5 / ap1

Grafana Cloud

RUNNER_CONNECTORS=real RUNNER_OBSERVABILITY=grafana \
  GRAFANA_CLOUD_TOKEN=… \
  GRAFANA_PROM_URL=https://prometheus-prod-XX-prod-REGION.grafana.net/api/prom

A diferencia de Datadog, Grafana expone un endpoint por datasource: Mimir, Loki y Tempo tienen hosts distintos, y cada uno autentica por HTTP Basic, con el usuario igual al ID numérico de la instancia y la contraseña igual al token de la Access Policy. Sin _USER, el token se envía como Bearer.

Solo el token y Mimir son obligatorios. Mimir es la columna vertebral: ahí viven el service graph y las métricas de Faro y de Synthetics. Loki, Tempo y Alerting se degradan operación por operación, con errores accionables.

Variable	Obligatoria	Para qué
`GRAFANA_CLOUD_TOKEN`	sí	Token de la Access Policy.
`GRAFANA_PROM_URL`	sí	Mimir.
`GRAFANA_PROM_USER`	no	El ID numérico de la instancia.
`GRAFANA_LOKI_URL` / `_USER`	no	Logs.
`GRAFANA_TEMPO_URL` / `_USER`	no	Traces.
`GRAFANA_STACK_URL`	no	API de Alerting (monitors).
`GRAFANA_SYNTHETICS_URL`	no	Por defecto, `https://synthetic-monitoring-api.grafana.net`.

Mapeo de labels

Este es el punto en que una instalación de Grafana funciona con el primer cliente y se rompe con el segundo.

service y env son conceptos de primera clase en Datadog. En Prometheus y Loki son la convención de labels del cliente, y puede ser service, app, job o el service_name de OTel. Los valores por defecto de abajo son una convención, no una garantía.

Variable	Por defecto
`GRAFANA_SERVICE_LABEL`	`service`
`GRAFANA_ENV_LABEL`	`env`
`GRAFANA_NAMESPACE_LABEL`	`namespace`
`GRAFANA_HOST_LABEL`	`instance`
`GRAFANA_ROUTE_LABEL`	`http_route`

Descubre los tuyos con el endpoint /api/v1/labels de Mimir.

SigNoz

RUNNER_CONNECTORS=real RUNNER_OBSERVABILITY=signoz \
  SIGNOZ_ENDPOINT=http://signoz.observability.svc.cluster.local:8080 \
  SIGNOZ_API_KEY=…

SigNoz es el primer backend autoalojado soportado, y eso cambia dos cosas respecto a los otros dos.

El endpoint suele ser interno. Datadog y Grafana Cloud son hosts públicos del proveedor; tu SigNoz normalmente solo existe dentro de tu red. WhyStack lo alcanza porque el runner corre ahí dentro: es una consecuencia directa del modelo BYOC, y una dirección a la que un SaaS de observabilidad alojado nunca llegaría. Usa el nombre de servicio interno; no expongas la instancia solo para configurar WhyStack.

La versión varía. Datadog y Grafana Cloud tienen exactamente una versión, la que opera el proveedor. Un SigNoz autoalojado puede estar meses atrasado. El connector usa la API query_range v5; las instalaciones anteriores no están soportadas, y el self-check de boot reporta la versión que encontró en vez de fallar de forma oscura en la primera lectura.

Variable	Obligatoria	Para qué
`SIGNOZ_ENDPOINT`	sí	URL base de la instancia. Puede ser HTTP interno.
`SIGNOZ_API_KEY`	sí	Clave de service account (header `SIGNOZ-API-KEY`).

Capabilities: lo que sirve, y lo que no

Sirve metrics, logs, traces, topology (el service map, que en SigNoz vive como métrica) y monitors (las alert rules).

No sirve rum ni synthetics, y esa ausencia se declara a propósito. El frontend monitoring de SigNoz es OTel de navegador, que no responde las mismas preguntas que el RUM de Datadog, y no hay producto de synthetics. Como WhyStack oculta de la superficie del agente toda tool cuyas operaciones nadie sirve, esas tools simplemente no aparecen, en vez de aparecer y responder una media verdad. Un tenant SigNoz + Checkly sigue teniendo synthetics, porque el especialista entra por separado.

Mapeo de campos

El mismo problema que con Grafana, sobre terreno más firme: SigNoz es OTel-native, así que el vocabulario tiende a ser semconv. Los valores por defecto son un piso defendible, no una suposición. Pero siguen siendo ajustables, porque semconv 1.27 renombró deployment.environment a deployment.environment.name y las dos generaciones conviven en la práctica.

Variable	Por defecto
`SIGNOZ_SERVICE_FIELD`	`service.name`
`SIGNOZ_ENV_FIELD`	`deployment.environment`
`SIGNOZ_NAMESPACE_FIELD`	`k8s.namespace.name`
`SIGNOZ_HOST_FIELD`	`host.name`
`SIGNOZ_ROUTE_FIELD`	`http.route`

Checkly: el especialista que asume `synthetics`

CHECKLY_API_KEY=…
# CHECKLY_ACCOUNT_ID=…

checkly se dedica a una capability. Cuando está presente, asume synthetics del provider general que esté configurado, y convive tanto con Datadog como con Grafana. Sin CHECKLY_API_KEY, synthetics se queda con el provider. El boot dice quién es dueño de la capability en los dos casos, en una línea capability arbitration (owner: checkly u owner: datadog).

Aquí, a diferencia de la elección del provider, inferir por credencial es seguro: con la clave, el especialista asume; sin ella, nada cambia para el provider.

CHECKLY_ACCOUNT_ID es obligatorio en la práctica para un token de usuario, porque sin él la API responde 401 sin decir por qué. Para un token de cuenta o de servicio no hace falta.

Analytics: la segunda familia exclusiva

RUNNER_ANALYTICS=amplitude   # or mixpanel, or none

Amplitude y Mixpanel responden la misma pregunta (volumen de eventos, usuarios activos, retención) cambiando de fuente. Por eso reutilizan las mismas operaciones del catálogo y son mutuamente excluyentes, exactamente por la misma razón que el bloque de observabilidad: dos fuentes declarando la misma operación harían que el Agent se negara a arrancar, porque el despacho tiene que saber a quién enviar.

La elección es explícita y nunca se infiere de una credencial presente, por la razón de siempre: inferir produciría un “mi Amplitude dejó de responder” sin causa visible.

Mixpanel sirve 8 de las 16 operaciones, y es por diseño

No hay API de Boards, Insights solo responde por bookmark de reporte guardado (sin listado), y no hay realtime ni métrica de sesión calculada del lado del servidor. En un proyecto de Mixpanel, las tools que dependen de esas operaciones desaparecen de la superficie del agente, en vez de devolver una lista vacía que se leería como “este proyecto no tiene dashboards”.

Cuota

La Query API de Mixpanel permite 60 consultas por hora y 5 concurrentes, por proyecto. Amplitude no tiene equivalente. El connector ya lo maneja: la lectura de volumen toma su línea base de la misma consulta en vez de hacer dos, y un 429 vuelve con el tiempo de espera en vez de convertirse en “la fuente se cayó”.

Deploys: tres fuentes, tres preguntas, ninguna en competencia

Vercel: ortogonal, no en competencia

VERCEL_TOKEN=…
VERCEL_TEAM_ID=…

Vercel no disputa con GitHub la propiedad de ninguna operación, porque los dos responden hechos distintos: GitHub responde “qué PR se fusionó”, Vercel responde “qué artefacto salió al aire”. Por eso Vercel crea sus propias operaciones, con nombres propios del proveedor, y entra directamente en el conjunto de connectors, sin arbitraje.

VERCEL_TEAM_ID es obligatorio en la práctica para un token de equipo (sin él la API responde 403 sin explicar) y está ausente en una cuenta personal. Usa un token read-only con alcance al equipo.

Argo CD: la tercera pregunta

ARGOCD_SERVER_URL=https://argocd-server.argocd.svc.cluster.local
ARGOCD_TOKEN=…

Si tu backend llega a Kubernetes por GitOps, ni GitHub ni Vercel responden lo que importa. Las tres preguntas son distintas, y por eso los tres connectors conviven sin disputar nada:

Fuente	Responde
GitHub	qué PR se fusionó
Vercel	qué artefacto de frontend salió al aire
Argo CD	qué revisión está corriendo el clúster

La tercera es la única que sobrevive a la pregunta “¿el merge de ayer ya está en producción?” Entre el merge y el deploy cabe el incidente entero.

Dos ganancias concretas: la revisión sincronizada es el commit, así que deploy → commit → PR → diff sale directo, sin emparejar tags de imagen; y un rollback es un evento en el registro (una sincronización a una revisión ya vista) en vez de algo que inferir de un commit de revert.

El servidor suele ser interno al clúster, y el Agent lo alcanza porque corre ahí dentro. Usa una cuenta local con RBAC de solo lectura. Consulta Alcances y permisos.

El criterio: ¿reutilizar la operación o crear una nueva?

Si vas a escribir un segundo connector para una capability que ya tiene dueño, el criterio es semántico:

¿El consumidor que ya usa esta operación aceptaría la respuesta del nuevo connector como equivalente?

Sí → reutiliza la operación. Es el caso de Grafana en metrics.*: p99 es p99. catalogHash queda intacto, nada cambia para los consumidores, y el connector pasa por el arbitraje, porque disputa la propiedad de la operación.

No → una operación nueva, con un nombre propio del proveedor. Es el caso de Vercel y Argo CD. catalogHash cambia deliberadamente, y el connector entra directo, sin arbitraje, porque las operaciones son disjuntas.

Una operación con más de una implementación necesita un contrato

Cuando dos implementaciones sirven la misma operación, un nombre compartido no alcanza: hace falta un contrato de output declarado. Es lo que hace seguro “cambiar el dueño de la operación”.

El contrato es por operación, no por capability, y es un piso, no un techo: un campo extra pasa, un campo declarado que falta degrada la capability a opaque.

Al agregar o cambiar una operación servida por dos o más connectors, actualiza el contrato y corre la suite de conformidad contra las implementaciones, con un escenario poblado y uno vacío.