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.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.