Optimisation du volume de logs générés

[thbar]

Notre usage AppSignal est stable côté APM, mais croissant sur la partie "logging".

Les options sont:

1. accepter l'upgrade (passage à 63€ sur le logging)
2. travailler un peu à diminuer le taux de logs

De façon générale, même si on accepte l'option 1) (qui me va parfaitement à court terme), on aura intérêt à surveiller la taille des logs générés, car:

• le fait de logger (même hors AppSignal) consomme malgré tout de la performance petit à petit, à une certaine échelle (IO, CPU) ça peut être problématique
• laisser trop de logs en place (qui ne seraient pas vraiment nécessaires au débugging après coup) finit par être une forme de dette technique en soit
• ça peut devenir un centre de coût plus important dans le temps que l'upgrade considérée ici (ex: changement de trafic important chez nous, changement de politique de pricing, etc)

Il est important en review à une certaine échelle de considérer le volume de logs générés, sans pour autant s'interdire de logger évidemment (il faut garder une capacité à regarder un historique de logs en cas de besoin, pour analyser un souci opérationnel).

Donc je crée ce ticket pour qu'on en parle en équipe @etalab/transport-tech, même si j'imagine qu'on va probablement accepter l'upgrade pour l'instant.

[AntoineAugusti]

Actuellement on log les HTTP user-agent (ça se configure) et les requêtes proxy, ça fait beaucoup de bruit.

On pourrait déjà retirer ça et enlever un bon paquet de lignes

[thbar]

En regardant de plus près je vois d'autres candidats (du type beaucoup de 404 sur le GBFS par exemple), aussi j'essaye de récupérer les logs sur une journée représentative, pour grouper et optimiser ça, si c'est pas trop galère (pas gagné).

Je supprimerai de toute façon les logs proxy, vu que ça fait effectivement du volume.

[thbar]

(j'ai posé la question à CleverCloud)

[thbar]

@AntoineAugusti a fouillé aussi, et partage aujourd'hui une quantification de ce que j'ai décrit plus haut ("beaucoup de 404 sur le GBFS"):

On fait 1M de requêtes 404 / jour actuellement sur prod-site et 1.1M de requêtes en 200.

En regardant rapidement il y a une bonne dose d'apps zombies qui tapent dans les anciennes URLs de conversions GBFS :face_with_rolling_eyes: et d'autres sur des URLs de download de ressources qui n'existent pas (on a des URLs de download sur notre domaine quand la source est en HTTP et on 404 si c'est du HTTPS)
clever logs --alias prod-site | grep "method=GET path=/gbfs" est assez déprimant
1M de lignes de logs par jour pour du 404 pour ça c'est dommage

En lien avec les changements récents:

• État des lieux des traitements GBFS réalisés #3455
• Suppression de l'application gbfs #4131
• État des lieux des traitements GBFS réalisés #3455
• GBFS : suppression des conversions VCub et V'Lille #4005

Réflexion à avoir sur comment couper les services, améliorer la communication quand on le fait (ou quand on les fait évoluer, ce qui inclut le versioning), authentification autour si besoin (comme le font IDFM par exemple etc).

[thbar]

Je prends en main la suite du traitement, j'ai pu réaliser un script qui me donne une idée non ambiguë d'où aller optimiser, ce qui est essentiel sur ce genre de cas.

[thbar]

Il y a eu réduction du volume sur la partie proxy (#4440), on peut garder ouvert pour avoir ça en tête.