|
| 1 | +--- |
| 2 | +title: Introduction à l'observabilité |
| 3 | +description: Concepts fondamentaux de l'observabilité |
| 4 | +weight: 9 |
| 5 | +default_lang_commit: 71833a5f8b84110dadf1e98604b87a900724ac33 |
| 6 | +cSpell:ignore: webshop |
| 7 | +--- |
| 8 | + |
| 9 | +## Qu'est-ce que l'observabilité ? |
| 10 | + |
| 11 | +L'observabilité est la capacité à comprendre l'état d'un système en examinant |
| 12 | +ses données sortantes, sans avoir besoin de connaître son fonctionnement |
| 13 | +interne. Elle permet non seulement de résoudre facilement les problèmes et |
| 14 | +d'appréhender les nouveaux "inconnus inconnus" mais également de répondre à la |
| 15 | +question "Pourquoi cela arrive-t-il ?" |
| 16 | + |
| 17 | +Pour pouvoir poser ce type de questions à votre système, votre application doit |
| 18 | +être correctement instrumentée, c'est-à-dire que votre code doit émettre : |
| 19 | +[des signaux](/docs/concepts/signals/) tels que |
| 20 | +[des traces](/docs/concepts/signals/traces/), |
| 21 | +[des métriques](/docs/concepts/signals/metrics/), et |
| 22 | +[des logs](/docs/concepts/signals/logs/). |
| 23 | + |
| 24 | +Une application est correctement instrumentée si les développeurs disposent de |
| 25 | +toutes les informations nécessaires pour corriger un problème et n'ont pas |
| 26 | +besoin d'ajouter une instrumentation supplémentaire. |
| 27 | + |
| 28 | +[OpenTelemetry](/docs/what-is-opentelemetry/) est le mécanisme permettant |
| 29 | +d'instrumenter le code des applications afin de rendre le système observable. |
| 30 | + |
| 31 | +## Fiabilité et métriques |
| 32 | + |
| 33 | +Le terme **télémétrie** fait référence aux données émises par un système et son |
| 34 | +comportement. Les données peuvent prendre la forme de |
| 35 | +[traces](/docs/concepts/signals/traces/), de |
| 36 | +[métriques](/docs/concepts/signals/metrics/), et de |
| 37 | +[logs](/docs/concepts/signals/logs/). |
| 38 | + |
| 39 | +La **fiabilité** répond à la question : "Est-ce que le service fait ce que les |
| 40 | +utilisateurs attendent de lui ?" Un système peut afficher un pourcentage de |
| 41 | +disponibilité de 100%, mais s'il ne répond pas à la demande de l'utilisateur |
| 42 | +(par exemple : ajouter une paire de chaussettes noires dans le panier à chaque |
| 43 | +fois qu'il clique sur "Ajouter au panier"), alors le système pourrait être |
| 44 | +considéré comme **peu** fiable. |
| 45 | + |
| 46 | +Les **métriques** sont un ensemble de données numériques collectées pour votre |
| 47 | +infrastructure ou votre application sur une période donnée. Le nombre d'erreurs |
| 48 | +système, le nombre d'erreurs sur les requêtes ainsi que l'utilisation mémoire |
| 49 | +d'un service donné sont quelques exemples de métriques. Pour plus d'informations |
| 50 | +sur les métriques et leur rôle dans OpenTelemetry, référez-vous à la page |
| 51 | +[Métriques](/docs/concepts/signals/metrics/). |
| 52 | + |
| 53 | +L'indicateur de niveau de service, également connu sous le nom de **SLI**, est |
| 54 | +un indicateur de fonctionnement d'un service qui est évalué côté utilisateur. La |
| 55 | +vitesse à laquelle une page Web se charge est un exemple de SLI. |
| 56 | + |
| 57 | +Les objectifs de niveau de service, communément appelés **SLO**, permettent de |
| 58 | +rendre compte à une organisation ou à d'autres équipes de la fiabilité d'un |
| 59 | +système. |
| 60 | + |
| 61 | +## Comprendre le traçage distribué |
| 62 | + |
| 63 | +Le traçage distribué vous permet d'observer les requêtes au fur et à mesure |
| 64 | +qu'elles se propagent au travers de systèmes distribués complexes. Il vous offre |
| 65 | +une meilleure visibilité sur la santé de votre application ou de votre système |
| 66 | +et vous permet de debugger un comportement qu'il est difficile de reproduire |
| 67 | +localement. Le traçage distribué est indispensable pour les systèmes distribués |
| 68 | +pour lesquels nous rencontrons souvent des problèmes aléatoires ou difficiles à |
| 69 | +reproduire localement. |
| 70 | + |
| 71 | +Pour comprendre le traçage distribué, vous devez comprendre le rôle de chacun de |
| 72 | +ses composants : les logs, les spans et les traces. |
| 73 | + |
| 74 | +### Logs |
| 75 | + |
| 76 | +Un **log** est un message horodaté émis par des services ou d'autres composants. |
| 77 | +Contrairement aux [traces](#les-traces-distribuées), ils ne sont pas |
| 78 | +nécessairement associés à une requête ou une transaction utilisateur en |
| 79 | +particulier. Presque tous les logiciels émettent des logs. Par le passé, les |
| 80 | +développeurs et les opérateurs se sont largement appuyés sur les logs pour |
| 81 | +comprendre le comportement des systèmes. |
| 82 | + |
| 83 | +Exemple de log : |
| 84 | + |
| 85 | +```text |
| 86 | +I, [2021-02-23T13:26:23.505892 #22473] INFO -- : [6459ffe1-ea53-4044-aaa3-bf902868f730] Started GET "/" for ::1 at 2021-02-23 13:26:23 -0800 |
| 87 | +``` |
| 88 | + |
| 89 | +Les logs, à eux seuls, ne suffisent pas pour suivre précisément l'exécution du |
| 90 | +code, car ils manquent souvent de contexte, comme l'origine exacte de leur |
| 91 | +déclenchement. |
| 92 | + |
| 93 | +Ils sont nettement plus utiles lorsqu'ils font partie d'un [span](#spans) ou |
| 94 | +lorsqu'ils sont mis en corrélation avec une trace ou un span. |
| 95 | + |
| 96 | +Pour plus d'informations sur les logs et leur rôle dans OpenTelemetry, |
| 97 | +référez-vous à la page [Logs](/docs/concepts/signals/logs/). |
| 98 | + |
| 99 | +### Spans |
| 100 | + |
| 101 | +Un **span** représente une unité de travail ou d'opération. Il retrace les |
| 102 | +actions effectuées par une requête, offrant une vue détaillée des événements qui |
| 103 | +se sont déroulés pendant l'exécution de l'opération. |
| 104 | + |
| 105 | +Un span contient un nom, des données de temps, |
| 106 | +[des messages de log structurés](/docs/concepts/signals/traces/#span-events), et |
| 107 | +[autres métadonnées (les attributs)](/docs/concepts/signals/traces/#attributes) |
| 108 | +pour fournir des informations sur l'opération qu'il suit. |
| 109 | + |
| 110 | +#### Attributs de span |
| 111 | + |
| 112 | +Les attributs de span sont des métadonnées attachées à un span. |
| 113 | + |
| 114 | +La table suivante liste des exemples d'attributs de span : |
| 115 | + |
| 116 | +| Clé | Valeur | |
| 117 | +| :-------------------------- | :--------------------------------------------------------------------------------- | |
| 118 | +| `http.request.method` | `"GET"` | |
| 119 | +| `network.protocol.version` | `"1.1"` | |
| 120 | +| `url.path` | `"/webshop/articles/4"` | |
| 121 | +| `url.query` | `"?s=1"` | |
| 122 | +| `server.address` | `"exemple.com"` | |
| 123 | +| `server.port` | `8080` | |
| 124 | +| `url.scheme` | `"https"` | |
| 125 | +| `http.route` | `"/webshop/articles/:article_id"` | |
| 126 | +| `http.response.status_code` | `200` | |
| 127 | +| `client.address` | `"192.0.2.4"` | |
| 128 | +| `client.socket.address` | `"192.0.2.5"` (le client passe par un proxy) | |
| 129 | +| `user_agent.original` | `"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"` | |
| 130 | + |
| 131 | +Pour plus d'informations sur les spans et leur rôle dans OpenTelemetry, |
| 132 | +référez-vous à la page [Spans](/docs/concepts/signals/traces/#spans). |
| 133 | + |
| 134 | +### Les traces distribuées |
| 135 | + |
| 136 | +Une **trace distribuée**, plus communément connu sous le nom de **trace**, |
| 137 | +enregistre les chemins pris par les requêtes (lancées par une application ou un |
| 138 | +utilisateur final) au fur et à mesure qu'elles se propagent au travers |
| 139 | +d'architectures multiservices, tels que des microservices ou des applications |
| 140 | +serverless. |
| 141 | + |
| 142 | +Une trace se compose d'un ou de plusieurs spans. Le premier span représente le |
| 143 | +span racine. |
| 144 | + |
| 145 | +Chaque span racine représente une requête, depuis son origine jusqu'à son |
| 146 | +aboutissement. Les spans présents sous le parent fournissent plus d'informations |
| 147 | +sur ce qui se passe pendant une requête (ou les étapes qui composent une |
| 148 | +requête). |
| 149 | + |
| 150 | +Sans traçage, il peut être difficile d'identifier pour un système distribué la |
| 151 | +cause première de problèmes de performance. Le traçage simplifie le débogage et |
| 152 | +la compréhension des systèmes distribués en décomposant le parcours des requêtes |
| 153 | +au fil de leur exécution dans le système. |
| 154 | + |
| 155 | +De nombreuses plateformes d'observabilité représentent les traces sous forme de |
| 156 | +diagrammes en cascade comme celui-ci : |
| 157 | + |
| 158 | + |
| 159 | + |
| 160 | +Les diagrammes en cascade permettent de visualiser la relation parent-enfant |
| 161 | +entre un span racine et ses spans enfants. Lorsqu'un span encapsule un autre |
| 162 | +span, on parle de relation imbriquée. |
| 163 | + |
| 164 | +Pour plus d'informations sur les traces et leur rôle dans OpenTelemetry, |
| 165 | +référez-vous à la page [Traces](/docs/concepts/signals/traces/). |
0 commit comments