Written by David Testé

Dernier article de notre série consacrée aux changements apportés récemment à notre reverse-proxy. Après le pare-feu applicatif et la gestion du Cache HTTP, nous vous présentons ici la mise en place des logs personnalisés.

Logs d’upstreams

Chez alwaysdata, un upstream est le serveur HTTP que notre proxy va interroger dans le but de servir une de vos pages à un visiteur. L’upstream peut être soit votre application si elle sert un serveur HTTP, soit un serveur tiers comme Apache ou uWSGI.

Tous les messages émis par un upstream sur les flux standards¹⁾ sont désormais écrits dans un fichier, accessible dans le répertoire ~/admin/logs/sites/. Ces logs offrent aux développeurs et DevOps des applications des informations précieuses sur le monitoring ou le débogage. Dans le cas d’un upstream personnalisé (comme un service Node.js), ils vont vous permettre d’obtenir les lignes de sorties de votre application, et donc vous faciliter la maintenance, comme en cas de bug au démarrage.

L’ensemble des messages de tous les upstreams d’un compte alwaysdata sont écrits dans le même fichier. Chaque upstream est identifiable par son PID²⁾. Cet identifiant est représenté entre crochets après la date : [14/Jul/2018:10:04:21 +0200] [PID]. Lorsqu’un upstream est terminé — comme quand il demeure inoccupé trop longtemps — le PID affiché dans le fichier de log sera probablement différent après son redémarrage. Afin de déterminer la correspondance entre upstream et PID et vous permettre de vous y retrouver, deux lignes sont écrites à la suite :

Logs d’accès

Vous avez désormais la possibilité de choisir le nom commun aux fichiers de logs d’accès HTTP. Pour effectuer cette modification, rendez-vous dans Sites → Modification → Logs.

Vous avez la possibilité de changer le format des lignes de sorties. Si vous devez traiter ces fichiers automatiquement via un parser ou un script, le format des logs d’accès personnalisé vous permet d’obtenir des fichiers dont le format sera compatible avec votre flux de données. Ce champ accepte aussi bien les noms de variables entre accolades {}, qui seront substituées à leurs valeurs lors de la sortie ; que les caractères libres. La syntaxe utilisée et les variables disponibles sont indiquées dans notre page de documentation des logs.

Le format par défaut est le suivant :

En sortie, cette chaîne retourne le résultat suivant :

Pour personnaliser le format, en spécifiant le protocole utilisé, le temps écoulé pour répondre à la requête et quelques chaînes de caractères, vous pourriez utiliser la syntaxe de formatage suivante :

Pour obtenir la sortie suivante :

Avec des lignes de logs d’accès complètement personnalisables, ainsi qu’un debug d’upstream facilité, nous espérons vous faciliter encore la mise en production et la surveillance de vos services sur les plateformes d’alwaysdata.

Ce billet clôt donc cette série sur les modifications liées au proxy de notre infrastructure. Nous construisons ce service pour vous et avec vous, et nous sommes toujours à votre écoute. N’hésitez pas à nous laisser un commentaire ou à nous contacter si certaines fonctionnalités vous manquent !