{"id":2311,"date":"2018-07-26T13:37:13","date_gmt":"2018-07-26T11:37:13","guid":{"rendered":"https:\/\/blog.alwaysdata.com\/?p=2311"},"modified":"2020-02-11T15:29:06","modified_gmt":"2020-02-11T14:29:06","slug":"les-logs-personnalises","status":"publish","type":"post","link":"https:\/\/blog.alwaysdata.com\/fr\/2018\/07\/26\/les-logs-personnalises\/","title":{"rendered":"Les logs personnalis\u00e9s"},"content":{"rendered":"

Dernier article de notre s\u00e9rie consacr\u00e9e aux changements apport\u00e9s r\u00e9cemment \u00e0 notre reverse-proxy<\/em>. Apr\u00e8s le pare-feu applicatif<\/a> et la gestion du Cache HTTP<\/a>, nous vous pr\u00e9sentons ici la mise en place des logs personnalis\u00e9s<\/em>.<\/p>\n

\"Log<\/div>\n

Logs d\u2019upstreams<\/em><\/h2>\n

Chez alwaysdata, un upstream<\/em> est le serveur HTTP que notre proxy va interroger dans le but de servir une de vos pages \u00e0 un visiteur. L\u2019upstream peut \u00eatre soit votre application si elle sert un serveur HTTP, soit un serveur tiers comme Apache<\/em> ou uWSGI<\/em>.<\/p>\n

Tous les messages \u00e9mis par un upstream<\/em> sur les flux standards1)<\/sup><\/a><\/span><\/span> sont d\u00e9sormais \u00e9crits dans un fichier, accessible dans le r\u00e9pertoire ~\/admin\/logs\/sites\/<\/code>. Ces logs offrent aux d\u00e9veloppeurs et DevOps des applications des informations pr\u00e9cieuses sur le monitoring ou le d\u00e9bogage. Dans le cas d\u2019un upstream personnalis\u00e9<\/em> (comme un service Node.js), ils vont vous permettre d\u2019obtenir les lignes de sorties de votre application, et donc vous faciliter la maintenance, comme en cas de bug au d\u00e9marrage.<\/p>\n

L\u2019ensemble des messages de tous les upstreams<\/em> d\u2019un compte alwaysdata<\/em> sont \u00e9crits dans le m\u00eame fichier. Chaque upstream est identifiable par son PID<\/code>2)<\/sup><\/a><\/span><\/span>. Cet identifiant est repr\u00e9sent\u00e9 entre crochets apr\u00e8s la date : [14\/Jul\/2018:10:04:21 +0200] [PID]<\/code>. Lorsqu\u2019un upstream est termin\u00e9\u200a\u2014\u200acomme quand il demeure inoccup\u00e9 trop longtemps\u200a\u2014\u200ale PID affich\u00e9 dans le fichier de log sera probablement diff\u00e9rent apr\u00e8s son red\u00e9marrage. Afin de d\u00e9terminer la correspondance entre upstream et PID et vous permettre de vous y retrouver, deux lignes sont \u00e9crites \u00e0 la suite :<\/p>\n

[14\/Jul\/2018:10:04:21 +0200] Upstream starting: \/commande\/d\u00e9marrant\/votre\/upstream ...\n[14\/Jul\/2018:10:04:21 +0200] Upstream started PID: 12345\n<\/code><\/pre>\n
Logs d\u2019acc\u00e8s<\/h2>\n
Vous avez d\u00e9sormais la possibilit\u00e9 de choisir le nom commun aux fichiers de logs d\u2019acc\u00e8s HTTP. Pour effectuer cette modification, rendez-vous dans Sites \u2192 Modification \u2192 Logs<\/em>.<\/p>\n
\"Capture<\/p>\n
Vous avez la possibilit\u00e9 de changer le format des lignes de sorties. Si vous devez traiter ces fichiers automatiquement via un parser<\/em> ou un script, le format des logs d\u2019acc\u00e8s personnalis\u00e9 vous permet d\u2019obtenir des fichiers dont le format sera compatible avec votre flux de donn\u00e9es. Ce champ accepte aussi bien les noms de variables entre accolades {}<\/code>, qui seront substitu\u00e9es \u00e0 leurs valeurs lors de la sortie ; que les caract\u00e8res libres. La syntaxe utilis\u00e9e et les variables disponibles sont indiqu\u00e9es dans notre page de documentation des logs<\/a>.<\/p>\n
Le format par d\u00e9faut est le suivant :<\/p>\n
{request_hostname} {client_ip} - - [{completion_date:{%d\/%b\/%Y:%H:%M:%S %z}}] {request} {status} {response_size} {referer} {user_agent}\n<\/code><\/pre>\n
En sortie, cette cha\u00eene retourne le r\u00e9sultat suivant :<\/p>\n
sandbox.alwaysdata.net 127.0.0.1 - - [16\/Jul\/2018:12:04:07 +0200] \"GET \/wp\/ HTTP\/1.1\" 200 55380 \"-\" \"curl\/7.47.0\"\n<\/code><\/pre>\n
Pour personnaliser le format, en sp\u00e9cifiant le protocole utilis\u00e9, le temps \u00e9coul\u00e9 pour r\u00e9pondre \u00e0 la requ\u00eate et quelques cha\u00eenes de caract\u00e8res, vous pourriez utiliser la syntaxe de formatage suivante :<\/p>\n
[{completion_date:{%d\/%b\/%Y:%H:%M:%S %z}}] protocole : {protocol} {request} dur\u00e9e = {duration} secondes\n<\/code><\/pre>\n
Pour obtenir la sortie suivante :<\/p>\n
[16\/Jul\/2018:12:04:07 +0200] protocole : \"https\" \"GET \/wp\/ HTTP\/1.1\" dur\u00e9e = 0.134 secondes\n<\/code><\/pre>\n
\n
Avec des lignes de logs d\u2019acc\u00e8s compl\u00e8tement personnalisables, ainsi qu\u2019un debug d\u2019upstream facilit\u00e9, nous esp\u00e9rons vous faciliter encore la mise en production et la surveillance de vos services sur les plateformes d\u2019alwaysdata<\/em>.<\/p>\n
Ce billet cl\u00f4t donc cette s\u00e9rie sur les modifications li\u00e9es au proxy<\/em> de notre infrastructure. Nous construisons ce service pour vous et avec vous, et nous sommes toujours \u00e0 votre \u00e9coute. N\u2019h\u00e9sitez pas \u00e0 nous laisser un commentaire ou \u00e0 nous contacter si certaines fonctionnalit\u00e9s vous manquent !<\/p>\n
\"jin<\/div>\n
 
Notes<\/span>[+<\/a>]<\/span><\/p><\/div> 
 \n\n
Notes<\/caption> 
 \u2191<\/span>1<\/a><\/th> stdout<\/code> et stderr<\/code><\/td><\/tr>\n\n
 \u2191<\/span>2<\/a><\/th> Process IDentifier<\/a><\/td><\/tr>\n\n <\/tbody> <\/table> <\/div><\/div>