Dernier article de notre série consa­crée aux chan­ge­ments appor­tés récem­ment à notre reverse-proxy. Après le pare-feu appli­ca­tif et la ges­tion du Cache HTTP, nous vous pré­sen­tons ici la mise en place des logs per­son­na­li­sés.

Log GIF @Giphy

Logs d’upstreams

Chez always­da­ta, un ups­tream est le ser­veur HTTP que notre proxy va inter­ro­ger dans le but de ser­vir une de vos pages à un visi­teur. L’upstream peut être soit votre appli­ca­tion si elle sert un ser­veur HTTP, soit un ser­veur tiers comme Apache ou uWSGI.

Tous les mes­sages émis par un ups­tream sur les flux stan­dards1) sont désor­mais écrits dans un fichier, acces­sible dans le réper­toire ~/admin/logs/sites/. Ces logs offrent aux déve­lop­peurs et DevOps des appli­ca­tions des infor­ma­tions pré­cieuses sur le moni­to­ring ou le débo­gage. Dans le cas d’un ups­tream per­son­na­li­sé (comme un ser­vice Node.js), ils vont vous per­mettre d’obtenir les lignes de sor­ties de votre appli­ca­tion, et donc vous faci­li­ter la main­te­nance, comme en cas de bug au démar­rage.

L’ensemble des mes­sages de tous les ups­treams d’un compte always­da­ta sont écrits dans le même fichier. Chaque ups­tream est iden­ti­fiable par son PID2). Cet iden­ti­fiant est repré­sen­té entre cro­chets après la date : [14/Jul/2018:10:04:21 +0200] [PID]. Lorsqu’un ups­tream est ter­mi­né — comme quand il demeure inoc­cu­pé trop long­temps — le PID affi­ché dans le fichier de log sera pro­ba­ble­ment dif­fé­rent après son redé­mar­rage. Afin de déter­mi­ner la cor­res­pon­dance entre ups­tream et PID et vous per­mettre de vous y retrou­ver, deux lignes sont écrites à la suite :

Logs d’accès

Vous avez désor­mais la pos­si­bi­li­té de choi­sir le nom com­mun aux fichiers de logs d’accès HTTP. Pour effec­tuer cette modi­fi­ca­tion, ren­dez-vous dans Sites → Modification → Logs.

Capture d'écran de l'interface d'administration pourla configuration des logs par site

Vous avez la pos­si­bi­li­té de chan­ger le for­mat des lignes de sor­ties. Si vous devez trai­ter ces fichiers auto­ma­ti­que­ment via un par­ser ou un script, le for­mat des logs d’accès per­son­na­li­sé vous per­met d’obtenir des fichiers dont le for­mat sera com­pa­tible avec votre flux de don­nées. Ce champ accepte aus­si bien les noms de variables entre acco­lades {}, qui seront sub­sti­tuées à leurs valeurs lors de la sor­tie ; que les carac­tères libres. La syn­taxe uti­li­sée et les variables dis­po­nibles sont indi­quées dans notre page de docu­men­ta­tion des logs.

Le for­mat par défaut est le sui­vant :

En sor­tie, cette chaîne retourne le résul­tat sui­vant :

Pour per­son­na­li­ser le for­mat, en spé­ci­fiant le pro­to­cole uti­li­sé, le temps écou­lé pour répondre à la requête et quelques chaînes de carac­tères, vous pour­riez uti­li­ser la syn­taxe de for­ma­tage sui­vante :

Pour obte­nir la sor­tie sui­vante :


Avec des lignes de logs d’accès com­plè­te­ment per­son­na­li­sables, ain­si qu’un debug d’upstream faci­li­té, nous espé­rons vous faci­li­ter encore la mise en pro­duc­tion et la sur­veillance de vos ser­vices sur les pla­te­formes d’always­da­ta.

Ce billet clôt donc cette série sur les modi­fi­ca­tions liées au proxy de notre infra­struc­ture. Nous construi­sons ce ser­vice pour vous et avec vous, et nous sommes tou­jours à votre écoute. N’hésitez pas à nous lais­ser un com­men­taire ou à nous contac­ter si cer­taines fonc­tion­na­li­tés vous manquent !

jin yang handshake GIF by Silicon Valley @Giphy

Notes   [ + ]

1. stdout et stderr
2. Process IDentifier