Grafana 13.1 en guardias: alertas, roles y prueba
Guía para usar Grafana 13.1.1 con PostgreSQL, alertas y permisos por carpeta. Qué dato consulta, quién edita reglas y cómo probar avisos antes de depender de ellos.
Una alerta útil empieza en una consulta: mide un hecho, compara un umbral y deja una notificación revisable. Grafana 13.1.1, publicado el 21 de julio, sirve para mirar métricas, logs y datos de PostgreSQL desde una misma guardia. Para una pyme con soporte nocturno, la guía muestra qué tablero crear, quién puede editarlo y cómo probar que el aviso llega.
Dónde se pierde la guardia cuando todo avisa igual
El problema operativo aparece cuando el mismo chat recibe cortes de internet, errores de base, disco lleno, cámaras caídas y avisos de usuarios. La guardia lee diez mensajes y atiende el que suena más urgente. El antagonista es la alerta sin dueño: molesta durante semanas y nadie sabe qué regla la creó. La release 13.1.1 de Grafana quedó publicada el 21 de julio de 2026. La documentación de Grafana Alerting explica que las reglas pueden evaluar métricas o logs desde múltiples fuentes y enviar notificaciones según contacto, política y estado. En una municipalidad chica del Gran Mendoza, el detalle que volvió tangible el problema fue una planilla impresa con teléfonos de guardia corregidos a mano. La cifra externa viene de Stack Overflow 2025: 54% de quienes respondieron usa seis o más aplicaciones o plataformas para crear, analizar, gestionar o compartir información en su trabajo. Esa dispersión explica por qué una alerta útil debe cerrar una pregunta concreta: qué falló, desde cuándo, a quién afecta y qué persona tiene permiso para tocar la regla.
Cómo funciona por dentro
Grafana consulta datos, dibuja paneles y evalúa reglas de alerta. PostgreSQL guarda registros estructurados del sistema operativo: servicios, estados, tickets, eventos, mediciones o auditoría. La fuente de datos de PostgreSQL en Grafana permite consultas de series temporales, tablas, EXPLAIN, variables y alertas sobre resultados en formato temporal. La regla toma una consulta, aplica una condición y envía una notificación si el estado cambia. 1. El servicio registra medición, estado o evento en PostgreSQL. 2. Grafana consulta la fuente con un usuario de solo lectura. 3. El tablero muestra estado, tendencia y último evento. 4. La regla evalúa umbral, ventana y ausencia de datos. 5. La política envía el aviso al canal de guardia correcto. 6. Los permisos definen quién ve, edita y administra carpetas. 7. El backup copia dashboards, reglas y base de configuración; una restauración abre el tablero y dispara una alerta de prueba. Los roles separan lectura, edición y administración. La guía de roles y permisos distingue administrador del servidor, roles de organización y permisos por carpeta o dashboard. Soporte puede ver tableros. Sistemas edita reglas. Gerencia lee indicadores. Un administrador toca fuentes de datos y usuarios. Si falla PostgreSQL, el panel queda sin datos; si falla Grafana, el dato sigue en la base y se consulta por SQL.
Qué se instala o configura primero
El primer entregable verificable es un tablero de guardia con cinco indicadores: disponibilidad, latencia, errores de aplicación, backups vencidos y tickets críticos. Cada indicador tiene consulta, dueño, umbral, canal y prueba escrita. La pila mínima usa Grafana 13.1.1, PostgreSQL 17 o 18, correo o mensajería para avisos, HTTPS, usuarios por grupo y exportación de dashboards. Con dólar oficial vendedor a ARS 1.515 informado por DolarAPI, una instancia chica puede ubicarse entre USD 35 y USD 70 mensuales, entre ARS 53.025 y ARS 106.050, según disco y respaldo. Un piloto de 20 a 32 horas técnicas a USD 30/h queda entre USD 600 y USD 960, es decir entre ARS 909.000 y ARS 1.454.400. Incluye instalación, fuente PostgreSQL, tres carpetas, cinco reglas, notificación, backup y restauración. Quedan fuera desarrollo de sensores, mesa de ayuda formal y guardia humana. UMSA puede aplicar este patrón cuando una organización ya tiene sistemas con datos y necesita convertirlos en avisos revisables. La decisión inicial es nombrar la condición que merece despertar a alguien. Disco al 91% durante cinco minutos puede ser una alerta; un pico aislado de diez segundos puede quedar como evento de tablero.
Dónde se rompe y cómo probarlo
El primer riesgo es usar una consulta pesada para alertas frecuentes. El indicio aparece cuando el tablero responde lento al mismo tiempo que la alerta evalúa. La prueba corre EXPLAIN, fija índice o vista materializada y mide duración antes de activar la regla. El segundo riesgo es abrir permisos de edición a toda la guardia. El indicio es una regla modificada sin motivo escrito. La prueba crea un usuario Viewer, uno Editor y un Admin; cada uno intenta leer, editar y borrar un panel en una carpeta de ensayo. El tercer riesgo es avisar sin salida operativa. La notificación dice "error" y nadie sabe qué mirar. La prueba apaga un servicio controlado, revisa mensaje, responsable, enlace al tablero y horario de recuperación. Después se restaura el tablero en otra instancia y se repite el disparo. Una guardia madura se reconoce por una alerta que alguien puede explicar al día siguiente.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.