El gasto en observability crece mas rapido que la infraestructura que vigila. Los equipos entregan dashboards que nadie lee, alertas en las que nadie confia y facturas que hacen que el CFO formule preguntas incomodas. Existe una arquitectura mejor -- y comienza por admitir que la mayor parte de lo que recopilas es desperdicio.

Operamos 22 sistemas en produccion. Nuestra factura combinada de observability es inferior al presupuesto mensual de cafe de un solo ingeniero. No porque seamos negligentes. Porque somos deliberados. Este articulo explica como llegamos ahi, y por que tal vez quieras seguir el mismo camino.

I. La factura que nadie esperaba

En algun momento alrededor de 2023, un patron emergio en nuestros proyectos de consultoria. Equipos que habian dedicado anos a optimizar su computo en la nube -- dimensionamiento correcto de instancias, migracion a ARM, adopcion de serverless -- abrian su factura mensual y encontraban una nueva linea que silenciosamente devoraba sus ahorros.

Datadog. New Relic. Splunk. Elastic Cloud. Dynatrace.

El proveedor de observability se habia convertido en la segunda o tercera linea mas grande. En algunos casos, la mayor. Un cliente fintech con 40 microservicios en AWS gastaba $8.200/mes en EKS y Fargate. Su factura de Datadog era $14.600/mes. La herramienta que vigilaba la infraestructura costaba un 78% mas que la propia infraestructura.

Esto no es una anomalia. Esto es el mercado.

Los ingresos anuales de Datadog superaron los $2.100 millones en 2024. New Relic, Splunk (ahora Cisco), Elastic y Dynatrace representan colectivamente un mercado superior a $40.000 millones. Ese dinero viene de algun lado. Viene de ti.

La pregunta no es si la observability importa. Importa. La pregunta es si tu arquitectura de observability es proporcional a las decisiones que habilita. Para la mayoria de los equipos, la respuesta es no.

II. La trampa de precios: Como extraen valor los proveedores

Comprender el costo requiere comprender los modelos de precios. No estan disenados para la transparencia. Estan disenados para la dependencia y la sorpresa.

Precio por host. Datadog cobra por host por mes. El monitoreo de infraestructura comienza en aproximadamente $15/host/mes, pero APM lo eleva a $31-40/host. Un cluster de Kubernetes con 100 nodos cuesta $3.100-4.000/mes antes de activar una sola metrica personalizada.

Precio por GB de ingesta. La gestion de logs cobra por volumen. Datadog cobra aproximadamente $0,10/GB ingestado en el primer nivel, con costos de retencion adicionales. Una aplicacion moderadamente verbosa que produce 500 GB/mes de logs son $50/mes solo por ingesta -- antes de indexacion, alertas o retencion.

Precio por metrica personalizada. Aqui es donde mueren los presupuestos. El plan base de Datadog incluye 100 metricas personalizadas. Cada metrica personalizada adicional cuesta aproximadamente $0,05/mes. Suena economico hasta que un desarrollador instrumenta un servicio con Prometheus y accidentalmente crea 50.000 metricas personalizadas a partir de etiquetas de alta cardinalidad. Eso son $2.500/mes de un solo despliegue.

Precio por span para trazas. Ingestar 1.000 millones de spans/mes a $0,0000002/span no suena costoso. Hasta que te das cuenta de que una sola solicitud de API a traves de 8 microservicios produce 8+ spans, y a 10.000 solicitudes/segundo estas generando 6.900 millones de spans/mes. Las cuentas se ponen serias rapido.

Cost model for a mid-size SaaS (100 hosts, 50 services):


Infrastructure monitoring:  100 hosts x $23/mo  = $ 2,300
  APM (50 services):          50 hosts  x $40/mo  = $ 2,000
  Log management (2TB/mo):    2,000 GB  x $0.10   = $   200
  Log indexing + retention:                        = $ 1,800
  Custom metrics (15,000):    15,000    x $0.05   = $   750
  Trace ingestion (5B spans): 5B x $0.0000002     = $ 1,000
  Synthetics (500 tests):     500       x $12/mo  = $ 6,000
  RUM (1M sessions):                               = $ 1,500
  ─────────────────────────────────────────────────────────
  Monthly total:                                   ~$15,550
  Annual total:                                    ~$186,600

Eso equivale a dos ingenieros senior. O a la factura completa de la nube para un sistema bien arquitecturado a la misma escala. Y crece con cada host que agregas, cada metrica que creas, cada linea de log que emites.

III. Monitoreo impulsado por el miedo y el cementerio de dashboards

El costo seria defendible si cada dolar impulsara una decision. No lo hace.

La mayoria de las configuraciones de observability son producto del miedo. Ocurre un incidente. Alguien dice "necesitamos mas visibilidad." Se construye un dashboard. Se crea una alerta. Nadie elimina el dashboard seis meses despues cuando el problema subyacente ha sido corregido. Nadie revisa si la alerta alguna vez se disparo. La superficie de monitoreo crece monotonicamente.

Tenemos un nombre para esto: el cementerio de dashboards. Toda organizacion tiene uno. Filas de paneles de Grafana que nadie ha abierto en meses. Dashboards de Datadog creados por ingenieros que dejaron la empresa hace dos anos. Servicios de PagerDuty con reglas de alerta que referencian infraestructura que ya no existe.

El costo no es solo financiero. La fatiga de alertas es real y medible.

Un estudio de 2023 del propio equipo de investigacion de PagerDuty encontro que el ingeniero de guardia promedio recibe mas de 25 alertas por turno. De esas, menos de 3 son accionables. El resto es ruido -- violaciones de umbrales en metricas que no correlacionan con el impacto al usuario, picos transitorios que se resuelven solos y alertas en cascada de una sola causa raiz.

La regla 90/10: el 90% de las alertas son ruido. El 10% son accionables. Y el ruido hace que la senal sea mas dificil de encontrar.

Alert taxonomy (based on audit of 4 client systems, 2024-2025):


Actionable + urgent:      8%   -- Real incidents, need human response
  Actionable + deferred:    4%   -- Real issues, can wait for business hours
  Informational:           22%   -- Interesting but requires no action
  Noise (self-resolving):  41%   -- Transient spikes, auto-scaling events
  Stale (dead references): 25%   -- Alerts on decommissioned services

Si una cuarta parte de tus alertas referencian infraestructura que ya no existe, tu observability no esta proporcionando visibilidad. Esta proporcionando teatro.

IV. El problema de la instrumentacion de culto cargo

Existe un patron en como los equipos adoptan observability que refleja como adoptan las pruebas: comienzan con buenas intenciones y terminan con metricas de cobertura que miden esfuerzo, no valor.

El culto cargo funciona asi:

  1. Lee un articulo de blog sobre como Uber instrumenta sus microservicios.
  2. Instala el agente de Datadog en todo.
  3. Activa APM en cada servicio.
  4. Agrega metricas personalizadas para cada contador, gauge e histograma que se te ocurra.
  5. Construye dashboards que se ven impresionantes en las demos de sprint.
  6. Nunca elimines nada.

El resultado es una instrumentacion exhaustiva de un sistema que no comprendes mejor que antes. Tienes mas datos. No tienes mas perspectiva.

La distincion importa. Los datos son lo que tus sistemas emiten. La perspectiva es lo que cambia tu comportamiento. Una metrica que nadie consulta no es observability. Es un asiento contable.

Considera la alternativa: en lugar de instrumentar todo y esperar a que emerjan patrones, comienzas preguntando que decisiones necesitas tomar y trabajas hacia atras hasta los datos minimos requeridos para tomarlas.

Decision: Esta la API saludable desde la perspectiva del usuario? Datos minimos: Latencia de solicitud P50/P95/P99, tasa de errores y disponibilidad -- tres metricas por endpoint.

Decision: Se esta acercando la base de datos a los limites de capacidad? Datos minimos: Utilizacion del pool de conexiones, latencia de consultas P95, porcentaje de uso de disco -- tres metricas.

Decision: El ultimo despliegue causo una regresion? Datos minimos: Delta de tasa de errores y delta de latencia comparados con la ventana de 24 horas anterior -- dos metricas.

No necesitas 15.000 metricas personalizadas para responder estas preguntas. Necesitas menos de 100.

V. El estandar OpenTelemetry: Tu estrategia de salida

OpenTelemetry es el proyecto de infraestructura mas importante que la mayoria de los equipos esta ignorando. Es un framework de observability de codigo abierto y neutral respecto a proveedores que estandariza como se recopilan, procesan y exportan los datos de telemetria -- trazas, metricas y logs.

Por que importa: desacopla la instrumentacion del destino. Instrumentas tu codigo una vez con los SDK de OpenTelemetry y puedes enviar esos datos a cualquier backend. Datadog hoy, Grafana Cloud manana, ClickHouse autoalojado el proximo trimestre. Sin re-instrumentacion. Sin dependencia de proveedor.

El OpenTelemetry Collector es la pieza arquitectonica clave. Se situa entre tus aplicaciones y tus backends, gestionando la recopilacion, el procesamiento, el filtrado y el enrutamiento.

# otel-collector-config.yaml


receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318



processors:
  batch:
    timeout: 5s
    send_batch_size: 8192



# Drop metrics you don't need before they hit storage
  filter/metrics:
    metrics:
      exclude:
        match_type: regexp
        metric_names:
          - "http.server.request.body.size"
          - "runtime.cpython.*"
          - "process.runtime.*"



# Sample traces intelligently -- keep errors, sample successes
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors-always
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-requests
        type: latency
        latency: { threshold_ms: 2000 }
      - name: sample-normal
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }



# Add deployment context to every signal
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert
      - key: service.version
        from_attribute: DEPLOY_SHA
        action: upsert



exporters:
  otlp/tempo:
    endpoint: tempo.internal:4317
    tls:
      insecure: false
  prometheusremotewrite:
    endpoint: http://mimir.internal/api/v1/push
  loki:
    endpoint: http://loki.internal/loki/api/v1/push



service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling, resource, batch]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [filter/metrics, resource, batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [loki]

La perspectiva clave esta en la seccion processors. Antes de que un solo byte llegue a tu backend de almacenamiento, el collector filtra las metricas que no necesitas, muestrea trazas inteligentemente (conservando errores y solicitudes lentas mientras muestrea el trafico rutinario al 5%) y enriquece todo con contexto de despliegue.

Esa etapa de filtrado es donde recuperas el 60-80% de tu presupuesto de observability.

VI. Logging estructurado que realmente funciona

La mayoria del logging es narrativo. Un desarrollador escribe logger.info("Processing order for customer") y sigue adelante. Esa linea de log es legible para humanos e inutil para maquinas. No puedes agregarla, filtrarla ni alertar sobre ella sin acrobacias de regex.

El logging estructurado invierte esto. Cada entrada de log es un evento tipado con campos nombrados. La narrativa sigue ahi -- en el campo message -- pero los datos accionables viven en atributos estructurados.

// Bad: narrative logging
logger.info(Processing order ${orderId} for customer ${customerId});
logger.error(Payment failed for order ${orderId}: ${error.message});


// Good: structured logging with OpenTelemetry semantic conventions
logger.info("order.processing", {
  order_id: orderId,
  customer_id: customerId,
  currency: order.currency,
  amount_cents: order.totalCents,
  items_count: order.items.length,
});



logger.error("payment.failed", {
  order_id: orderId,
  customer_id: customerId,
  payment_provider: "stripe",
  error_code: error.code,
  error_category: categorizePaymentError(error),
  retry_eligible: isRetryable(error),
  attempt_number: attemptCount,
});

La version estructurada cuesta lo mismo de emitir pero es infinitamente mas util aguas abajo. Puedes consultar todos los pagos fallidos por proveedor. Puedes calcular tasas de error elegibles para reintento. Puedes construir alertas sobre error_category en lugar de hacer coincidencia regex con mensajes de error que cambian con cada refactorizacion.

Una taxonomia de niveles de log con significado

La mayoria de los equipos tratan los niveles de log como sensaciones. Aqui hay una taxonomia que vincula cada nivel a una respuesta operativa:

Nivel Significado Respuesta operativa Retencion
FATAL El proceso no puede continuar. Los datos pueden estar en riesgo. Alerta inmediata. Todos disponibles. Para siempre
ERROR La operacion fallo. Impacto al usuario confirmado. Alertar al de guardia. Investigar dentro del SLO. 90 dias
WARN Degradado pero funcional. Acercandose a un limite. Crear ticket. Revisar el siguiente dia habil. 30 dias
INFO Hitos de operacion normal. Transiciones de estado. Sin accion. Disponible para investigacion. 14 dias
DEBUG Flujo detallado para resolucion activa de problemas. Sin accion. Activar bajo demanda. 3 dias

La columna de retencion es la palanca de costos. Si los logs de DEBUG representan el 60% de tu volumen y los retienes 3 dias en lugar de 30, acabas de reducir los costos de almacenamiento en un 54%. Si desactivas DEBUG en produccion por completo y lo activas por servicio al investigar, los ahorros son mayores.

VII. Telemetria en el edge: La observability mas economica que no estas usando

Si despliegas en Cloudflare Workers, Vercel Edge Functions o cualquier CDN con capacidades de analitica, ya tienes una capa de telemetria que la mayoria de los equipos ignora.

Cloudflare Workers Analytics Engine proporciona metricas por solicitud en el edge -- latencia, codigos de estado, tasas de acierto de cache, distribucion geografica -- sin costo adicional mas alla de tu plan de Workers. Sin agente que instalar. Sin SDK que integrar. Sin precio por metrica.

// Cloudflare Worker: lightweight telemetry at the edge
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const start = Date.now();
    const url = new URL(request.url);


try {
      const response = await handleRequest(request, env);
      const duration = Date.now() - start;



// Write to Analytics Engine -- included in Workers plan
      env.TELEMETRY.writeDataPoint({
        blobs: [
          url.pathname,                    // index 1: route
          response.status.toString(),      // index 2: status
          request.headers.get("cf-ipcountry") || "XX", // index 3: country
        ],
        doubles: [
          duration,                        // index 1: latency_ms
          response.headers.get("content-length")
            ? parseInt(response.headers.get("content-length")!)
            : 0,                           // index 2: response_bytes
        ],
        indexes: [url.pathname],           // queryable index
      });



return response;
    } catch (err) {
      env.TELEMETRY.writeDataPoint({
        blobs: [url.pathname, "500", "error"],
        doubles: [Date.now() - start, 0],
        indexes: [url.pathname],
      });
      throw err;
    }
  },
};

Puedes consultar estos datos con SQL a traves de la API de Cloudflare o GraphQL. Latencia P50/P95 por ruta, tasas de error por pais, patrones de trafico por hora. Los datos que necesitas para el 80% de las decisiones operativas, recopilados en el punto mas cercano al usuario, con costo marginal cero.

Esta es la inversion de observability: en lugar de extraer metricas desde el interior de tu sistema hacia afuera, las capturas en la frontera donde los usuarios realmente experimentan tu servicio.

VIII. La arquitectura: Almacenamiento economico, consultas inteligentes

Las plataformas comerciales de observability agrupan tres cosas: recopilacion, almacenamiento y consulta. Cobran precios premium porque el paquete es conveniente. Pero cada componente tiene una alternativa commoditizada que cuesta entre 5 y 20 veces menos.

The Observability Tax architecture vs. the alternative:


VENDOR BUNDLE                    UNBUNDLED ARCHITECTURE
  ┌──────────────────────┐         ┌─────────────────────────────────┐
  │  App + Agent          │         │  App + OTel SDK                  │
  │       │               │         │       │                          │
  │       v               │         │       v                          │
  │  Vendor Collector     │         │  OTel Collector (self-hosted)    │
  │       │               │         │       │         │         │      │
  │       v               │         │       v         v         v      │
  │  Vendor Storage       │         │   ClickHouse  S3/R2    Loki     │
  │  ($$$$/GB)            │         │   (metrics+   (cold    (logs)   │
  │       │               │         │    traces)    archive)          │
  │       v               │         │       │         │         │      │
  │  Vendor UI            │         │       └────┬────┘─────────┘      │
  │  (included)           │         │            v                     │
  │                       │         │        Grafana                   │
  │  Cost: ~$15K/mo       │         │        (dashboards + alerts)     │
  │                       │         │                                  │
  │                       │         │  Cost: ~$1.5K-3K/mo             │
  └──────────────────────┘         └─────────────────────────────────┘

Los componentes:

ClickHouse para almacenamiento de metricas y trazas. Orientado a columnas, tasas de compresion de 10-20x en telemetria estructurada, rendimiento de consultas que rivaliza con sistemas TSDB dedicados. Los precios de ClickHouse Cloud comienzan en aproximadamente $0,03/GB para almacenamiento comprimido -- aproximadamente 10-30 veces mas economico que el almacenamiento APM comercial cuando se tiene en cuenta la compresion.

S3/R2/GCS para archivo frio. Despues de 7-14 dias, mueve la telemetria cruda a almacenamiento de objetos. Cloudflare R2 cobra $0,015/GB/mes sin cargos por trafico de salida. Consulta bajo demanda con Athena, DuckDB o tablas externas de ClickHouse.

Grafana para visualizacion y alertas. Grafana en si es codigo abierto. El nivel gratuito de Grafana Cloud maneja 10.000 metricas, 50 GB de logs y 50 GB de trazas por mes. El nivel de pago comienza en aproximadamente $0,50/1.000 series de metricas -- aun una fraccion del precio APM comercial.

Loki para agregacion de logs. Disenado por el equipo de Grafana como un "Prometheus para logs." No indexa el contenido de los logs -- solo las etiquetas. Esto lo hace dramaticamente mas economico de operar que Elasticsearch/Splunk para almacenamiento de logs.

Una comparacion de costos real

Para el mismo SaaS mediano de la Seccion II (100 hosts, 50 servicios):

Commercial APM (Datadog-class):     ~$186,600/year


Unbundled architecture:
    ClickHouse Cloud (metrics+traces):  $  7,200/year
    R2 cold storage (24 months):        $  2,160/year
    Grafana Cloud (Pro):                $  6,000/year
    Loki (self-hosted on 2 nodes):      $  3,600/year
    OTel Collector (3 nodes):           $  2,400/year
  ──────────────────────────────────────────────────
    Total:                              ~ $21,360/year



Annual savings:                       ~$165,240
  Savings percentage:                   ~89%

La contrapartida es la complejidad operativa. Tu operas el collector. Tu administras ClickHouse (o pagas por ClickHouse Cloud). Tu configuras los dashboards de Grafana. Esto requiere un equipo que entienda los componentes. No es esfuerzo cero.

Pero es esfuerzo honesto. Estas pagando por tiempo de ingenieria en lugar de margen del proveedor. Y los ingenieros que operan este stack entienden su observability profundamente -- porque lo construyeron. Esa comprension vale mas que cualquier dashboard de proveedor.

IX. Cuando las plataformas comerciales son la respuesta correcta

Este articulo no es una polemica contra la observability comercial. Hay casos genuinos donde pagar el impuesto es racional:

Startups en fase temprana sin capacidad de operaciones. Si tienes 5 ingenieros y ninguna persona dedicada a operaciones, el modelo de instalar-y-listo de Datadog ahorra tiempo que no puedes permitirte gastar. El costo es real pero el costo en tiempo del autoalojamiento es mayor. Reevalua cuando llegues a 50 ingenieros o $10.000/mes en gasto de observability.

Sistemas distribuidos genuinamente complejos. Si operas mas de 200 microservicios en multiples nubes con runtimes poliglotas, el motor de correlacion de Datadog o New Relic proporciona un valor dificil de replicar con herramientas de codigo abierto. El mapa de servicios, la correlacion automatica de trazas, la deteccion de anomalias -- estas caracteristicas justifican un precio premium cuando la alternativa es un equipo de tres dedicando todo su trimestre a construir equivalentes.

Entornos de cumplimiento con requisitos de auditoria. Algunas industrias reguladas requieren politicas de retencion especificas, controles de acceso y registros de auditoria que las plataformas comerciales proporcionan de forma nativa. Construir infraestructura de logs compatible con SOC 2 desde cero es posible, pero costoso en una moneda diferente.

Equipos sin interes en convertirse en expertos en observability. Esto es valido. No todos los equipos deberian construir su propio stack de monitoreo. Si la observability no es una competencia central y prefieres dedicar el tiempo de ingenieria a funcionalidades del producto, el impuesto del proveedor es una compensacion razonable. Solo ten presente que lo estas pagando.

La prueba es simple: divide tu gasto anual en observability por el numero de incidentes que te ayudo a resolver. Si el costo por incidente supera el costo del incidente en si, estas sobreinstrumentado.

X. El enfoque de Gothar: 22 sistemas, impuesto minimo

Practicamos lo que predicamos. Asi es como observamos 22 sistemas en produccion a traves de Cloudflare Workers, AWS e infraestructura bare-metal:

Capa 1: Telemetria en el edge. Cada Cloudflare Worker escribe en Analytics Engine. Latencia a nivel de ruta, codigos de estado, rendimiento de cache. Costo marginal cero. Esto cubre el 70% de nuestras preguntas de "esta el sistema saludable?".

Capa 2: Logging estructurado con propagacion de contexto. Cada servicio emite logs JSON estructurados con trace IDs, request IDs y SHAs de despliegue. Los logs se envian a Loki a traves del OTel Collector. Retencion: 14 dias en caliente, 90 dias en frio en R2.

Capa 3: Cuatro senales doradas por servicio. Latencia (P50/P95/P99), trafico (solicitudes/seg), errores (tasa) y saturacion (utilizacion de recursos). Exportadas como metricas Prometheus via el SDK de OTel. Almacenadas en una instancia ligera de Mimir. Sin metricas personalizadas mas alla de estas cuatro categorias.

Capa 4: Trazas bajo demanda. No trazamos cada solicitud. Trazamos errores, solicitudes lentas (>2s) y una muestra del 5% del trafico normal. Almacenadas en Tempo. Consultadas a traves de Grafana al investigar incidentes especificos.

Capa 5: Canarios sinteticos. Verificaciones HTTP simples contra endpoints criticos, cada 60 segundos, desde tres regiones geograficas. Cloudflare Health Checks mas un punado de Workers personalizados. Las alertas van a un unico canal de Slack con rotacion de guardia.

Gasto total en observability para 22 sistemas: aproximadamente $340/mes. No es un error tipografico. La telemetria en el edge es gratuita. Loki, Mimir y Tempo corren en dos VMs modestas ($85/mes cada una). El almacenamiento en R2 es insignificante. El nivel gratuito de Grafana Cloud cubre nuestras necesidades de dashboards y alertas.

La restriccion que hace esto posible: decidimos que preguntas necesitamos responder antes de decidir que recopilar. La disciplina en la fase de diseno elimina el desperdicio en la fase de facturacion.

XI. La ruta practica de migracion

Si actualmente estas pagando el impuesto de observability y quieres reducirlo, no hagas un reemplazo total. Migra incrementalmente:

Mes 1: Auditoria. Inventaria cada dashboard, alerta y metrica. Para cada uno, responde: cuando fue la ultima vez que se consulto? Impulso una decision? Elimina todo lo que falle ambas pruebas. La mayoria de los equipos pueden eliminar el 40-60% de su superficie de observability en este paso solo, sin riesgo alguno.

Mes 2: Instrumentar con OpenTelemetry. Agrega el SDK de OTel junto a tu agente de proveedor existente. Envia telemetria en paralelo tanto a tu proveedor actual como a un collector autoalojado. Esto te da una linea base de comparacion sin ninguna interrupcion.

Mes 3: Montar almacenamiento economico. Despliega ClickHouse Cloud o una instancia autoalojada, Loki para logs y Grafana para dashboards. Enruta la salida del OTel Collector a ambos backends. Verifica que tu stack autoalojado responde las mismas preguntas que la plataforma comercial.

Mes 4: Migracion. Desactiva el agente del proveedor en servicios no criticos primero. Monitorea en busca de vacios. Expande a todos los servicios en 2-4 semanas. Mantiene el contrato con el proveedor activo un mes mas como seguro.

Mes 5: Optimizar. Ahora que controlas el pipeline, implementa filtrado y muestreo agresivos en el OTel Collector. Elimina metricas que nadie consulta. Muestrea trazas rutinarias. Acorta la retencion de logs de debug. Aqui es donde se materializa la reduccion de costos del 80-90%.

XII. Lo que la observability deberia ser

La observability existe para informar decisiones. No para proporcionar confort. No para generar dashboards. No para marcar una casilla de SOC 2. Para informar decisiones.

Cada metrica deberia tener un propietario y un plan de respuesta. Cada alerta deberia tener un runbook. Cada dashboard deberia responder una pregunta que alguien realmente formula. Todo lo demas es costo sin valor.

Al antiguo medico griego Hipocrates se le atribuye el principio: "Primero, no hagas dano." El equivalente en observability es: primero, no desperdicies. No recopiles datos que no vas a consultar. No alertes sobre condiciones ante las que no vas a actuar. No retengas logs mas alla de la ventana en la que son utiles.

Hay un paralelo mas profundo aqui. En las Meditaciones de Marco Aurelio, vuelve repetidamente a la idea de distinguir entre lo que esta en tu control y lo que no. La disciplina estoica consiste en enfocar la atencion y la energia exclusivamente en lo primero. La observability, practicada correctamente, es una disciplina estoica. No puedes prevenir cada incidente. Puedes controlar que mides, sobre que alertas y como respondes. El resto es ruido -- y el ruido, en observability como en filosofia, es el enemigo de la claridad.

El mejor sistema de monitoreo es aquel que comprendes completamente, que cuesta proporcionalmente al valor que proporciona y que podrias reconstruir desde cero en una semana. Si tu proveedor de observability desapareciera manana, estarias perdido -- o liberado?

Esa pregunta merece una respuesta honesta.

Referencias

  1. Datadog, Inc. "Pricing." datadoghq.com/pricing
  2. OpenTelemetry Project. "OpenTelemetry Collector Documentation." opentelemetry.io/docs/collector
  3. ClickHouse, Inc. "ClickHouse Cloud Pricing." clickhouse.com/pricing
  4. Grafana Labs. "Grafana Loki Documentation." grafana.com/docs/loki
  5. Cloudflare. "Workers Analytics Engine." developers.cloudflare.com/analytics/analytics-engine
  6. Charity Majors, Liz Fong-Jones, George Miranda. Observability Engineering. O'Reilly Media, 2022.
  7. Google SRE Team. "Monitoring Distributed Systems." sre.google/sre-book/monitoring-distributed-systems
  8. Cindy Sridharan. Distributed Systems Observability. O'Reilly Media, 2018.
  9. PagerDuty. "State of Digital Operations Report 2023." pagerduty.com/resources
  10. Cloudflare. "R2 Pricing." developers.cloudflare.com/r2/pricing
  11. Grafana Labs. "Grafana Tempo Documentation." grafana.com/docs/tempo
  12. New Relic, Inc. "New Relic Pricing." newrelic.com/pricing