Je commence une série d'articles dans lesquels je souhaite partager mon expérience de connexion Exchange et ELK. Cette pile vous aidera à traiter de gros volumes de journaux sans vous demander à quelle taille les outils de journalisation habituels refuseront de nous aider. Faisons connaissance avec le nouveau combattant avec des journaux.
Exchange dispose d'un système de journalisation assez étendu. Les journaux les plus courants sont les journaux de suivi, qui suivent le passage étape par étape d'une lettre particulière au sein de l'organisation postale; les journaux du serveur Web, qui suivent chaque nouvelle session utilisateur dans le système, et les journaux d'applications Web spécifiques avec différents degrés de granularité de session. Exchange peut également stocker les journaux de protocole bruts smtp, imap et pop3.
Quels outils pouvons-nous utiliser pour travailler avec les journaux:
- Cmdlet Get-MessageTrackingLog standard: pratique pour traiter les journaux de suivi;
- L'utilitaire logparser: utilise un langage de recherche pseudo-SQL pour la journalisation et fonctionne assez rapidement;
- Serveur SQL externe: pour des cas particuliers (par exemple, analyse de données sur de longues périodes).
Tout cela fonctionne bien lorsque nous avons quelques serveurs et que le volume de journaux traités est mesuré en dizaines ou en centaines de gigaoctets. Mais que faire s'il y a des dizaines de serveurs et que la taille des journaux dépasse un téraoctet? Ce schéma commence très probablement à s'effriter.
Et voici ce qui se passe: Get-MessageTrackingLog commence à tomber en raison du délai d'expiration, logparser atteint le plafond de l'architecture 32 bits et le téléchargement sur le serveur SQL s'interrompt au moment le plus inopportun, sans digérer l'exception multi-lignes du service.
Ici, un nouveau joueur entre en scène - la pile ELK, spécialement conçue pour jongler avec d'énormes volumes de journaux dans un temps raisonnable et avec une consommation de ressources tolérable.
Dans la première partie, j'expliquerai en détail comment connecter filebeat, qui fait partie de la pile ELK- est responsable de la lecture et de l'envoi de fichiers texte simples dans lesquels différentes applications écrivent leurs journaux. Dans les articles suivants, nous nous attarderons plus en détail sur les composants Logstash et Kibana.
Installation
Ainsi, l'archive de fichiers de l'agent filebeat peut être téléchargée depuis ce site .
Nous terminerons l'installation en décompressant simplement le contenu du fichier zip. Par exemple, dans
c:\Program Files\filebeat. Ensuite, vous devez exécuter le script PowerShell install-service-filebeat.ps1fourni avec le kit pour installer le service filebeat.
Nous sommes maintenant prêts à commencer à personnaliser le fichier de configuration.
tolérance aux pannes
Filebeat garantit la livraison des journaux au système de collecte de journaux. Ceci est accompli en tenant un registre des entrées dans les fichiers journaux. Le Registre stocke des informations sur les enregistrements lus à partir des fichiers journaux et marque les enregistrements spécifiques qui ont été livrés à la destination.
Si un enregistrement ne peut pas être livré, filebeat essaiera de l'envoyer à nouveau jusqu'à ce qu'il reçoive une confirmation de livraison du système destinataire ou que le fichier journal d'origine soit supprimé pendant la rotation.
Lorsque le service est redémarré, filebeat lira les informations sur les derniers enregistrements lus et livrés à partir du registre et lira les enregistrements dans les fichiers journaux en fonction des informations du registre.
Cela minimise le risque de perdre des informations sur les journaux qui doivent être envoyés aux serveurs Elastic \ logstash lors de pannes inattendues et lors des opérations de maintenance du serveur.
Vous pouvez en savoir plus à ce sujet dans la documentation dans les paragraphes : Comment Filebeat conserve-t-il l'état des fichiers et Comment Filebeat assure-t-il une livraison au moins une fois?
Mise en place
Toute la configuration est effectuée dans le fichier de configuration de format
yml, qui est divisé en plusieurs sections. Examinons certains d'entre eux qui sont impliqués dans la collecte de journaux à partir de serveurs Exchange.
Unité de traitement des journaux
Le bloc de traitement du journal commence par le champ:
filebeat.inputs:Nous utiliserons un outil de collecte de journaux commun:
- type: logEnsuite, nous indiquons l'état (activé) et les chemins d'accès au dossier avec les journaux. Par exemple, dans le cas des journaux IIS, les paramètres peuvent être les suivants:
enabled: true
paths:
- C:\inetpub\logs\LogFiles\W3SVC1\*.log
- C:\inetpub\logs\LogFiles\W3SVC2\*.log
Un autre paramètre important est la façon dont filebeat doit lire les enregistrements multilignes. Par défaut, filebeat considère qu'une ligne du fichier journal est un enregistrement. Cela fonctionne bien, tant que nous ne commençons pas à recevoir des exceptions liées au fonctionnement incorrect du service dans le journal. Dans ce cas, les exceptions peuvent s'étendre sur plusieurs lignes. Par conséquent, filebeat doit traiter un enregistrement multiligne comme un enregistrement si la ligne suivante commence par une date. Le format d'enregistrement des journaux dans Exchange est le suivant: chaque nouvel enregistrement dans le fichier journal commence par une date. Dans la configuration, cette condition ressemble à ceci:
multiline:
pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
negate: true
match: afterIl est judicieux d'ajouter des balises au message que vous envoyez, par exemple:
tags: ['IIS', 'ex-srv1']Et n'oubliez pas d'exclure du traitement les lignes commençant par un caractère de hachage:
exclude_lines: ['^#']Ainsi, le bloc de lecture des journaux ressemblera à ceci:
filebeat.inputs:
- type: log
enabled: true
paths:
- C:\inetpub\logs\LogFiles\W3SVC1\*.log
- C:\inetpub\logs\LogFiles\W3SVC2\*.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 de journal
Filebeat envoie des entrées individuelles dans le fichier journal en tant qu'objet json, dans lequel une entrée spécifique du journal est contenue dans un champ de message unique. Si nous voulons travailler d'une manière ou d'une autre avec ces informations, nous devons d'abord analyser ce champ dans des champs séparés. Cela peut être fait, par exemple, dans logstash. Ce 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, l'équilibrage peut être activé pour eux: alors filebeat n'enverra pas les journaux au premier serveur disponible de la liste, mais distribuera les journaux envoyés entre plusieurs serveurs:
hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
loadbalance: true Filebeat, lors du traitement des journaux dans le json envoyé, en plus de l'entrée de journal, qui est contenue dans le champ de message, ajoute une certaine quantité de métadonnées, ce qui affecte la taille du document qui entre dans Elastic. Ces métadonnées peuvent être supprimées de manière sélective de la soumission. Cela se fait dans le bloc processeur à l'aide du processeur
drop_fields. Vous pouvez 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"]Le choix des champs exclus doit être abordé avec précaution, car certains d'entre eux peuvent être utilisés du côté élastique pour créer des index.
Ainsi, le bloc d'envoi des journaux ressemblera à ceci:
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 Filebeat
Il est judicieux de définir les paramètres de journalisation suivants:
- Informations sur le niveau de journalisation;
- Nous écrivons des journaux dans des fichiers situés par défaut (le répertoire des journaux, dans le répertoire d'installation de filebeat);
- Le nom du fichier journal est filebeat;
- Conservez les 10 derniers fichiers journaux;
- Démarrez la rotation lorsque la taille atteint 1 Mo.
Enfin, le bloc des paramètres de journalisation ressemblera à ceci:
logging.level: info
logging.to_files: true
logging.files:
name: filebeat
keepfiles: 10
rotateeverybytes: 1048576Configuration finale
Nous avons rassemblé la configuration, et maintenant elle ressemble à ceci:
filebeat.inputs:
- type: log
enabled: true
paths:
- C:\inetpub\logs\LogFiles\W3SVC1\*.log
- C:\inetpub\logs\LogFiles\W3SVC2\*.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: 1048576Il est important de comprendre que le format du fichier de configuration est yml. Par conséquent, il est important de placer correctement les espaces et les signes moins.
Filebeat peut vérifier le fichier de configuration et, si la syntaxe contient des erreurs, il indiquera dans quelle ligne et où dans la ligne la syntaxe est incorrecte. Le contrôle se fait comme suit:
.\filebeat.exe test configFilebeat peut également vérifier la disponibilité réseau du récepteur de journal. Le contrôle est lancé comme ceci:
.\filebeat.exe test outputDans les prochaines parties, je parlerai de la connectivité Exchange et de l'amitié avec les composants Logstash et Kibana.