Hola.
¿Sabeis si existe algún plugin moodle_* para munin?
Salu2
Fernando
Es complicado, pues munin está hecho para monitorizar distintos aspectos del sistema (servidor web, BD, carga del sistema, uso de disco, etc...) ¿qué tipo de información crees que debería mostrar el plugin acerca de Moodle? a lo mejor se puede programar algo... 
Hola, Xavier.
En principio con tener un gráfico en el que aparezca el número de usuarios en línea puede ser un buen inicio, aunque después seguro que a alguien se le ocurre poner el número de clicks por horas o minutos, la ratio clicks/usuarios activos, etc.
Quizá se podría desarrollar un módulo de moodle que realizara las consultas en la BD y que dejara los datos ya elaborados en una carpeta específica, que es donde buscaría el plugin moodle_ de munin.
Cada instalación de moodle podría dejar un archivo en la carpeta a la que accede munin para poder tener en una gráfica la información de todas las instalaciones.
En la configuración del módulo habría que indicar en qué carpeta se deja el archivo y el nombre del mismo.
El módulo se ejecutaría mediante el cron de moodle.
¿Qué te parece?
Salu2
Fernando
Quizá se podría desarrollar un módulo de moodle que realizara las consultas en la BD y que dejara los datos ya elaborados en una carpeta específica, que es donde buscaría el plugin moodle_ de munin.
Cada instalación de moodle podría dejar un archivo en la carpeta a la que accede munin para poder tener en una gráfica la información de todas las instalaciones.
En la configuración del módulo habría que indicar en qué carpeta se deja el archivo y el nombre del mismo.
El módulo se ejecutaría mediante el cron de moodle.
¿Qué te parece?
Salu2
Fernando
Justo te iba a comentar eso mismo, que munin no podría acceder directamente a esos datos, o al menos yo no he visto plugins tan complicados. Para que el plugin pudiese recopilar los datos, o bien los lee de algún sitio, tal y como propones, o tiene acceso a la BD o algún tipo de API. El tema de incluir consultas a la BD dentro de propio plugin es que tal vez lo complique de forma innecesaria.
Los datos se podrían dejar en la carpeta temp dentro del moodledata.
Los datos se podrían dejar en la carpeta temp dentro del moodledata.
Además no sería lógico tener que acceder al modelo desde munin. Una vez instalado el plugin no debería verse afectado por actualizaciones de la plataforma.
¿Cómo lo ves? ¿Sencillo, complicado?
Salu2
Fernando
Por la parte de Moodle, sencillo, puesto que no es más que saber donde recopilar la información y volcarla a un fichero con un formato determinado. Desde munin, habría que echar un vistazo a algún plugin similar, puesto que no sé si munin fuerza a que los plugins estén en algún lenguaje determinado. Normalmente están en Perl, pero he visto algunos en shell-script también.
En la parte de munin también es sencillo.
Como el archivo generado sería un conjunto de pares variable/valor ya elaborado quizá sólo habría que mostrarlo y se podría hacer vía shell o perl, aunque munin también permitiría utilizar php o cualquier otro lenguaje de scripting.
Como el archivo generado sería un conjunto de pares variable/valor ya elaborado quizá sólo habría que mostrarlo y se podría hacer vía shell o perl, aunque munin también permitiría utilizar php o cualquier otro lenguaje de scripting.
Si, pero si quieres estadísticas tendrás que almacenar los datos que previamente hayas procesado en algún sitio. Munin hace uso de una especie de BD (rrdtool), aunque realmente guarda los datos acumulados en ficheros, pero no sé si esto lo hace por defecto o tienes que especificarlo tu en el plugin.
En cuanto al lenguaje de programación a usar, también he visto plugins en Python. Supongo que la elección del lenguaje en este caso depende del alcance que quieras que tenga tu plugin. Para procesar ficheros, shellscript y/o Perl son suficientes.
En fin, que es cuestión de buscar ejemplos entre lo que ya existe y ponerse a ello. Yo voy a intentar empezar con la parte de Moodle.
En cuanto al lenguaje de programación a usar, también he visto plugins en Python. Supongo que la elección del lenguaje en este caso depende del alcance que quieras que tenga tu plugin. Para procesar ficheros, shellscript y/o Perl son suficientes.
En fin, que es cuestión de buscar ejemplos entre lo que ya existe y ponerse a ello. Yo voy a intentar empezar con la parte de Moodle.
Ok.
Yo me pongo con el plugin de munin.
Te enviaré unos posibles ejemplos del archivo que tendría que generar el módulo.
Yo me pongo con el plugin de munin.
Te enviaré unos posibles ejemplos del archivo que tendría que generar el módulo.
En respuesta a Fernando Navarro Páez
Re: ¿Existe el plugin moodle_* para munin?
Caso de Uso 1: Mostrar el número de usuarios activos en varias instalaciones de moodle.
La salida del plugin ha de ser:
instalacion1.value 12
instalacion2.value 55
instalacion3.value 0
Se mostraría un gráfico similar al que muestra munin para los datos de cpu
Tenemos 2 opciones:
1. Un archivo por cada instalación de moodle. El nombre del archivo se ha de incluir en la configuración del módulo de moodle y no debe existir. El módulo crea el archivo con los datos cada vez que se ejecuta mediante el cron. Todos los archivos generados han de estar en la misma ruta. El plugin de munin sólo mira en una carpeta.
Carpeta ruta/moodle_munin
instalacion1.dat
active_users.value 12
instalacion2.dat
active_users.value 55
instalacion3.dat
active_users.value 0
El plugin moodle_active_users para munin genera la salida
instalacion1.value 12
instalacion2.value 55
instalacion3.value 0
2. Un archivo común a todas las instalaciones. En la configuración del módulo el nombre del archivo no es editable (moodle_active_users.dat) pero si la ruta a la carpeta y un identificador texto. El módulo actualiza el registro correspondiente a su identificador de instalación. El plugin de munin sólo mira en un archivo.
El archivo quedaría de la siguiente forma, con lo que el plugin se limitaría a mostrar el contenido.
instalacion1.value 12
instalacion2.value 55
instalacion3.value 0
¿Por cual te decantas?
La salida del plugin ha de ser:
instalacion1.value 12
instalacion2.value 55
instalacion3.value 0
Se mostraría un gráfico similar al que muestra munin para los datos de cpu
Tenemos 2 opciones:
1. Un archivo por cada instalación de moodle. El nombre del archivo se ha de incluir en la configuración del módulo de moodle y no debe existir. El módulo crea el archivo con los datos cada vez que se ejecuta mediante el cron. Todos los archivos generados han de estar en la misma ruta. El plugin de munin sólo mira en una carpeta.
Carpeta ruta/moodle_munin
instalacion1.dat
active_users.value 12
instalacion2.dat
active_users.value 55
instalacion3.dat
active_users.value 0
El plugin moodle_active_users para munin genera la salida
instalacion1.value 12
instalacion2.value 55
instalacion3.value 0
2. Un archivo común a todas las instalaciones. En la configuración del módulo el nombre del archivo no es editable (moodle_active_users.dat) pero si la ruta a la carpeta y un identificador texto. El módulo actualiza el registro correspondiente a su identificador de instalación. El plugin de munin sólo mira en un archivo.
El archivo quedaría de la siguiente forma, con lo que el plugin se limitaría a mostrar el contenido.
instalacion1.value 12
instalacion2.value 55
instalacion3.value 0
¿Por cual te decantas?
Yo en este caso optaría por un fichero por cada instalación, indicando la ruta al fichero en la configuración del plugin. Asi el plugin solo tiene que contar la cantidad de rutas, y pintar tantos elementos como rutas haya:
La principal ventaja que yo veo a los archivos independientes es que puedes meter distintos datos en unos u otros, mostrando más información para unas plataformas que para otras. Habrá plataformas en las que te interese por ejemplo, saber la cantidad de clicks, y en otras la cantidad de clicks/sesión.
Por cierto, respecto a qué se consideran usuarios activos, voy a suponer que son usuarios que han hecho login (que han entrado en la plataforma) y han realizado algún tipo de actividad en un periodo de tiempo determinado, denominado lapso de inactividad, a partir del momento en que se recopilan los datos. Este parámetro se podrá configurar a nivel de sistema para cada instalación.
Por ejemplo, usuarios activos con movimiento en los últimos 30 minutos.
Otra cosa más, la idea para la parte de Moodle es que el módulo recopile todo tipo de información, pero que sea el usuario, a través de la configuración del módulo, el que indique qué datos quiere recopilar.
[moodle_*]
/var/moodledata/m1/temp/
/var/moodledata/m2/temp/
/var/moodledata/m3/temp/
La principal ventaja que yo veo a los archivos independientes es que puedes meter distintos datos en unos u otros, mostrando más información para unas plataformas que para otras. Habrá plataformas en las que te interese por ejemplo, saber la cantidad de clicks, y en otras la cantidad de clicks/sesión.
Por cierto, respecto a qué se consideran usuarios activos, voy a suponer que son usuarios que han hecho login (que han entrado en la plataforma) y han realizado algún tipo de actividad en un periodo de tiempo determinado, denominado lapso de inactividad, a partir del momento en que se recopilan los datos. Este parámetro se podrá configurar a nivel de sistema para cada instalación.
Por ejemplo, usuarios activos con movimiento en los últimos 30 minutos.
Otra cosa más, la idea para la parte de Moodle es que el módulo recopile todo tipo de información, pero que sea el usuario, a través de la configuración del módulo, el que indique qué datos quiere recopilar.
Hay otro problema, que surgirá al final, pero que es importante. La frecuencia de actualización de munin es bastante mayor que la del cron, ya que el cron no se debe poner con frecuencias altas (30 seg. o menos) Bueno, lo puedes hacer, pero posiblemente consumirá bastantes recursos.
El caso es que hay que tener en cuenta eso para el futuro. No sé si haciendo que el módulo añada la información por intervalos (minutos, segundos, horas) hasta que munin lo lea, procese y borre los datos o de cualquier otro modo.
El caso es que hay que tener en cuenta eso para el futuro. No sé si haciendo que el módulo añada la información por intervalos (minutos, segundos, horas) hasta que munin lo lea, procese y borre los datos o de cualquier otro modo.
Sobre la frecuencia de actualización, al tener munin una frecuencia mayor que moodle leerá más de una vez el mismo dato, por lo que no se pierde información. Lo contrario si que sería peor, ya que perderiamos información.
"No sé si haciendo que el módulo añada la información por intervalos (minutos, segundos, horas) hasta que munin lo lea, procese y borre los datos o de cualquier otro modo."
No se me ocurre como se podría implementar. Los datos que recoge munin no llevan la fecha y la hora. En la base de datos de munin se guardan con el instante en el que munin recogió los datos.
Sobre qué se considera usuario activo utiliza el criterio que creas más correcto. Lo que se pretende es que un administrador pueda tener información en tiempo real e histórica del uso de la plataforma.
"No sé si haciendo que el módulo añada la información por intervalos (minutos, segundos, horas) hasta que munin lo lea, procese y borre los datos o de cualquier otro modo."
No se me ocurre como se podría implementar. Los datos que recoge munin no llevan la fecha y la hora. En la base de datos de munin se guardan con el instante en el que munin recogió los datos.
Sobre qué se considera usuario activo utiliza el criterio que creas más correcto. Lo que se pretende es que un administrador pueda tener información en tiempo real e histórica del uso de la plataforma.
" la idea para la parte de Moodle es que el módulo recopile todo tipo de información, pero que sea el usuario, a través de la configuración del módulo, el que indique qué datos quiere recopilar."
Me parece perfecta. Lo único que hay que tener en cuenta es que para cada tipo de dato que se recopile hay que preparar un plugin para munin, pero será tan sencillo como copiar el plugin y modificar el tipo de dato que tiene que recopilar.
Esa es la idea, una gráfica para cada tipo de dato, pero pudiendo recopilar los datos de distintas fuentes, indicadas por configuración.
Como ejemplo, podemos tomar los plugins de Apache que muestran el tráfico, los usuarios, las peticiones, etc...
Como ejemplo, podemos tomar los plugins de Apache que muestran el tráfico, los usuarios, las peticiones, etc...
"Yo en este caso optaría por un fichero por cada instalación, indicando la ruta al fichero en la configuración del plugin. Asi el plugin solo tiene que contar la cantidad de rutas, y pintar tantos elementos como rutas haya:
[moodle_*]
/var/moodledata/m1/temp/
/var/moodledata/m2/temp/
/var/moodledata/m3/temp/"
Con ficheros independientes lo ideal sería que todos estuvieran en la misma carpeta. En el plugin de munin se le indica que ruta es y ya no hay que tocar el plugin para nada. Cuando tengas una nueva instalación de moodle le indicas en el módulo en que carpeta estas dejando los datos y ya no tienes que hacer nada más.
Hay varios problemas en ese planteamiento. El primero es que de lo único que puedes estar seguro es de como están estructurados los archivos dentro del ambito de Moodle (plataforma y moodledata) porque fuera, la estructura de ficheros puede estar organizada de cualquier manera. Por esto, creo que es más adecuado intentar, en la medida de lo posible, no crear dependencias en este sentido. Los datos se deberían almacenar dentro del ámbito de Moodle, ya sea en el moodledata o entre los scripts la plataforma.
En este punto, creo que es mejor dejar los datos en moodledata, en vez de entre los scripts de la plataforma, por aquello de los permisos de escritura, y porque es más seguro dejar los datos en un lugar privado de Moodle, no accesible desde fuera, donde munin, que es un proceso del sistema, pueda manipularlos y procesarlos sin problemas de seguridad (aparentementes)
La opción de indicar la ruta del fichero desde Moodle no es mala idea, desde el punto de vista de la configuración, pero implica que podemos tener los datos en sitios muy distintos. Yo opino que la responsabilidad de localizar los datos volcados recae en munin, Moodle solo los recopila y los deja en un sitio accesible dentro de su entorno, que es común a cualquier instalación de Moodle. Es decir, todas las plataformas tienen moodledata, pero solo munin sabe la ruta especifica de cada una, la cual puede ser diferente (/var/mooodledata1, /var/moodledata/m3 y /moodledata3 por ejemplo)
En este punto, creo que es mejor dejar los datos en moodledata, en vez de entre los scripts de la plataforma, por aquello de los permisos de escritura, y porque es más seguro dejar los datos en un lugar privado de Moodle, no accesible desde fuera, donde munin, que es un proceso del sistema, pueda manipularlos y procesarlos sin problemas de seguridad (aparentementes)
La opción de indicar la ruta del fichero desde Moodle no es mala idea, desde el punto de vista de la configuración, pero implica que podemos tener los datos en sitios muy distintos. Yo opino que la responsabilidad de localizar los datos volcados recae en munin, Moodle solo los recopila y los deja en un sitio accesible dentro de su entorno, que es común a cualquier instalación de Moodle. Es decir, todas las plataformas tienen moodledata, pero solo munin sabe la ruta especifica de cada una, la cual puede ser diferente (/var/mooodledata1, /var/moodledata/m3 y /moodledata3 por ejemplo)
El único inconveniente de usar /var/mooodledata1, /var/moodledata/m3 y /moodledata3 es que cada vez que se incluya una nueva instalación habría que acceder a la configuración del plugin para indicarle la ruta de la nueva instalación o bien utilizar un nombre o extensión específica que permita al plugin encontrar los archivos con los datos, por ejemplo /var/mooodledata1/instalacion1.m2m, /moodledata3/instalacion3.m2m
Si ponemos todos los archivos en /var/moodle2munin no hay que tocar en la configuración del plugin cuando se incluya una nueva instalación.
La ruta /var/moodle2munin es un ejemplo que podemos usar como valor por defecto, tanto para munin como para moodle. Si se quiere usar otra carpeta el administrador tendría que modificar los valores de configuración del plugin en munin (lo cual es algo bastante sencillo) y en las instalaciones de moodle indicar la ruta.
Esa es precisamente la idea, porque el tener una única ruta implica entre otras cosas, que es posible que Moodle, o más concretamente el usuario del sistema que corresponde a apache, no tenga permisos de escritura en dicha ruta. Y si le das permisos, podrías abrir un agujero de seguridad.
Por eso insisto en que es mejor que los datos se mantengan dentro del entorno de Moodle, algo que es más fácil de asegurar, incluso si tienes la configuración por defecto, que crear un nuevo directorio fuera del entorno, lo cual implica modificaciones y comprobaciones a nivel de sistema en lo relativo a la seguridad.
En cualquier caso, la acción a realizar en cuanto a configuración es similar. Añadir una ruta de acceso a los datos. La cuestión es cual podría suponer menos molestia en cuanto a configuración.
Por eso insisto en que es mejor que los datos se mantengan dentro del entorno de Moodle, algo que es más fácil de asegurar, incluso si tienes la configuración por defecto, que crear un nuevo directorio fuera del entorno, lo cual implica modificaciones y comprobaciones a nivel de sistema en lo relativo a la seguridad.
En cualquier caso, la acción a realizar en cuanto a configuración es similar. Añadir una ruta de acceso a los datos. La cuestión es cual podría suponer menos molestia en cuanto a configuración.
Comparto tu opinión: "es mejor que los datos se mantengan dentro del entorno de Moodle"
La solución entonces es que el archivo generado tenga una extensión específica para realizar la búsqueda de los archivos de datos en cualquier carpeta, quizá .mo2mu
La solución entonces es que el archivo generado tenga una extensión específica para realizar la búsqueda de los archivos de datos en cualquier carpeta, quizá .mo2mu
Estoy de acuerdo, también valdría .momu
En cuanto al tema de la frecuencia de actualización, no sé si tendremos que almacenar los datos en series, en función del periodo de actualización que tenga munin. Me explico, si munin toma los datos cada minuto y cron cada 5, el plugin de Moodle tiene que grabar los datos de cada uno de los últimos 5 minutos por ejemplo. Así no se perdería información, y munin podría almacenar los históricos.
Habrá que revisar algún otro plugin de munin, para ver como lo hace..
En cuanto al tema de la frecuencia de actualización, no sé si tendremos que almacenar los datos en series, en función del periodo de actualización que tenga munin. Me explico, si munin toma los datos cada minuto y cron cada 5, el plugin de Moodle tiene que grabar los datos de cada uno de los últimos 5 minutos por ejemplo. Así no se perdería información, y munin podría almacenar los históricos.
Habrá que revisar algún otro plugin de munin, para ver como lo hace..
Algún plugin tira de archivos logs diarios, no de una instantánea. (Por ejemplo, http://exchange.munin-monitoring.org/plugins/qmailsend_plesk/version/1)
El plugin lo que hace es recuperar la información de esos archivos de logs. En cuanto tenga oportunidad le doy un vistazo a ver como lo resuelven, pero creo que hoy será imposible.
Salu2
Fernando
El plugin lo que hace es recuperar la información de esos archivos de logs. En cuanto tenga oportunidad le doy un vistazo a ver como lo resuelven, pero creo que hoy será imposible.
Salu2
Fernando
He estado revisando algunos de los plugins de munin, y la mayoría hacen uso de comandos del sistema para acceder a la información. No he visto ninguno que haga consultas a la base de datos, ya que todas las aplicaciones soportadas por los plugins tienen comandos del sistema con parámetros que permiten acceder a la información, con lo cual la velocidad de actualización es mayor.
En cuanto al tema de la actualización, por lo que pone en el FAQ de Munin, el intervalo de actualización por defecto es de 5 min. y la granularidad no puede ser menor, aunque se fuerce a ello, debido a como trabaja rrdtool, la herramienta que guarda la información recopilada. Eso nos deja suficiente margen, ya que para el cron de Moodle si es más normal ejecutarse cada 5-10 minutos.
Por cierto, algunas ideas para plugins
- Usuarios conectados
- Cantidad de login/logout
- Tráfico de Mensajes privados (entrada/salida)
- Comentarios publicados y temas abiertos en los foros
- Cantidad de subscriptores los foros
- Actividad por módulos, rastreando el log de Moodle
- Backups de cursos (cantidad por unidad de tiempo)
- Actividad del chat (usuarios)
- Cantidad de cursos (total y activos/visibles)
- Cantidad total de usuarios y alumnos matriculados en cursos (usuarios/estudiantes)
- Cantidad de entradas creadas en los blogs.
En cuanto al tema de la actualización, por lo que pone en el FAQ de Munin, el intervalo de actualización por defecto es de 5 min. y la granularidad no puede ser menor, aunque se fuerce a ello, debido a como trabaja rrdtool, la herramienta que guarda la información recopilada. Eso nos deja suficiente margen, ya que para el cron de Moodle si es más normal ejecutarse cada 5-10 minutos.
Por cierto, algunas ideas para plugins
- Usuarios conectados
- Cantidad de login/logout
- Tráfico de Mensajes privados (entrada/salida)
- Comentarios publicados y temas abiertos en los foros
- Cantidad de subscriptores los foros
- Actividad por módulos, rastreando el log de Moodle
- Backups de cursos (cantidad por unidad de tiempo)
- Actividad del chat (usuarios)
- Cantidad de cursos (total y activos/visibles)
- Cantidad total de usuarios y alumnos matriculados en cursos (usuarios/estudiantes)
- Cantidad de entradas creadas en los blogs.
Hola, Xavier.
Aunque se podría, ninguno de los plugins hace consultas a bases de datos excepto los que proporcionan información sobre mysql.
La mejor opción es en la que estamos trabajando ahora mismo: El cron de moodle prepara la información y el plugin lo integra en munin, cogiendo los datos de uno o varios archivos previamente elaborados.
La verdad es que se pueden integrar muchísimas cosas, y todas importantes para conocer el uso de una o varias plataformas. Yo donde le veo una gran ventaja es cuando recopilamos datos de más de una plataforma, ya que la alternativa es entrar plataforma a plataforma para obtener la información.
Creo que deberíamos abordar un primer caso y resolverlo. Eso nos enseñará lo suficiente para poder empezar
"Cuando se termina un programa es cuando estás en condiciones de empezarlo"
Salu2
Fernando
La mejor opción es en la que estamos trabajando ahora mismo: El cron de moodle prepara la información y el plugin lo integra en munin, cogiendo los datos de uno o varios archivos previamente elaborados.
La verdad es que se pueden integrar muchísimas cosas, y todas importantes para conocer el uso de una o varias plataformas. Yo donde le veo una gran ventaja es cuando recopilamos datos de más de una plataforma, ya que la alternativa es entrar plataforma a plataforma para obtener la información.
Creo que deberíamos abordar un primer caso y resolverlo. Eso nos enseñará lo suficiente para poder empezar
"Cuando se termina un programa es cuando estás en condiciones de empezarlo"
Salu2
Fernando
Totalmente de acuerdo, Fernando. Es más, incluso los de mysql, usan comandos del sistema relativos a mysql y una serie de parámetros, así pues en realidad tampoco realizan consultas a la BD.
En cuanto al diseño de la parte de Moodle, no estoy seguro de si implementarlo como módulo sería la solución más adecuada. Hay otras formas de vincular un elemento a la ejecución del cron (admin reports, bloques o añadiendo el código explícitamente al script) y me surge la duda de si el implementar un módulo es demasiado para nuestro propósito.
Por otro lado, no sé si en el caso del módulo es necesario que exista al menos una instancia del mismo en algún lado, para que el cron lo tenga en cuenta a la hora de ejecutarse. Por lo que veo en el script del cron.php (línea 102 y ss) parece que no, pero no he visto módulos que estén diseñados para no aparecer en los cursos.
En cuanto al diseño de la parte de Moodle, no estoy seguro de si implementarlo como módulo sería la solución más adecuada. Hay otras formas de vincular un elemento a la ejecución del cron (admin reports, bloques o añadiendo el código explícitamente al script) y me surge la duda de si el implementar un módulo es demasiado para nuestro propósito.
Por otro lado, no sé si en el caso del módulo es necesario que exista al menos una instancia del mismo en algún lado, para que el cron lo tenga en cuenta a la hora de ejecutarse. Por lo que veo en el script del cron.php (línea 102 y ss) parece que no, pero no he visto módulos que estén diseñados para no aparecer en los cursos.
Para empezar creo que deberiamos optar por la opción más sencilla desde tu punto de vista.
Cuando tengamos funcionando algo básico si queremos ampliar o, como comentabas, dar la posibilidad de que el administrador pueda indicar que parametros quiere monitorizar de cada instalación, entonces nos podemos plantear la posibilidad de desarrollar un módulo.
Si se necesita al menos una instancia se puede incluir un bloque que muestre los últimos datos recogidos y que sólo lo vean los administradores.
Estaba trasteando en el código del cron y he encontrado esto, que tal vez pueda sernos útil
Lo que hace el cron es este punto es buscar en el directorio local (/var/www/moodle/local por ejemplo) de Moodle por si hay funciones del cron a medida, creadas por el usuario. A lo mejor esta es una solución más simple y accesible que el tener que crear módulos o informes de admin. Basta con crear las funciones, poner el script en ese directorio y esperar a que el cron las ejecute.
525 // run any customized cronjobs, if any
526 // looking for functions in lib/local/cron.php
527 if (file_exists($CFG->dirroot.'/local/cron.php')) {
528 mtrace('Processing customized cron script ...', '');
529 include_once($CFG->dirroot.'/local/cron.php');
530 mtrace('done.');
531 } Lo que hace el cron es este punto es buscar en el directorio local (/var/www/moodle/local por ejemplo) de Moodle por si hay funciones del cron a medida, creadas por el usuario. A lo mejor esta es una solución más simple y accesible que el tener que crear módulos o informes de admin. Basta con crear las funciones, poner el script en ese directorio y esperar a que el cron las ejecute.
Perfecto. Para un primer acercamiento es ideal
Yo estoy mirando como encontrar una lista de archivos por la extensión si tenemos un servidor con muchos archivos. Necesitaría pruebas reales, pero no dispongo de un servidor con muchiiiiiiiiiiiiiiisimos archivos.
¿Sabes qué tal anda el comando find de rendimiento?
Se puede acotar que la búsqueda sea dentro de /var/www y será configurable en el plugin.
¿Sabes qué tal anda el comando find de rendimiento?
Se puede acotar que la búsqueda sea dentro de /var/www y será configurable en el plugin.
Es un comando bastante rápido, y más si acotas la búsqueda por directorio, nombre del archivo y extensión. Se puede hacer todo en uno mediante una expresión regular. Además se puede buscar únicamente entre los archivos que más recientemente se hayan modificado, como es nuestro caso.
He realizado algunas pruebas de rendimiento de find con muchos archivos y no me han convencido mucho.
Y para empezar creo que podíamos simplificar incluyendo manualmente en el archivo de configuración de munin el path al archivo generado via cron. Como la instalación y configuración de plugins de munin es manual no debería ser un inconveniente.
Espero tus comentarios para hacer una síntesis de los posts y preparar la primera versión que nos permita tener un prototipo funcionando.
Salu2
Fernando
Y para empezar creo que podíamos simplificar incluyendo manualmente en el archivo de configuración de munin el path al archivo generado via cron. Como la instalación y configuración de plugins de munin es manual no debería ser un inconveniente.
Espero tus comentarios para hacer una síntesis de los posts y preparar la primera versión que nos permita tener un prototipo funcionando.
Salu2
Fernando
Estoy de acuerdo, creo que sería lo más adecuado. Tampoco se gana tanto usando el find, y a fin de cuentas, los archivos casi siempre estarán todos en el mismo sitio.
Voy a comenzar con el desarrollo del cron local, en cuanto tenga algo, te lo mando.
Voy a comenzar con el desarrollo del cron local, en cuanto tenga algo, te lo mando.
La cosa está casi lista para empezar la fase de pruebas. Fernando tiene casi listo el plugin de munin, y yo estoy a falta de pulir unos detalles en la parte de Moodle. Supongo que en breve publicaremos algo...
Una muestra de algunos de los plugins que estamos probando. Clicks por usuario y logins/logouts. Como veréis aún hay algunos problemas con las escalas de los gráficos...
