Améliorer l'observabilité avec les métadonnées

Les métadonnées sont omniprésentes dans les technologies de l'information. La première description des « métadonnées » pour les systèmes informatiques aurait été notée par David Griffel et Stuart McIntosh du MIT en 1967. Initialement, l'objectif principal des métadonnées était de trouver l'emplacement physique des données provenant de cartes perforées et de bandes sur une étagère et, plus tard, sur des lecteurs de disque et des dossiers, à mesure que la technologie numérique progressait. Dans une base de données de télémétrie presque illimitée, l'emplacement physique des éléments a tendance à être moins important pour l'utilisateur, même si nous pouvons considérer des éléments tels que les identifiants de compte et les environnements nommés (par exemple, QA, DEV, Prod) comme proxies logiques pour l'organisation physique.

À la base, les données télémétriques ne sont en réalité qu'une série de chiffres.  Certains chiffres représentent des décomptes, des grandeurs et parfois une chaîne qualitative qui désigne une condition telle que OK, PASS, FAIL.  Certaines valeurs sont supérieures à ce qu'elles étaient il y a une heure et d'autres inférieures.  C'est la nature des données de séries chronologiques dont New Relic est principalement constitué.  Sans une certaine capacité à analyser les données de télémétrie en comparant et en contrastant des groupes semblables ou différents, notre capacité à prendre des décisions data-driven est presque inexistante.  Au niveau le plus élevé, tous les agents standards de New Relic regrouperont au moins la télémétrie sous un nom et un identifiant d'application communs.  C'est nécessaire mais pas suffisant pour l'observabilité moderne.  Ce blog explique en quoi les métadonnées sont utiles, comment les métadonnées peuvent être gérées dans New Relic et à quoi peut ressembler une norme simple pour les métadonnées d'entité.

Pourquoi nous avons besoin des métadonnées

Au plus haut niveau, les métadonnées vous aideront à :

• Trouver l'entité et la télémétrie lorsque vous savez quelles caractéristiques vous intéressent, mais que vous ne connaissez peut-être pas toutes les entités ou tous les enregistrements associés (ou qu'ils sont trop nombreux pour être analysés comme un seul grand ensemble).
• Visualiser l'entité et la télémétrie par caractéristiques d'intérêt.  Cela permet de voir la taille relative des groupes et de visualiser les anomalies lorsque la taille des groupes ne semble pas correcte.
• Acheminer vers et répondre aux workflows en fonction de la balise des entités associées.
• Planifier les activités et évaluer la conformité des différentes entités (par exemple, s'assurer que tous les serveurs d'une équipe sont mis à niveau vers la dernière version de Linux)
• Consigner les KPI commerciaux et organisationnels de haut niveau pour connaître les domaines d'activité qui fonctionnent bien ou ceux qui doivent être améliorés.

Un exemple de cas d'utilisation de l'observabilité avec des balises dans le monde réel est un scénario dans lequel nous remarquons qu'une application génère soudainement un nombre élevé d'erreurs.  Nous avons peut-être déjà un workflow d'incidents configuré avec le schéma de marquage correct qui nous permet de définir :

• l'équipe qui est propriétaire cette entité (contactez-la si nécessaire)
• les personnes responsables du référentiel de code (invitez-les dans une salle de crise pour l'incident )
• la région opérationnelle impactée (impact commercial de triage, SLA/conformité régional)
• l'unité commerciale est impactée (trier l'impact commercial, coût horaire de l'incident)

Approche 1 : balisage pour l'organisation de l'entité

Dans certains cas, les balises sont automatiquement appliquées à l'entité à partir des sources suivantes :

• Métadonnées du compte
• Contexte de l'agent New Relic
• Contexte de l'agent OpenTelemetry
• Contexte de l'agent d'infrastructure

Il existe plusieurs façons d'afficher et d'interagir avec les balises dans New Relic. La plus simple est de cliquer sur l'icône des balises dans l'une de nos vues organisées comme APM. Cette icône vous montre également le nombre de balises associées.

Vous pouvez ensuite visualiser toutes les balises et même en ajouter manuellement.

Pour une vue plus globale, vous pouvez utiliser l'explorateur d'entités pour filtrer et regrouper par entités (y compris celles intégrées comme « type d'entité »).

Pour les types d'entités standard comme APM, il est possible d'intégrer des balises dans les requêtes New Relic Query Language (NRQL). Cela comble l'écart entre la simple organisation des données et leur analyse. Par exemple, la requête suivante peut nous indiquer le nombre d'erreurs de transaction associées à des équipes spécifiques. Les balises disponibles dans NRQL sont précédées de « tags » :

FROM TransactionError select count(*) facet tags.Team

Le résultat apparaîtra comme n'importe quelle autre facette d'attribut.

Il est clair que l'une des utilisations les plus précieuses des balises est de rendre les données plus exploitables.  Comme indiqué ci-dessus, l'idée de « routage » des incidents ou de l'attention peut être mise en œuvre plus efficacement lorsque nous avons quelques connaissances quant au propriétaire du code ou sur la manière de traiter les problèmes.

La plupart des équipes auront tendance à s'arrêter après avoir balisé le nom de leur équipe et leur environnement, mais il n'y a aucune raison pour que nous ne puissions pas ajouter plus de contexte, comme une balise « canal d'aide ».

En plus d'être visualisées, elles peuvent être incluses dans la charge des incidents incluse dans le workflow d'incidents New Relic. Vous trouverez plus d'informations sur les différentes utilisations des balises dans notre documentation.

Approche 2 : attribut personnalisé pour des données dynamiques

Il arrive parfois que les balises, par nature centrées sur l'entité, ne puissent pas permettre la différenciation granulaire requise entre les enregistrements de télémétrie. Lorsque nous avons besoin de catégoriser dynamiquement une unité de télémétrie individuelle, nous pouvons réfléchir aux attributs personnalisés. Ces attributs sont souvent utilisés pour capturer des caractéristiques spécifiques de l'expérience d'un utilisateur ou plus généralement « l'état » d'une application ou d'un système à un instant donné pour une requête donnée. Voici des exemples de données d'état dynamiques :

• Contexte utilisateur
  • ID de l'utilisateur
  • Localisation de l'utilisateur
  • Autres informations sur la cohorte d'utilisateurs (de base ou professionnelle)
• Contexte de la demande
  • Produit ou sous-produit utilisé
  • Type de produit 
    • Type de police d'assurance (voiture, moto, camping-car)
    • Type de vidéo en streaming (science-fiction, comédie, etc.)
    • Informations détaillées sur l'appareil utilisateur (version Android, etc.)

Même si les attributs personnalisés semblent répondre à nos besoins en métadonnées, nous devons prendre en compte de quelques inconvénients, notamment :

• Leur gestion n'est pas centralisée et se fait au niveau du code.
• Il n'est pas rare d'accumuler de nombreux attributs obsolètes.
• Chaque attribut ajouté entraîne des coûts d'ingestion de télémétrie supplémentaires.
• Un attribut de cardinalité très élevé peut engendrer des problèmes de performances et avoir un impact sur les requêtes.
• Limites de compte (par exemple, la création d'un identifiant unique pour chaque demande effectuée par une application n'est pas un fonctionnement viable à long terme).

L'APM, le navigateur et l'agent mobile New Relic ont tous des capacités intégrées pour l'injection des attributs personnalisés. Vous trouverez plus de détails dans notre documentation.

Approche 3 : tableaux de recherche pour des informations ad hoc

Il ne sera jamais possible de capturer toutes les métadonnées utiles au moment de l'instrumentation.  De nombreuses métadonnées ont un cycle de vie éphémère (lié au projet). Dans certains cas, nous ne souhaitons peut-être pas avoir à appliquer des normes de métadonnées pour des dizaines de balises ou d'attributs qui peuvent être utilisés principalement pour des analyses ad hoc. New Relic a une solution pour cela. Il est possible de télécharger un fichier CSV dans New Relic comme table de recherche. Ce fichier CSV peut ensuite être utilisé comme n'importe quel autre espace de nommage de télémétrie (par exemple, log, transaction, SystemSample). En utilisant la syntaxe de jointure de NRQL, vous pouvez relier n'importe quel contenu du CSV à n'importe quelle télémétrie existante, si vous disposez d'une clé commune. Cela signifie que tant que vous appliquez un ou deux éléments de métadonnées de très haut niveau, vous pouvez y associer des recherches ad hoc selon vos besoins. Un exemple concret est celui d'un client qui utilise une balise APP_ID à l'échelle de l'organisation. Cette balise est utilisée pour tout, de l'APM à l'infrastructure, en passant par la métrique de streaming AWS. Dans ce contexte, APP_ID est un concept plus logique qui fait référence à toutes les application et les infrastructures associées qui composent un service métier logique tel que la « gestion des stocks ». Cela peut être particulièrement utile pour faire le suivi de projets.

Supposons que l'organisation dispose d'un fichier CSV sous le nom « migration_status » qui fait le suivi l'état de la migration vers le cloud de certaines applications.

Nous pouvons afficher le contenu de n'importe quelle table de recherche en utilisant le NRQL suivant :

FROM lookup(migration_status) SELECT *

Si nous avons appliqué la balise APP_ID de base, nous pouvons produire des rapports détaillés sur les hôtes migrés liés à l'équipe qui en est propriétaire.

FROM SystemSample JOIN (FROM lookup(migration_status) SELECT count(*) where MIGRATED = 'Yes' FACET APP_ID, TEAM limit max) ON APP_ID SELECT uniqueCount(hostname) as 'Hosts Migrated By Team' where APP_ID is NOT NULL facet TEAM  since 1 week ago

Un exemple simple de norme de métadonnées

Cette simple « norme » de marquage en cinq parties est formée à partir de diverses approches utilisées pour l'observabilité dans un certain nombre d'organisations. Une organisation peut la modifier et la développer considérablement, mais cela représente un ensemble de balises assez léger qui peut être utilisé pour démontrer la valeur des métadonnées dans votre organisation.