1. Le cahier des charges #
Ce qu'on attend.
Contexte #
Une équipe exploitation veut centraliser les journaux de ses serveurs Linux et d'une application historique qui écrit dans un fichier texte, les conserver 30 jours, les analyser et être prévenue en cas de rafale d'erreurs.
| Exigence | Brique | Formation |
|---|---|---|
| Collecter les logs système des serveurs | Elastic Agent + Fleet | Elastic Agent |
| Structurer les logs de l'application historique | Logstash (dissect, translate) | Logstash |
| Conserver 30 jours | Data streams + ILM | Elasticsearch |
| Analyser et visualiser | ES|QL, Lens | Kibana |
| Alerter sur une rafale d'erreurs | Règle ES|QL + connecteur | Kibana |
| Accès en lecture pour l'équipe | Rôle et espace dédiés | Elasticsearch, Kibana |
2. Les étapes #
Le TP guidé.
Déroulé #
- Monter le labo Fleet (TP 1 de la formation Elastic Agent).
- Vérifier la collecte des logs système.
- Créer le modèle d'index et la politique ILM de 30 jours.
- Ajouter Logstash pour l'application historique.
- Analyser avec ES|QL et construire le tableau de bord.
- Créer la règle d'alerte et le rôle de lecture.
3. Grille d'évaluation #
Ce qui valide le projet.
Critères #
| Critère | Vérification |
|---|---|
| Collecte | l'agent est Healthy dans Fleet et logs-system.*-lab reçoit des données |
| Structuration | les champs log.level, http.response.status_code et le libellé traduit existent dans logs-legacyapp-lab |
| Rétention | GET logs-legacyapp-lab/_ilm/explain montre la politique de 30 jours |
| Analyse | un tableau de bord avec au moins trois visualisations sur les deux sources |
| Alerte | la règle passe en Active lors d'une rafale d'erreurs simulée |
| Sécurité | un utilisateur « lecteur » voit le tableau de bord mais ne peut rien modifier |
Bonne pratique : Exportez le tableau de bord (objets enregistrés) et versionnez-le avec vos fichiers de configuration : c'est votre livrable.
