🥇 Amis ELK et Exchange. Partie 1

Je commence une série d'articles où je souhaite partager mon expérience de connexion d'Exchange et d'ELK. Cette stack aidera à traiter de grands volumes de logs sans se demander à quel moment les outils de logging habituels cesseront de nous être utiles. Découvrons ce nouveau combattant des logs.

Exchange dispose d'un système de logging assez étendu. Les logs les plus demandés sont les logs de tracking, qui suivent le parcours d'un courriel spécifique au sein de l'organisation de messagerie ; les logs du serveur web, qui suivent chaque nouvelle session d'utilisateur dans le système, et les logs d'applications web spécifiques avec différents niveaux de détails sur les sessions. Exchange peut également stocker des logs bruts des protocoles smtp, imap et pop3.

Quels outils pouvons-nous utiliser pour travailler avec les logs :

Le cmdlet natif Get-MessageTrackingLog : pratique pour traiter les logs de tracking ;
L'outil logparser : pour le logging utilise un langage pseudo-SQL pour la recherche et fonctionne assez rapidement ;
Un serveur SQL externe : pour des cas très spécifiques (par exemple, l'analyse de données sur de grandes périodes de temps).

Tout cela fonctionne assez bien quand nous avons quelques serveurs et que le volume de logs traité est mesuré en dizaines à centaines de gigaoctets. Mais que se passe-t-il si le nombre de serveurs atteint des dizaines et que la taille des logs dépasse le téraoctet ? Ce schéma commence probablement à s'effondrer.

Et voilà ce qui se passe : Get-MessageTrackingLog commence à avoir des délais d'attente, logparser atteint la limite de l'architecture 32 bits, et l'exportation vers le serveur SQL échoue au moment le plus inopportun, ne gérant pas un exception multiline du service.

C'est alors qu'un nouvel acteur entre en jeu – la stack ELK, qui est spécialement conçue pour jongler avec d'énormes volumes de logs dans des délais raisonnables et avec une consommation raisonnable de ressources.

Dans la première partie, je détaillerai comment connecter filebeat, qui fait partie de la stack ELK — il est responsable de la lecture et de l'envoi de fichiers texte simples, dans lesquels différentes applications écrivent leurs logs. Dans les articles suivants, nous examinerons plus en détail les composants Logstash et Kibana. Ainsi, l'archive du fichier agent filebeat

Installation

peut être téléchargée sur ce site Nous allons procéder à l'installation en décompressant simplement le contenu du fichier zip. Par exemple, dans.

c:Program Filesfilebeat . Ensuite, il est nécessaire d'exécuter le script PowerShellinstall-service-filebeat.ps1 , qui est inclus, pour installer le service filebeat., inclus, pour l'installation du service filebeat.

Nous sommes maintenant prêts à commencer à configurer le fichier de configuration.

Résilience

Filebeat garantit la livraison des journaux au système de collecte de journaux. Cela se fait en maintenant un registre des entrées dans les fichiers journaux. Le registre contient des informations sur les entrées qui ont été lues à partir des fichiers journaux, ainsi que sur les entrées spécifiques qui ont été livrées à destination.

Si une entrée ne peut pas être livrée, filebeat tentera de la renvoyer jusqu'à ce qu'il reçoive une confirmation de livraison de la part du système récepteur, ou que le fichier journal d'origine soit supprimé lors de la rotation.

Lors du redémarrage du service filebeat, il lira dans le registre les informations sur les dernières entrées lues et livrées et lira les entrées dans les fichiers journaux en fonction des informations dans le registre.

Cela permet de minimiser le risque de perte d'informations sur les journaux qui doivent être envoyés aux serveurs elasticlogstash, en cas de défaillances imprévues et lors des opérations de maintenance des serveurs.

Pour en savoir plus, vous pouvez lire la documentation dans les sections: Comment Filebeat maintient l'état des fichiers et Comment Filebeat garantit une livraison au moins une fois ?

Configuration

Toute la configuration est réalisée dans un fichier de configuration au format fichier yml, qui est divisé en plusieurs sections. Examinons certaines d'entre elles qui participent au processus de collecte des journaux depuis les serveurs Exchange.

Bloc de traitement des journaux

Le bloc de traitement des journaux commence par le champ :

filebeat.inputs :

Nous allons utiliser un outil de collecte de journaux commun :

- type : log

Ensuite, nous indiquons le statut (activé) et les chemins vers le dossier contenant les journaux. Par exemple, dans le cas des journaux IIS, les paramètres peuvent être les suivants :

    enabled: true
    paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log

Une autre configuration importante : comment filebeat doit lire les entrées multilignes. Par défaut, filebeat considère une ligne du fichier journal comme une seule entrée. Cela fonctionne bien, tant que les journaux ne commencent pas à contenir des exceptions liées à un fonctionnement incorrect du service. Dans ce cas, les exceptions peuvent consister en plusieurs lignes. Ainsi, filebeat doit considérer l'entrée multilignes comme une seule, si la ligne suivante commence par une date. Le format d'entrée des journaux dans Exchange est tel que chaque nouvelle entrée dans le fichier journal commence par une date. Dans la configuration, cette condition se présente comme suit :

multiline:
	pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negate: true
	match: after

Il est judicieux d'ajouter des tags à l'enregistrement envoyé, par exemple :

  tags: ['IIS', 'ex-srv1']

Et n'oubliez pas d'exclure les lignes commençant par un symbole de hachage :

  exclude_lines: ['^#']

Ainsi, le bloc de lecture des logs ressemblera à ce qui suit :

filebeat.inputs:
- type: log
  enabled: true
  paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log
  multiline:
	pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negate: true
	match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']

Bloc d'envoi des logs

Filebeat envoie les enregistrements individuels dans le fichier log sous forme d'objet json, dans lequel un enregistrement spécifique du log est contenu dans un seul champ message. Si nous voulons travailler avec ces informations, nous devons d'abord analyser ce champ en différents champs. Cela peut être fait, par exemple, dans logstash. Celui-ci sera le destinataire des enregistrements de filebeat. Voici à quoi cela pourrait ressembler dans le fichier de configuration de filebeat :

output.logstash:
  hosts: ["logstash1.domain.com:5044"]

S'il y a plusieurs serveurs, vous pouvez activer l'équilibrage de charge : alors filebeat n'enverra pas les logs au premier serveur disponible dans la liste, mais répartira les logs envoyés entre plusieurs serveurs :

hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true

Lors du traitement des logs, filebeat ajoute à l'json envoyé, en plus de l'enregistrement du log qui est contenu dans le champ message, un certain nombre de métadonnées, ce qui affecte la taille du document qui sera envoyé à elastic. Ces métadonnées peuvent être sélectivement supprimées de l'envoi. Cela se fait dans le bloc processor à l'aide du processeur drop_fields. Il est possible d'exclure, par exemple, les champs suivants :

processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Il convient d'approcher le choix des champs à exclure avec soin, car certains d'entre eux peuvent être utilisés du côté d'elasticsearch pour la création des index.

Ainsi, le bloc d'envoi des logs ressemblera à ce qui suit :

output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Paramètres de journalisation de filebeat

Il est judicieux de définir les paramètres de journalisation suivants :

Niveau de journalisation info;
Enregistrer les logs dans des fichiers, situés par défaut (répertoire logs, dans le répertoire d'installation de filebeat);
Nom du fichier de log — filebeat;
Conserver les 10 derniers fichiers de logs;
Lancer la rotation dès que la taille atteint 1 Mo.

Le bloc final de configuration du journal sera le suivant :

logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Configuration finale

Nous avons rassemblé la configuration, et elle se présente maintenant comme suit :

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:inetpublogsLogFilesW3SVC1*.log
    - C:inetpublogsLogFilesW3SVC2*.log
  multiline:
    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
    negate: true
    match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']
 
output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
    fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]
 
logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Il est important de comprendre que le format du fichier de configuration est yml. Il est donc essentiel de respecter correctement les espaces et les signes moins.

Filebeat est capable de vérifier le fichier de configuration et, si la syntaxe présente des erreurs, il indiquera dans quelle ligne et à quel endroit la syntaxe est incorrecte. La vérification se fait de la manière suivante :

.filebeat.exe test config

De plus, filebeat peut vérifier la connectivité réseau du récepteur de journaux. La vérification se lance comme suit :

.filebeat.exe test output

Dans les prochaines parties, je parlerai de la connexion et de l'interaction entre Exchange et les composants Logstash et Kibana.

Liens utiles

Source : habr.com

Intégration d'ELK et d'Exchange. Partie 1