|
Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado. |
Mejores prácticas de monitorización
No changes needed. No changes needed. No changes needed.
No changes needed. No changes needed. No changes needed. No changes needed.
Configuración del uso de recursos de Prometheus
No changes needed. No changes needed.
No changes needed.
No changes needed. No changes needed. No changes needed. No changes needed. No changes needed.
No changes needed.
rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])
No changes needed.
rate(prometheus_tsdb_head_samples_appended_total[1h])
No changes needed.
average chunk size in bytes * ingestion rate per second * retention time in seconds * 1.1 = necessary storage in bytes
No changes needed.
No changes needed.
Solicitudes y límites de CPU y memoria
No changes needed. La cantidad de memoria que necesita Prometheus se correlaciona directamente con la cantidad de series temporales, con la cantidad de etiquetas que almacena y con el intervalo de scraping en el que se llenan.
Puedes encontrar más información sobre cómo calcular la memoria necesaria en este post del blog.
La cantidad de CPUs necesarias se correlaciona con la cantidad de consultas que estás realizando.
Federación y almacenamiento a largo plazo
Prometheus no está destinado a almacenar métricas durante un largo período de tiempo, sino que debe ser utilizado solo para almacenamiento a corto plazo.
Para almacenar algunas o todas las métricas durante un largo tiempo, puedes aprovechar las capacidades de lectura-escritura remota de Prometheus para conectarlo a sistemas de almacenamiento como Thanos, InfluxDB, M3DB u otros. Puedes encontrar un ejemplo de configuración en este post del blog.
Scraping de cargas de trabajo personalizadas
Mientras que la monitorización integrada de Rancher ya recopila las métricas del sistema de los nodos y de los componentes de vuestro clúster, las cargas de trabajo personalizadas que desplegáis en Kubernetes también deberían ser recopiladas para obtener datos. Para ello, podéis configurar Prometheus para que realice una solicitud HTTP a un endpoint de vuestras aplicaciones en un intervalo determinado. Estos endpoints deberían devolver sus métricas en un formato de Prometheus.
En general, queréis recopilar datos de todas las cargas de trabajo que se ejecutan en vuestro clúster para poder utilizarlos para alertas o para depurar problemas. A menudo, reconocéis que necesitáis algunos datos solo cuando realmente necesitáis las métricas durante un incidente. Es bueno, si ya se ha recopilado y almacenado. Dado que Prometheus está destinado a ser solo un almacenamiento de métricas a corto plazo, recopilar y mantener muchos datos generalmente no es tan costoso. Si estáis utilizando una solución de almacenamiento a largo plazo con Prometheus, aún podéis decidir qué datos estáis realmente persistiendo y manteniendo allí.
Acerca de los Exportadores de Prometheus
Muchas cargas de trabajo de terceros, como bases de datos, colas y servidores web, ya admiten la exposición de métricas en un formato de Prometheus, o ofrecen exportadores que traducen entre las métricas de la herramienta y un formato que Prometheus entiende. Normalmente, podéis añadir estos exportadores como contenedores sidecar adicionales a los Pods de la carga de trabajo. Muchos gráficos de Helm ya incluyen opciones para desplegar el exportador correcto. Podéis encontrar una lista curada de exportaciones en ExporterHub.
Soporte de Prometheus en Lenguajes de Programación y Frameworks
Para introducir las métricas de vuestra propia aplicación personalizada en Prometheus, tenéis que recopilar y exponer estas métricas directamente desde el código de vuestra aplicación. Afortunadamente, ya hay bibliotecas e integraciones disponibles para ayudar con esto para la mayoría de los lenguajes de programación y frameworks populares. Un ejemplo de esto es el soporte de Prometheus en el Spring Framework.
ServiceMonitors y PodMonitors
Una vez que todas vuestras cargas de trabajo expongan métricas en un formato de Prometheus, debéis configurar Prometheus para que las recopile. Bajo el capó, Rancher utiliza el prometheus-operator. Esto facilita la adición de objetivos de recopilación con ServiceMonitors y PodMonitors. Muchos gráficos de Helm ya incluyen una opción para crear estos monitores directamente. También puedes encontrar más información en la documentación de Rancher.
Prometheus Push Gateway
Hay algunas cargas de trabajo que tradicionalmente son difíciles de recopilar por Prometheus. Ejemplos de esto son cargas de trabajo de corta duración como Jobs y CronJobs, o aplicaciones que no permiten compartir datos entre las solicitudes entrantes manejadas individualmente, como las aplicaciones PHP.
Para seguir obteniendo métricas para estos casos de uso, puedes configurar prometheus-pushgateways. El CronJob o la aplicación PHP enviarían actualizaciones de métricas al pushgateway. El pushgateway agrega y las expone a través de un punto final HTTP, que luego pueden ser recopiladas por Prometheus.
Prometheus Blackbox Monitor
A veces es útil monitorizar cargas de trabajo desde el exterior. Para esto, puedes usar el blackbox-exporter de Prometheus que permite sondear cualquier tipo de punto final a través de HTTP, HTTPS, DNS, TCP e ICMP.
Monitorización en una arquitectura de (micro)servicios
Si tienes una arquitectura de (micro)servicios donde múltiples cargas de trabajo individuales dentro de tu clúster se comunican entre sí, es realmente importante tener métricas y trazas detalladas sobre este tráfico para entender cómo se comunican todas estas cargas de trabajo entre sí y dónde puede haber un problema o un cuello de botella.
Por supuesto, puedes monitorizar todo este tráfico interno en todas tus cargas de trabajo y exponer estas métricas a Prometheus. Pero esto puede volverse rápidamente bastante intensivo en trabajo. Las mallas de servicios como Istio, que se pueden instalar con un clic en Rancher, pueden hacer esto automáticamente y proporcionar una rica telemetría sobre el tráfico entre todos los servicios.
Monitorización de usuarios reales
Monitorizar la disponibilidad y el rendimiento de todas tus cargas de trabajo internas es vital para ejecutar aplicaciones estables, fiables y rápidas. Pero estas métricas solo te muestran partes de la imagen. Para obtener una visión completa, también es necesario saber cómo tus usuarios finales lo están percibiendo realmente. Para esto, puedes consultar varias soluciones de monitorización de usuarios reales.
Control de la seguridad
Además de monitorizar las cargas de trabajo para detectar problemas de rendimiento, disponibilidad o escalabilidad, también se deben monitorizar el clúster y las cargas de trabajo que se ejecutan en él para detectar posibles problemas de seguridad. Un buen punto de partida es ejecutar y alertar frecuentemente sobre Escaneos de Cumplimiento que verifican si el clúster está configurado de acuerdo con las mejores prácticas de seguridad.
Para las cargas de trabajo, puedes echar un vistazo a soluciones de seguridad de Kubernetes y Contenedores como NeuVector, Falco, Aqua Kubernetes Security, SysDig.
Configuración de Alertas
Obtener todas las métricas en un sistema de monitoreo y visualizarlas en paneles es genial, pero también quieres ser alertado proactivamente si algo sale mal.
El monitoreo integrado de Rancher ya configura un conjunto sensato de alertas que tienen sentido en cualquier clúster de Kubernetes. Debes extender estas alertas para cubrir tus cargas de trabajo y casos de uso específicos.
Al configurar alertas, configúralas para todas las cargas de trabajo que son críticas para la disponibilidad de tus aplicaciones. Pero también asegúrate de que no sean demasiado ruidosas. Idealmente, cada alerta que recibas debería ser por un problema que necesita tu atención y que debe ser solucionado. Si tienes alertas que se activan todo el tiempo pero no son tan críticas, existe el peligro de que empieces a ignorar tus alertas por completo y luego te pierdas las realmente importantes. Menos puede ser más aquí. Empieza a centrarte primero en las métricas realmente importantes; por ejemplo, si tu aplicación está fuera de línea, genera una alerta. Soluciona todos los problemas que empiecen a surgir y luego comienza a crear alertas más detalladas.
Si una alerta comienza a activarse, pero no hay nada que puedas hacer al respecto en ese momento, también está bien silenciar la alerta durante un cierto período de tiempo, para que puedas revisarla más tarde.
Puedes encontrar más información sobre cómo configurar alertas y canales de notificación en la Documentación de Rancher.