Categoría: Observabilidad
Monitorización con Grafana y Prometheus, implantada y operada
Métricas, registros y alertas que avisan de lo que importa a vuestros usuarios, no de cada pico de CPU, en una plataforma que vive en vuestra cuenta.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
Grafana y Prometheus son herramientas de código abierto para recoger métricas, visualizarlas y generar alertas; Loki hace lo mismo con los registros. Los implantamos en vuestra cuenta con Alloy u OpenTelemetry como recolector, definimos objetivos de servicio (SLO), configuramos Alertmanager para que las alertas lleguen sin ruido a quien toca, creamos paneles por servicio y vigilamos la retención y el coste.
¿Qué pieza hace qué?
Una plataforma de monitorización no es un panel bonito: es una cadena que recoge datos, los guarda, decide si algo va mal y avisa a la persona adecuada. Si un eslabón falla, os enteráis por un cliente.
Prometheus
Recoge y guarda métricas, y evalúa las reglas de alerta cada pocos segundos.
Loki
Guarda los registros indexando solo sus etiquetas, lo que lo hace barato de almacenar.
Alloy u OpenTelemetry
Recolectores en cada servidor o clúster que envían métricas, registros y trazas.
Alertmanager
Agrupa, enruta, inhibe y silencia alertas antes de mandarlas a nadie.
Grafana
Paneles por servicio y exploración de métricas y registros en un mismo sitio.
Comprobación externa
Una prueba desde fuera que avisa aunque caiga la propia monitorización.
¿Cómo diseñamos las alertas para que no hagan ruido?
La mayoría de las alertas que encontramos avisan de causas, como CPU alta o memoria al 80 %, y no de síntomas. El resultado es que suenan a menudo, nadie las mira y la que importa se pierde. Lo enfocamos al revés:
Objetivos de servicio
Definimos con vosotros qué es funcionar bien: por ejemplo, que el 99,5 % de las peticiones respondan sin error. Eso es un SLO.
Alertas por consumo del margen
Se avisa cuando el margen de error se gasta demasiado deprisa, no por cada pico aislado.
Rutas en Alertmanager
Cada alerta va al equipo y al canal que toca; lo urgente, a la guardia si existe, y lo demás, a una cola de trabajo.
Agrupación e inhibición
Si cae un servidor, llega un aviso, no cuarenta. Si el centro de datos no responde, las alertas de sus servicios quedan inhibidas.
Cada alerta lleva un enlace a su panel y una nota de qué comprobar primero. Una alerta sin acción posible se quita.
¿Qué problemas encontramos en la monitorización que ya existe?
- Cientos de alertas que nadie atiende: el canal de avisos está silenciado desde hace meses.
- Etiquetas con demasiados valores: identificadores de usuario o de petición como etiqueta disparan la memoria de Prometheus o el índice de Loki.
- Registros sin retención: el disco se llena de logs que nadie consulta.
- Paneles hechos a mano: solo existen en la interfaz y se pierden al reinstalar.
- La monitorización corre en el mismo servidor que vigila: si cae, no avisa nadie.
- Nada mide lo que ve el usuario: todo está en verde y la web no carga.
¿Cómo controlamos la retención y el coste?
En servicios de pago por uso, el coste crece con cada host y cada gigabyte de registros. En una pila propia lo que crece es el almacenamiento, y se controla: retención corta con todo el detalle, datos resumidos para el histórico, almacenamiento de objetos para lo antiguo y filtros en el recolector para no guardar registros que no aportan. Lo revisamos cada mes con el resto del informe.
¿Qué vigilamos de cada aplicación?
Cada aplicación tiene sus señales propias. En PostgreSQL, el retraso de réplica y el archivado de WAL; en Kafka, el retraso de los consumidores; en Kubernetes en Hetzner, el plano de control y los nodos; en GitLab, los runners y el registry; en Keycloak, los inicios de sesión fallidos. Si lo que queréis es que alguien responda de todo esto cada mes, encaja en el SRE como servicio.
¿Y Graylog?
Graylog indexa el texto completo de los registros sobre OpenSearch: busca muy bien, pero pide más disco y memoria que Loki, que solo indexa etiquetas, y para la mayoría de equipos Loki junto a Grafana basta. Si buscáis a menudo en el contenido de los registros o ya lo tenéis, lo contamos en centralización de logs con Graylog u OpenSearch.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Prometheus, Loki y Grafana en servidores cloud o en vuestro clúster, con los datos de Loki y el histórico de métricas en Object Storage de Hetzner. | Sin servicio gestionado de monitorización: lo operamos todo nosotros. Muy económico en almacenamiento. |
| AWS | La pila en EC2 o EKS con S3 como almacenamiento, o Amazon Managed Service for Prometheus y Amazon Managed Grafana. | CloudWatch sigue haciendo falta para algunos servicios de AWS; lo integramos como fuente de datos. |
| Google Cloud | La pila en GKE con Cloud Storage, o Google Cloud Managed Service for Prometheus. | Cloud Monitoring se puede consultar desde Grafana. |
| Azure | La pila en AKS con Blob Storage, o Azure Monitor managed service for Prometheus con Azure Managed Grafana. | Azure Monitor se añade como fuente de datos en Grafana. |
| DigitalOcean | La pila en Droplets o en DOKS, con Spaces como almacenamiento de objetos. | Sin servicio gestionado equivalente: la montamos y la operamos nosotros. |
| OVH | La pila en instancias de Public Cloud o en Managed Kubernetes, con Object Storage compatible con S3. | |
| Servidor propio | Prometheus, Loki y Grafana en un servidor de la oficina o en una máquina virtual. | El vigilante no debe caer con lo vigilado: añadimos una comprobación externa desde otro sitio. |
Qué incluye
- Prometheus o un almacén compatible para métricas, con retención y almacenamiento a largo plazo definidos.
- Loki para registros, con etiquetas pensadas para que las búsquedas sean rápidas y baratas.
- Grafana Alloy u OpenTelemetry Collector en servidores, contenedores y Kubernetes.
- Objetivos de servicio (SLO) para lo que notan vuestros usuarios: disponibilidad, latencia y errores.
- Alertmanager con rutas, agrupación, inhibiciones y silencios, conectado a correo, chat o vuestra herramienta de guardias.
- Paneles por servicio en Grafana, guardados en código en vuestro repositorio.
- Inicio de sesión en Grafana con vuestro proveedor de identidad.
- Revisión mensual de alertas: las que no sirven se eliminan o se ajustan.
Preguntas frecuentes
¿Grafana y Prometheus sirven como alternativa a Datadog?
Para métricas, registros, paneles y alertas, sí. Perdéis la comodidad de un servicio que se instala en una tarde y ganáis control sobre los datos y sobre el coste, que no crece por host ni por gigabyte ingerido. Lo que hace falta es alguien que opere la pila; ese es nuestro trabajo.
¿Quién atiende las alertas de noche?
La vigilancia automática es continua: las alertas saltan y quedan registradas a cualquier hora. La respuesta humana es el siguiente día hábil, en horario laboral, con plazos pactados por escrito.
¿Cuánto tiempo se guardan las métricas y los registros?
Lo que decidamos según el uso y el coste. Lo habitual es poco tiempo con todo el detalle y más tiempo con datos resumidos. Los registros con datos personales tienen además un plazo máximo que fijamos por protección de datos.
¿Podéis añadir monitorización a lo que ya tenemos?
Sí. Si ya tenéis Prometheus o Grafana a medias, partimos de ahí: revisamos qué se recoge, quitamos las alertas que nadie atiende y añadimos lo que falta.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el