Bien Lire les Logs : Une Compétence Cruciale en DevOps
Lire les Logs : La Compétence Qui Fait la Différence
La lecture de logs est probablement la compétence la plus sous-estimée en DevOps. N'importe qui peut grep un fichier de logs. Mais savoir quoi chercher, où chercher, et comment relier les indices entre eux, c'est ce qui transforme un incident de 4 heures en un diagnostic de 15 minutes.
Un Exemple Qui a Tout Changé
Chez un client dans la mobilité, l'application retournait des erreurs 500 sporadiques. L'équipe de développement avait passé deux jours à chercher un bug dans le code. Quand j'ai pris le relais, j'ai commencé par les logs.
Dans Loki (via Grafana), j'ai filtré les logs du pod applicatif sur la période des erreurs. Les logs applicatifs ne montraient rien d'anormal. Mais en croisant avec les logs du load balancer, j'ai vu que les erreurs 500 correspondaient à des timeouts vers un service tiers. Le problème n'était pas dans le code, mais dans un service externe qui répondait lentement à certaines heures.
Diagnostic : 20 minutes au lieu de 2 jours. La différence ? Savoir où chercher et comment corréler les logs.
Les Outils Que J'Utilise
Loki + Grafana est mon setup standard pour les logs. Loki stocke les logs de façon économique (indexation par labels seulement), et Grafana permet des requêtes LogQL puissantes. La corrélation avec les métriques Prometheus et les traces Tempo dans la même interface est un game-changer.
Pour les cas où Loki n'est pas disponible, kubectl logs reste mon premier réflexe pour un diagnostic rapide. Avec les options --since, --tail, et le flag -c pour cibler un container spécifique dans un pod multi-container.
Les Techniques de Lecture
Le Filtrage Intelligent
Ne lisez pas les logs du début à la fin. Commencez par la fin (les erreurs les plus récentes), filtrez par niveau de sévérité (ERROR, WARN), et remontez dans le temps pour trouver la cause racine. En LogQL, une requête comme {namespace="production"} |= "error" | json | level = "ERROR" est un bon point de départ.
La Corrélation Temporelle
Le secret du diagnostic rapide : corréler les timestamps. Si une erreur apparaît à 14:32:15, regardez ce qui s'est passé dans les 30 secondes précédentes sur tous les services impliqués. Un déploiement ? Un pic de trafic ? Un timeout vers un service externe ?
Les Logs Structurés
J'insiste toujours auprès des équipes de développement pour que les logs soient structurés en JSON. Un log structuré {"level":"error","service":"api","path":"/users","status":500,"duration_ms":3200,"trace_id":"abc123"} est infiniment plus exploitable qu'un Error: something went wrong.
Centralisation et Rétention
Sur chaque projet, je mets en place une politique de rétention adaptée :
- 7 jours pour les logs de debug en développement
- 30 jours pour les logs applicatifs en production
- 90 jours pour les logs d'audit et de sécurité (souvent imposé par la conformité)
Chez un client en conformité HDS, la rétention des logs de sécurité était de 1 an, stockée sur S3 avec glacier pour les archives.
Conclusion
Bien lire les logs, c'est comme être un bon détective : vous devez savoir quelles questions poser, où chercher les indices, et comment relier les preuves. C'est une compétence qui s'affine avec l'expérience, et après 15 ans d'incidents en production, je continue à apprendre de chaque investigation.