Enregistrement d'événements à grande échelle sur AWS

Version imprimable, PDF et e-mail

La plupart des applications génèrent des événements de configuration et d'accès, que les administrateurs doivent pouvoir visualiser. Le service Barracuda Email Security offre une plus grande transparence et visibilité sur tous ces événements pour aider les administrateurs à ajuster et comprendre leur système. Il vous permet notamment de connaître l'identité des utilisateurs connectés à un compte ainsi que le moment où ils se connectent ou encore d'identifier la personne qui a ajouté, modifié ou supprimé la configuration d'une politique spécifique.

Développer un tel système distribué et interrogeable requière de se poser plusieurs questions, parmi lesquelles :

  • Comment extraire ces enregistrements de l'ensemble de vos applications, services et machines pour les envoyer vers un emplacement centralisé ?
  • Quel doit être le format standard de ces fichiers journaux ?
  • Combien de temps devrez-vous conserver ces journaux ?
  • Comment relier les événements provenant de différentes applications ?
  • Comment proposer à l'administrateur un mécanisme de recherche à la fois simple et rapide, accessible depuis une interface utilisateur ?
  • Comment permettre l'accès à ces journaux via une API ?

Elasticsearch est la première solution qui nous vient à l'esprit lorsque l'on pense à un moteur de recherche distribué. Hautement évolutif, il permet une recherche en temps quasi réel et est disponible en tant que service entièrement géré via AWS. Pour cet exemple, nous allons donc enregistrer nos journaux d'événements dans Elasticsearch, et Kinesis Data Firehose assurera leur transfert depuis les différentes applications jusqu'à notre moteur de recherche.

Les composants de cette architecture

  1. Kinesis Agent – Amazon Kinesis Agent is a standalone Java software application that offers an easy way to collect and send data to Kinesis Data Firehose. The agent continuously monitors event log files on EC2 Linux instances and sends them to the configured Kinesis Data Firehose delivery stream. The agent handles file rotation, checkpointing, and retry upon failures. It delivers all of your data in a reliable, timely, and simple manner. Note: If the application that needs to write to Kinesis Firehose is a Fargate container, you will need a Fluentd container. However, this article focuses on applications running on Amazon EC2 instances.
  2. Kinesis Data Firehose – Amazon Kinesis Data Firehose direct put method can write the JSON formatted data into Elasticsearch. This way it doesn’t store any data on the stream.
  3. S3 – Un compartiment S3 peut être utilisé pour sauvegarder la totalité des enregistrements ou seulement ceux dont l'envoi vers Elasticsearch a échoué. Il est également possible de créer des politiques de cycle de vie afin d'automatiser l'archivage des journaux.
  4. Elasticsearch – Elasticsearch hébergé par Amazon. L'accès à Kibana peut être activé afin de simplifier la requête et la recherche de journaux à des fins de débogage.
  5. Curator – AWS recommends using Lambda and Curator to manage the indices and snapshots of the Elasticsearch cluster. AWS has more details and sample implementation that can be found here
  6. REST API interface – You can create an API as an abstraction for Elasticsearch which integrates well with the User interface. API-driven microservice architectures are proven to be the best in many aspects such as security, compliance, and integration with other services.

 

Évolutivité

  • Kinesis Data Firehose: By default, firehose delivery streams can scale up to 1,000 records/sec or 1MiB/sec for US East (Ohio). This is a soft limit and can be increased up to 10,000 records/sec. This is region specific.
  • Elasticsearch : les capacités de stockage et la puissance de calcul du cluster Elasticsearch peuvent être étendues dans AWS. Des mises à niveau sont également disponibles. Amazon ES fait appel à un flux de déploiement Blue-Green pour la mise à jour des domaines. Par conséquent, le nombre de nœuds contenus dans le cluster est susceptible de croître temporairement lorsque des modifications sont appliquées.

Les avantages de cette architecture

  1. L'architecture de pipeline est entièrement gérée, demandant très peu de maintenance.
  2. If the Elasticsearch cluster fails, Kinesis Firehose can retain records for up to 24 hours. In addition, records that fail to deliver are also backed up to S3.

Les risques de perte de données sont ainsi moindres.

  1. Fine-grained access control is possible to both Kibana and Elasticsearch API through IAM policies.

Les limites

  1. Pricing needs to be carefully considered and monitored. The Kinesis Data Firehose can handle large amounts of data ingestion with ease, and if a rogue agent starts logging large amounts of data, the Kinesis Data Firehose will deliver them without issues. This can incur large costs.
  2. L'intégration Kinesis Data Firehose vers Elasticsearch est uniquement compatible avec les clusters Elasticsearch non VPC.
  3. The Kinesis Data Firehose currently cannot deliver logs to Elasticsearch clusters that are not hosted by AWS. If you would like to self-host Elasticsearch clusters, this setup will not work. 

Conclusion

If you are looking for a solution that is completely managed and (mostly) scales without intervention, this would be a good option to consider. The automatic backup to S3 with lifecycle policies also solves the log retention and archival problem easily.

Remonter en haut de page
Tweeter
Partager
Partager