Vos logs méritent mieux que la config par défaut

Les logs comptent parmi les trois piliers de l'observabilité avec les métriques et les traces. Lors de cette présentation, nous nous focaliserons sur les bonnes pratiques, méthodes, et outils pour ne manquer aucun événement.

Au programme :

* Comment écrire une bonne ligne de log ?
* Où placer cette ligne de log ?
* Comprendre l'architecture de Monolog, pour en tirer le maximum
* Où envoyer ses logs ?
* Et ensuite ?

DEMO: https://s.lyrixx.info/log-demo

Transcript

1. Vos logs méritent mieux que la config par défaut Grégoire Pineau dev-ops @jolicode & @redirectionio core team @symfony github.com/lyrixx twitter.com/lyrixx
2. 2 Les logs, un sujet passionnant
4. En trois points L’observabilité 4
5. Les metrics mesurent ce qu’il se passe Donnée structurée Stockées dans une TSDB Les traces Les trois piliers de l’observabilité expliquent ce qu'il se passe Donnée non structurée (texte) ou structurée (json) Stockés dans un «journal» Les logs montrent ce qu’il se passe Donnée structurée Stockées dans une DB 5
6. Les logs 6
7. Les logs Exemple avec Kibana 7
8. Les metrics Exemple avec Grafana 8
9. Les traces Exemple avec Symfony 9
10. Pourquoi logger ? 10 1. logger ? 2. logguer ? 3. loger ? 4. loguer ?
11. 11 Pour debugger • Suivre un flow d'exécution • Comprendre du code • Trouver les bugs • Résoudre les bugs ? ProTips
12. Pour alerter et monitorer 12 • Recevoir un mail pour chaque nouvelle erreur • Recevoir une notification Slack • Envoyer ses logs vers ◦ Produit SaaS ▪ Sentry ▪ Datadog ▪ … ◦ Base de données ▪ Loki ▪ Elasticsearch ▪ ClickHouse ▪ … • …
13. Anatomie d’un log 13
14. 14 Un standard • PSR3 : psr/log@v3 • LoggerInterface • AbstractLogger + LoggerTrait • NullLogger • Des LogLevels • Et une exception : InvalidArgumentException • Et du tooling pratique 🥺
15. LoggerInterface 15
16. LogLevel 16 ⭐ debug information pour le debug ⭐ info événement intéressant ⭐ notice événement intéressant, mais occasionnel warning événement occasionnel, mais qui n’impacte pas l’utilisateur ❗ error Erreur lors de l'exécution critical Erreur grave, qui doit être résolue le plus rapidement alert Erreur grave, qui doit être résolue encore plus rapidement emergency WTF OMG BBQ !!! plus rien ne marche
17. LoggerInterface 17
18. Un standard, un context, et une exception 18 #[SensitiveParameter] $ready ProTips
19. Monolog 19 Le logger par défaut de Symfony
20. 20 Monolog API
21. 21 Monolog API
22. 22 Dans Symfony
23. Comment bien logger ? 23
24. 24 Comment bien écrire une ligne de log ? • Mettre un message simple, clair, et descriptif • Ne pas mettre de variable dans le message ◦ Ajouter autant de contexte que nécessaire • En cas d’erreur, le message doit être unique au sein de l’application • Bonus ◦ Finir par un point, comme les Exceptions 🙃 ◦ Mettre une URL vers une page de documentation
25. Où logger ? 25 • Partout, vraiment, partout • Encore plus dans les crons, workers, processus async • Dans les workflows critiques ou complexes : ◦ un message “notice” avant : “Trying to do something” + un context bien rempli ◦ des messages “info” pour les embranchements de code ◦ un message “debug” après : “Did something” ◦ un message si une erreur survient “cannot do something” + l’exception en context
26. Signaler tout ce qui est suspect 26 • Dans un worker, quand une entité n’existe plus, niveau “warning” • Un valeur de retour d’API suspecte : “warning” ou “error” • Un fichier manque sur S3, un cache est vide alors qu’il devrait être chaud • …
27. Mais aussi quand ça se passe bien 27 • C’est important de savoir qu’une action est en success • Cela prouve que le code s’est bien exécuté jusqu’au bout
28. 28 Les «processors» • Modifier les logs • Enrichir les logs
29. Serialization du context 29
30. ProcessorInterface 30
31. ModelProcessor 31
32. ModelProcessor 32
33. ModelProcessor 33
34. Autres processors utiles 34 • Mes préférés: ◦ Symfony\Bridge\Monolog\Processor\WebProcessor ◦ Symfony\Bridge\Monolog\Processor\ConsoleCommandProcessor ◦ Symfony\Bridge\Monolog\Processor\TokenProcessor • Mais il en existe plein d’autres : https://github.com/Seldaek/monolog/blob/main/doc/02-handlers-formatt ers-processors.md#processors
35. Autres processor utiles - Configuration 35
36. Quelques créations 🎨 - AmqpEnvelopeProcessor 36
37. Quelques créations 🎨 - SapiProcessor 37
38. Quelques créations 🎨 - UuidProcessor 38 UuidProcessor • Ajoute un identifiant unique à tous les logs pour une requête ou un message messenger • Mais permet d'être remplacé si une en-tête HTTP est présente • Transmet cet identifiant à un message (messenger) pour conserver l'intégralité de la trace • Plug & Play • https://s.lyrixx.info/log-uuid-processor
39. Exemple de log 39
41. 41 Organiser ses logs Avec des channels
42. 42 Channels • Un channel est un journal de logs • Il existe différents channels par défaut : asset, cache, console, doctrine, event, http, lock, mailer, messenger, php, profiler, request, router, security, semaphore, translation, workflow • L’application utilise le channel “app” par défaut • Et vous pouvez créer les vôtres
43. Channels personnalisés 43
44. Channels personnalisés 44
45. 45 Envoyer ses logs Avec des handlers
46. 46 Les handlers Elasticsearch … DataDog var/log/prod.log Sentry Your app Monolog
47. Différents groupe de handlers 47 • Monolog fournit une très grande liste de handlers ◦ stream (file), socket (tcp/udp), amqp, syslog, … ◦ mail, Slack, IFTTT, Sendgrid, Telegram, … ◦ Sentry, NewRelic, Logmatic, … ◦ Redis, Doctrine, Elasticsearch, Elastica, MongoDB, … ◦ Cependant, certains sont déconseillés • Certains sont spéciaux ◦ FingersCrossed ◦ Group ◦ Buffer ◦ …
48. Transporter tous les logs 48 Comment transporter tous vos log à destination ? Tout dépend de la destination ! • Via STDERR (Docker, PaaS) (StreamHandler) • Via un fichier (bare metal, faible trafic) (StreamHandler) ◦ ⚠ Mettre en place un log rotate (RotatingFileHandler) • Via TCP, ou UDP (bare metal, fort trafic) (Syslog*Handler) ◦ Vers un agrégateur local : ▪ Vector ▪ Logstash ▪ Fluentd ▪ FileBeat • Via le handler du SaaS
49. Et des formatters 49 Va formater le LogRecord avant de l’envoyer • line • JSON • HTML • logstash • …
50. 50 Exemple de configuration
51. Les erreurs PHP ? 51 Avant Symfony 7.1 les notices et warning n’étaient pas remontés dans les logs au niveau erreur !
52. 52 En dev
53. En prod 53
54. fingers crossed - activation strategy 54
55. En prod - certains channels sont toujours loggués 55
56. Deprecation 56 • Symfony log les dépréciations dans un channel “deprecation” si il existe • On peut utiliser un handler spécifique pour écrire les logs dans un fichier ◦ Et pourquoi pas faire du sampling • Attention à la facturation
57. 57 Quel moteur de stockage ? • L’alerting • La recherche
58. 58 L’alerting • Quand quelque chose se passe mal ◦ Être prévenu le plus rapidement possible ◦ Recevoir une alerte à la première occurrence d’une erreur ▪ Sentry ▪ BugSnag ▪ …
59. La recherche 59 • Pour analyser pourquoi ça s’est mal passé ◦ ll faut un maximum de log et de contexte • Mais où stocker tous ces logs ? ◦ In house : ▪ Elasticsearch + Kibana ▪ Loki + Grafana ▪ ClickHouse + Grafana ▪ Signoz ▪ Open observe ▪ … ◦ Produit - Saas ▪ Datadog ▪ NewRelic ▪ … github.com/lyrixx/symfony-observability-demo
60. 60 Conclusion
61. Conclusion 61 • Logger un maximum ◦ Utiliser le context avec des processor ◦ Utiliser des channels, dont un pour l’audit log ◦ Configurer les handlers en fonction des channels • Utiliser de l’alerting • Si possible, stocker les logs pour de l’analyse
62. 62 Merci ! Grégoire Pineau dev-ops @jolicode & @redirectionio core team @symfony github.com/lyrixx twitter.com/lyrixx 🌲Qui a compris la relation entre le thème des slides et le sujet ? 🌲