New Relic Now Vous rêvez d'innover plus ? En octobre, faites de ce rêve une réalité.
Réservez votre place maintenant

Qu'est-ce qu'une entité et pourquoi synthétiser les données dans une entité ?

Une entité est tout ce qui a) rapporte des données à New Relic ou contient des données connexes auxquelles on a accès et b) envoie de la télémétrie marquée d'un identifiant d'entité unique. Il est important de se concentrer sur l'entité, car l'objectif de New Relic est non seulement de fournir un contexte d'observabilité pratique sur les objets centrés sur l'entreprise, mais aussi de les organiser facilement en systèmes logiques. Grâce aux informations détaillées fournies au niveau de l'entité, il devient plus facile d'obtenir un meilleur monitoring et de dépanner les systèmes complexes et modernes d'aujourd'hui.

Lorsque la télémétrie entre dans le pipeline de données de New Relic, il y a une tentative de classement du type de source de données et de marquage de cette télémétrie entrante avec des identifiants distincts (appelés « guids »), ce qui permet ensuite de faciliter la classification des données ingérées. New Relic dispose d'un ensemble de types d'entités standard qui sont utilisés pour catégoriser les données dans ce que l'on appelle des entités ; par exemple, APM, infrastructure, navigateur et mobile. 

Mais que se passe-t-il lorsque la télémétrie est envoyée en dehors des agents standard, en utilisant Flex, les API d'ingestion ou via OpenTelemetry, par exemple ? C'est là que la synthèse des entités entre en jeu.

La synthèse des entités est un processus basé sur la configuration qui génère dynamiquement des guids d'entité, sur la base de critères uniques contenus dans la télémétrie entrante. Les avantages du mappage des données télémétriques vers une entité sont les suivants :

  • Accès rapide à la télémétrie par le biais d'expériences curatives, y compris l'explorateur d'entités, les workloads, les niveaux de service, et toutes les autres fonctionnalités de la plateforme spécifiques aux entités.
  • Une vue standard qui peut être utilisée pour comparer les signaux provenant de plusieurs instances de la même entité.
  • Un ensemble standard de métriques récapitulatives/dorées qui représentent les indicateurs de performances clés (KPI) d'un type d'entité donné.
  • Les entités peuvent porter un tag avec plusieurs paires de valeurs clés pour faciliter le filtrage et le regroupement.
  • Les définitions des états d'alerte fournissent une vue intuitive de l'état de santé des entités, en fonction des conditions d'alerte configurées.

Exemple de télémétrie (forme brute)     

La capture d'écran ci-dessous montre des données personnalisées brutes où le type d'événement (eventType) est event, qui est dérivé de l'extraction, de l'analyse et de l'insertion de données via l'API Event.

Ces données n'ont pas encore de guids d'entité marqués, elles sont donc considérées comme étant non synthétisées et ne sont pas encore classées dans un type d'entité. L'attribut unique nodeUid ci-dessus peut cependant être utilisé comme identifiant primaire pour générer un guid. Nous fournirons plus d'informations à ce sujet un peu plus loin dans ce billet.

 

Les mêmes données peuvent facilement être visualisées dans un dashboard personnalisé. Vous trouverez ci-dessous un exemple du même événement personnalisé représenté sous forme de diagramme circulaire, et ciblant une dimension clé — state — qui peut être une métrique dorée intéressante à visualiser et/ou pour laquelle des alertes sont nécessaires.

Nous vous recommandons d'ajouter, quand vous le pouvez, le contexte pertinent aux données. En créant une entité, vous pouvez aligner ce type de données sur un type d'entité spécifique, et à terme, classer les données, de sorte qu'elles puissent être plus rapidement reconnues et associées à d'autres entités ou à la télémétrie dans New Relic.

Pour vous aider à définir les entités, New Relic a créé un référentiel public pour définir les types d'entités personnalisés et l'emplacement où se trouve un grand nombre des définitions créées par New Relic pour des outils courants tels que l'APM ou l'infrastructure :

https://github.com/newrelic/entity-definitions

 

Les étapes suivantes vous aideront à transformer la télémétrie brute (c'est-à-dire les données ingérées dans New Relic qui ne sont pas classées ou marquées d'un guid) en entités.

Synthèse de la télémétrie, étape par étape

Étape 1 : Cloner le référentiel public et créer une branche

Clonez ou dupliquez (fork) ce référentiel (repository) : https://github.com/newrelic/entity-definitions/entity-types, puis créez une branche. Dans ce référentiel, il y a des centaines d'autres définitions d'entités existantes. Nous vous recommandons d'examiner ces définitions pour vous y référer lors de la création de votre première définition d'entité. Cette documentation fournit également des informations détaillées sur les quatre fichiers nécessaires à la définition d'une entité : definition.yml, dashboard.json, golden_metrics.yml, et summary_metrics.yml.

Étape 2 : Définissez des règles de synthèse (definition.yml)

En utilisant comme exemple le type d'entité ext-solarwinds_server, la capture d'écran ci-dessous montre le fichier definition.yml (à gauche) et l'expérience résultante dans l'explorateur d'entités New Relic (à droite).

Le fichier definition.yml définit le type d'entité, ainsi que les règles qui déterminent comment les entités uniques doivent être générées. Les données reçues par New Relic sont vérifiées en les comparant à ces « règles de correspondance » et si la télémétrie entrante y est conforme, elle est automatiquement associée, ce qui crée un guid unique pour chaque ensemble de données. Dans l'exemple ci-dessus, l'identifiant unique (npm.nodeName) est le seul identifiant permettant de générer un guid d'entité unique. En outre, la stance (ou section) conditions définit deux conditions de filtrage qui indiquent le type d'événement de base où se trouve la télémétrie (correspondance partielle des chaînes sur solarwinds_) et un attribut spécifique utilisé pour filtrer davantage la télémétrie (npm.Category). En d'autres termes, l'équivalent NRQL suivant montre comment les guids sont générés en fonction des critères spécifiés :

SELECT uniques(npm.nodeId) FROM solarwinds_* where npm.Category = 2

Notez également la catégorie « other Entities » dans laquelle nous avons placé ce type d'entité. Tout type d'entité qui n'est pas natif de la plateforme New Relic est placé dans cette catégorie.

 

Autres configurations importantes dans le fichier de définitions :

  • Tags : il s'agit de paires de valeurs clés qui existent dans la télémétrie et qui peuvent être apposées sur chaque entité unique en tant que marqueurs.
  • entityExpirationTime : le délai après lequel l'entité disparaît de l'interface utilisateur si aucune donnée n'apparaît dans le laps de temps défini.
  • Alertable : indique si les entités générées permettent d'y joindre une alerte, et donc de modifier leur état.

Cycle de vie : si votre entité cesse de communiquer des données, combien de temps la plateforme New Relic doit-elle conserver l'entité présente ? La valeur par défaut est de huit jours, mais elle peut être ajustée en fonction du type d'entité.

Étape 3 : Définissez les métriques dorées (golden_metrics.yml)

Ce fichier est utilisé pour définir les métriques qui sont affichées dans la vue de synthèse de chaque entité unique (en cliquant dessus) et les requêtes qui les définissent. Il s'agit généralement des principaux indicateurs d'une entité donnée pour faire le suivi de l'état de santé et des performances globales.

Exemple de golden_metrics.yml

Étape 4 : Définissez les métriques récapitulatives (summary_metrics.yml) 

En utilisant le même type d'entité que précédemment comme exemple, le fichier summary_metrics.yml ici définit quelles métriques clés nous voulons voir apparaître dans la vue List de l'explorateur d'entités. Comme pour les métriques dorées, il s'agit d'importants KPI qui sont le plus utiles dans une vue instantanée. Ils sont généralement définis en 1-1 avec les métriques dorées. Toute télémétrie qui existe dans un ensemble de données peut être configurée en tant que métrique récapitulative.

Exemple de Summary_metrics.yml

Exemple de vue récapitulative

Cette vue est idéale pour comparer rapidement les instances de votre type d'entité les unes aux autres. La vue fournit également un état d'alerte, qui permet d'identifier rapidement les nœuds problématiques. Comme indiqué dans l'introduction, une fois que la plateforme New Relic reconnaît les données en tant que type d'entité et qu'au moins une alerte a été créée pour cette entité, l'état d'alerte de cette entité est visualisé à différents endroits de l'interface, comme le montre l'exemple ci-dessus.

 

Étape 5 : Définissez le dashboard récapitulatif (dashboard.json)

Enfin, un dashboard plus détaillé est défini et affiche toutes les métriques clés utiles au suivi des performances et de la santé globale d'un type d'entité donné. En règle générale, nous vous recommandons de créer ces dashboard à l'avance (sous Dashboards), puis de les exporter au format JSON et de nettoyer le JSON pour supprimer les identifiants de compte codés en dur et d'autres données spécifiques au compte. Un outil d'assainissement est inclus dans le référentiel entity-definitions pour faciliter cette opération. L'exemple ci-dessous peut vous servir de référence.

Exemple de dashboard.json

Exemple d'une vue de dashboard d'entité

Le schéma json du fichier dashboard.json est exactement le même que le schéma standard du dashboard New Relic. C'est ici qu'est défini un dashboard standard avec les signaux critiques pour une entité donnée. Cette vue fournit également l'état d'alerte de l'entité, le flux d'activité (activité d'alerte) et toutes les entités associées (par exemple, les services en amont et en aval).

 

Étape 6 : Vérifiez la branche et créez une demande de tirage

Une fois que les quatre fichiers sont validés/complétés, vous pouvez valider (commit) la branche, la pousser et créer une demande de tirage pour qu'elle puisse être fusionnée avec la branche principale (ou envoyer une demande de tirage contre votre fork). Le délai de révision et de fusion est généralement d'une à deux semaines.

 

Conclusion

Vous pouvez transformer en entités toutes les données qui sont entrées dans New Relic, même si elles ne sont pas classées ou marquées avec un guid d'entité. La synthèse de la télémétrie brute présente de nombreux avantages :

  • Le framework pour la création d'entités personnalisées est simple à utiliser, car il est basé sur la configuration.
  • Toute télémétrie envoyée à New Relic, y compris les événements ou les métriques, peut être synthétisée en entités pour assurer de meilleures expériences personnalisées.
  • Les données synthétisées (ou entités) permettent d'améliorer l'expérience générale en matière de visualisation et d'alerte sur les données télémétriques clés.
  • La possibilité de relier plusieurs entités associées et de corréler leurs états dans le temps. 

Lorsque vous disposez de plus d'informations détaillées au niveau de l'entité, vous pouvez plus facilement contrôler et dépanner votre système.