Utiliser des métriques dimensionnelles pour requêter plus de données

Les métriques dimensionnelles sont une norme industrielle pour le stockage et l'interrogation de données métriques. New Relic stocke toutes les métriques infrastructure sous forme de données d'événement, mais vous pouvez également les requêter sous forme de métriques dimensionnelles.

Chez New Relic, nous rapportons les métriques de plusieurs manières, y compris les métriques dimensionnelles, que notre API métrique, notre SDK télémétrie, certaines intégrations open source et nos services infrastructure peuvent tous utiliser.

Ce type de métrique vous permet de :

• Bénéficiez d'une expérience de requête améliorée pour les données d'infrastructure.
• Découvrez toutes vos métriques en un seul endroit.
• Utilisez des sources plus métriques, comme Prometheus.

Par exemple, vous pouvez utiliser la requête suivante pour obtenir la durée maximale de votre fonction Lambda:

FROM ServerlessSample
SELECT max(provider.duration.Maximum)
WHERE provider = 'LambdaFunction'

FROM Metric
SELECT max(aws.lambda.function.duration)

Démarrer

Vous n’avez besoin d’aucune mise à jour d’agent ou d’intégration pour utiliser ces métriques. Nous prenons en charge les alertes NRQL basées sur des métriques dimensionnelles, à l'exception des données provenant du cloud d'intégration (telles que les métriques d'intégration de sondage AWS, GCP et Azure). New Relic ingère les métriques AWS CloudWatch Metric Streams en tant que métriques dimensionnelles, et nous vous recommandons d'utiliser NRQL alertesdans ces cas.

Où et comment requêter des métriques dimensionnelles

New Relic prend en charge toutes les fonctionnalités de requête NRQL actuelles. Vous pouvez utiliser WHERE, FACET et les fonctions de sélection de temps telles que SINCE, UNTIL et COMPARE WITH pour l'interrogation.

Conventions de dénomination pour les métriques et les attributs

Tous les noms et attributs métriques pour les métriques dimensionnelles suivent la même convention de dénomination pour les rendre faciles à trouver et à utiliser. Les noms de métrique et d'attribut sont séparés par des points : par exemple, le préfixe host. est utilisé pour les métriques de l'hôte, le préfixe k8s. est utilisé pour les métriques Kubernetes et aws. est utilisé pour les métriques AWS.

Le graphique ci-dessous montre comment un ProcessSample contenant trois métriques (cpuPercent, ioTotalReadBytes et ioTotalWriteBytes) est divisé en trois métriques distinctes. Notez la dénomination mise à jour des métriques et de l'attribut.

Différences dans l'interrogation des mesures dimensionnelles et des événements

Les métriques dimensionnelles sont un type de données fondamentalement différent des données d’événement. Ci-dessous, vous trouverez quelques différences notables lors de l'interrogation de métriques dimensionnelles :

• la requête métrique avec * ne renvoie pas d'échantillons de données infrastructure . Par exemple:

  SELECT * FROM Metric

  Copier

• La requête métrique avec metricName LIKE ne renvoie pas d'échantillons de données infrastructure . Par exemple:

  SELECT uniques(metricName) FROM Metric where metricName like 'k8%'

  Copier

• Afin de sélectionner un attribut commençant par tags. , un nom métrique doit être fourni. Par exemple, cela ne fonctionne pas sans la clause WHERE :

  SELECT uniques(tags.environment) FROM Metric WHERE metricName='aws.lambda.function.duration'

  Copier

• Les résultats peuvent ne pas être complets si les critères de sélection correspondent à trop d’échantillons. Par exemple, cette requête correspond à tous les exemples d’infrastructure et peut renvoyer des résultats incomplets :

  SELECT uniqueCount(entity.guid) FROM Metric

  Copier

• Nous ne prenons pas en charge la nouvelle fonctionnalité de métrique générique, par exemple :

  SELECT average(host.swap%Bytes) FROM Metric

  Copier

• Les fonctions utilisées sur plusieurs métriques peuvent échouer ou renvoyer des résultats incorrects, par exemple :

  FROM Metric SELECT latest(metricNameA + metricNameB)

  Copier

• Lorsque vous incluez RAW dans une requête, la demande se transforme en interne et imprime des données d'événement agrégées équivalentes. Il n'imprimera pas de données brutes. Reportez-vous à l'exemple de requête pour voir ce comportement :

  SELECT max(host.cpuPercent) FROM Metric TIMESERIES 1 MINUTE SINCE 60 MINUTES AGO RAW

  Copier

• Nous ne prenons pas en charge l'utilisation de keyset avec TIMESERIES, car cela renverrait une erreur. Voir l'exemple ci-dessous :

  FROM Metric SELECT keyset() WHERE instrumentation.provider = 'infrastructure' TIMESERIES

  Copier

Pour un aperçu des différences de types de données, voir Types de données New Relic.

Exemples de requêtes dimensionnelles

Voici quelques exemples de requêtes NQRL avec et sans métriques dimensionnelles :

FROM BlockDeviceSample
SELECT sum('provider.volumeTotalWriteTime.Sum')
WHERE provider = 'EbsVolume'
FACET entityName

FROM Metric
SELECT sum(aws.ebs.volume.TotalWriteTime)
FACET entity.name

FROM AzureServiceBusTopicSample
SELECT max(activeMessages.Maximum)
FACET resourceGroupName

FROM Metric
SELECT max(azure.servicebus.topic.activeMessages)
FACET azure.resourceGroup

FROM AzureFunctionsAppSample
SELECT sum(functionExecutionCount.Total)
FACET regionName
TIMESERIES SINCE 6 hours ago

FROM Metric
SELECT sum(azure.functions.app.functionExecutionCount)
FACET azure.region
TIMESERIES SINCE 6 hours ago

FROM AzureVirtualMachineScaleSetSample
SELECT uniqueCount(vMName)
FACET name
SINCE 30 MINUTES AGO COMPARE WITH 1 WEEK AGO

FROM Metric
SELECT uniqueCount(azure.vms.vmName)
FACET azure.resourceName
WHERE azure.resourceType='Microsoft.Compute/virtualMachineScaleSets'
SINCE 30 MINUTES AGO COMPARE WITH 1 WEEK AGO

FROM NginxSample
SELECT average(net.requestsPerSecond)
TIMESERIES

FROM Metric
SELECT average(nginx.server.net.requestsPerSecond)
TIMESERIES

FROM MysqlSample
SELECT max(net.maxUsedConnections)

FROM Metric
SELECT max(mysql.node.net.maxUsedConnections)