Rubrique précédente: Exemple : Architectures réseau

Rubrique suivante: Planification d'espace disque

Planification de la collecte de journaux

La planification de la collecte de journaux pour votre réseau est basée sur le nombre d'événements par seconde que vous devez traiter à des fins de stockage et la durée pendant laquelle vous devez conserver les données en ligne (dans ce sens, en ligne signifie pouvant faire l'objet d'une recherche immédiate). Généralement, vous disposez seulement de 30 à 90 jours de mise en ligne des données.

Chaque réseau dispose de ses propres volumes d'événements en fonction du nombre d'unités, des types d'unités et du degré de réglage des unités et applications réseau telles que les pare-feu, pour répondre aux besoins d'informations sur les événements de l'entreprise. Par exemple, en fonction de leur configuration, certains pare-feu peuvent générer d'énormes volumes d'événements inutiles.

Nous vous recommandons de planifier votre collecte d'événements pour que votre volume total d'événements soit uniformément réparti sur vos serveurs CA User Activity Reporting Module, sans forcer l'un d'entre eux à dépasser le niveau normal d'utilisation constante. Pour conserver d'excellentes performances avec les volumes d'événements d'une entreprise, nous vous recommandons d'installer au moins deux serveurs CA User Activity Reporting Module fédérés.

L'illustration ci-dessous présente un exemple simple de ce type de réseau CA User Activity Reporting Module fédéré. Deux serveurs CA User Activity Reporting Module, un pour les rapports et un pour la collecte, gèrent le trafic d'événements provenant de différentes sources d'événement. Les deux serveurs peuvent partager des données pour les requêtes, les rapports et les alertes.

Ce diagramme illustre une configuration de base avec deux serveurs CA Enterprise Log Manager : un pour l'insertion et un pour les requêtes.

Le serveur de collecte gère principalement le trafic de journaux d'événements entrants et se concentre sur les insertions dans la base de données. Il utilise une stratégie de conservation brève des données, au maximum 24 heures. Un script automatisé déplace les journaux d'événements stockés vers un serveur de rapports chaque jour, ou plus souvent, en fonction du volume d'événements. La fédération et l'utilisation de requêtes fédérées entre les deux serveurs vous garantissent de recevoir des rapports précis à partir des journaux d'événements sur les deux serveurs.

Le serveur de rapports réalise plusieurs fonctions.

Un script de sauvegarde automatisé déplace les données du serveur de rapports au serveur distant (stockage sauvegardé). Si vous décidez de restaurer des données à partir du stockage sauvegardé, vous le faites généralement sur le serveur de rapports. Si l'espace est limité sur le serveur de rapports, vous pouvez également restaurer sur le serveur de collecte. Comme le serveur de collecte ne stocke pas de grandes quantités de données et qu'il est fédéré, les résultats des rapports sont les mêmes.

De plus, le serveur de rapports peut fonctionner comme récepteur de basculement pour les événements collectés par un connecteur sur un agent distant, si le serveur de collecte cesse de recevoir les événements pour une raison quelconque. Vous pouvez configurer le basculement au niveau de l'agent. Le traitement par basculement envoie les événements à un ou plusieurs serveurs CA User Activity Reporting Module alternatifs. La collecte d'événements par basculement n'est pas disponible pour les événements provenant de sources d'événement héritées, collectés par les écouteurs SAPI et iTech.

Informations complémentaires :

Planification de la configuration d'agents

CA User Activity Reporting Module et virtualisation