Durante PromCon Online 2020, di una charla titulada "El futuro de Prometheus y su ecosistema". Y quiero compartir con ustedes sus puntos clave.
Resumen
Desde la última conferencia PromCon - 2019, ha habido muchos cambios en Prometheus.
2.14
La versión 2.14 introduce una nueva interfaz en React. Aunque en términos de funcionalidad todavía está por detrás del anterior, estamos trabajando en él y seguimos mejorando.
2.15
La versión 2.15 vino bajo el estandarte de la API de metadatos. El formato de exposición Prometheus ha admitido durante mucho tiempo expresiones especiales
HELP, TYPEetc., sin embargo, el propio Prometheus solía simplemente descartar estos datos. Ahora que permanecen, puede abrir el acceso externo a ellos a través de la API. Por ejemplo, Grafana ya aprovecha esta oportunidad y brinda a los usuarios información adicional sobre la serie temporal con la que trabajan:
2.16
La versión 2.16 se ha centrado en varias mejoras y estabilidad. Por ejemplo, desde 2016, los usuarios han estado preguntando sobre la capacidad de seleccionar la hora local en la interfaz de usuario, así como sobre la implementación del registro de consultas; fue bueno cerrar estos problemas.
2.17
Hablando de solicitudes de funciones persistentes, la versión 2.17 finalmente trajo la tan esperada "I" en ACID para la base de datos : aislamiento .
2.18
En 2.18 , se ha mejorado el seguimiento y la compatibilidad con instancias de formato de exposición. Las instancias son el primer impacto que el usuario nota al implementar OpenMetrics en Prometheus. Combinándolos con Grafana, puede lograr una granularidad conveniente, lo que le permite pasar de:
... a:
2.19
¡En 2.19, redujimos el consumo de memoria hasta en un 50%! Aunque Prometheus ya es bastante eficaz, existe un potencial significativo de optimización que es a la vez emocionante e intimidante.
Este gráfico es una excelente ilustración de esto:
2,20
La versión 2.20 cuenta con el registro de cambios más largo desde la v2.6 (!). El principal es probablemente el soporte de descubrimiento de servicios nativo para Docker Swarm y DigitalOcean.
Pero hay un cambio más importante que va más allá de la implementación de dos mecanismos de descubrimiento de servicios independientes: separamos Prometheus y echamos un vistazo a muchas de las soluciones antiguas y enfoques establecidos. El mundo ha cambiado (quizás también nosotros participamos en esto), esto hay que tenerlo en cuenta tanto en el proyecto como en otros.
exportador_nodo
Para resumir, me gustaría señalar que node_exporter ha alcanzado la versión 1.0 y ahora incluye soporte EXPERIMENTAL TLS. La Cloud Native Computing Foundation patrocinó la auditoría de node_exporter por Cure53 (cubrió tanto el exportador en general como nuestra implementación de TLS en particular). Y valió doblemente la pena: no solo verificamos TLS antes de copiarlo a otros exportadores, sino que también usamos node_exporter como un conejillo de indias del que se copian otros patrones.
Futuro
A veces tengo la sensación de que nosotros, como proyecto, nos dormimos en los laureles. Hace un tiempo realicé una sesión de lluvia de ideas dentro de Grafana bajo el lema "Prometheus carece de características" y animé a Red Hat a hacer lo mismo. En el camino, creamos un documento sobre TODO disponible para todo el equipo de Prometheus. Sirve como marco para abordar temas específicos, divididos en puntos para debatir durante las cumbres de desarrolladores (tan pronto como estos puntos estén listos).
Cumbres de desarrolladores
El año pasado tuvimos dos cumbres de desarrolladores: una después de la KubeCon EU y la segunda después de la PromCon. Se planeó hacer lo mismo en 2020, pero COVID lo impidió. Este año no ha habido cumbres, pero creo que hemos encontrado una salida: reuniones más breves, más frecuentes y virtuales. Pasamos bloques de 4 horas en lugar de recolectar durante 1-2 días a la vez. La primera cumbre de desarrolladores de este tipo tuvo lugar el 10 de julio y la próxima probablemente tendrá lugar el 7 de agosto. Continuaremos realizándolos hasta que hayamos resuelto todas las preguntas acumuladas (aunque su número aumenta constantemente a medida que se agregan más y más elementos del documento anterior).
Ahora mismo quiero hacer dos cosas:
- , . , , . , . — , , .
- , , . , , .
Los metadatos están comenzando a aportar un valor real a Prometheus (ver 2.15 arriba). Necesitamos implementar más opciones para trabajar con metadatos (por ejemplo, distribuirlos mediante lectura / escritura remota). El consenso a continuación no cubre preguntas interesantes como "¿Qué pasa si los metadatos cambiaron / desaparecieron?" o "¿Qué pasa si se convierten en un vector de ataque?"
CONSENSO: Queremos mantener mejor los metadatos. El trabajo se realizará en un documento especial .
CONSENSO: PR 6815 será una solución EXPERIMENTAL. Lo más probable es que sea diferente en las versiones 3.x.
Cambios en el flujo de trabajo y s / master / main /
El tema de rastrillar la basura acumulada en los procesos de trabajo no requiere una explicación especial, pero conviene decir algunas palabras sobre la eliminación de la verborrea (unidad de terminología). Nos tomamos en serio la limpieza de la terminología: esto no es lo más importante, sino algo que podemos hacer ahora. Mientras esperamos el kit de herramientas correspondiente de GitHub. Tan pronto como aparezca, intentaremos atraer a un pasante remunerado a este trabajo a través del Puente Comunitario.
Estoy en conversaciones con la Fundación Linux y CNCF para implementar esto en todos los proyectos. Una gran oportunidad para cualquier persona interesada en este tema: la oportunidad de explorar muchos proyectos, trabajar con varias herramientas, conocer a mucha gente. Contácteme en Twitter ( @TwitchiH ) o por correo ( richih en grafana.com) si está interesado.
CONSENSO: Establecer "Requerir comprobaciones de estado antes de fusionar" en todos los repositorios / prometheus ... ¿No permitir empujes directos en la rama principal? ¿No permiten empujes de fuerza en la rama principal?
CONSENSO: Desactive el empuje forzado a todas las ramas principales.
CONSENSO: El comportamiento predeterminado permite empujar en la rama principal, sin embargo, debe deshabilitarse para algunos repositorios "importantes", por ejemplo, prometheus / prometheus (a discreción del mantenedor).
Llenado de datos (relleno)
Esta es una de las solicitudes de funciones más antiguas y un buen ejemplo de cómo abordar el consenso. Hay muchas opiniones diferentes que circulan en el equipo de Prometheus sobre esto, y es difícil llegar a un denominador común. Por lo tanto, escribí una propuesta de consenso limitada y muy específica con tres criterios: "Queremos apoyar el relleno en la red al menos en bloques que no se superponen con el bloque de cabeza ".
Después de largas discusiones e intentos de llegar a un consenso, quedó claro que esto no sería fácil de hacer. Por lo tanto, reformulé la propuesta de la siguiente manera: “Queremos apoyar el relleno en la red al menos por arroyos que no se cruzan con el bloque de cabecera".
Solo al obligar a todos a expresar su propia opinión sobre este tema, pudimos llegar a la versión final: "Nos gustaría apoyar el relleno sobre la red en bloques que no se cruzan con el bloque de cabecera, siempre que esté correctamente implementado ". Cada palabra aquí se ha elegido para reflejar el alcance exacto y los límites del consenso.
: Prometheus OpenMetrics, CSV- .
: backfilling , .
: backfilling , .
: backfilling , .
Otra de las tareas asociadas a poner las cosas en orden. Aquí quiero criticar a Go: se desarrolló en un mundo en el que el monorep único es la norma. Google almacena todo (o la mayoría) de su código común en un solo repositorio. Este enfoque tiene muchas ventajas, pero no se traduce bien en las condiciones del mundo real. Go se está alejando lenta pero seguramente de este legado.
Dato curioso: escribí la propuesta de consenso casi al comienzo de la discusión. Estaba claro que al menos lo intentaríamos. Estaba claro que Ben Kochie se ofrecería como voluntario para hacer esto. Y estaba claro que node_exporter sería la "víctima". Como regla, nos esforzamos por mejorar el flujo de trabajo, y Ben siempre es un voluntario, y node_exporter es el banco de pruebas desde el cual luego copiamos los resultados a otros exportadores. Y sí, era importante que la discusión se prolongara por un tiempo y que la gente llegara a esto por su cuenta, en lugar de confrontarlos con un hecho.
CONSENSO: Bórralo en node_exporter y mira si estamos contentos con el resultado.
Listas de correo e IRC
Google está bloqueado en China, pero nuestras listas de correo funcionan. Decidimos intentar hacer posible la suscripción por correo electrónico. Comprobé: prometheus-users+subscribe@googlegroups.com funciona. También puede leer los archivos ( https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html ) si lo desea.
Además, nos aseguramos de que todo el mundo pueda utilizar IRC a través de Matrix, ya que para algunos xkcd 1782 es muy relevante.
:
, Google ; - .
docs/community , Google.
IRC, Matrix; , .
Permítanme repetir lo que dije en la cumbre: “Lo primero que no me gustó de Prometheus en 2015 fue la documentación; en 2020, simplemente la odio. Es difícil de usar y casi inútil, apto solo para quienes ya saben lo que están haciendo, o al menos tienen una buena idea de los conceptos ". En definitiva, trabajaremos en esta dirección:
:
:
* (user manual) .
* (reference) , PromQL /.
* (guides), .
Diana Payton , .. .
.
Si está interesado, actualmente estamos buscando un redactor técnico en Grafana Cloud para trabajar en la documentación oficial original de Prometheus. Al final del día, nos tomamos en serio nuestro compromiso con la comunidad.
Como de costumbre, se publicarán las notas del dev-summit. También puede leer los resultados de la cumbre 2020-1 y las cumbres de los últimos años .
PD del traductor
Lea también en nuestro blog:
- " Monitoreo y Kubernetes " (informe de revisión y video);
- " El dispositivo y mecanismo del operador Prometheus en Kubernetes ";
- " Presentamos k8s-image-availability-exporter para detectar imágenes faltantes en Kubernetes ».