¿Por qué carajo es la observabilidad tan cara?

¡ACTÚA YA! ¡OFERTA POR TIEMPO LIMITADO! ¡LOS OPERADORES ESTÁN A LA ESPERA! Estoy listo para mi próxima aventura como promotor de DevRel, evangelista técnico y creador de historias de TI. Si necesitas algo, escríbeme por correo electrónico o en LinkedIn.

Llevo 27 años especializado en monitorización y observabilidad, y he visto surgir y desaparecer muchas herramientas y técnicas (¿alguien conoce RMon?); y más de unas pocas llegan y se quedan (los rumores sobre la desaparición de SNMP han sido, y siguen siendo, muy exagerados). Últimamente he estado explorando una de las mejoras más recientes en este campo: OpenTelemetry (que abreviaré como "OTel" en lo que resta de este blog). Escribí recientemente sobre mi decisión de adentrarme en OTel .

En general, estoy disfrutando del proceso. Pero hay un problema con la observabilidad desde hace tiempo, y es algo que OTel no está solucionando. El título de esta publicación lo sugiere, pero quiero ser más explícito. Empecemos con algunas comparaciones.

Antes de molestar a todos los proveedores, quiero aclarar que estas son cifras generales, aproximadas y de alto nivel. He incluido enlaces a las páginas de precios si desean consultar los detalles, y reconozco que lo que ven a continuación no es necesariamente indicativo del precio que podrían pagar después de obtener un presupuesto para un entorno de producción real.

• Cargos de New Relic

  • 35¢ por GB por cualquier dato que les envíes.
  • …aunque la página de precios no lo deja particularmente claro

  
  

• Datadog tiene una verdadera lista de opciones, pero en un nivel alto, cobran :

  • $15-$34 por anfitrión

  • 60¢ – $1,22 por millón de registros de flujo neto

  • $1,06-$3,75 por millón de registros

  • 1,27-3,75 dólares por millón de tramos

    
    

• La página de precios de Dynatrace presenta una lista casi tan larga como la de Datadog, pero incluye algunos elementos clave:

  • 15¢ por cada 100,00 métricas

    • más 0,07¢ por Gig por día por retención

  • 2¢ por gig para troncos

    • más 0,07¢ por concierto por día para retenerlos
    • más 0,035¢ por gig consultado

  • Los eventos tienen la misma frecuencia que los registros.

  • .014¢ por cada 1,000 tramos

    
    

• Grafana, que, cabe destacar, es de código abierto y te ofrece todo gratis si estás dispuesto a hacer el trabajo pesado de instalación y alojamiento. Pero sus precios se pueden resumir en :

  • $8.00 por 1k métricas (hasta 1 por minuto)
  • 50¢ por gig para registros y rastreos, con retención de 30 días

Esta lista no es exhaustiva ni completa. He omitido a muchos proveedores, no porque no tengan precios basados en el consumo, sino porque sería más de lo mismo. Incluso con los mencionados, la información aquí no está completa. Algunas empresas no solo cobran por el consumo (ingesta), sino también por almacenar los datos y por consultarlos (te estoy hablando, New Relic). Algunas empresas te presionan para que elijas un nivel de servicio, y si no lo haces, te cobrarán una tarifa estimada basada en el percentil 99 de uso mensual ( te estoy hablando, Datadog ).

No debería sorprender a nadie que lo que aparece en su página de precios ni siquiera sea la última palabra. Algunas de estas empresas, incluso ahora, están considerando redefinir su interpretación del concepto de "precios basados en el consumo", lo que podría volver las cosas aún más opacas (te estoy mirando de nuevo, New Relic).

Incluso con todo lo dicho, me arriesgaré y afirmaré para que quede constancia que todos y cada uno de esos precios son tan bajos que incluso la palabra "trivial" es demasiado grande.

Es decir, hasta que las cargas de trabajo de producción se ajusten a la hoja de precios. En ese momento, esas pequeñas cantidades se convierten en dinero real, y rápidamente.

El plural de anécdota

Les pregunté a unos amigos si habían tenido experiencias reales con precios impactantes. Como siempre, mis amigos no me decepcionaron.

Hace un par de años, hice una comparación detallada de precios entre New Relic y Datadog, utilizando Fargate como principal uso. New Relic era significativamente más económico hasta que se empezaron a enviar registros, y entonces Datadog de repente era un 30-40 % más económico, incluso con APM. [Pero] el coste por host también influye, lo que hace que APM sea poco atractivo a menos que se trabaje con servidores. Queríamos usarlo en Kubernetes, pero era tan caro que la dirección se negaba a creer los costes de los servicios en Fargate, así que solía mostrar mis cifras cada dos o tres meses. __– Evelyn Osman, directora de plataforma en enmacc

“Lo único que tengo en la memoria es la cara del director financiero cuando vio la factura.” __– alguien que prefiere permanecer anónimo, aunque esa cita es increíblemente épica.

Y, por supuesto, está el misterio (ahora infame en los círculos de observabilidad) de la factura de 65 millones de dólares de Datadog .

El primer paso es admitir que tienes un problema

Hubo un tiempo (me refiero a principios de los años 2000) en que el desafío del monitoreo (la observabilidad no era un término que usáramos todavía) era cómo identificar los datos que necesitábamos, lograr que los sistemas nos entregaran esos datos y luego almacenarlos de una manera que hiciera posible (y mucho menos eficiente) su uso en consultas, visualizaciones, alertas, etc.

Ahí residía casi todo el coste. Los sistemas en sí estaban en las instalaciones y, una vez adquirido el hardware, eran prácticamente gratuitos. Como resultado, la práctica aceptada era recopilar la mayor cantidad posible y conservarla indefinidamente. Y a pesar del cambio tecnológico, el razonamiento de muchas organizaciones sigue siendo el mismo.

Alec Isaacson, arquitecto de soluciones de Grafana, señala que sus conversaciones con los clientes a veces son así:

“Recopilo métricas de CDM de mis sistemas más críticos cada 5 segundos porque una vez, hace mucho tiempo, alguien recibió un grito porque el sistema iba lento y las métricas no le indicaban por qué”.

Hoy en día, recopilar datos de monitorización y observabilidad ("telemetría") es comparativamente fácil, pero, tanto a nivel individual como organizacional, no hemos cambiado nuestra forma de abordar el problema. Por ello, seguimos recopilando todos los datos disponibles. Instrumentamos nuestro código con todas las etiquetas y rangos imaginables; si hay un mensaje de registro, lo enviamos; ¿métricas de hardware? Mejor recopilarlas, ya que proporcionarán contexto; si hay telemetría de red (NetFlow, registros de flujo de VPC, telemetría de streaming), también la aceptamos.

Pero nunca nos tomamos el tiempo de pensar en qué haremos con él. La experiencia de la Sra. Osman ilustra el resultado:

No tenían ni idea de lo que hacían con el monitoreo [...]. Toda la instrumentación y el registro estaban habilitados y, por lo tanto, se retenía información durante un tiempo prolongado "por si acaso". Así que estaban gastando cantidades absurdas de dinero.

Para relacionarlo con otro mal comportamiento del que (más o menos) nos hemos deshecho: en los inicios del "lift and shift" (a menudo descrito con más precisión como "lift and shit") a la nube, no solo migramos aplicaciones al por mayor, sino que las migramos a los sistemas más grandes que ofrecía la plataforma. ¿Por qué? Porque en el antiguo contexto local solo se podía pedir un servidor una vez y, por lo tanto, se pedía lo más grande posible para asegurar la inversión a futuro. Esta decisión resultó no solo graciosamente ingenua, sino también carísima, y a todos les llevó varios años comprender cómo funcionaba la "computación elástica" y adaptar sus aplicaciones al nuevo paradigma.

Del mismo modo, ya es hora de que reconozcamos que no podemos permitirnos recopilar todos los datos de telemetría disponibles y que, además, no tenemos un plan para esos datos incluso si el dinero no fuera un problema.

Admítelo: tu problema también tiene un problema

Permítanme hablar de OTel por un momento. Una de las razones clave —posiblemente LA principal— para cambiar a OTel es eliminar, para siempre, la dependencia de un proveedor. Esto es algo que exploré en mi última entrada del blog y que un amigo me comentó recientemente:

OTel resuelve muchos de los problemas relacionados con "¡Genial! Ahora estamos atrapados con el proveedor x y nos va a costar millones refactorizar todo este código", en lugar de "¿Vamos a cambiar de proveedor? Genial, déjame actualizar mi endpoint..." – Matt Macdonald-Wallace, Arquitecto de Soluciones, Grafana Labs

Para ser claros, OTel hace un trabajo increíble resolviendo este problema, lo cual es increíble de por sí. PERO… OTel tiene una desventaja que la gente no nota de inmediato, si es que la nota. Ese problema empeora aún más el anterior.

OTel toma todos tus datos (métricas, registros, seguimientos y demás), los recopila y los envía a donde quieras. Pero OTel no siempre lo hace de forma EFICIENTE.

Ejemplo 1: mensajes de registro

Tomemos el mensaje de registro a continuación, que proviene directamente de syslog. Sí, el clásico RFC 5424. Nacido en los 80, estandarizado en 2009 y el indiscutible "parlanchín" de los protocolos de mensajes de red. He visto redes de tamaño modesto generar más de 4 millones de mensajes de syslog por hora. La mayoría eran pura basura, ¿eh? Pero esos mensajes tenían que ir a algún sitio y ser procesados (o descartados) por algún sistema durante el proceso. Es una de las razones por las que he sugerido un sistema de filtrado de syslog y traps desde hace prácticamente siempre .

Dejando de lado las críticas sobre el volumen de mensajes, algunos de ellos tienen valor para algunos profesionales de TI, a veces. Por eso, también debemos considerarlos (y recopilarlos).

 <134>1 2018-12-13T14:17:40.000Z myserver myapp 10 - [http_method="GET"; http_uri="/example"; http_version="1.1"; http_status="200"; client_addr="127.0.0.1"; http_user_agent="my.service/1.0.0"] HTTP request processed successfully

Tal como está, ese mensaje de registro ocupa 228 bytes, apenas una gota en la telemetría que se recopila cada minuto, y mucho menos cada día. Pero para lo que voy a hacer, quiero una comparación exacta, así que así se vería si lo convirtiera en JSON:

 {  "pri": 134,  "version": 1,  "timestamp": "2018-12-13T14:17:40.000Z",  "hostname": "myserver",  "appname": "myapp",  "procid": 10,  "msgid": "-",  "structuredData": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0"  },  "message": "HTTP request processed successfully" }

Esto aumenta la carga útil a 336 bytes sin espacios en blanco, o 415 bytes con ellos. A modo de comparación, aquí hay un ejemplo de mensaje de registro OTLP:

 { "resource": { "service.name": "myapp", "service.instance.id": "10", "host.name": "myserver" }, "instrumentationLibrary": { "name": "myapp", "version": "1.0.0" }, "severityText": "INFO",  "timestamp": "2018-12-13T14:17:40.000Z",  "body": { "text": "HTTP request processed successfully"  },  "attributes": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0"  } }

Ese mensaje (genérico y mínimo) ocupa 420 bytes (sin espacios; son 520 bytes con todo incluido). Sigue siendo pequeño, pero aun así, la versión de OTel con espacios es un 25 % más grande que el mensaje JSONificado (con espacios) y más del doble que el mensaje de registro original.

Una vez que empecemos a aplicar datos del mundo real, la situación se dispara aún más. Mi punto es este: si OTel hace eso con cada mensaje de registro, estos pequeños costos se acumulan rápidamente.

Ejemplo 2: Prometeo

Resulta que los métodos modernos de gestión métrica son igualmente susceptibles a la inflación.

• Una métrica típica de Prometheus, formateada en JSON, es de 291 bytes.
• Pero esa misma métrica convertida al formato de métricas OTLP pesa 751 bytes.

Es cierto que OTLP cuenta con una función de procesamiento por lotes que mitiga este problema, pero solo ayuda con la transferencia por cable. Una vez que llega al destino, muchos proveedores (no todos, pero la mayoría) desagrupan el mensaje antes de almacenarlo, por lo que vuelve a ser 2,5 veces más grande que el mensaje original. Como dijo mi amigo Josh Biggley:

“Es mejor que las métricas de 2,5x tengan una historia increíble que contar sobre el contexto para justificar ese costo”.

No eres tú, OTel, somos nosotros. (Pero también eres tú)

Si todo esto les parece un poco crítico con OTel, por favor, denme la oportunidad de explicarlo. Creo sinceramente que OTel es un avance asombroso y que cualquiera que se tome en serio la monitorización y la observabilidad debe adoptarlo como estándar, tanto para usuarios como para proveedores. La capacidad de emitir la red de registros, métricas y rastros, manteniendo su contexto, independientemente del destino, es invaluable.

(Pero…) OTel fue diseñado por (y para) ingenieros de software. Se originó en aquella época pasada (me refiero a “2016”), cuando aún nos preocupaba más la dificultad de obtener los datos que el coste de moverlos, procesarlos y almacenarlos. OTel, por diseño, está orientado al volumen.

A pesar de la broma del título de esta sección, el problema no es OTel. La culpa es nuestra. En concreto, de nuestra mala relación con la telemetría. Si insistimos en recopilar y transmitir todos los datos, no tendremos a nadie a quien culpar más que a nosotros mismos por las exorbitantes facturas que recibimos a fin de mes.

¿Estos datos te traen alegría?

Es fácil dejar que tu solución de observabilidad se encargue del trabajo pesado y distribuya cada byte de datos en una interfaz unificada. Es fácil hacerlo si eres un ingeniero de software que (al menos nominalmente) gestiona las soluciones de monitorización y observabilidad.

Es aún más fácil si eres un simple consumidor de esos servicios, un observador pasivo. Entre quienes entran en esta categoría se incluyen aquellos estrechamente vinculados a un silo específico (base de datos, almacenamiento, red, etc.); o equipos de soporte técnico y NOC que reciben los tickets y brindan soporte, pero no están involucrados en la instrumentación ni en las herramientas a las que está conectada; o equipos con necesidades más especializadas que, sin embargo, se superponen con la monitorización y la observabilidad, como la seguridad de la información.

Pero seamos honestos, si eres ingeniero de seguridad, ¿cómo puedes justificar pagar el doble del precio de la ingesta de registros o métricas, en comparación con los estándares perfectamente válidos que ya existen y han funcionado bien durante años? ¿Significa eso que podrías estar usando más de una herramienta? Sí. Pero como he señalado ( una y otra vez), no existe (ni nunca ha existido, ni existirá) una solución universal. Yen la mayoría de los casos, ni siquiera existe una solución universal. La monitorización y la observabilidad siempre se han basado en implementaciones heterogéneas. Cuanto antes adoptes este ideal, antes comenzarás a construir ecosistemas de observabilidad que satisfagan tus necesidades, las de tu equipo y las de tu negocio.

Para tal fin, es necesario llevar a cabo una discusión seria sobre el retorno de la inversión (ROI) antes de invertir todo en OTel o en cualquier solución de observabilidad.

<EOF> (por ahora)

Hemos visto en el pasado la transición del precio por puesto (o interfaz, chasis o CPU) a un modelo de consumo en el mercado. Y también hemos visto cómo las tecnologías retroceden (como la transición del servicio móvil de por minuto o por mensaje de texto a datos ilimitados con una tarifa mensual). Sospecho que veremos una oscilación similar en el futuro con la monitorización y la observabilidad. Pero por ahora, debemos lidiar con el sistema de precios vigente y con nuestra propia compulsión —surgida en un momento diferente de la historia de la monitorización— de recopilar, transmitir y almacenar cada bit (y byte) de telemetría que pasa ante nuestras narices.

Por supuesto, el costo no es el único factor. Es necesario considerar el rendimiento, el riesgo (y más). Pero en el fondo, es fundamental que empecemos a preguntarnos:

• ¿Qué haré con estos datos?
• ¿Quién lo utilizará?
• ¿Durante cuánto tiempo debo conservarlo?

Y por supuesto ¿quién carajo va a pagar por ello?