Les logs provenant d'un éventail de services AWS peuvent être stockés dans des compartiments S3, comme les logs d'accès au serveur S3, les logs d'accès ELB, les logs CloudWatch et les logs de flux VPC. Par exemple, les logs d'accès au serveur S3 fournissent des enregistrements détaillés pour les requêtes envoyées à un compartiment. Ces informations sont très utiles. Malheureusement, AWS crée de multiples fichiers .txt pour plusieurs opérations, ce qui ne permet pas de voir exactement les opérations enregistrées dans les logs sans ouvrir chaque fichier .txt séparément. En outre, les logs d'accès au serveur S3 sont enregistrés dans un format complexe. Il est donc très difficile pour les utilisateurs d'ouvrir simplement le fichier .txt et de trouver les informations dont ils ont besoin.
Heureusement, tous vos logs AWS peuvent être facilement indexés, analysés et visualisés avec la Suite Elastic. Ainsi, vous pouvez utiliser toutes les données importantes qu'ils contiennent. Dans cet article, je vais vous montrer combien ce processus est facile.
Introduction
Dans Filebeat 7.4, l'entrée s3 est devenue une option pour les utilisateurs. Ainsi, ils peuvent récupérer des événements à partir de fichiers dans un compartiment S3. Chaque ligne de chaque fichier devient un événement distinct. Outre l'entrée s3, nous avons transféré deux nouveaux ensembles de fichiers pour le module AWS de Filebeat, à savoir s3access et elb (une nouveauté de la version 7.5). Grâce à eux, les utilisateurs peuvent collecter des logs dans différents compartiments S3, puis les visualiser et les analyser dans un emplacement centralisé sans télécharger ni ouvrir manuellement chaque fichier.
Pour éviter tout retard important lors de l'interrogation de l'ensemble des fichiers de logs provenant de chaque compartiment S3, nous avons décidé d'associer la notification à l'interrogation en utilisant Amazon Simple Queue Service (SQS) pour la notification Amazon S3 lors de la création d'un nouvel objet S3. L'entrée s3 de Filebeat vérifie dans SQS l'arrivée de nouveaux messages concernant le nouvel objet créé dans S3 et utilise les informations de ces messages pour récupérer les logs dans les compartiments S3. Grâce à cette configuration, il est inutile d'interroger régulièrement chaque compartiment S3. En effet, l'entrée s3 de Filebeat garantit une collecte des données des compartiments S3 rapide, fiable et en temps quasi réel.
Configuration des notifications des événements S3 à l'aide de SQS
En suivant les quatre étapes ci-dessous, les utilisateurs peuvent ajouter une configuration de notification à un compartiment nécessitant AWS S3 pour publier des événements de type s3:ObjectCreated:* dans une file d'attente AWS SQS. Pour en savoir plus, consultez la présentation d'un exemple de configuration d'une notification pour un compartiment.
1ère étape : création d'une file d'attente SQS et d'un compartiment S3
Créez une file d'attente SQS et un compartiment S3 dans la même région AWS à l'aide de la console Amazon SQS.
2e étape : configuration d'une file d'attente SQS
Remplacez la règle d'accès liée à la file d'attente par la règle suivante.
{
"Version": "2012-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"AWS":"*"
},
"Action": [
"SQS:SendMessage"
],
"Resource": "<SQS-queue-ARN>",
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:*:*:<bucket-name>" }
}
}
]
}
Assurez-vous de modifier les variables <sqs-queue-arn> et <bucket-name> afin qu'elles correspondent à l'arn de votre file d'attente SQS et au nom de votre compartiment S3.
3e étape : configuration du compartiment S3
Via la console Amazon S3, ajoutez une configuration de notification demandant à Amazon S3 de publier
des événements du
type s3:ObjectCreated:* dans votre file d'attente Amazon SQS.
4e étape : test de la configuration S3-SQS
Chargez un objet dans le compartiment S3 et vérifiez la notification de l'événement dans la console Amazon SQS.
Utilisation de l'entrée s3 de Filebeat
En activant Filebeat avec l'entrée s3, les utilisateurs peuvent collecter les logs des compartiments AWS S3. Chaque ligne de chaque fichier de log devient un événement distinct et est stockée dans la sortie Filebeat configurée, comme Elasticsearch. En utilisant seulement l'entrée s3, les messages des logs sont stockés dans le champ message de chaque événement sans analyse.
Lors du traitement d'un objet S3 référencé par un message de SQS, si la moitié du délai de visibilité configuré s'écoule sans interruption du processus, le délai de ce message SQS est réinitialisé pour s'assurer que le message ne retourne pas dans la file d'attente pendant le traitement. En cas d'erreurs au cours du traitement de l'objet S3, le processus s'arrête et le message de SQS retourne dans la file d'attente.
Étape 0 : Création d'une politique IAM
Une politique IAM est une entité qui définit les permissions envers un objet au sein de votre environnement AWS. Il est nécessaire de créer une politique IAM personnalisée pour Filebeat avec des permissions spécifiques. N'hésitez pas à consulter la rubrique Création de politiques IAM pour plus de détails. Vous trouverez ci-dessous une liste des permissions requises pour accéder à SQS et S3 :- s3:GetObject
- sqs:ReceiveMessage
- sqs:ChangeMessageVisibility
- sqs:DeleteMessage
1ère étape : installation de Filebeat
Pour télécharger et installer Filebeat, différentes commandes fonctionnent pour plusieurs systèmes. Par exemple, avec Mac :
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.5.1-darwin-x86_64.tar.gz tar xzvf filebeat-7.5.1-darwin-x86_64.tar.gz
Pour en savoir plus, consultez la page consacrée à l'installation de Filebeat.
2e étape : configuration de l'entrée s3
Voici un exemple d'activation de l'entrée s3 dans filebeat.yml :
filebeat.inputs: - type: s3 queue_url: https://sqs.us-east-1.amazonaws.com/1234/test-fb-ks visibility_timeout: 300s credential_profile_name: elastic-beats
Grâce à cette configuration, Filebeat accède à la file d'attente AWS SQS test-fb-ks pour lire les messages de notification. Ainsi, Filebeat obtient des informations sur les objets S3 spécifiques et les utilise pour lire les objets ligne par ligne. La variable visibility_timeout est la durée (en secondes) pendant laquelle les messages reçus sont cachés dans les demandes de récupération suivantes après avoir été récupérés par une requête ReceiveMessage. Par défaut, la variable visibility_timeout est de 300 secondes, avec un minimum de 0 seconde et un maximum de 12 heures. Pour passer des appels d'API AWS, l'entrée s3 doit comprendre des informations d'identification AWS dans sa configuration. Dans l'exemple ci-dessus, le nom de profil elastic-beats est donné pour passer des appels d'API AWS. Pour en savoir plus, consultez la page consacrée à la configuration des informations d'identification AWS.
3e étape : démarrage de Filebeat
Pour Mac et Linux :
sudo chown root filebeat.yml sudo ./filebeat -e
Pour en savoir plus, consultez la page consacrée au démarrage de Filebeat.
Collecte des logs d'accès au serveur S3 grâce à l'ensemble de fichiers s3access
L'ensemble de fichiers s3access a été ajouté à Filebeat 7.4 afin de collecter les logs d'accès au serveur S3 grâce à l'entrée s3. Les logs d'accès au serveur fournissent des enregistrements détaillés pour les requêtes envoyées à un compartiment, ce qui peut être très utile pour les audits d'accès et de sécurité. Par défaut, la journalisation des accès au serveur est désactivée. Pour suivre les demandes d'accès à votre compartiment, vous pouvez activer la journalisation des accès au serveur. Chaque enregistrement de log d'accès fournit des informations sur une seule demande d'accès, comme la personne à l'origine de la requête, le nom du compartiment, la date et l'heure de la demande, l'action menée, l'état de la réponse et un code d'erreur, le cas échéant.
1ère étape : activation de la journalisation des accès au serveur
Dans les propriétés d'un compartiment S3 spécifique, vous pouvez activer la journalisation des accès au serveur en cochant l'option Enable logging.
2e étape : activation du module aws dans Filebeat
Dans une configuration par défaut de Filebeat, le module aws n'est pas activé. La commande suivante active la configuration du module aws dans le répertoire modules.d sur les systèmes macOS et Linux :
sudo ./filebeat modules enable aws
3e étape : configuration du module aws
Par défaut, l'ensemble de fichiers s3access est désactivé. Pour activer l'ensemble de fichiers s3access, consultez le fichier aws.yml de la manière suivante.
- module: aws
s3access:
enabled: true
var.queue_url: https://sqs.myregion.amazonaws.com/123456/myqueue
var.credential_profile_name: fb-aws
4e étape : démarrage de Filebeat
Pour Mac et Linux :
sudo chown root filebeat.yml sudo ./filebeat -e
Pour en savoir plus, consultez la page consacrée au démarrage de Filebeat.
5e étape : utilisation du tableau de bord de l'ensemble de fichiers s3access dans Kibana
L'ensemble de fichiers s3access comprend un tableau de bord prédéfini, appelé [Filebeat AWS] S3 Server Access Log Overview. En lançant la commande de configuration au démarrage de Filebeat, vous définissez automatiquement ces tableaux de bord dans Kibana.
Pour Mac et Linux :
./filebeat setup --dashboards
Pour plus d'informations à ce sujet, n'hésitez pas à consulter la documentation intitulée Configurer les tableaux de bord Kibana.
Ce tableau de bord est un aperçu des logs d'accès au serveur AWS S3. Il montre les premières URL avec leur code de réponse, leur état HTTP dans le temps et tous les logs d'erreur.
Et ensuite ?
Avec l'entrée s3 de Filebeat, les utilisateurs peuvent facilement collecter des logs dans les services AWS et les transférer en tant qu'événements dans notre Elasticsearch Service sur Elastic Cloud ou dans un cluster exécuté à partir de la distribution par défaut. Dans la version 7.4, l'ensemble de fichiers s3access est à la disposition des utilisateurs afin qu'ils puissent collecter et analyser les logs d'accès au serveur S3. Dans la version 7.5, l'ensemble de fichiers elb est à la disposition des utilisateurs afin qu'ils puissent collecter les logs d'équilibreur de charge classique, d'application et de réseau. Nous commencerons bientôt à ajouter des ensembles de fichiers supplémentaires afin de prendre en charge d'autres logs couramment utilisés, comme les logs de flux VPC, les logs CloudWatch et les logs Cloudtrail. Si vous avez des questions ou des commentaires, n'hésitez pas à les publier sur le forum de discussion consacré à Beats.