Juste une courte note à propos de ce livre que j’ai utilisé dans le cadre de mon travail. Tout d’abord deux points positifs. Le premier est qu’il traite des sujets monitoring, alerting et reporting en général, c’est-à-dire indépendamment de l’outillage utilisé. C’est à la fois un point fort et un point faible puisqu’il pourrait être utile d’identifier des familles d’outils adaptés à chaque usage. Cette volonté de s’écarter des outils est assez rare pour être soulignée. Cette prise de recul permet d’introduire de la structure – je pense par exemple à l’organisation du monitoring en stacks qui est absolument cruciale –, des notions et des définitions générales et applicables en toutes circonstances – ou presque. Et on en vient au deuxième point fort, les définitions donc. Il est essentiel dans le cadre professionnel de s’appuyer sur des définitions précises qui permettent d’encadrer des concepts que la plupart des gens ont une fâcheuse tendance à confondre comme monitoring et alerting par exemple.
Dans les points faibles, il manque de fond et de cas pratiques. Si on ne connaît pas bien le sujet on terminera la lecture a peu près aussi démuni – j’exagère, on sera au moins armé de définitions et de concepts et c’est déjà beaucoup. L’écriture est totalement dépourvue d’âme: pas d’humour, pas d’anecdotes ce qui rend la lecture assez ennuyeuse. Ce n’est pas très grave, le point plus gênant concerne la structure du livre qui n’est vraiment pas claire et ne permettra pas de s’y référer aisément pour retrouver un élément. Plus important il manque des éléments dimensionnants permettant de structurer la mise en oeuvre d’une solution comme les 4 golden signals1.
- Latency: The time it takes to service a request, with a focus on distinguishing between the latency of successful requests and the latency of failed requests.
- Traffic: A measure of how much demand is being placed on the service. This is measured using a high-level service-specific metric, like HTTP requests per second in the case of an HTTP REST API.
- Errors: The rate of requests that fail. The failures can be explicit (e.g., HTTP 500 errors) or implicit (e.g., an HTTP 200 OK response with a response body having too few items).
- Saturation: How “full” is the service. This is a measure of the system utilization, emphasizing the resources that are most constrained (e.g., memory, I/O or CPU). Services degrade in performance as they approach high saturation.
Ou les 5 golden signals si on ajoute à cela la mesure de la disponibilité (availability) – j’ai écrit un article à ce sujet. Malgré ces réserves, il est tout de même utile de l’avoir sous la main pour s’y référer de temps en temps, mais ce n’est pas un incontournable – loin de là. Je lirais par contre avec intérêt un livre sorti récemment chez le même éditeur: Practical Monitoring: Effective Strategies for the Real World2.
Slawek Ligus, Effective Monitoring and Alerting, O′Reilly, 2012, 166 p, Amazon.