Moodle 5.2 trae una novedad que pasó bastante desapercibida y que a mí me hizo ilusión: soporte de serie para OpenTelemetry. Traducido: Moodle puede emitir trazas de lo que hace en cada petición —el enrutado, el controlador, cada tarea de cron, cada llamada a un webservice— para que veas, con detalle de milisegundos, por dónde se va el tiempo.

Llevaba tiempo con la espinita de no tener buena observabilidad de mi Moodle. Tengo analítica de visitas sin cookies y un panel de monitorización que me dice si algo está caído, pero nada que me dijera por qué una página concreta tarda. Así que aproveché el soporte nuevo. Y, fiel a la costumbre de esta casa, con el dato quedándose en casa: nada de mandar la telemetría a un SaaS.

Te cuento qué es, cómo lo monté y —sobre todo— los sustos, que es donde se aprende.

Qué es esto de OpenTelemetry (en cristiano) #

OpenTelemetry (OTel) es un estándar abierto de observabilidad. La pieza que me interesa aquí son las trazas: cada petición web genera un span raíz, y dentro cuelgan spans hijos por cada operación relevante (enrutado, controlador/acción, procesamiento de tareas, webservices…). El resultado es una cascada en la que ves qué llamó a qué y cuánto tardó cada cosa.

No es monitorización de errores ni de “está caído / está arriba”. Es la pregunta siguiente: cuando algo va lento, ¿qué parte concreta se come el tiempo?

La decisión: Jaeger en local, no un SaaS #

OTel solo genera las trazas; necesitas un backend donde recogerlas y mirarlas (Jaeger, Grafana Tempo, SigNoz, Honeycomb, Datadog…). Los dos últimos son servicios de pago en la nube. Los descarté por lo de siempre: no quiero mandar fuera datos de rendimiento de mi sitio. Me quedé con Jaeger, que se levanta en un contenedor y guarda todo localmente. Coherente con el resto de mi infraestructura autoalojada.

Cómo funciona el montaje #

Tres piezas, y ninguna en la interfaz de Moodle (todo va por consola y configuración):

1. La extensión de PHP. OTel necesita una extensión C que se instala vía PECL:

   1pecl install opentelemetry
   

2. Los paquetes de Composer, en la raíz de la instalación de Moodle:

   1composer require moodlehq/moodle-package-otel open-telemetry/exporter-otlp
   

   El primero es la integración oficial de Moodle HQ (registra las hooks de auto-instrumentación); el segundo, el exportador que habla el protocolo OTLP.
3. La configuración, que en OTel se hace solo por variables de entorno o php.ini —no hay pantalla de ajustes—. Lo esencial: activar el autoload, dar nombre al servicio, decir “exporta por OTLP a esta dirección” y fijar un muestreo (en producción no quieres trazar el 100 % de las peticiones):

   1OTEL_PHP_AUTOLOAD_ENABLED=true
   2OTEL_TRACES_EXPORTER=otlp
   3OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
   4OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4318
   5OTEL_TRACES_SAMPLER=parentbased_traceidratio
   6OTEL_TRACES_SAMPLER_ARG=0.2
   

Y Jaeger, en un contenedor, escuchando OTLP y sirviendo su interfaz web. Con eso, cada petición de Moodle que caiga en el muestreo aparece en Jaeger a los pocos segundos.

Como remate, no quería otra URL más que recordar: metí la interfaz de Jaeger como una pestaña dentro de mi panel de monitorización, junto a las visitas y las alertas. Un iframe y un reverse proxy de Apache, y ya lo tengo todo en el mismo sitio.

Los sustos que enseñan #

Aquí es donde el “instalar cuatro cosas” se convierte en tarde de depuración.

Susto 1: recargué Apache, pero PHP no se enteró. Instalé la extensión, recargué Apache, generé tráfico… y el log se llenó de warnings diciendo que “la extensión opentelemetry debe estar cargada”. Encima, las trazas aparecían a ratos. El motivo: mi PHP corre con php-fpm, que es un servicio aparte de Apache. Recargar Apache no recarga php-fpm; sus workers seguían con la versión vieja, sin la extensión. Las trazas intermitentes eran de los pocos workers que se habían reciclado solos. La solución: recargar php-fpm de verdad (un kill -USR2 al proceso maestro hace un reload elegante). Moraleja: cuando instales una extensión de PHP, acuérdate de que php-fpm es su propio servicio.

Susto 2: no quería instrumentar TODOS mis sitios. En mi servidor, varios sitios comparten el mismo pool de php-fpm. Si activaba OTel en php.ini, se lo comía todo el PHP del servidor, no solo Moodle. Quería acotarlo a una sola instalación. La salida elegante: definir las variables de entorno por virtual host en Apache (SetEnv), no globalmente. El detalle bonito es por qué funciona: esas variables viajan a PHP como parámetros FastCGI y aterrizan en $_SERVER, y el SDK de OpenTelemetry lee su configuración también de $_SERVER, no solo de getenv(). Así, aunque el pool sea compartido, las variables solo existen en las peticiones de ese vhost. Instrumentación quirúrgica, sin tocar a los vecinos.

Susto 3: la interfaz de observabilidad no tiene contraseña. Jaeger, de fábrica, no trae ningún login. Y su interfaz muestra tus trazas: URLs internas, tiempos, nombres de tareas… información que no quieres regalar. Exponer una herramienta así a internet tal cual es un error de manual. Lo puse detrás de una contraseña a nivel de servidor web, con el añadido de que desde mi red privada no la pide. La regla general: una UI de observabilidad sin autenticación no se publica jamás sin poner algo delante.

Para qué sirve, en la práctica #

Cuando una página de Moodle va lenta, ya no adivino. Busco su traza en Jaeger, abro la cascada de spans y veo, barra a barra, qué operación se come el tiempo: un controlador pesado, el procesamiento de una tarea, una llamada externa que tarda. Además, Jaeger deja comparar dos trazas lado a lado, así que puedo poner una petición rápida junto a una lenta y ver exactamente en qué se diferencian.

No lo necesito cada día. Pero el día que algo va raro, la diferencia entre mirar una cascada de spans y mirar el techo es enorme.

Vista al futuro: ¿y si le pongo Grafana? #

Jaeger me resuelve una pregunta muy concreta: "¿por qué esta petición fue lenta?". Pero se queda ahí, en una traza cada vez. La evolución natural —y lo próximo que quiero explorar— es sumarle Grafana.

Conviene entender que Jaeger y Grafana no compiten; juegan en posiciones distintas. Jaeger guarda y muestra trazas: el detalle fino de una petición. Grafana es un panel de visualización que junta varias fuentes en un mismo sitio; no almacena datos por sí mismo, sino que se conecta a otros backends (y uno de ellos puede ser el propio Jaeger). Dicho en una frase: Jaeger me enseña un árbol; Grafana me enseñaría el bosque.

¿Qué ganaría con Grafana encima?

1. Métricas a lo largo del tiempo. OTel no solo emite trazas, también métricas (que ahora mismo tengo desactivadas). Con un almacén de métricas —Prometheus— y Grafana delante, vería tendencias: la latencia media y sus percentiles (p95, p99), las peticiones por minuto, la tasa de errores… día a día. Una traza es una foto; esto sería la película.
2. Correlación entre las tres patas. El ideal de la observabilidad es saltar de una métrica que se dispara → a las trazas de ese momento → a los logs de esa petición, sin cambiar de herramienta. Grafana es quien cose esas tres capas.
3. Alertas. Grafana puede avisarme cuando algo se degrada (“el p95 pasa de tal”, “la tasa de error sube”). Jaeger, por sí solo, no alerta.
4. Mis propios paneles. En vez de la búsqueda de trazas de Jaeger, cuadros a medida: los endpoints más lentos, la salud del cron, lo que yo decida.

¿El precio? Más piezas que mantener. Grafana, un almacén de métricas, quizá cambiar Jaeger por Grafana Tempo (su equivalente para trazas, que integra de fábrica) y, si me animo con los logs, Loki. Es el conocido stack “LGTM” (Loki, Grafana, Tempo, Mimir). Para un Moodle personal como el mío, Jaeger solo ya cumple; Grafana empieza a tener sentido cuando quieres pasar de “apagar un fuego concreto” a “vigilar la tendencia y que te avisen antes de que arda”.

Así que lo dejo apuntado como siguiente paso: mantener Jaeger para el detalle y montar Grafana encima para las tendencias, las alertas y tener las tres patas —trazas, métricas y logs— cosidas en un mismo panel. Cuando lo haga, os lo cuento.

La lección #

Tres cosas me llevo. La primera: la observabilidad self-hosted está al alcance. Un contenedor y tres paquetes, y tienes trazas de nivel profesional sin pagar una suscripción ni mandar tus datos a nadie. Que Moodle 5.2 lo traiga de serie ayuda mucho.

La segunda: el trabajo de verdad no está en instalar, está en desplegar bien. Recargar el servicio correcto, acotar la instrumentación a lo que quieres, poner autenticación donde el software no la trae. Ahí es donde se va la tarde, y ahí es donde está el criterio.

Y la tercera, la de siempre cuando uno se autoaloja: cada pieza nueva es una superficie nueva que cuidar. Una herramienta que “solo es para ver gráficas” también se expone, también se protege y también hay que mantenerla. Merece la pena, pero con los ojos abiertos.