mardi 11 septembre 2018mardi 11 septembre 2018 Lemon

Architecture

Architecture (suite) 3 couches Production / consommation de données Manipulation de données Stockage des données

Présentation des agents L’Agent : communique de façon bi-directionnelle avec les sensors configure les classes de metriques d’un sensor et va chercher les métriques (pull ) vérifie le statut des sensors envoie des data au serveur via TCP ou UDP se monitore lui même à travers le sensor interne MSA place les données en caches locales

Présentation du serveur Serveur basé sur Oracle – OraMon Tourne actuellement sur machine virtuelle http://cclcgvmli05/lrf/entry.php optimisé pour un grand nombre de machines Vérification et validation des données Utilisation de méta data Possibilités additionnelles : Possibilités de multi threading TCP / UDP Possibilités d’introduire de l’authentification dans les données (données cryptées , nécessité d’une clé pour les déchiffrer )

Estimations physiques En terme d’espace Environ 700kB de données par machine/jour En terme CPU Pour un Dual PIV, 3GHz, 4GB de mémoire avec un serveur Oracle DB + OraMon nécessite environ 15% de CPU pour 4000 machines monitorées. Ajouter le système d’alarmes dans Oracle nécessite environ 5% de CPU de plus . OraMon a besoin de 105 MB de mémoire pour fonctionner .

Installation et configuration Mode d’installation préconisé : Quattor Installation par rpms de Oramon , lemonmrd laborieuse . Version actuelle qui fonctionne avec php4 . Pour les nouvelles fonctionnalités de gestion d’alarmes , il va falloir installer du php5 / apache 2 sur le serveur . Installation aisée des agents avec des sensors par défaut .

Ajout d’une nouvelle machine Ajouter l’agent sur la machine rpm -ivh edg-fabricMonitoring-agent-x.x.x-y.i386.rpm After the installation, modify the /etc/lemon/agent/transport/udp.conf file to point to your Lemon server and to identify your machine add the name of your machine after the MSA keyword. An example of such a configuration would be: UDP Server myserver.mydomain Port 12409 NoWarnings After this you can start your client by calling its init.d startup script: > /etc/init.d/edg-fmon-agent start Ajouter le nom du host sur le serveur pour la visualisation dans /etc/lemon/lrf/clusters.conf : [CEs_PROD] hosts=cclcgceli01,cclcgceli02,cclcgceli03 name=CE_PROD [CEs_PPS] hosts=cclcgceli07 name=CE_PPS

Ajout d’un sensor Sur les agents : Sur le serveur et dans la base Créer deux fichiers de conf /etc/lemon/agent/sensors/sensor.conf (défini l’appel au sensor) /etc/lemon/agent/metrics/sensor.conf (défini les métriques ) Créer le sensor (CPP ou perl) Sur le serveur et dans la base modifier le fichier /etc/oramon-server.conf (ajouter la classe des métriques et les métriques) Mettre à jour la base : lemon-ora.admin --file=/etc/oramon-server.conf -d lemon … Redémarrer Oramon Rajouter la métrique dans /etc/lemon/lemonmrd.conf Éventuellement rajouter un graphe pour l’historique dans /var/www/html/lrf/metric_map.php Redémarrer lemonmrd

Facilité d’enregistrer des données dans la base . Avantages de lemon Facilité d’enregistrer des données dans la base . De nombreux sensors existent déjà au CERN (notamment grille : LFC , expiration de certificats , BDII …) Ajout d’une nouvelle machine aisé

Installation / config pas toujours évidente Inconvénient de lemon Installation / config pas toujours évidente Interface Web limité ( par contre facilement malléable en utilisant JpGrap / php) Il faut installer un agent sur chaque machine monitorée ( cela veut dire qu’en cas de nouvel agent, il faut upgrader sur chaque machine ).

Prospectives Se mettre d’accord sur des sensors pertinents . Les ajouter . Package les nouveaux sensors pour pourvoir les redistribuer sur de nouvelles machines Installer le serveur sur un machine avec php5 / apache 2 pour tester les alarmes qui me semble être la fonctionnalité la plus intéressante. Travailler pour améliorer l’interface .