La première chose à regarder sont les métriques exposées par votre serveur HTTP. La plupart des serveurs aujourd’hui utilisent plusieurs threads (appelé souvent un threadpool). Ces serveurs ont également parfois des queues internes (c’est le cas de Netty par exemple). Récupérer les métriques de ces composants est un bon début.

Par exemple, savoir combien de threads sont utilisés ou au repos peut être intéressant. Si le serveur HTTP utilise une queue interne, connaître la taille de cette queue set très important: si elle est au dessus de zéro pendant une certaine durée, voir augmente, c’est probablement que votre serveur HTTP n’arrive pas à traiter assez rapidement l’ensemble des requêtes reçues.
Bref, ces métriques permettent d’avoir une information globale sur la santé de votre serveur HTTP.

Il est important d’exposer également des métriques sur les requêtes HTTP reçues par votre serveur. On veut généralement savoir deux choses:

Parfois, certains outils de monitoring vous permettent d’obtenir ces deux métriques en une seule fois. Commençons par le nombre de requêtes HTTP reçues.

Nombre de requêtes

Nous appelerons cette métrique http_request_count. La valeur de cette métrique est donc le nombre de requêtes reçues par votre serveur. Mais reçues par quoi ? Nous voulons compter le nombre de requêtes:

En effet, je veux savoir précisément comment mon serveur web est utilisé. Si les compteurs de requêtes étaient mélangés, il serait impossible de savoir si un endpoint est plus utilisé qu’un autre par exemple.

Cela permet aussi de voir précisément les fonctionnalités de votre produit qui sont utilisées (ou non).
Notre métrique aura donc deux labels: path et method. On pourra donc avoir des statistiques pour chaque combinaison de labels, et des statistiques globales en les additionant par exemple.

Notre métrique finale ressemblera à quelque chose comme (au format Prometheus par exemple) http_request_count{path="/foo", method="get"} 1000, 1000 étant un compteur (et donc en croissance permanente). Cette métrique peut se traduire "A cet instant, mon application a reçu 1000 requêtes sur le path /foo en `get`". Comme vous le voyez, les labels permettent d’être précis.

La majorité (totalité ?) des produits de monitoring savent convertir un compteur en débit. Par exemple, si à temps = 10 j’ai ma métrique qui vaut 1000, et à temps = 20 ma métrique vaut 2000, j’ai reçu en 10 secondes 1000 requêtes. J’ai donc à peu près 100 requêtes par seconde sur ce endpoint.
Travailler avec des compteurs n’est donc pas un problème.

Mais il y a quand même ici quelques pièges, dans lesquels je tombe d’ailleurs régulièrement.

404 not found

Un exemple vécu: votre application a des métriques aux petits oignons. Chaque path de votre API a sa métrique, parfait.

Sauf qu’un petit malin se met à spam votre API sur des url inexistantes, du genre /azeija ou azijazrijaija. Chaque appel crée une nouvelle métrique. Cela cause plusieurs problèmes:

En gros, quelqu’un peut DDOS votre outil de monitoring voir votre application en vous envoyant des tonnes de requêtes sur des chemins aléatoires.

La solution est de détecter les 404, pourquoi pas log l’url non trouvée, et générer une métrique comptant le nombre de 404 au niveau global et non par path. De cette façon, vous ne créez pas de métriques inutiles.

Variables dans les url

Problème équivalent mais légèrement différent.

Vous avez une API REST permettant de récupérer une ressource par ID, par exemple via un GET /my-resource/ID. Voulez vous vraiment générer une métrique par ressource ou globalement pour ce endpoint ? Vous voulez 99 % du temps la seconde option pour vos métriques (je n’aborderai pas le tracing ici).

Si vous ne faites pas attention, vous aurez des métriques avec path="my-resource/3a189cc2-ef21-11eb-abf6-0bf0708be395,path="my-resource/42b6662a-ef21-11eb-bf8c-37a36554f35c…​ Bref, il vaudrait mieux grouper tout cela dans une seule métrique ayant path="my-resource/ID" non ?

Donc pareil, selon les langages c’est quelque chose de facile ou non à paramétrer, mais c’est vraiment quelque chose à ne pas oublier.

Temps d’exécution des requêtes

Maintenant qu’on mesure correctement l’utilisation de notre API, nous voulons savoir le temps d’exécution des requêtes. Appelons cette métrique http_request_duration.
Nous aurons pour commencer les mêmes labels que notre métrique précédente (path et method), ce qui nous permet là aussi d’avoir une métrique unique pour chaque combinaison de labels. Les mêmes pièges seront à éviter pour ces labels, en particulier le path.

Les librairies de monitoring exposent généralement les temps d’exécution de deux manières.

La première consiste à rajouter un label appelé par exemple percentile à chaque métrique. Nous pourrions avoir par exemple pour un path (/foo) et une méthode (get) les métriques suivantes exposées par l’application:

Comme vous le voyez, le label percentile rajoute une indication sur le pourcentage de requêtes s’exécutant en un temps inférieur à la valeur de la métrique (la valeur de la métrique étant donc un temps d’exécution). Vous pouvez généralement configurer les percentiles voulus (99, 98, 75, 50 …​), et détecter des problèmes de performances en vous basant sur ces métriques.

La seconde manière, utilisée généralement par des outils comme Prometheus, est la suivante:

Vous avez compris le principe: le représente une durée, et on compte pour chaque valeur de le le nombre de requêtes s’exécutant dans un temps inférieur à cette durée. Cette façon de faire est intéressante, car elle permet de facilement additionner ces métriques si vous avez plusieurs instances de votre application (ce qui n’est pas possible avec les percentiles). La difficulté est par contre de définir des intervalles pertinents.

Il y a quand même ici une autre question à se poser: on veut mesurer une durée, mais quand la mesure doit-elle commencer (et se terminer) dans votre application ? Une application web est généralement composée de plusieurs "étages" (ou middlewares, interceptors…​), chaque étage étant responsable d’un traitement sur la requête. On peut imaginer par exemple:

→ serveur web → déserialisation → routing → authentification → action à réaliser

Vous devez essayer de mesurer le plus de choses possibles, et donc commencer la mesure le plus tôt possible. En effet, si vous commencez la mesure à la fin de la chaine, une lenteur sur l’étage précédent ne sera pas détectée.
Mais vous allez à un moment arriver à la limite de votre framework ou outil, et il y aura toujours une partie qui ne sera pas mesurée. C’est pour cela qu’il est également très intéressant d’avoir le temps d’exécution des appels remonté également par un load balancer devant votre application par exemple, ou par vos applications clientes quand cela est possible. Ces clients de l’application pourront mesurer le temps réel que met votre service à répondre.

labels supplémentaires

Vous aurez sur vos métriques en réalité d’autres labels, comme par exemple host pour l’hostname où l’application tourne, environment dont la valeur peut être prod, preprod…​ C’est à vous de voir. L’idée est d’avoir des labels pertinents pour que vous puissez ensuite facilement exécuter des requête sur vos métriques, et identifier précisément quelle instance d’une application pose problème.

Cet article contient déjà beaucoup de choses, et nous n’avons vu que deux métriques. Une métrique indispensable à exposer est également le nombre de réponses HTTP, par path, method, et code HTTP. Par exemple:

On compte ici le nombre de réponses HTTP, et il devient facile de détecter une augmentation d’erreurs grâce au label status.

Et voilà pour la partie HTTP !