Grafana Alloy en clínicas: métricas, logs y salida
Un caso de clínica privada muestra cómo ordenar métricas, logs y trazas con Grafana Alloy, OpenTelemetry, permisos, costos y prueba de caída.
Antes, sistemas revisaba cada servidor cuando admisión decía que el turno no cargaba; después, una misma pantalla mostró API, base, cola y error. En una clínica privada de Godoy Cruz, los logs estaban en archivos locales y las métricas en paneles sueltos. Grafana Alloy ordena la recolección con OpenTelemetry; este caso muestra qué entra, qué sale y cómo se prueba una caída.
Dónde se pierde la primera hora de soporte
La primera hora se pierde cuando cada proveedor mira su propio panel. Historia clínica, turnos, facturación y laboratorio generan señales distintas: logs, métricas, trazas y estados de servicio. Si esas señales quedan separadas, soporte descubre tarde si falló la API, la base, la red o una integración.
La referencia global ayuda a no tratar el caso como rareza local. Stack Overflow 2024 midió PostgreSQL con 48,7% de uso y Docker con 59,8% entre desarrolladores. En clínicas medianas, esa mezcla se repite: bases conocidas, contenedores, aplicaciones web y servicios que necesitan observabilidad antes de que el mostrador empiece a llamar.
Grafana Alloy es una distribución abierta del OpenTelemetry Collector con componentes para métricas, logs, trazas y perfiles. Su repositorio oficial lo describe como distribución del collector con pipelines programables y soporte de Prometheus. Esa definición baja a una tarea concreta: recibir señales, transformarlas y mandarlas a un destino medible.
El antagonista del caso era el archivo app.log copiado por chat. El encargado de sistemas tenía una carpeta con exports de distintos días; el dato servía para discutir un incidente viejo, pero llegaba tarde para operar el turno de la mañana.
En el rack quedaba una etiqueta blanca con nombres de servidores escritos a mano. Esa etiqueta ayudaba a ubicar cables, aunque no decía si turnos, laboratorio o facturación estaban perdiendo solicitudes en ese momento. El tablero debía responder esa pregunta sin abrir sesión en cada máquina.
Cómo funciona por dentro
El flujo empieza en cada servidor o contenedor. Alloy corre como agente y recibe métricas de exporters, logs del sistema y trazas por OTLP. El componente otelcol.receiver.otlp acepta datos de aplicaciones instrumentadas; otros componentes leen archivos o endpoints Prometheus. Después, procesadores agregan etiquetas: clínica, sistema, ambiente, host y servicio.
El componente otelcol.exporter.prometheus convierte métricas OTLP al formato que consumen componentes Prometheus. Para logs, Alloy puede enviar a Loki; para trazas, a un destino compatible con OpenTelemetry. PostgreSQL sigue guardando turnos, pacientes, pagos y auditoría de la aplicación. Alloy no reemplaza esa base; transporta señales sobre su estado.
Los permisos separan lectura y cambio. Soporte puede ver paneles de servicio y errores recientes. Sistemas puede editar configuración de Alloy, credenciales y destinos. Proveedores externos reciben un panel acotado por servicio. Si un log contiene datos sensibles, el pipeline debe borrar o reducir campos antes de salir del servidor.
El backup incluye configuración de Alloy, reglas de alertas y tableros. Las señales históricas pueden vivir en Loki, Prometheus, Mimir o un destino propio. La restauración prueba que un agente nuevo arranca con la misma configuración, etiqueta el servicio correcto y vuelve a mandar métricas.
Qué se instala o configura primero
La pila mínima usa Grafana Alloy, Prometheus o Mimir para métricas, Loki para logs, un panel Grafana y alertas por correo o mensajería interna. En una clínica con cinco a diez servicios, el costo mensual de infraestructura ronda USD 18 a 45, entre ARS 25.776 y ARS 64.440 al dólar vendedor de ARS 1.432. Ese costo no incluye horas de instrumentación ni retención larga de logs.
El primer entregable verificable es un panel con cuatro señales: latencia de API, errores por servicio, uso de base y cola de integración. UMSA suele pedir que el panel tenga un incidente simulado con hora de inicio, alerta enviada y cierre, porque la observabilidad se compra con evidencia y se pierde con etiquetas mal puestas.
La implementación toma de dos a cuatro semanas si ya hay contenedores y endpoints de métricas. Si las aplicaciones solo escriben archivos locales, la primera semana se dedica a definir formato de log, campos sensibles y retención. La tarjeta de guardia queda plastificada junto al rack: servicio, panel, alerta y responsable.
Dónde se rompe y cómo probarlo
El primer riesgo es generar demasiadas etiquetas. La señal aparece cuando la cantidad de series crece por paciente, turno o IP. La prueba carga tráfico simulado y revisa cardinalidad antes de guardar datos durante días.
El segundo riesgo es enviar datos sensibles. La señal es un log con nombre, documento o diagnóstico. La prueba inyecta un evento controlado y verifica que el pipeline quite esos campos antes de salir.
El tercer riesgo es que la alerta llegue tarde. La señal aparece cuando el panel muestra caída y nadie recibió aviso. La prueba apaga un servicio de baja criticidad, mide minutos hasta alerta y registra quién cerró el incidente.
La clínica gana cuando soporte puede decir qué falló antes de llamar al proveedor equivocado.