Ubuntu

Observabilidad basada en modelos: la magia de la topología Juju para métricas

Observabilidad basada en modelos: la magia de la topología Juju para métricas

En la primera publicación de esta serie, cubrimos la idea general y los beneficios de la observabilidad basada en modelos con Juju, pero no profundizó en la idea de contextualización y cómo hace que la observabilidad sea más procesable. En esta publicación comenzamos a abordar lo que significa la contextualización en la observabilidad impulsada por modelos, comenzando por agregar Topología Juju metadatos agregados a la telemetría, y cómo eso mejora el procesamiento y la consulta de la telemetría para aplicaciones encantadas.

El ejemplo corriente

En el resto de esta publicación, usaremos el siguiente ejemplo como una evolución del escenario en el primer blog de esta serie:

Representación de tres modelos sencillos de Juju. El modelo LMA contiene los procesos de seguimiento; los modelos “producción1” y “producción2” contienen dos grupos de Cassandra separados.

En el ejemplo anterior, las relaciones de monitoreo entre Prometheus y los dos clústeres de Cassandra son relaciones entre modelos. Las relaciones entre modelos conectan encantos en diferentes modelos; A los efectos de este artículo, las relaciones entre modelos no son materialmente diferentes de las relaciones dentro de un modelo.

Topología de Juju, o cómo identificar de forma única las cargas de trabajo

El objetivo de la topología Juju es identificar de forma unica una pieza de software que se ejecuta en cualquiera de sus implementaciones administradas por Juju. Esto se logra combinando los siguientes cuatro elementos:

  • nombre del modelo
  • modelo uuid
  • Nombre de la aplicación
  • identificador de unidad

Repasemos cada uno de ellos con más detalle.

Nombre del modelo y uuid del modelo

Los administradores de Juju pueden recuperar detalles del modelo en el que están trabajando actualmente, junto con otra información, utilizando el juju show-model mando:

$ juju show-model
production1:
  name: admin/production1
  short-name: production1
  model-uuid: 03a5f688-a79c-4a80-8c3e-2ad3177800cc
  ...

El nombre de un modelo es único dentro de un controlador, pero es probable que implemente modelos homónimos similares en varios controladores que operan en diferentes entornos utilizados en su proceso de entrega de software. Por ejemplo, puede tener uno para el entorno de desarrollo, uno para el aseguramiento de la calidad y uno para cada uno de los distintos entornos de producción. Por lo tanto, para evitar colisiones en la topología de Juju, debemos agregar el IDentificador único universal (UUID) del modelo a la topología de Juju.

Nombre de la aplicación

El nombre de la aplicación Juju es fácil: al implementar un encanto en un modelo, opcionalmente puede especificar un nombre personalizado para la aplicación Juju resultante. Si no se especifica un nombre de aplicación personalizado, el nombre de acceso también se utilizará como nombre de la aplicación. Como los modelos en un controlador, los nombres de las aplicaciones son únicos dentro de un modelo. Prácticamente siempre especifico nombres de aplicaciones personalizados que son significativos en el modelo desde el punto de vista de mi sistema en general, como nombrar la implementación del encanto de la base de datos que contendrá las cuentas de usuario «users-db», en lugar de solo «cassandra» . Dar nombres personalizados a las aplicaciones de Juju también es una forma de tener múltiples instancias de un encanto en el mismo modelo, por ejemplo, cuando su aplicación puede necesitar múltiples clústeres de Cassandra separados, cada uno de los cuales sirve para un caso de uso diferente o por razones de acceso a datos de espacio aislado para gobernanza más fácil.

Identificador de unidad

Cuando despliegas un amuleto, puedes escalarlo hacia arriba y hacia abajo sin esfuerzo. Cada instancia se llama unidad. Una de las muchas decisiones de diseño de Juju que me encantan (más sobre esto más adelante) es que las unidades tienen una identidad fija y predecible: cuando escalas una aplicación Juju a, digamos, tres unidades, cada instancia tiene un identificador estable construido en el nombre de la aplicación Juju y un número ordinal que comienza desde cero, por ejemplo, “users-db / 0”, “users-db / 1 ”Y“ users-db / 2 ”. Cuando una de las unidades se reinicia, porque su encanto se actualiza o se bloquea, ¡una nueva unidad con el mismo identificador ocupa su lugar! Esto también tiene implicaciones cuando se reduce la escala de una aplicación Juju: cuando se reduce la aplicación users-db de tres unidades a dos, se sabe que la aplicación «users-db / 2» se está iniciando. (Por cierto, la previsibilidad en términos de qué unidad se reduce es una propiedad muy agradable de Juju en términos de operaciones de software).

Atarlo todo junto

En nuestro ejemplo, las tres unidades de la aplicación «users-db» se identifican de forma única como:

{ juju_model="production1", juju_model_uuid="1234567", juju_application="users-db", juju_unit="users-db/0" }
{ juju_model="production1", juju_model_uuid="1234567", juju_application="users-db", juju_unit="users-db/1" }
{ juju_model="production1", juju_model_uuid="1234567", juju_application="users-db", juju_unit="users-db/2" }

Inmediatamente habrá notado que la sintaxis que usamos anteriormente es la de las etiquetas de Prometheus, y esa es una presagio.

Intermezzo: estabilidad de la entidad

Además, antes de unirme a Canonical, trabajé en una empresa de gestión de rendimiento de aplicaciones. La herramienta se basa en el concepto de entidades, como un proceso, un clúster o un host (virtual). Uno de los problemas clave en ese dominio es lo que llamamos estabilidad de la entidad, es decir, dar un nombre coherente a su servidor HTTP en los reinicios. La estabilidad de la entidad es mucho, mucho más difícil de resolver para una herramienta de monitoreo de lo que parece: cuando una máquina virtual Java desaparece y aparece otra en el host la próxima vez que la herramienta verifica, no se puede saber si son el «mismo» proceso en el modelo mental del usuario.

La estabilidad de la entidad en realidad no se puede resolver en general y requiere un trabajo a medida y aproximaciones para cada nueva tecnología que se debe monitorear. Si no se resuelve, resulta muy difícil proporcionar datos históricos para las distintas partes de su infraestructura a través de los cambios que ocurren a lo largo del tiempo. Como se discutió en la sección anterior, Juju resuelve este problema de inmediato, y cuando vi eso, simplemente me quedé impresionado.

Agregar topología de Juju a las métricas

Considerando el el ejemplo corriente, el siguiente fragmento de configuración, centrado en el servidor Prometheus que se ejecuta en la aplicación prometheus Juju, es generado automáticamente por el encantamiento Prometheus basado en las relaciones en el modelo Juju:

scrape_configs:
- job_name: juju_production1_1234567_users-db_prometheus_scrape
  honor_labels: true
  relabel_configs:
  - source_labels: [juju_model, juju_model_uuid, juju_application, juju_unit]
    separator: _
    regex: (.*)
    target_label: instance
    replacement: $1
    action: replace
  static_configs:
  - targets:
    - 10.1.151.128:9500
    labels:
      juju_application: users-db
      juju_model: production1
      juju_model_uuid: 12345678-0c91-46a7-8843-d3695e4dad9a
      juju_unit: users-db-0
  - targets:
    - 10.1.151.114:9500
    labels:
      juju_application: users-db
      juju_model: production1
      juju_model_uuid: 12345678-0c91-46a7-8843-d3695e4dad9a
      juju_unit: users-db-1
  - targets:
    - 10.1.151.109:9500
    labels:
      juju_application: users-db
      juju_model: production1
      juju_model_uuid: 12345678-0c91-46a7-8843-d3695e4dad9a
      juju_unit: users-db-2

Observe cómo la configuración de raspado asegura que la topología de Juju se aplique correctamente a todas las métricas raspadas agregando las etiquetas requeridas a cada elemento en los objetivos de «static_configs». Además, la configuración de “honor_labels” establecida en “true” significa que si la métrica ya viene con la topología de Juju anotada, Prometheus no la anulará. Este comportamiento será útil cuando, en una publicación posterior de esta serie, cubramos cómo monitorear con el software Prometheus que no es ejecutado por Juju.

Métricas contextualizadas y su poder

Entonces, ¿qué puede hacer la “topología Juju” por nosotros? Bueno, resulta que mucho. La contextualización en la observabilidad basada en modelos consiste en anotar la telemetría y las alertas con información coherente y procesable sobre qué sistema las genera. Después de todo, un aumento en la métrica que informa el uso de latencia de consultas en un clúster de base de datos puede hacer que su buscapersonas suene a las 3 a.m. de la noche o esperar hasta el tercer café mañana por la mañana, dependiendo de si el aumento se produce en producción o en el entorno de prueba. .

Continuidad de métricas

Los pods pueden terminar o fallar, y Kubernetes mostrará reemplazos automáticamente. Para Prometeo, sin embargo, el identidad de dónde viene una métrica es en gran parte una cuestión de etiqueta de instancia. Prometheus agregará automáticamente la etiqueta de la instancia a todas las métricas raspadas, estableciendo su valor en la dirección de red y el puerto del punto final raspado, por ejemplo, «1.2.3.4:5670». Sin embargo, cuando se recrea un pod, puede tener una dirección IP diferente, y la «misma» métrica recopilada por la unidad recién recreada puede contar para Prometheus como una métrica completamente diferente.

¡Esto no es un problema con Juju! En la configuración de Prometheus que se muestra en la sección anterior, hay una parte muy interesante que aborda este problema directamente:

relabel_configs:
  - source_labels: [juju_model, juju_model_uuid, juju_application, juju_unit]
    separator: _
    regex: (.*)
    target_label: instance
    replacement: $1
    action: replace

La configuración anula la configuración predeterminada de Prometheus etiqueta de instancia valor con una combinación del modelo Juju, model_uuid, aplicación y unidad. En otras palabras, la etiqueta de la instancia se crea a partir de la topología de Juju y, por lo tanto, el valor de la etiqueta de la instancia es estable en la recreación de unidades. El resultado es que, cuando se recrea una unidad Juju, sus métricas se recuperan con la nueva unidad precisamente donde se detuvo con la unidad anterior.

Un gráfico de la métrica «ascendente» para las unidades del clúster users-db Cassandra: la caída en la línea azul claro alrededor de la marca de las 15:23:00 se debe a que maté el pod que ejecuta «users-db / 1» con un llamar a «kubectl eliminar pod users-db / 1 -n production1»; la métrica se reanuda cuando Kubernetes genera un nuevo pod para «users-db / 1».

El valor de esta continuidad de métricas no se puede exagerar: sobre actualizaciones de encanto, cambios de configuración, problemas que hacen que una unidad se bloquee, incluso migraciones de modelos (cuando mueve un modelo Juju y sus aplicaciones de, digamos, un clúster de Kubernetes a otro), el historial de tu métrica se conserva. Imagine el caso de actualizar el clúster de Cassandra: todas las unidades se recrean, una tras otra, y puede detectar fácilmente problemas potenciales con la granularidad de la unidad, con solo mirar sus paneles de Prometheus, sin necesidad de agrupaciones o mapas complicados. Es fácil e intuitivo, y reduce mucho la complejidad de escribir consultas PromQL: en la práctica, rara vez necesitamos usar operadores de coincidencia de vectores para analizar métricas sobre reinicios o actualizaciones, y si ha utilizado PromQL con Kubernetes sin la topología Juju, apreciará las dificultades que esto elimina.

Que sigue

Con la continuidad de las métricas, acabamos de comenzar a rascar la superficie de todo lo bueno que viene con anotar la topología de Juju en la telemetría.

La primera publicación de esta serie cubrió la observabilidad basada en modelos y sus beneficios desde una perspectiva de alto nivel.

Las siguientes entregas de esta serie cubrirán:

  • Los beneficios de la topología Juju para agrupar alertas en Alertmanager
  • Los beneficios de la topología Juju para los paneles de Grafana

Además, comenzaré a cubrir la perspectiva de los autores encantadores, discutiendo:

  • Cómo agrupar reglas de alerta con sus encantos y hacer que Prometheus las evalúe automáticamente
  • Cómo combinar Grafana Dashboards con sus encantos y permitir que los administradores de Juju los importen en sus Grafanas con una relación de Juju

Mientras tanto, podrías empezar encantando sus aplicaciones que se ejecutan en Kubernetes. Además, eche un vistazo a varios encantos disponibles hoy para una variedad de aplicaciones.

Además, Canonical se unió recientemente a reconocidos expertos de AWS, Google, Cloudbees y otros para analizar el resultado de una encuesta completa administrada a más de 1200 encuestados de KubeCon. El detallado informe resultante sobre el uso de tecnologías nativas de la nube está disponible aquí:

Informe de operaciones nativas de la nube y de Kubernetes 2021

Leave a Comment

You may also like

Más