Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
Nouveaux types de données Relic : métriques, événement, log et trace (MELT)
La plateforme New Relic est construite autour des quatre types fondamentaux de données télémétriques que nous pensons nécessaires pour monitoring complète et efficace du système : métriques, événement, log et trace (souvent appelés "MELT" dans le secteur de l'observabilité).
Dans ce document, nous donnerons une explication assez technique de nos principaux types de données MELT, de leur structure et de la manière dont ils sont utilisés dans notre fonctionnalité. Vous pouvez utiliser la plupart de nos fonctionnalités sans avoir besoin de comprendre la structure de données sous-jacente. Mais une meilleure compréhension de cela peut vous aider à intégrer des données dans New Relic, à comprendre les données que vous voyez dans notre UI, ainsi qu'à interroger et à cartographier vos données.
Métriques
Tout d’abord, nous expliquerons la définition des métriques du point de vue de l’industrie monitoring, puis nous expliquerons comment New Relic gère les métriques.
Métriques dans l'industrie monitoring
Dans le secteur monitoring des logiciels, une métrique signifie une mesure numérique d'une application ou d'un système. Les métriques sont généralement rapportées selon un calendrier régulier.
Deux grands types de métriques sont :
Données agrégées. Par exemple : le nombre d'événements sur une durée d'une minute, ou la fréquence d'un événement par minute.
Un statut numérique à un instant donné. Par exemple : une lecture de la température du processeur ou un statut « % CPU utilisé ».
Les métriques sont relativement faciles à signaler et à stocker car un seul enregistrement peut représenter une plage de temps. Ils peuvent également s’agréger de plus en plus au fil du temps. Par exemple, les données par minute peuvent être « regroupées » en agrégations par heure après un certain temps, et éventuellement être regroupées en une agrégation par jour. Cette approche est efficace pour le stockage de données à long terme.
Les métriques sont une solution puissante pour stocker des données à long terme et comprendre les tendances au fil du temps. L’un des inconvénients potentiels est qu’il peut être difficile de réaliser une analyse détaillée de données plus anciennes qui ont été agrégées au fil du temps ; lorsque des détails très précis sont requis sur des actions importantes spécifiques, des données d’événement peuvent être utilisées.
Métriques à New Relic
Conceptuellement, les « métriques » constituent une catégorie large et générale. New Relic dispose de différentes manières de mesurer et de signaler des métriques, mais, en pratique, lorsque vous utilisez l'UI de New Relic, vous n'aurez généralement pas besoin de comprendre exactement comment cela se produit. Dans notre documentation, nous ferons généralement simplement référence aux « métriques », quelle que soit la manière dont ces données sont rapportées, à moins qu'il n'y ait une raison pour laquelle vous ayez besoin d'en savoir plus (comme comprendre comment interroger vos données).
Voici quelques-unes des façons dont les métriques sont signalées et stockées sur la plateforme New Relic :
Dans le secteur monitoring, les métriques « dimensionnelles » font référence aux données métriques auxquelles sont associés une variété d' attributs (dimensions), tels que l'attribut lié à la durée (heure de début, heure de fin), l'ID d'entité, la région, l'hôte, etc. Ce niveau de détail permet une analyse et des requêtes approfondies.
Chez New Relic, ces données métriques sont attachées à notre type de données Metric . Il s'agit de notre principal type de données métriques et il est utilisé par bon nombre de nos outils, notamment :
Pour interroger le type de données Metric, vous pouvez utiliser une requête NRQL comme :
SELECT*FROM Metric
Au fil du temps, les métriques sont de plus en plus agrégées dans des tranches de temps plus grandes. Ceci est fait pour optimiser votre capacité à interroger des données sur une longue période de temps.
Certains de nos autres types de données métriques sont exposés en tant que métriques dimensionnelles et sont disponibles pour l'interrogation. Par exemple:
L'APM, le navigateur et le rapport de New Relic affichent les métriques dans un format de données simple que nous appelons metric timeslice data. Un intervalle de temps métrique se compose de trois parties : un nom métrique, le segment de temps que la métrique représente (la « tranche de temps ») et une valeur numérique (la mesure).
Par exemple : un intervalle de temps métrique pour le temps passé dans une transaction particulière est nommé WebTransaction/URI/foo et peut avoir un temps de réponse de 0,793 pour une tranche horaire d'une minute de 10 h 20 à 10 h 21. Ces métriques suivent généralement un modèle comme <category>/<class>/<method>.
Nos agents (APM, navigateur et mobile) peuvent collecter des milliers de tranches de temps métriques par minute pour une variété de métriques de performance. Par exemple : taux d’erreur, utilisation de la bande passante et temps de collecte des déchets. Vous avez également la possibilité de créer des métriques personnalisées.
Les données d'intervalle de temps métrique sont un type de données léger et ne possèdent pas les détails des mesures dimensionnelles .
Façons d’explorer et de requêter des données d’intervalle de temps métrique :
Pour APM : les données d'intervalle de temps métrique sont converties en métriques dimensionnelles et peuvent être requêtes via NRQL
Si vous souhaitez en savoir plus sur la structure des données de l'intervalle de temps métrique et voir quelques exemples, développez le bouton ci-dessous.
Voici quelques exemples courants de données d'intervalle de temps métrique, en mettant l'accent sur les exemples courants utilisés par les applications Ruby .
ActiveMerchant
New Relic suit une variété de mesures sur ActiveMerchant transactions qui peuvent être utilisées pour l'analyse commerciale ainsi que monitoring des performances. Les métriques sont résumées par opération ainsi que par passerelle.
ActiveRecord est l'API de modélisation objet-relationnelle utilisée par les applications Ruby on Rails . Les métriques présentées ici mesurent les performances des méthodes find et save de ActiveRecord.
Apdex est une mesure de la satisfaction des utilisateurs concernant le temps de chargement de la page.
Controller
Dans les applications Ruby on Rails, requests HTTP sont gérées par les actions du contrôleur. Une application Rails possède de nombreux contrôleurs, chacun ayant une ou plusieurs actions. Lorsque votre application Rails reçoit une requête http, cette requête est acheminée vers le contrôleur et l'action appropriés, en fonction de l'URL de cette requête. Cette action effectue ensuite tout le traitement nécessaire pour générer une réponse http, qui est le plus souvent une page Web, mais peut également être un fragment de page, un document XML ou tout autre type de données demandées par le client.
Les mesures suivantes suivent les performances des actions du contrôleur, quel que soit le routage, et sans prendre en compte les effets du réseau ou du serveur Web.
Cette métrique suit le nombre d'erreurs ou d'exceptions générées lors du traitement requests.
expression régulière
exemple de métrique
nom de la légende
Errors/all
Errors/all
External services
L'instrumentation de service externe capture les appels vers des services hors processus tels que les services Web, les ressources dans le cloud et tout autre appel réseau. Il n'inclut pas d'autres composants backend de première classe tels que MemCache et la base de données.
Dans les applications Ruby nous instrumentons la bibliothèque Net::Http pour capturer tous les services HTTP.
expression régulière
exemple de métrique
nom de la légende
External/[^/]+/all$
External/service.example.com/all
Tous les appels à service.example.com
External/
External/host.aws.com/Net::Http::POST
Net::Http::POST[host.aws.com]
External/all$
External/all
Services externes
External/[^/]+/(?!all)/
External/service.example.com/all
Tous les appels à service.example.com
HTTP dispatcher
Cette métrique représente un résumé du débit et du temps de réponse de toutes requests web.
expression régulière
exemple de métrique
nom de la légende
^HttpDispatcher$
HttpDispatcher
Répartiteur Http
MemCache
MemCache est une technologie populaire qui permet aux applications d'accéder à la mémoire partagée fournie par n'importe quel nombre de machines physiques sous forme de cache global. Les applications qui utilisent beaucoup la base de données utilisent souvent MemCache pour des avantages en termes de performances et d'évolutivité.
Ces métriques mesurent la fréquence et les temps de réponse des appels à MemCache pour lire et écrire des données à partir du cache. Les temps de réponse doivent être faibles (moins de 5 ms) pour un déploiement MemCache performant.
expression régulière
exemple de métrique
nom de la légende
MemCache/.*
MemCache/read
Opérations de lecture MemCache
MemCache/read
MemCache/read
Opérations de lecture MemCache
MemCache/write
MemCache/write
Opérations d'écriture MemCache
Mongrel
Cette métrique mesure la longueur de la file d'attente mongrel, qui contient requests http en attente de traitement par mongrel. Le graphique d'activité HTTP superpose la longueur maximale de la file d'attente pour une période donnée. La valeur est zéro si mongrel traite une requête mais n'a aucune autre requests en attente dans sa file d'attente.
Lorsque l'on examine cette valeur sur un cluster agrégé de bâtards, les longueurs de file d'attente de tous les bâtards sont additionnées, affichant la somme de toutes les longueurs de file d'attente.
La longueur d'une file d'attente bâtarde doit être égale ou proche de zéro ; si elle est systématiquement à un niveau plus élevé, cela indique que votre application Rails a du mal à répondre à ses exigences de charge.
expression régulière
exemple de métrique
nom de la légende
Mongrel/Queue Length
Mongrel/Queue Length
Longueur de la file d'attente
View
ActionView est un package dans Rails qui est utilisé pour restituer la sortie qui est la réponse à une requête http, comme une page html ou un document xml. Le View est rendu par le contrôleur qui gère la demande.
Si les métriques View représentent une grande partie du temps de réponse de votre contrôleur, cela peut signifier que vous effectuez de nombreuses opérations de base de données à l'intérieur du modèle de vue lui-même.
Étant donné que les données de type événement peuvent être associées à n'importe quel type de données de paire valeur clé, une façon de rapporter les métriques est d'utiliser un attribut attaché à un événement.
Quelques exemples de cela chez New Relic :
Notre monitoring d'infrastructure rapporte de nombreuses métriques attachées à l'événement. Par exemple, nous signalons un événement ProcessSample, auquel sont associées diverses mesures basées sur des échantillons, comme le pourcentage de CPU. Pour en savoir plus sur monitoring des données infrastructure, consultez Données d'infrastructure.
Dans APM, l'événement Transaction est associé à plusieurs métriques, notamment databaseDuration.
Pour en savoir plus sur ces données et comment les interroger, consultez événement.
Les métriques peuvent être formées en comptant les événements New Relic ou en effectuant un autre calcul mathématique sur ces événements. Par exemple, si vous souhaitez mesurer le nombre total d'événements Transaction au cours de la dernière demi-heure, vous pouvez exécuter cette requête NRQL :
SELECTcount(*)FROMTransaction SINCE 30 minutes ago
Autre exemple : si vous souhaitez calculer le temps de réponse moyen de votre service, vous pouvez exécuter une requête comme :
FROMTransactionSELECT average(duration) SINCE 30 minutes ago
Certains graphiques New Relic sont générés avec ce type de requête. L’inconvénient de cette approche est qu’il existe des limites quant au nombre d’événements qu’un système monitoring (y compris le nôtre) peut signaler. Cela signifie que parfois, pour les systèmes à débit élevé, le décompte peut ne pas représenter avec précision l'activité totale sur ce système. Pour en savoir plus sur la manière dont cela peut être résolu, consultez les limites et l'échantillonnage des événements.
Tout d’abord, nous expliquerons la définition de events du point de vue de l’industrie monitoring, puis nous expliquerons quelques spécificités sur la manière dont New Relic gère les données d’événements.
événement dans l'industrie monitoring
Dans l’industrie du logiciel, un événement peut être considéré simplement comme « des choses qui se produisent dans un système ». Par exemple, la modification d’un paramètre de serveur serait un événement. Un autre exemple : un utilisateur d’un site Web qui clique sur une souris.
Un événement générera un enregistrement stocké, et cet enregistrement est généralement également appelé event.
Les données d'événement représentent des occurrences discrètes et présentent généralement un niveau de détail élevé. Les données d'événement sont donc adaptées à une analyse et à une interrogation détaillées. L’inconvénient de l’utilisation de données d’événements est qu’il y a généralement tellement d’événements signalés qu’il peut devenir difficile d’interroger ce grand ensemble de données sur des périodes plus longues.
événement à New Relic
Chez New Relic, nous signalons les événements aux objets de données également appelés events. Ces événements ont plusieurs attributs (paires valeur clé) attachés. Les données d'événement sont utilisées dans certains graphiques et tableaux UI, et vous pouvez également les interroger. La durée pendant laquelle les données d'événement restent disponibles est déterminée par les règles de rétention des données.
Un exemple d'événement : APM signale un type d'événement nommé Transaction, qui représente une unité de travail logique dans une application. Pour voir l' attribut attaché à cet événement, vous pouvez utiliser une requête NRQL comme :
SELECT*FROMTransaction
Pour des exemples d'interrogation de données d'événements, voir Introduction à NRQL.
Autres détails sur les données d'événement New Relic :
Pour augmenter la disponibilité de vos données d'événement pour l'interrogation/la création de graphiques, vous pouvez transformer l'événement en métriques.
Certains systèmes génèrent un grand nombre d'événements qui dépassent les limites de collecte et génèrent des résultats de requête incomplets. Pour en savoir plus, voir événement sampling.
Étant donné que event est un terme général, dans certains contextes New Relic, il fera référence à tout type de données pouvant être interrogé via NRQL. Par exemple, lorsque vous exécutez une requête NRQL, elle renvoie un nombre d' événements inspectés: il s'agit d'un nombre de tous les types de données de la requête.
données du log
Tout d’abord, nous expliquerons la définition de logs du point de vue du secteur de monitoring, puis nous expliquerons quelques détails sur la manière dont New Relic gère les rapports log .
Connectez-vous à l'industrie monitoring
Un log est un message sur un système utilisé pour comprendre l'activité du système et pour diagnostiquer les problèmes.
se connecter à New Relic
Nos capacités vous offrent une plateforme centralisée qui connecte vos données log avec d'autres données de monitoring New Relic. Par exemple, vous pouvez voir le log à côté de vos données APM.
Dans New Relic Logs, les données sont signalées avec plusieurs attributs (données de valeur clé) attachés. Pour interroger vos données log, vous pouvez utiliser une requête NRQL comme :
SELECT*FROM Log
Pour signaler des données log personnalisées, consultez l' API de log.
Données de trace
Tout d’abord, nous expliquerons la définition de trace du point de vue de l’industrie monitoring, puis nous expliquerons quelques détails sur la manière dont New Relic gère le tracing.
Tracing dans le secteur du monitoring
Dans le monde des applications/monitoring d'infrastructure, tracing est un terme général utilisé pour désigner différentes manières de rapporter des informations sur le fonctionnement d'un programme ou d'un système. Par exemple, un stack trace fournit des informations détaillées sur les sous-routines d'un programme.
Pour les grands systèmes modernes, qui sont souvent distribués sur de nombreux services et microservices, le « tracing » fait souvent référence à distributed tracing, qui est un moyen de monitorer requests lorsqu'elles se propagent dans un environnement complexe et distribué.
Tracing à New Relic
New Relic propose une fonctionnalité de tracing distribué qui suit requests sur un système distribué et fournit une UI dédiée pour comprendre et analyser votre trace. Dans New Relic, les données trace sont signalées sous forme d'objets Span, avec plusieurs paires d'attributs (valeur-clé) attachées.
Pour interroger vos données de tracing, vous pouvez utiliser une requête NRQL comme :