Introducción a la monitorización y al stack de Prometheus, haciendo especialmente hincapié en el por qué y sus motivaciones. Se muestra brevemente el stack de Prometheus así como varios Exporters. Por ultimo, veremos varias alternativas para escalar con alta disponibilidad.

1. Monitorizacion
con Prometheus
Héctor Fuente Pérez
Septiembre 2021

2. Monitarización
Por qué y qué monitorizar.
The Four Golden Signals.
Alertas
La importancia de las alertas
en los sistema de
monitorización
01 02
Tabla de contenidos
Prometheus
¿Qué es Prometheus? Su
arquitectura y algunos
exporters
Alta disponiblidad
Stack de monitorización en
una arquitectura de alta
disponibilidad
03 04

3. Monotirización
01
Breve introducción a la
monitorización.

4. ¿Por qué?
 Seguimiento continuo del estado del sistema y aplicaciones desplegadas.
 Conocer cuando y qué va mal.
 Aviso temprano de problemas, defectos o ataques para solventarlos. Alertas!!!
 Análisis de tendencias a largo plazo, p.e. mostrar la degradación de los
recursos de infraestructura.
 Realización de análisis retrospectivos, lo cual nos permite calcular con mayor
precisión valores futuros (carga, recursos necesarios, …)
 Creación de dashboards.
 Black Box Monitoring: Pruebas de humo, probar el comportamiento como si lo
viese un usuario externo (sistema no funciona, servidor caído, ping no
responde, …)
 White Box Monitoring: Basado en la métricas expuestas (profiling JVM,
estadísticas HTTP, …) y permite la detección de problemas inminentes, fallos
enmascarados, ...
Monitoring Distributed System: https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/

5. Host
CPU, Memory, I/O,
Network, Filesystem
Contenedores
CPU, Memory, I/O,
Restarts, Throttling
Aplicaciones
Throughput, Latencia
¿Qué monitorizar?

6. The Four Golden Signals
The Four Golden
Signals
Latencia
El tiempo que tarda nuestro
sistema en atender una solicitud.
Es importante distinguir entre la
latencia de las solicitudes
correctas y la latencia de las
solicitudes fallidas.
Trafico
Una medida de cuánta demanda está
recibiendo nuestro sistema, medida
en una métrica específica del sistema
de alto nivel. P.e: solicitudes por
segundo desglosadas por su
naturaleza (estático vs. dinámico).
Errores
Tasa/ratio de solicitudes que fallan,
explícitamente (HTTP 500),
implícitamente (HTTP 200, payload
incorrecto) o por políticas (p.e.
solicitud que tarda más de 10 sgs).
Saturación
Como de “lleno” se encuentra el
servicio. Una medida de parte de
nuestro sistema, enfocada en los
recursos más ocupados. Los sistemas
degradan su rendimiento antes de
alcanzar el 100% de recursos.
Monitoring Distributed System: https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/

7. Alertas
02
La importanción de las alertas para
ser proactivos.

8. Alertas
Alertas basadas en síntomas
 Ser proactivo
Evitar la fatiga por alertas
 Utilizando sistema de tickets (PagerDuty, Teams, Slack, …)
 No utilizar en la medida de lo posible los emails para evitar la sensación
de que las alertas son Spam.
 Warning  Tarea  Nueva Funcionalidad
Manuales (runbooks) asociados a las Alertas
 Específicos por alerta y basado en experiencias.
 Explicación del síntoma, con sugerencias y links.
 Dinámicos: Se deben actualizar con observaciones recientes.
Realizar simulacros de “incendio”
 Se deben hacer regularmente en entornos no de producción para
evaluar como de eficientes son nuestras alarmas.
Alarmas Proactivas
 Adelantarnos al incendio para no ser bomberos
”Esperar no es una estrategia”
Site Realiability Engineering: https://landing.google.com/sre/sre-book/toc/index.html

9. Prometheus
03
¿Qué es Prometheus? Arquitectura,
Métricas y ejemplos.

10. Prometheus
 Sistema de monitorización de métricas y generador de alertas
 Inspirado en el sistema de monitorización Borgmon
 Creado por SoundCloud (ex-Googlers)
 100% Open Source, principalmente escrito en GO
 Proyecto CNCF (Cloud Native Computing Foundation)
 Ampliamente extendido y multitud de integraciones con
terceros
 Docker, DigitalOcean, Boxever, SpaceNet, SoundCloud, Core OS,
Ericsson, Red Hat, …

11. ¿Qué es Prometheus?
 Modelo de datos multidimensional. Series temporales se identifican mediante pares de clave-
valor.
 Pares clave valor database.connections {host=host1, db=ventas, estado=open}
 Flexible lenguaje de consultas. PromQL es un potente lenguaje de consultas que permite
navegar entre las dimensiones de la series temporales para generar gráficos, tablas y alertas.
 Obtención de métricas mediante el modelo Pull sobre HTTP.
 Instrumentación directa
 Instrumentación no directa: Exporters
 Almacenamiento eficiente
 Base de datos local en disco
 Datos se almacenan en un formato especifico
 Nodos de servidor autónomos sin dependencia de almacenamiento distribuido
 Escalado mediante fragmentación funcional y federación
 Proporciona interfaces para integrase con sistemas de almacenamiento remoto.
 Bajo impacto operacional. Cada servidor es independiente en cuanto a confiabilidad, solo
dependen del almacenamiento local. En caso de fallo del servidor, los ‘targets’ no sufren ninguna
interferencia en su funcionamiento.

12. ¿Qué es Prometheus?
 Múltiples modos de visualización
 Navegador de expresiones PromQL integrado en el servidor
 Integración con Grafana
 Consola de lenguaje de plantillas integrada en AlertManager
 Sistema de Alarmas. Prometheus tiene su propio sistema de alertas (AlertManager).
 Las alarmas se definen mediante PromQL sobre los datos multidimensionales y se
activan/desactivan dependiendo del resultado de la definición de la alerta y otras
variables, como la continuidad en el tiempo de una determinada condición.
 Fácil integración con email, sms, Teams, Slack, PagerDuty, JIRAlert, …
 Las alertas pueden adjuntar “runbooks” específicos para cada alerta, con
información de como abordar las operaciones asociadas a la alerta:
explicaciones, sugerencias, enlaces…
 Librerías cliente e integraciones. Existen librerías clientes para multitud de lenguajes
(Java, Go, Python, C, C++, Rust, …). Los exporters permiten una fácil integración terceros
con Prometheus (Databases, Hardware, Store, …)
 Infrastructure as code (targets, alerts, notifications, webhooks, …)
 Everybody loves Prometheus
Red Hat OpenShift: Prometheus Cluster Monitoring, Monitoring Kubernetes with Prometheus, OpenShit: Prometheus Operator

13. ¿Qué no es Prometheus?
 Procesamiento de logs o colecciones de eventos (usar ELK, EFK o PLG stack)
 Request Tracing (usar Open Tracing, Zipkin o Jaeger)
 Herramienta Mágica para la detección de anomalías
 Escalado horizontal automático
 Almacén de información a largo plazo. La información de las métricas se
mantiene durante varias semanas
 User/Auth Management
PromCon 2016: Prometheus Design and Philosophy - Why It Is the Way It Is - Julius Volz: https://youtu.be/4DzoajMs4DM https://goo.gl/1oNaZV

14. Prometheus Manifiesto
Monitorización de sistema operativos
(no solo) para la nube
Nodo único simple
Almacenamiento local durante algunas
semanas
Ficheros de configuración
Extraer (Pull) datos de procesos
individuales
NoSQL querys & data messaging
Multidimensional Data
Todo es float64
Ficheros de logs en cruzo, traceo de requests,
magia para la detección de anomalías, SLA
reportings
Escalar horizontalmente, clustering
multitenancy
Web UI, gestión de usuarios
Push datos desde los procesos
point-and-click
Datos lineales
Tipos de datos complejos
versus
versus
versus
versus
versus
PromCon 2016: Prometheus Design and Philosophy - Why It Is the Way It Is - Julius Volz: https://youtu.be/4DzoajMs4DM https://goo.gl/1oNaZV

15. Arquitectura

16. ¿Cómo se obtienes las Métricas?
Directly
Instrumented
Not Directly
Instrumented
Exporter
PromCon 2016: So You Want to Write an Exporter - Brian Brazil https://promcon.io/2016-berlin/talks/so-you-want-to-write-an-exporter/

17. EXPORTERS
Exporters: https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters

18. EXPORTERS
Exporters: https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters

19. Métricas: AIX
IBM – Nimon Working With Prometheus: https://www.ibm.com/support/pages/nimon-working-prometheus

20. Métricas: Orable DB
Oracle DB Exporter expone métricas mediante un endPoint en formato
Prometheus. Por defecto, expone una serie de métricas (estado Oracle,
commits, rollbacks, sesiones, tablespaces, procesos, …), pero también permite
crear métricas personalizadas.
Monitoring Oracle Database using Prometheus: https://technology.amis.nl/2019/08/09/monitoring-oracle-database-using-prometheus/

21. Métricas: Apache
Apache Exporter permite exponer un endPoint con métricas en formato
Prometheus. Se puede instalar como servicio y el único requisito es que el
exporter tenga acceso a la pagina server-status.
Monitoring Apache Web Server with Prometheus in 5 minutes: https://computingforgeeks.com/how-to-monitor-apache-web-server-with-prometheus-
and-grafana-in-5-minutes/

22. Alta
Disponiblidad
04
Alternativas para la configuración de una
arquitectura de alta disponiblidad

23. Federación
● Hierarchical federation: La topología se asemeja a un árbol, con
servidores Prometheus de nivel superior que recopilan datos de series
temporales agregadas de servidores subordinados.
● Cross-service federation: En la federación de servicios cruzados, un
servidor Prometheus de un servicio está configurado para raspar datos
seleccionados del servidor Prometheus de otro servicio para permitir
alertas y consultas contra ambos conjuntos de datos dentro de un solo
servidor.
Solución de serie de Prometheus. Un servidor de Prometheus obtiene la métricas de
otros servidores de Prometheus. Un caso de uso, centralizar las métricas de varios
servicios o entornos (prod, test, desarrollo) en un único servidor, funcionando como
DataSource a un único Grafana, evitando tener tantos Grafana como Prometheus.
Prometheus Federation: https://prometheus.io/docs/prometheus/latest/federation/, https://mattermost.com/blog/monitoring-a-multi-cluster-
environment-using-prometheus-federation-and-grafana/,

24. Cortex
Es una implementación de clustered de Prometheus que proporciona escalabilidad
horizontal, multi-tenency, durability and long-term storage. Cortex un proyecto CNCF
en sandbox (Early Stage). Grafana soporta Cortex para clustering.
Cortex consta de múltiples microservicios escalables horizontalmente. Cada
microservicio utiliza la técnica más adecuada para el escalado horizontal, la mayoría
no tienen estado y pueden manejar las solicitudes de cualquier usuario, mientras que
algunos (los ingesters) tienen estado parcial y dependen de un hash constante.
Un ingester es un servicio responsable de escribir series entrantes en un back-end de
almacenamiento a largo plazo, en la ruta de escritura (Write Path) y devolver
muestras de series en memoria para consultas en la ruta de lectura (Query Path). Es
un claro ejemplo de CQRS.
Cortex: https://www.cncf.io/blog/2018/12/18/cortex-a-multi-tenant-horizontally-scalable-prometheus-as-a-service/,
https://grafana.com/blog/2020/01/16/how-cortex-is-evolving-to-ingest-1-trillion-samples-a-day/, https://www.youtube.com/watch?v=f8GmbH0U_kI

25. Thanos
Thanos es un conjunto de componentes para generar un sistema métrico de alta
disponibilidad con capacidad de almacenamiento ilimitada, que se puede agregar sin
problemas en la parte superior de las implementaciones de Prometheus existentes. Al
igual que Cortex, es un proyecto CNCF en sandbox (Early Stage).
Thanos consta de varios componentes: Bucket, Check, Compactor, Query, Rule, Store
y Sidecar.
Thanos: https://github.com/thanos-io/thanos, https://improbable.io/blog/thanos-prometheus-at-scale

26. Thanos
Sidecar es la pieza clave para entender la arquitectura de Thanos y recibe su nombre por
el Patrón Sidecar. Cada una de las instancias de Prometheus, tiene un Sidecar de Thanos.
De esta manera, el sidecar puede cargar (opcionalmente) las métricas en los Store
(almacenamiento de objetos), que es de donde los Queriers consultan los datos de
Prometheus a través del StoreAPI
Thanos: https://improbable.io/blog/thanos-architecture-at-improbable, https://medium.com/@mail2ramunakerikanti/thanos-for-prometheus-
f7f111e3cb75

27. Openshift Monitoring Stack
Basado en Prometheus y su ecosistema, incluye componentes de monitorización para la
plataforma (instalados por defecto) y componentes para monitorizar proyectos (definido
por el usuario).
https://docs.openshift.com/container-platform/4.6/monitoring/understanding-the-monitoring-stack.html, https://docs.openshift.com/container-
platform/4.6/operators/operator_sdk/osdk-monitoring-prometheus.html

28. DEMO
TIME

29. Referencias

30. CREDITS: This presentation template was created by
Slidesgo, including icons by Flaticon and infographics
& images by Freepik
Gracias!
¿Tienes alguna pregunta?
hfuentepe@gmail.com