Durante un incidente
Todos miran pantallas distintas, pero nadie puede decir cuándo empezó el problema ni qué cambió. Investigo el problema reconstruyendo primero lo que debería estar registrado.
Moodle · Operación
Observabilidad en Moodle: señales, alertas y respuesta operativa
La monitorización básica de la infraestructura informa sobre disponibilidad y consumo de procesador, memoria o disco. Para explicar por qué una operación tardó doce segundos necesito además señales de la aplicación y correlación entre la petición, la base de datos y las integraciones. Reúno esas señales con métricas, registros e identificadores de correlación o trazas; ninguna etiqueta garantiza por sí sola que una petición pueda reconstruirse. También consulto los tiempos por tipo de página, el estado de las tareas, los errores agrupados y las versiones desplegadas.
- La vigilancia de la infraestructura y la instrumentación de la aplicación responden a preguntas distintas y se complementan.
- Los fallos de las tareas en segundo plano pueden pasar inadvertidos si nadie vigila su estado ni recibe alertas, y así originar problemas que aparecen días después.
- Toda alerta debe tener una persona responsable y una actuación prevista. Si se dispara sin exigir respuesta, reviso el umbral o la traslado a un panel.
- Correlacionar la experiencia de la persona con la base de datos y las integraciones reduce la incertidumbre del diagnóstico.
Experiencia en operación
Mido la experiencia real, la aplicación, la base de datos, las tareas en segundo plano y las integraciones. Defino alertas sobre percentiles, errores y divergencias, cada una con la actuación que dispara, y relaciono la señal con los despliegues coincidentes para comprobar si alguno explica el cambio.
Mi trayectoriaCuándo se echa en falta
Cuatro situaciones en las que la falta de observabilidad me cuesta horas de trabajo.
Cuando alguien dice que va lento
Sin datos, no puedo confirmar ni descartar el problema. El aviso queda sin verificar y la incidencia puede no hacerse visible hasta que aparecen más casos.
Cuando una integración deja de sincronizar
Durante semanas, nadie nota el fallo porque no da señales. Lo detecto por una discrepancia que ya afecta a personas.
Después de un despliegue
Despliego el cambio y no tengo nada que mirar. Si algo empeora, me entero por otra vía y no lo relaciono con el despliegue.
Las cinco capas que necesito ver
Investigo desde la experiencia de la persona que usa la plataforma hacia dentro, en ese mismo orden. Empezar por la máquina me ha hecho perder tardes enteras.
- 01
La experiencia real
Mido el tiempo de respuesta por tipo de página y acompaño la media con percentiles. Una medida agregada por sí sola puede ocultar las esperas de una parte de las personas, y la portada y un cuestionario no se parecen.
- 02
La aplicación
Agrupo los errores por causa, no por orden de aparición. Así puedo decir «esto ha pasado cuatrocientas veces desde el martes» en lugar de revisar cuatrocientas líneas sueltas. Asocio también la versión desplegada para relacionar un aumento con un cambio.
- 03
La base de datos
Vigilo las consultas lentas, las esperas, las conexiones en uso y el crecimiento de las tablas. Muchas veces encuentro el límite en esta capa, que explica lo que observo en las capas superiores.
- 04
Las tareas en segundo plano
Compruebo cuáles se han ejecutado, cuánto han tardado, cuáles han fallado y cuáles siguen sin completarse. Pueden fallar en silencio y mostrar su efecto días después, cuando faltan datos.
- 05
Las integraciones
Vigilo el volumen de operaciones, los errores, los tiempos de respuesta del sistema externo y las diferencias detectadas en la reconciliación. Configuro alertas para las caídas de la integración y no espero a descubrirlas por un descuadre.
Qué medir y qué alertar
Cinco preguntas que me hago para no acabar con veinte paneles y ninguna respuesta.
- 01
¿Qué preguntas quiero poder responder en un incidente?
Empiezo por ahí, no por las herramientas. Mis cuatro preguntas habituales son «¿cuándo empezó?», «¿qué cambió?», «¿a cuánta gente afecta?» y «¿qué capa está lenta?».
- 02
¿Esta alerta exige que alguien haga algo?
Si no exige actuar, no la considero una alerta: la llevo a un panel y documento cuándo se revisará.
- 03
¿Se mide lo que sufre la persona o lo que consume la máquina?
La máquina puede ir sobrada mientras la experiencia es mala. Tomo como indicador principal el tiempo de respuesta percibido.
- 04
¿Sé qué versión estaba desplegada?
Sin asociar los datos a la versión, no puedo comprobar si la degradación coincide con un cambio ni investigar una posible relación causal.
- 05
¿Quién mira esto y cuándo?
Un panel que nadie abre no sirve de nada. Dejo escrito quién lo revisa, con qué frecuencia y qué hace cuando ve algo.
Lo que falla
Seis problemas habituales incluso en plataformas que ya tienen herramientas.
Alertas que saltan constantemente
Si una alerta salta cada día y no exige ninguna actuación, el equipo puede dejar de mirarla. Puede ser peor que no tenerla, porque crea una falsa sensación de cobertura y favorece que se ignoren también las alertas útiles.
Medias en lugar de percentiles
Un tiempo medio aparentemente bueno puede convivir con esperas muy altas para una parte de las personas. Por eso lo acompaño de los percentiles 95 y 99: la media puede esconder justo el problema que busco.
Tareas fallidas sin vigilancia
Una tarea puede tardar demasiado en completarse sin aparecer en el panel del servidor. Mientras tanto, puede dejar datos incompletos en la aplicación.
Sin una conservación justificada
Si un problema empezó hace un mes y los datos ya se han borrado, no se puede reconstruir. Fijo el plazo de conservación según el tiempo máximo de detección y la finalidad de cada clase de dato. Cuando vence, compruebo que los datos se hayan suprimido.
Registros con datos personales
Si las métricas, las trazas o los registros contienen datos personales, su recogida, consulta y conservación constituyen un tratamiento. Por eso documento la finalidad y la base jurídica, minimizo los datos, limito el acceso, aplico las medidas de seguridad adecuadas y fijo plazos de supresión.
Sin relación entre capas
Cuando las métricas de aplicación y de base de datos están separadas y las integraciones carecen de señales, investigar obliga a cruzar las horas a mano.
Diez comprobaciones para saber qué veis durante un incidente
Si durante un incidente no podéis responder a las cuatro primeras, centro el trabajo en ellas.
- Puedo decir el tiempo de respuesta de ayer por tipo de página.
- Puedo saber cuándo empezó una degradación sin preguntar a nadie.
- Sé qué versión estaba desplegada en ese momento.
- Los errores están agrupados por causa, no sueltos.
- Una tarea en segundo plano que falla genera un aviso.
- Una regla de vigilancia detecta la interrupción de una integración y avisa a la persona responsable.
- Las alertas que tenemos exigen todas alguna actuación.
- La retención cubre el tiempo que tarda en detectarse un problema lento.
- Los registros no guardan datos personales innecesarios.
- Está decidido quién mira esto y qué hace cuando ve algo.
Qué cambia con la criticidad
Decido qué inversión es razonable según el coste de no detectar un problema.
- Plataforma pequeña
Compruebo la disponibilidad, vigilo el estado de las tareas y reviso periódicamente los informes que incluye la plataforma. Con una inversión acotada puedo detectar antes algunos fallos comunes y reducir su impacto; estas medidas no evitan por sí solas los incidentes.
- Plataforma con actividad diaria
Mido los tiempos de respuesta, agrupo los errores y configuro alertas ante situaciones que exigen actuar. Aquí obtengo el mayor rendimiento por lo invertido.
- Con picos de convocatoria
Vigilo el pico en directo y lo comparo con el histórico. También limito algunas funciones de forma deliberada cuando necesito conservar lo esencial.
- Servicio crítico
Correlaciono las trazas, defino la guardia y preparo el procedimiento de gestión de incidentes. Después reviso cada incidente e introduzco cambios; sin esa revisión, los incidentes se repiten.
Qué exigir sobre observabilidad en un contrato
Exijo que la organización sepa cómo va su propia plataforma sin depender del proveedor.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Métricas accesibles para la organización | Paneles con tiempos de respuesta, errores y tareas | La organización consulta el estado sin pedirlo al proveedor |
| Definir cada alerta con la actuación prevista | Listado de alertas con umbral y actuación esperada | Cada alerta exige una acción concreta |
| Vigilancia de tareas en segundo plano | Panel con la ejecución, la duración y los fallos de las tareas | Para cada tarea se acuerda, según su impacto, el plazo máximo para detectar un fallo, un retraso o una ejecución incompleta. Las que afectan a exámenes, matrículas o calificaciones avisan dentro del plazo operativo definido; las de baja criticidad pueden agruparse para su revisión. |
| Estado de las integraciones | Volumen, errores y comprobación de que los datos coinciden en cada integración | Una integración detenida genera una alerta automáticamente |
| Retención y protección de datos | Plazos distintos para las métricas y las trazas, justificación de cada plazo según el tiempo máximo de detección, acceso según la función de cada persona y prueba de que los datos se suprimen | El contrato fija por separado el plazo de las métricas y el de las trazas, justifica cada plazo por su finalidad y por el tiempo máximo de detección, limita el acceso según la función de cada persona e incluye una prueba de que los datos se suprimen automáticamente cuando vence el plazo correspondiente. |
Tres formas de creer que observo la plataforma
Con las tres consigo paneles, pero no respuestas a las preguntas importantes.
Vigilar solo el servidor
Compruebo que el procesador, la memoria y el disco funcionan con normalidad mientras la gente espera, pero con esas señales no puedo determinar si la demora está en la base de datos o en un servicio externo.
Comprobar que la página principal responde
Compruebo la disponibilidad: sé si el servidor contesta, pero no si los cuestionarios se guardan ni si las calificaciones se calculan.
Acumular registros que nadie lee
Si guardo todo sin agruparlo ni configurar alertas, tengo la información, pero no la respuesta. Los registros me sirven cuando sé qué buscar; en mitad de un incidente, la pregunta todavía no está formulada.
Referencias
Fuentes y límites
- Documentación oficialInformes de rendimiento — documentación oficial de Moodle
Indicadores que ofrece la propia plataforma y recomendaciones asociadas. Consultado el 1 de agosto de 2026.
- Documentación oficialRegistro de eventos — documentación oficial de Moodle
Registro de actividad de la plataforma y sus almacenes. Consultado el 1 de agosto de 2026.
- Documentación oficialTareas programadas — documentación oficial de Moodle
Estado, ejecución y fallos de las tareas en segundo plano. Consultado el 1 de agosto de 2026.
- NormativaReglamento general de protección de datos — texto oficial
Definición de tratamiento, principios, licitud y seguridad en los artículos 4.2, 5, 6 y 32. Consultado el 11 de agosto de 2026.
Las cinco capas y el orden de investigación son criterio propio, formado diagnosticando incidentes concretos: no proceden de un marco publicado, aunque coinciden con prácticas habituales de observabilidad. Lo que ofrece la plataforma de fábrica está en la documentación enlazada y cambia entre versiones. La elección de herramientas concretas depende de lo que ya use cada organización y no la trato aquí porque no es específica de Moodle.
Blog
Incidentes reconstruidos con señales.
En el blog reconstruyo incidentes a partir de métricas, registros, trazas y actuaciones verificables.
Ir a blog.albertolarah.comContacto
Cuando de los problemas se entera uno porque llama alguien
Miro qué se mide, qué alertas hay, qué pasó en el último incidente y cuánto se tardó en descubrir qué fallaba. Una carencia que encuentro con frecuencia es la falta de vigilancia de las tareas en segundo plano.
hola@albertolarah.comLinkedIn ↗