Nagios «surveille-t-il» le WAN idéal?

Je viens de commencer dans une nouvelle entreprise et l'une de mes premières missions est de chercher des alternatives à leur système de surveillance interne.

Leur solution actuelle est une application .Net qui vérifie divers appareils sur le WAN (car il s'agit d'une société de conseil informatique qui fournit un support / "maintenance" 24/7). Les appareils vont des routeurs / commutateurs / imprimantes aux serveurs et services MS.

Après avoir lu d'innombrables messages sur le site et googlé longuement, il semble que le consensus est qu'une sorte de mélange Nagios / Munin est la voie à suivre.

Ce qui m'amène à ma (mes) question (s):

A) Est-il possible d'avoir un serveur Nagios fonctionnant localement dans l'entreprise et de surveiller divers sites externes sur WAN? (Ils ne veulent pas de serveur Nagios local sur chaque site car la plupart des sites sont relativement petits (10-25 hôtes) et le nombre de sites est assez important (75-100)).

B) Si oui, comment les agents contacteraient-ils le backend Nagios? Par SSH? HTTP?

C) Mis à part le fait qu'elle serait sensible aux pannes de liaison WAN, quels seraient les inconvénients immédiats d'une telle solution?

Toute rétroaction est appréciée, et je m'excuse à l'avance pour toute idée fausse, car je suis assez nouveau dans l'industrie.

La surveillance sur un WAN est possible, mais n'est généralement pas idéale. En effet, si la liaison WAN tombe en panne ou se bloque, toutes les vérifications échoueront et vous ne comprendrez pas ce qui se passe dans l'emplacement distant. Vous avez également une latence accrue, ce qui la rend moins utile pour les mesures de performances LAN View. Cela étant dit, si vous procédez de cette façon, vous souhaiterez probablement configurer des dépendances afin de ne pas être inondé d'alertes lorsque la liaison WAN rencontre des problèmes.

La façon la plus courante dont j'ai vu la communication entre un système de surveillance et ses services surveillés est d'avoir un tunnel VPN de site à site. La communication n'est donc pas différente du réseau local. De plus, Nagios est souvent basé sur Pull (bien que cela ne soit pas obligatoire). Nagios contacte donc les services et serveurs qu'il surveille, et non l'inverse.

Enfin, une solution plus idéale consiste à utiliser une configuration de surveillance distribuée, avec Nagios, une option est décrite dans http://nagios.sourceforge.net/docs/3_0/distributed.html .

Cela dépend en quelque sorte de ce que vous allez surveiller sur le Wan. Pour la plupart, si vous ne faites que des vérifications de ping, des vérifications de services, des vérifications de disque, etc. et respectez le temps de vérification par défaut de 5 minutes de nagios, je ne peux pas le voir vous causer un problème.

Encore une fois, selon ce que vous vérifiez dépend de quoi il va parler. Si vous vérifiez les hôtes Windows, vous pouvez simplement utiliser des requêtes WMI et même pas besoin d'un agent s'exécutant sur la boîte.

Ceci est certainement possible, via plusieurs méthodes différentes.

Si la «configuration distribuée» est hors de question, vous devez effectuer au moins l'une des actions suivantes:

1. Demandez à chaque boîte du site distant de transmettre les résultats de la vérification à Nagios (voir NSCA )
2. Percez des trous dans le pare-feu afin que Nagios puisse atteindre chaque boîte sur chaque site distant
3. Désigner une seule case sur chaque site pour être une sorte de "proxy Nagios"

Je suggère le n ° 3, car il nécessite le moins de trous dans le pare-feu et simplifie également la configuration. C'est une sorte de version allégée de la configuration distribuée, en ce sens qu'elle ne nécessite pas d'instance Nagios complète sur chaque site.

Pour ce faire, vous pouvez configurer NRPE (ou utiliser check_by_ssh ) et demander à ce "proxy" d'exécuter toutes les autres vérifications par rapport aux autres hôtes du réseau. Cela a l'avantage supplémentaire des données de performances que vous récupérez étant relatives au proxy, donc elles ne seront pas affectées par le décalage WAN.

En outre, vous pouvez ensuite utiliser les configurations parent / enfant pour faire de chaque hôte du site distant un enfant de son proxy, afin de réduire les notifications fausses positives. Vous pouvez également vouloir rendre tous les services dépendants d'un service check_nrpe (ou check_ssh) du proxy. Consultez les documents d' accessibilité du réseau pour plus d'informations.

Quelle que soit la méthode utilisée, il est très important d' ajuster les délais par défaut de manière appropriée, pour tenir compte du retard supplémentaire lié à la traversée des liaisons WAN.