5 tâches régulières émettent des mesures vers Zabbix. Ces 5 tâches se déclenchent à des périodicités différentes et permettent d'observer les mesures sur des intervalles de temps progressifs.

Les différents capteurs de mesure sont associés à l'une de ses tâches, en fonction de la nature de la mesure et de l'intérêt statistique qu'elle représente.

Cette tâche est lancée à chaque lancement de cron. Elle émet les quelques mesures pour lesquelles on désire avoir une observation immédiate “temps réel”. Il est conseillé de laisser le nombre d'indicateurs émis en temps réel le plus faible possible pour ne pas induire une charge permanente au serveur. De même, on veillera à éviter d'y lancer des mesures dont les requêtes dans la base de données exploreraient trop de données ou conduirait à un temps de calcul trop long. Dans un moodle simple, la fréquence de lancement est toute les minutes.

Cette tâche est lancée une fois par heure.

Cette tâche est lancée une fois par jour.

Cette tâche est lancée une fois par semaine.

Cette tâche est lancée une fois par mois.

• Index des mesures

Le rapport zabbix ne propose pas de capacités de contrôle de droits.

Le plugin “Rapport Zabbix” accepte des “enregistrements” de mesure supplémentaires qui sont captées directement dans des plugins Moodle si ces plugins respectent :

• Le schéma de structure des classes d'indicateurs proposée par le rapport central
• Le principe d'enregistrement ajouté dans le script d'installation du plugin

Les classes d'indicateurs sont implémentées dans des fichiers séparés. Un fichier représente une classe d'indicateurs pouvant produire plusieurs mesures (submode). Chaque classe est lancée avec une régularité selon le répertoire dans lequel elle est placée dans le répertoire <modname>/classes/indicators :

• A la racine (instant) : la classe émet à chaque lancement du cron
• monthly : la classe émet une fois par mois
• weekly : la classe émet une fois pas semaine
• daily : la classe émet une fois par jour
• hourly : la classe émet toutes les heures

Pour chaque période d'émission, les données envoyées peuvent représenter des mesures portant sur un certain intervalle de données, par exemple, on peut émettre quotidiennement une mesure portant sur les données de la semaine (glissante) précédent la mesure, ou encore (suivant le calcul interne) portant sur les données depuis le lundi de la semaine en cours. Ce sera alors une mesure 'actualisée' quotidiennement. Il faut donc bien différencier la notion de fréquence d'actualisation, et celle de la portée temporelle de la mesure.

Par convention et pour faciliter le repérage, on utilise par convention le nom de la classe (et du fichier source associé) pour indiquer la portée des mesures :

• Un fichier monthly_xxxxxx_indicator.class.php ne devrait contenir que des mesures de portée d'un mois (en général 30 jours), même si sa fréquence d'actualisation est différente.
• Un fichier weekly_xxxxxx_indicator.class.php ne devrait contenir que des mesures de portée “24 heures”, même si sa fréquence d'actualisation est différente.
• Un fichier daily_xxxxxx_indicator.class.php ne devrait contenir que des mesures de portée “24 heures”, même si sa fréquence d'actualisation est différente.
• Un fichier hourly_xxxxxx_indicator.class.php ne devrait contenir que des mesures de portée de l'heure écoulée, même si sa fréquence d'actualisation est différente.
• Un fichier xxxxxxxx_indicator.class.php ne devrait contenir que des mesures portant sur toutes les données disponibles, sans référence de période.

• Plugin de virtualisation des moodle
• Plugin d'alimentation des ENTs
• Contrat de formation

Revenir à l'index du plugin - Revenir à l'index des plugins - Revenir au catalogue