Dans un monde où les systèmes distribués et les microservices sont omniprésents, il est devenu très difficile de vérifier le fonctionnement du système ou de suivre les erreurs. Dans cet environnement, de nombreux services doivent envoyer des données dans un format commun et les connecter pour analyser le système.
Opentelemetry (ci-après otel) est un cadre créé pour accroître l'observabilité des dernières tendances logicielles. Nous fournissons des API, des conventions, des kits d'outils, etc.
Mais même s'il ne s'agit que d'un seul service, il semble plus facile de visualiser les logs, et sa configuration n'est pas si difficile (tant que vous ne faites rien d'étrange...), donc ce n'est pas un problème. mauvaise idée de l'essayer.
Pour comprendre l'otel, vous devez connaître l'observabilité.
Bien que cela soit difficile à définir clairement, je pense que cela peut être défini comme la capacité de répondre à la question « Pourquoi est-ce arrivé ? »
Pour ce faire, le programme doit être « bien instrumenté ».
C'est une expression que vous rencontrerez souvent lors de la mise en œuvre d'Opentelementry. En coréen, cela signifie « mesure », mais vous pouvez penser que cela signifie bien mesurer les choses et les enregistrer.
Par exemple, plusieurs signaux (également appelés données de télémétrie) sont mesurés, et les journaux, traces et métriques appartiennent à ces signaux. (Ces signaux réapparaîtront plus tard)
Otel est indépendant des fournisseurs et des outils, il peut donc être largement utilisé. Il n’y a aucune obligation d’utiliser des backends d’observabilité. Vous pouvez utiliser des sources ouvertes qui répondent aux normes Otel.
Pour utiliser Otel, il vous suffit d'apprendre un peu (?) les concepts et l'API.
Vous devez apprendre les éléments qui composent Otel.
Traçage distribué
Journal, envergure, trace
Propagation de contexte
Signaux
Collectionneur
Il s'agit de suivre ce qui se passe lorsqu'une demande est faite dans un système distribué. C'est quelque chose qu'Otel prend au sérieux. Le système distribué fait référence à un système dans lequel une demande est complétée via le service A, le service B et le service C.
Le journal est le même journal que nous prenons toujours lors du codage. Il y a un horodatage donc il est écrit à ce moment-là. Cela aide beaucoup à interpréter le comportement du système.
Cependant, il est difficile de comprendre le code à partir du journal lui-même. Des informations plus contextuelles doivent être incluses. Le journal est plus utile lorsqu'il est lié à Span ou Trace.
Span est une unité d'action. Le nom d'une opération spécifique, les données temporelles et les journaux inclus dans le span ont des caractéristiques appelées attributs de span.
Par exemple, il possède des propriétés telles que http.request.method et url.path.
Le processus allant du début à la fin d’une demande est appelé une trace. Cette trace peut inclure des étendues provenant de plusieurs systèmes, et non d'un seul système.
La toute première travée s'appelle Root Span.
Habituellement représenté sous la forme d'un diagramme en cascade.
Continue de propager les informations contextuelles afin que les signaux et les traces associés puissent être connectés.
La propagation sérialise et désérialise cet objet d'information contextuelle, lui permettant de se déplacer entre les services et les processus. Dans les cas normaux, le propagateur TraceContext du W3C est utilisé.
Signal est un élément de collection d'Otel. Il y en a au total 4 : Log, Metric, Trace et Baggage.
Voici le journal mentionné ci-dessus. Il contient un message pris à une heure précise.
Il s'agit de données permettant de mesurer les chiffres qui doivent être mesurés dans le service. Par exemple, ce sont des éléments qui doivent être enregistrés pour mesurer des chiffres tels que le nombre de fois où quelque chose a été appelé et le niveau de remplissage de la file d'attente
.Identique à Trace mentionné ci-dessus.
Il s'agit d'informations qui se propagent comme un contexte via un magasin de valeurs clés. Il stocke principalement des informations supplémentaires telles que l'ID utilisateur.
Il s'appelle Opentelemetry Collector. Le collecteur est responsable de la réception des données de télémétrie de l'application, de leur traitement et de leur exportation vers le stockage de télémétrie.
Il est acceptable d'envoyer des données de télémétrie directement de l'application au stockage sans collecteur, mais il est préférable d'exécuter un collecteur et de laisser le traitement des données de télémétrie au collecteur, et l'application fait son propre travail.
L'utilisation d'un collecteur présente de nombreux avantages, tels que la possibilité de varier les configurations et d'effectuer un filtrage de queue de travée dans le collecteur.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!