Lire logs énormes d'exceptions PHP d'origines diverses

Salut,

Je dois parfois lire des fichiers de logs énormes (ne se transfèrent pas bien par le réseau voire ne s’ouvrent pas sur l’ordinateur ou après un très long délai de plus de 5min au moins). Ces fichiers contiennent des exceptions PHP avec les infos de bug tracing. Souvent je souhaite en prendre connaissance, et ignorer les exceptions PHP dont l’origine est le module X mais considérer celles dont l’origine est le connecteur d’API X. Enfin, j’ai souvent besoin d’aller à l’exception n°X (ou bien juste entre les lignes n° X et Y).

Les commandes tail //// head ne me semblent pas appropriées pour un tel usage, beaucoup trop fin et complet.

Je crois qu’il y a la commande sed.

Bref, je voudrais savoir ce que vous faites dans de telles situations svp ?

Merci !

PS : j’ai mis ça dans le forum "système et matériel" car c’est du Linux mais bon, je me suis peut-être trompé

J’ai l’impression que tu utilises peut-être le mauvais outil pour la tâche. Si le but est d’avoir un système qui va rapporter les erreurs applicatives pendant que l’instance est déployée, je pense que des outils comme Sentry.io seraient plus indiqués. Ils permettent de se tenir au courant des erreurs qui surviennent, tout en ayant un traceback complet avec du contexte additionnel (navigateur de l’utilisateur, version de PHP, versions des librairies utilisées, systèmes sous-jacent) et de filtrer par exception comme tu sembles le vouloir.

Les commandes tail //// head ne me semblent pas appropriées pour un tel usage, beaucoup trop fin et complet.

Je crois qu’il y a la commande sed.

tail et head ne font que te donner les n premières ou dernières lignes d’un fichier textuel (ou lire un stream bloquant). Ça ne te permettra pas de filtrer sur ce qui est digne d’intérêt. Le souci c’est que tes données semblent non structurées et aucun outil Unix basique ne comprend nativement les tracebacks de PHP et permet simplement de filtrer dessus. Si tes tracebacks sont en une seule ligne, tu peux éventuellement utiliser grep dessus avec la ou les bonnes regex.

À noter que grep peut fonctionner avec un flot de données (dans stdin, par exemple quand on fait curl https://example.com/lala.log | grep 'machin'), ce qui peut t’être utile compte tenu de la taille de ton fichier.

Personnellement je pense à des outils dédiés comme LogStash – mais il y en a d’autres.

J’ai fait la supposition que tu cherches une solution one shot pour cette fois-ci. Mais je rebondis sur le message de @SpaceFox : si tu as besoin d’une solution pérenne pour conserver et chercher les erreurs de façon courante, il conviendra certainement de mettre en place un véritable système de journalisation comme LogStash ou autre (il y en a à la pelle, il faut que tu farfouilles un peu pour voir ce qui te convient). Sentry que j’ai mentionné plus haut ne sert qu’à rapporter les erreurs (quand l’app lève une exception), mais il y a plus généraliste si tu veux gérer des logs en général. Dans une ancienne boîte, on avait par exemple un système basé sur fluentbit/ES qui était segmenté par type de logs, dont un type pour les erreurs applicatives en prod.

Bricoler avec des grep et cie. tout le temps, ça va bien 5 minutes

Ça fait longtemps que je n’ai plus touché ce genre de trucs côté administration, mais je sais qu’il y a des solutions qui permettent de traiter des fichiers de logs pré-existants, en plus d’une intégration « temps réel » à base d’évènements – donc utilisables pour un one shot si leur utilisation n’est pas trop complexe.

Dans tous les cas, « un seul fichier de logs avec des enregistrements d’origines diverses » c’est vite inutilisable.