jrds-developpers Mailing List for jrds (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Pas mal de changement en ce moment sur les starters dans jrds.

Si vous avez un trunk local, faites un ant clean avant de tenter une compil.

Quelques outils pour utiliser jrds en ligne de commande
Directement depuis le répertoire de source :

$ java -Dlibspath=lib:libjetty -jar build/boot.jar help
Lists of available command:
    checkjar
    wikidoc
    jetty
    collect

$ java -Dlibspath=lib:libjetty -jar build/boot.jar help jetty
Run an embedded web server, using jetty
The default listening port is 8080. It can be specified using the property jetty.port
The jrds configuration file is specified using the property propertiesFile

$ ant jkstat rstat munin &&  java -Dlibspath=lib:libjetty -jar build/boot.jar checkjar build/*/*.jar
...
no graphs for probe desc: KstatL2ArcStats

Je viens de rajouter une autre méthode de sélection dans les filtres, par nom de graph.
Il suffit d'utiliser l'élément qualifiedname et de spécifier le nom qui apparait dans le champ ALT d'un graph.

Petit complément d'information pour les auteurs de sondes.

Si un index possède un OID de label, il peut être précisé avec l'argument :
	<specific name="labelOid">OID du label</specific>
Un oid quelconque permet de servir d'indicateur d'existence de la sonde
	<specific name="existOid">OID flag</specific>

Le 23 mars 2010 à 12:02, Fabrice Bacchella a écrit :

> l'url /discover est un moyen de gérer facilement un squelette de fichier de conf pour un host.
> 
> Elle s'utiliser comme suit :
> curl http://<jrds>/discover?host=<host>
> 
> Elle peut prendre en plus les arguments suivants :
> withoid -> rajoute l'OID des élements indexé. Cela permet de réduire la charge sur les équipements pauvre en CPU et avec beaucoup d'index (typiquement un switch)
> community=<communauté> -> permet de préciser la communauté snmp.
> 
> Le XML généré est brut. Il est conseillé de le relire avant de l'utiliser.
> Notamment vérifier les doublons de sonde : 
> -IfSnmp vs IfSnmp et DiskIO vs DiskIO64 pour les compteurs 64 bits.
> -Supprimer les arguments pour les sondes IPx6 et IPx4. Si l'argument est le même, ne garder que IPx4.
> -choisir les types systèmes adaptés, notamment les compteurs CPU et RAM.

l'url /discover est un moyen de gérer facilement un squelette de fichier de conf pour un host.

Elle s'utiliser comme suit :
curl http://<jrds>/discover?host=<host>

Elle peut prendre en plus les arguments suivants :
withoid -> rajoute l'OID des élements indexé. Cela permet de réduire la charge sur les équipements pauvre en CPU et avec beaucoup d'index (typiquement un switch)
community=<communauté> -> permet de préciser la communauté snmp.

Le XML généré est brut. Il est conseillé de le relire avant de l'utiliser.
Notamment vérifier les doublons de sonde : 
-IfSnmp vs IfSnmp et DiskIO vs DiskIO64 pour les compteurs 64 bits.
-Supprimer les arguments pour les sondes IPx6 et IPx4. Si l'argument est le même, ne garder que IPx4.
-choisir les types systèmes adaptés, notamment les compteurs CPU et RAM.

Bonjour à tous,

je viens de commiter (r700) une sonde JMX permettant de monitorer le
nombre de hists d'un listenner HTTP Tomcat.

Exemple d'utilisation :

        <connection type="jrds.probe.JMXConnection" name="rtl">
                <arg type="Integer" value="42199" />
        </connection>

        <!-- rtl -->
        <probe type="TomcatStats" label="rtl" connection="rtl">
                <arg type="String" value="42180" />
        </probe>

Le 42199 est le port JMX, et le port 42180 est le port HTTP pour lequel
grapher les requêtes par secondes

a+

-- 
http://asyd.net/home/    - Home Page
http://www.guses.org/    - French Speaking (Open)Solaris User Group
http://netvibes.com/asyd - Portal

Une nouvelle sonde, permettant de surveiller le status NTP d'une machine.

Son usage est très simple :
< probe type="NTP" />
ou alors :
<probe type="NTP">
	<arg type="Integer" value="NTP port" />
</probe >

Attention, les indications de delay et d'offset sont entre la machine de collect et la machine de destination.

Une nouvelle sonde tournant dans jrdsagent.

Comme elle utilise jmx, elle devrait pouvoir tourner sur toute plate-forme sur laquel une jvm Sun existe.

Pour l'utiliser, il faut rajouter une connexion jrdsagent vers le serveur dans le fichier de host, la sonde ne prend pas d'arguments :

<?xml version="1.0" encoding="UTF-8"?>
<host name="mymachine" dnsName="localhost">
   <connection type="jrds.probe.RMIConnection" />
   <probe type="SystemInfoMXBean" />
</host>

Ne pas oublier de lancer l'agent sur la machine :
java -jar .../jrdsagent.jar

Elle ne fournit que deux graphes, la consommation mémoire et la run queue.

Il existe un agent jrds pour collecter des sondes via WMI sur serveur windows :
https://sourceforge.net/projects/jrds/files/Agents/jrdswmi.jar/download

WMI permet de collecter un très grand nombre de valeurs sur un serveur windows, c'est par ce moyen que les applications remontent normalement leurs informations.

Procédure d'installation:
-télecharger et déclarer à jrds la nouvelle sonde : https://sourceforge.net/projects/jrds/files/Agents/jrdswmi.jar/download
-installer aussi j-interop : http://www.j-interop.org/

Sur la machine windows, la procédure est plus compliquée.
1/configurer jrds pour effectuer la collecte avec les droits administrateur en déclarant les informations suivants dans le fichier du nœud windows :
   <connection type="jrds.wmi.WMIConnection">
       <arg type="String" value="domain ou host" />
       <arg type="String" value="Administrator" />
       <arg type="String" value="mot de passe administrator" />
   </connection>
   <probe type="PerfOS_Processor">
       <arge type="String" value="1" />
   </probe>
C'est une étape nécessaire pour préparer l'étape 5, rasssurez-vous ce n'est que provisoire.
Il faut effectuer au moins une collecte avec cette configuration.

2/créer un utilisateur dédié, (monitor par exemple) et le placer dans les groupes "Performance monitor users" et "Performance log users"

3/Il est nécessaire de donner le droit de lecture à ce compte sur la clé de registre :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg
Il faut pour cela lancer regedit, sélectionner la clé, bouton de droit -> Permissions
cf http://www.windowsreference.com/security/how-to-disablerestrict-remote-registry-access-in-windows/

4/Utiliser "WMI control" pour donner les droits à l'utilisateur pour le bon name space. 
Dans Windows 2008, c'est accessible dans le "serveur manager" -> Configuration -> WMI Control -> click droit -> Properties
sélectionnez l'onglet "security", puis dans l'arbre Root/CIMV2, bouton "Security"
Donnez les droits "Enable Account" et "Remote Enable" à l'utilisateur
cf http://msdn.microsoft.com/en-us/library/aa393613(VS.85).aspx

5/Lancez l'application dcomcnfg
dans Console Root->Component Services->Computers->My Computer->click droit->Properties
sélectionnez l'onglet "COM security", dans les 2 boutons Edit Limits, donnez tout les droit au compte
dans Console Root->Component Services->Computers->My Computer->DCOM Config->76A6415B-CB41-11d1-8B02-00600806D9B6>click droit->Properties
Sélectionnez l'onglet "Security"
Pour "Launch and Activation Permissions", ainsi que dans "Access Permissions", donnez tout les droits au compte de collecte
Dans "Configuration Permissions", les droits "Read" sont suffisants.
Si vous avez sauté le point 1, l'entrée "Console Root->Component Services->Computers->My Computer->DCOM Config->76A6415B-CB41-11d1-8B02-00600806D9B6" n'existera pas.

6/Changez la configuration jrds pour que ce soit l'utilisateur précédemment crée qui fasse la collecte.

Et voila !

Je sais c'est lourd, mais si un spécialiste Windows veut bien se pencher dessus et la simplifier, il sera le bienvenu.

Quelques sondes wmi disponibles actuellement :
   <probe type="PerfOS_Memory" />
   <probe type="PerfOS_Processor">
       <arge type="String" value="${processor}" />
   </probe>
   <probe type="PerfOS_System" />
   <probe type="Process" >
       <arg type="String" value="Process name" />
       <arg type="String" value="process command regexp" />
   </probe>

${processor} pouvant être un numéro de cœur ou "_Total" pour avoir la valeur totale.

Cela devient facile à gérer avec les macros et les variables

Une macro permet de regrouper plusieurs sonde et de les insérer en une seul fois dans un noeud.

Par exemple :
<macrodef name="ipstats">
       <probe type="TcpSnmp" />
       <probe type="IpSnmp" />
       <probe type="UdpSnmp" />
       <probe type="IcmpSnmp" />
</macrodef>

qui s'insère ensuite en rajoutant la ligne suivante :
<macro name="ipstats" />
dans la définition du noeud

Que faire si l'on cherche à gérer des petites différences, quand par exemple il y a des différences de hardware dans un parc de machines ?

Pour cela, il faut utiliser des variables.

Un exemple de définition de sonde les utilisants :

<macrodef name="solarisnet">
       <probe type="IfXSnmp" >
               <arg type="String" value="${netcard}0"/>
       </probe>
       <probe type="IfXSnmp" >
               <arg type="String" value="${netcard}1"/>
       </probe>

</macrodef>

il suffit ensuite d'utiliser la sonde de la façon suivante dans la définition du noeud :
<macro name="solaris"> 
   <properties>
       <entry key="netcard">bnx</entry>
   </properties>
</macro>

Il peut y avoir autant de variables que désiré.

Il est possible maintenant de superviser depuis nagios une sonde jrds et les valeurs des dsname :
Sur un graph, cliquer sur le bouton :

2010	Jan (4)	Feb (1)	Mar (3)	Apr (2)	May	Jun (3)	Jul (4)	Aug (1)	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar (1)	Apr	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2012	Jan	Feb (7)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2013	Jan	Feb	Mar	Apr (9)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

jrds-developpers Mailing List for jrds (Page 2)

jrds-developpers — The jrds' developpers mailing list