Fonctionalités d'un SA

[julio]

Aller de meme pour un SA :

:arrow: lui il utilise nagios normalement
:arrow: renvoie les status au SI par NSCA
:arrow: Met toutes données remontés dans un fichier perfdata
:arrow: a un acces SSH sur un repertoire ou se trouve le fichier perfdata pour le rapatriement sur le SI via SCP ou autre protocole secure.



Voila moi je le vois comme ca... a voir.

[krbian]

Arrow a un acces SSH sur un repertoire ou se trouve le fichier perfdata pour le rapatriement sur le SI via SCP ou autre protocole secure.

En réalité le cache est situé sur le SA, le but du cache est de ne pas perdre les données c'est pour cette raison que le cache est situé localement vis à vis de l acquisition

[krbian]

Voici la description du SA, c'est un bout de ma doc (plus à jour d ailleurs)
La partie acquisition est la première partie d'une architecture distribuée. Son rôle est d'intérroger les équipements et de stocker les données dans des caches temporaires. Cette partie est détachée de l'intégration pour être le plus proche que possible des équipements testés et ainsi offrir le maximun de justesse sur les résultats recueillis.
Dans ce cas-ci, les données d'un site sont recupérees par un SEUL serveur d'acquisition (SA).

Le SA possede une ou plusieurs interfaces de mirroring sur lesquels ipfm récupere les stats de bande passante pour chaque adresses ip. Sur son interface principale, le serveur intéroge les hosts de son réseau via SNMP, telnet, ssh, ping , etc... Ces test sont appellés « tests actifs » par opposition aux « tests passif » qui correspondent au remonté d'infos des équipements comme les trapSNMP ou les syslog.
Ces données sont ensuite copiées dans les caches, pour être à disposition des serveurs d'intégration.

Le rôle du SA s'arrete ici.
Capturer les données
Les mettre à disposition des serveurs d'intégration

[julio]

Bah ouais c pour ca quil faut avoir un acces a ce cache pour que le SI l'integre a sa base de données... c'est ce que j'ai ecrit nan.

Par contre il va falloir laisser ce cache assez longtemps pour que les autres SI ai le temps de chopper les données aussi... donc il va falloir mettre une routine pour le vider progressivement...

[julio]

Voici :
La partie acquisition est la première partie d'une architecture distribuée. Son rôle est d'intérroger les équipements et de stocker les données dans des caches temporaires. Cette partie est détachée de l'intégration pour être le plus proche que possible des équipements testés et ainsi offrir le maximun de justesse sur les résultats recueillis.
Dans ce cas-ci, les données d'un site sont recupérees par un SEUL serveur d'acquisition (SA).

Le SA possede une ou plusieurs interfaces de mirroring sur lesquels ipfm récupere les stats de bande passante pour chaque adresses ip. Sur son interface principale, le serveur intéroge les hosts de son réseau via SNMP, telnet, ssh, ping , etc... Ces test sont appellés « tests actifs » par opposition aux « tests passif » qui correspondent au remonté d'infos des équipements comme les trapSNMP ou les syslog.
Ces données sont ensuite copiées dans les caches, pour être à disposition des serveurs d'intégration.

Le rôle du SA s'arrete ici.
Capturer les données
Les mettre à disposition des serveurs d'intégration

ok c tout a fait ce que je pensais aussi. C'est ce que decrit les fonctionnalités que j'ai mis donc.

N'est ce pas ?

[krbian]

oui mais c'est moi qui est mal compris.

Pourquoi le sa a besoin d un acces ssh puisqu il stocke ces données dans un repertoire?

[julio]

nan il ouvre un acces SSH pour que le SI recupere les données... nan ? je suppose. il ne stocke pas ses données dans une base locale. Ca lui sert a rien lui.

[krbian]

Par contre il va falloir laisser ce cache assez longtemps pour que les autres SI ai le temps de chopper les données aussi... donc il va falloir mettre une routine pour le vider progressivement...

Lorsqu il y a plusieurs SI , on autant de cache on a donc un répertoire pour chaque SI avec les meme perfdata-file dedans. Comme chaque SI a son propre cache il peut supprimer les données de son cache sans se soucier de l etat des autres

[krbian]

nan il ouvre un acces SSH pour que le SI recupere les données... nan ? je suppose. il ne stocke pas ses données dans une base locale. Ca lui sert a rien lui.

ok on dit la meme chose mais pas de la meme maniere :wink:

[templuche]

Bonsoir,

Comment est(sont) géré(s) le(s) perfdata-files? A priori un seul est suffisant: Nagios du SA vient écrire les données dans ce fichier. Quand le SA vient les chercher, il déplace le fichier dans un répertoire temporaire, intègre les données (SQL ou RRDTool) et efface le fichier temporaire.

Est ce que cela correspond à l'idée que vous vous en faisiez?

[julio]

heu nan je le voyais pas comme ca moi ... deux c mieux... sinon l'un est toujours dependant de l'autre... si l'un tombe les infos ne seront pas remonté tant que l'autre n'est pas revenu...

donc faudrait ecrire dans deux rep... enfin autant de rep que de SI... autant le faire pour que qu'il y ai la possibilité d'avoir n SI