Solution de monitoring, vi mais laquelle?

Le
Bzzz
Salut liste,

depuis qq temps je me renseigne sur les solutions FOSS de
monitoring (2-3 serveurs Debian distants par site (liaisons inet),
voire 5-6 grand maximum).

Mais c'est un peu (hem!) le souk là-dedans: machin ne fait pas ce
que fait truc et bidule fait les 2 mais il lui manque des
fonctionnalités importantes de chose, etc (zabbis, nagios, xymon,
cacti, cricket, zenoss, opennms et la tête aloueeeette).

Je viens de tester zabbix, qui est pômal, mais centraliser *toutes*
les données n'est pas ce que je recherche; par contre ça
m'intéresserais *vraiment* de centraliser une version "dégradÃ=
©e"
par rapport à la locale (ex: recevoir les mêmes parms qu'en local
mais seulement toutes les 5' ou 10', alors que le local se fait sur
toutes les 30"), pour en tirer des stats et des projections
sur le dimensionnement des serveurs.
Par ailleurs, zabbix a une occupation RAM assez importante mais
d'après ce que j'ai compris, ça serait dur de faire moins; son
plus gros PB: on reçoit toutes les données sans exception.

J'en viens donc à vous demander ce que vous utilisez, ou
utiliseriez, en fonction de besoins spécifiques & de leur
priorité (s/5):

Côté client:

1- Alertes multiples (E-mail, IM, SMS) sur dépassements, incidents
& accidents
1- redémarrage auto des daemons ayant crashé + alerte
5- Visualisation des paramètres (graphes)

Côté superviseur:
==
1- Copie des alertes sur incidents & accidents + enregistrement
dans une DB
1- Réception des mêmes parms mais avec des intervalles de temps
bcp plus grands + enregistrement dans une DB
2- Visualisation des paramètres (graphes)
5- Accusés de réception des alertes par les admins locaux

Étant donné que 90% des fonctions des svrs distants sont les mÃ=
ªmes,
la complexité de conf a relativement peu d'importance.

Je me demande d'ailleurs si ça existe (le différentiel
de qté de données entre local et remote), vu que je n'ai pour
l'instant trouvé aucune référence à ce sujet.
Peut-être que ma solution passe par une réplication partielle
des DBs locales avec un script maison (?).

JY
--
The chicken that clucks the loudest is the one most likely to show up
at the steam fitters' picnic.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20120619184105.3f584b85@anubis.defcon1
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
David Hannequin
Le #24584061
Bonjour,

Personnellement, la solution de supervision que j'aime c'est Shinken.
Elle répond aussi a tes critères et les fichiers de configurations
ressemblent à ceux de Nagios. Pour les graphiques, j'utilise pnp4nagios
mais dés que je peux je regarde graphite.

Bonne soirée

Le 19/06/2012 18:41, Bzzz a écrit :
Salut liste,

depuis qq temps je me renseigne sur les solutions FOSS de
monitoring (2-3 serveurs Debian distants par site (liaisons inet),
voire 5-6 grand maximum).

Mais c'est un peu (hem!) le souk là-dedans: machin ne fait pas ce
que fait truc et bidule fait les 2 mais il lui manque des
fonctionnalités importantes de chose, etc (zabbis, nagios, xymon,
cacti, cricket, zenoss, opennms... et la tête aloueeeette).

Je viens de tester zabbix, qui est pômal, mais centraliser *toutes*
les données n'est pas ce que je recherche; par contre ça
m'intéresserais *vraiment* de centraliser une version "dégradée"
par rapport à la locale (ex: recevoir les mêmes parms qu'en local
mais seulement toutes les 5' ou 10', alors que le local se fait sur
toutes les 30"), pour en tirer des stats et des projections
sur le dimensionnement des serveurs.
Par ailleurs, zabbix a une occupation RAM assez importante mais
d'après ce que j'ai compris, ça serait dur de faire moins; son
plus gros PB: on reçoit toutes les données sans exception.

J'en viens donc à vous demander ce que vous utilisez, ou
utiliseriez, en fonction de besoins spécifiques & de leur
priorité (s/5):

Côté client:
=========== > 1- Alertes multiples (E-mail, IM, SMS) sur dépassements, incidents
& accidents
1- redémarrage auto des daemons ayant crashé + alerte
5- Visualisation des paramètres (graphes)

Côté superviseur:
================ > 1- Copie des alertes sur incidents & accidents + enregistrement
dans une DB
1- Réception des mêmes parms mais avec des intervalles de temps
bcp plus grands + enregistrement dans une DB
2- Visualisation des paramètres (graphes)
5- Accusés de réception des alertes par les admins locaux

Étant donné que 90% des fonctions des svrs distants sont les mêmes,
la complexité de conf a relativement peu d'importance.

Je me demande d'ailleurs si ça existe (le différentiel
de qté de données entre local et remote), vu que je n'ai pour
l'instant trouvé aucune référence à ce sujet.
Peut-être que ma solution passe par une réplication partielle
des DBs locales avec un script maison (?).

JY




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #24584681
On Thu, 21 Jun 2012 22:37:20 +0200
David Hannequin
Personnellement, la solution de supervision que j'aime c'est
Shinken. Elle répond aussi a tes critères et les fichiers de
configurations ressemblent à ceux de Nagios. Pour les graphiques,
j'utilise pnp4nagios mais dés que je peux je regarde graphite.



S'eu pu mais ça peut point: pas de support PostgreSQL :/

--
Among all savage beasts, none is found so harmful as woman.
-- St. John Chrysostom, 304-407.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme