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 profundizamos en la idea de. inmerso Contextualización y cómo mejora la observabilidad procesable. En esta publicación, comenzaremos con lo que significa la contextualización en la observabilidad basada en modelos, comenzando con la adición Topología de Juju Metadatos que se agregarán a la telemetría y cómo se mejora el procesamiento y la consulta de telemetría para aplicaciones atractivas.
Tabla de Contenidos
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:
En el ejemplo anterior, las relaciones de supervisión son entre Prometheus y los dos clústeres de Cassandra. relaciones entre modelos. Las relaciones entre modelos conectan estímulos en diferentes modelos; Para los propósitos de este artículo, las relaciones entre modelos no son tan 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 claramente un software que se ejecuta en todas las implementaciones administradas por Juju. Esto se logra combinando los siguientes cuatro elementos:
- Nombre del modelo
- Modelo uuid
- Nombre de la aplicación
- Identificador de dispositivo
Repasemos cada uno de ellos con más detalle.
Nombre del modelo y UUID del modelo
Los administradores de Juju pueden ver detalles del modelo en el que están trabajando junto con otra información sobre el modelo juju show 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 similares con el mismo nombre en diferentes controladores que operan en diferentes entornos que se utilizan en su proceso de implementación de software. Por ejemplo, tiene 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 simple: cuando implementa un encanto en un modelo, opcionalmente puede proporcionar 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 usa como el 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 definidos por el usuario que tienen sentido desde el punto de vista de mi sistema general en el modelo, como por ejemplo: . Asignar 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, si 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 una gobernanza más fácil .
Identificador de dispositivo
Cuando proporcionas un encanto, puedes escalarlo fácilmente hacia arriba y hacia abajo. Cada instancia se llama unidad. Una de las muchas decisiones de diseño de Juju que me encantan (más sobre eso más adelante) es esta Las unidades tienen una identidad fija y predecible: Si escalas una aplicación juju a, por ejemplo, tres unidades, cada instancia tiene un identificador estable basado en el nombre de la aplicación juju y un número ordinal que comienza en cero, por ejemplo, «users-db / 0», «users -db / 1 «y» users-db / 2 «. Si una de las unidades se reinicia porque su encanto se ha actualizado o se bloquea, ¡una nueva unidad con el mismo identificador ocupará su lugar! Esto también tiene implicaciones para reducir la escala de una aplicación Juju: si reduce la escala de la aplicación users-db de tres a dos unidades, sabrá que la aplicación users-db / 2 se inicia. (Por cierto, la previsibilidad de qué unidad se encogerá es una característica muy buena de Juju en términos de operaciones de software).
Atar 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 se habrá dado cuenta de que la sintaxis utilizada anteriormente es la de las etiquetas de Prometheus, y esa es una Predicción.
Intermezzo: estabilidad de la entidad
Por cierto, antes de unirme a Canonical, trabajé para una empresa de gestión del 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 principales problemas en esta área es lo que hemos mencionado Estabilidad de la unidad, eso significa darle a su servidor HTTP un nombre consistente en todos los reinicios. La estabilidad de la entidad es mucho más difícil de resolver para una herramienta de monitoreo de lo que parece: si una máquina virtual Java desaparece y aparece otra en el host la próxima vez que la herramienta la verifica, es difícil decir si es el mismo proceso el que actúa. modelo mental del usuario.
La estabilidad de las unidades es generalmente irresoluble y requiere trabajo a medida y aproximaciones para cada nueva tecnología que necesita ser monitoreada. Si no se resuelve, es realmente difícil proporcionar datos históricos para las diferentes partes de su infraestructura sobre los cambios que ocurrirán con el tiempo. Como se discutió en la sección anterior, Juju resuelve este problema instantáneamente, y cuando vi esto, me sentí abrumado.
Agregar la topología juju a las métricas
Teniendo en cuenta el ejemplo en ejecución, el siguiente fragmento de configuración, que se centra en el servidor Prometheus que se ejecuta en la aplicación prometheus Juju, es generado automáticamente por el encantamiento Prometheus en función de 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-2Observe cómo la configuración de raspado asegura que la topología juju se aplique correctamente a todas las métricas raspadas agregando las etiquetas requeridas a cada elemento en los destinos de «static_configs». Además, la configuración de «honor_labels» que se establece en «true» significa que Prometheus no los sobrescribirá si la métrica ya se recibió con la topología de Juju anotada. Este comportamiento será útil cuando cubramos el monitoreo con el software Prometheus que no es realizado por Juju en una publicación posterior de esta serie.
Métricas contextualizadas y su desempeño
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 proporcionar datos de telemetría y advertencias con información coherente y procesable sobre qué sistema los está generando. Por último, un aumento en el uso de latencia de consultas de informes de métricas 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 está en producción o en el entorno de prueba.
Continuidad métrica
Los pods pueden apagarse o bloquearse, y Kubernetes proporciona reemplazos automáticamente. Para Prometheus, por otro lado, es identidad El origen de una métrica depende principalmente del nombre de la instancia. Prometheus agrega automáticamente la etiqueta de la instancia a todas las métricas raspadas y establece su valor en la dirección de red y el puerto del punto final raspado, p. Ej. B. «1.2.3.4:5670». Sin embargo, cuando se reconstruye un pod, puede tener una dirección IP diferente, y la «misma» métrica recopilada por la entidad recién creada puede considerarse una métrica completamente diferente para Prometheus.
¡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 directamente este problema:
relabel_configs:
- source_labels: [juju_model, juju_model_uuid, juju_application, juju_unit]
separator: _
regex: (.*)
target_label: instance
replacement: $1
action: replaceLa configuración anula el valor predeterminado del nombre de la instancia de Prometheus con una combinación de modelo Juju, model_uuid, aplicación y unidad. En otras palabras, el nombre de la instancia se crea a partir de la topología de Juju y, por lo tanto, el valor del nombre de la instancia es estable sobre la recreación de la unidad. El resultado es que cuando se recrea una unidad de juju, Sus métricas comienzan con la nueva unidad exactamente donde se quedaron con la unidad anterior.
El valor de esta continuidad de métricas no se puede exagerar: a través de actualizaciones de encanto, cambios de configuración, problemas que provocan el bloqueo de una unidad, incluso Migraciones de modelos (si mueve un modelo Juju y sus aplicaciones de un clúster de Kubernetes a otro, por ejemplo), el historial de tu métrica se conserva. Imagine actualizar el clúster de Cassandra: todas las unidades se reconstruyen una a la vez, y puede detectar fácilmente problemas potenciales con la granularidad de la unidad al mirar sus paneles de Prometheus sin la necesidad de agrupaciones o mapeos complicados. Es simple e intuitivo, y lo hace Reduce significativamente la complejidad de escribir consultas PromQL: En la práctica, rara vez tenemos que usar operadores de coincidencia de vectores para analizar métricas en reinicios o actualizaciones, y si ha usado 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 empezar a rascar la superficie de todos los beneficios de anotar la topología de Juju en la telemetría.
La primera contribución de esta serie se ocupó de la observabilidad basada en modelos y sus ventajas desde una perspectiva de nivel superior.
Las siguientes partes de esta serie cubren los siguientes temas:
- Las ventajas de la topología Juju para agrupar alertas en el administrador de alertas
- Los beneficios de la topología Juju para los paneles de Grafana
Además, comenzaré a cubrir la perspectiva de los escritores encantadores discutiendo:
- Puede agrupar reglas de alarma con sus encantos y hacer que Prometheus las evalúe automáticamente
- Cómo combinar paneles de Grafana con sus encantos y dejar que los administradores de Juju los importen a sus Grafanas con una relación de Juju
Mientras tanto, puede comenzar a encantar sus aplicaciones que se ejecutan en Kubernetes. Además, consulte los diferentes amuletos disponibles hoy para una amplia variedad de usos.
Además, Canonical se asoció recientemente con reconocidos expertos de AWS, Google, Cloudbees y otros para analizar los resultados de una encuesta completa realizada a más de 1200 participantes de KubeCon. El detallado informe resultante sobre el uso de tecnologías nativas de la nube está disponible aquí:
Informe operativo de Kubernetes y Cloud Native 2021
