Extraire les données d'intervalle de temps métrique

Un type de données New Relic est les données d'intervalle de temps métrique. Il existe plusieurs manières de requêter des données d'intervalle de temps métrique :

• Vous pouvez requêter des données d'intervalle de temps métrique APM via NRQL (et donc via notre APINerdGraph).
• Vous pouvez requêter n'importe quelle donnée d'intervalle de temps métrique via l'API REST

Ce document explique comment procéder avec l'API REST. Notez que l'API n'est pas destinée à l'extraction de données en masse de points de données minute par minute.

Données basées sur le temps

Toutes les valeurs temporelles renvoyées par l'API REST et l'API Explorer sont UTC (Universal Time Coordinated). Assurez-vous d’ ajuster les valeurs de temps pour la collecte de données si nécessaire.

Considérations sur la plage horaire

L'API utilise le même mécanisme de demande de données que l'UI : cela dépend de la plage horaire des données que vous demandez. L’objectif est d’optimiser le nombre de points de données renvoyés et de fournir un graphique et un rapport facilement digestibles.

Par exemple:

• Si vous demandez des données à partir d'une plage horaire de three hours or less, l'API renvoie les valeurs de données d'une minute initialement collectées.
• Si vous augmentez la plage horaire à greater than three hours, les valeurs de données renvoyées seront une moyenne sur deux minutes.
• Si vous augmentez la plage horaire à over six hours, les valeurs de données renvoyées seront une moyenne sur cinq minutes, et ainsi de suite.

Tableau de planification de l'agrégation des données

Voici un résumé de la récupération des valeurs métriques pour les plages horaires disponibles.

Lorsque l'heure de début d'une plage horaire demandée est antérieure à huit jours, les données ont été agrégées ou moyennées sur des périodes d'une heure en raison du calendrier d'agrégation des données. Cela signifie que pour chaque période d'une heure, une seule valeur de données est disponible. L'obtention de données sur une période inférieure à une heure dans la plage horaire entraînerait un suréchantillonnage, ce qui entraînerait le renvoi de valeurs en double. Le renvoi de seulement dix valeurs évite le suréchantillonnage et présente un graphique plus fluide, ce qui élimine un effet de « plateau » potentiellement trompeur.

Contrôle de la sortie de la période de temps

Parfois, la granularité des données de sortie peut être trop fine ou la période de temps pour les données renvoyées peut être trop courte. Pour contrôler cela, incluez le paramètre period= dans la commande de requête comme nombre de seconds que vous souhaitez que chaque période de temps génère un rapport. Assurez-vous que vos spécifications suivent nos calendriers d’agrégation de données.

Example #1: Suivant le tableau de New Relic résumant la granularité des données collectées, l'appel d'API suivant renverrait normalement des données par périodes de 30 minutes, puisque la demande porte sur 4 jours (from=2018-02-13 et to=2018-02-17). En ajoutant period=3600, les données seront renvoyées sous forme de périodes de 60 minutes.

$
curl -X GET "https://api.newrelic.com/v2/applications/$APP_ID/metrics/data.xml" \
>
     -H "Api-Key:$API_KEY" -i \
>
     -d'names[]=CPU/User+Time&from=2018-02-13T04:00:00+00:00&to=2018-02-17T04:00:00+00:00&period=3600'

Vous ne pouvez pas spécifier une période plus petite que la valeur par défaut pour la plage horaire que vous demandez. Par exemple:

• Dans l'exemple de commande ci-dessus, vous pouvez demander des périodes d'une heure, car cela est supérieur à la granularité par défaut (une demi-heure) pour la plage horaire.
• Dans l'exemple de commande ci-dessus, vous cannot demandez des périodes d'une minute, car cela est inférieur à la granularité par défaut (une demi-heure) pour la plage horaire.

Example #2: Si vous demandez une plage > 7 jours mais ≤ 3 semaines, où la période par défaut est de 3 heures, vous pouvez spécifier des périodes telles que 6, 12 ou 24 heures. Cependant, vous ne pouvez pas demander des périodes d'une heure, car c'est moins que la durée par défaut (3 heures).

Rétention des données

La durée de disponibilité des données dépend de la rétention des données pour des types spécifiques de données.

Extraction de données d'intervalle de temps métrique inexistantes

Des situations peuvent survenir où des noms métriques inexistants sont demandés. Par exemple:

• Les données d'intervalle de temps métrique n'ont pas été créées pour une application, mais existent pour une autre. Lorsque la même requête d'extraction métrique est utilisée sur ces deux applications, elle ne sera pas localisée pour l'une.
• Le nom de la métrique a été incorrectement spécifié.

Une réponse réussie inclura un code d’état 200 et des métadonnées sur la demande. Les métadonnées contiendront les noms des métriques demandées et le statut de la demande pour ces noms.

Voici un exemple de sortie pour un nom de métrique valide, HttpDispatcher.

HTTP/1.1 200 OK
etag: "0dc87c63d8dff6b1a9714bdf7531ec09"
Content-Type: application/json
cache-control: max-age=0, private, must-revalidate
{
  "metric_data": {
    "from": "2016-01-28T18:06:06+00:00",
    "to": "2016-01-28T18:36:06+00:00",
    "metrics_not_found": [], <---<<< INDICATES NO INVALID METRIC NAMES REQUESTED
    "metrics_found": [
      "HttpDispatcher"       <---<<< INDICATES THIS METRIC NAME WAS VALID
    ],
    "metrics": [             <---<<< DATA RETURNED
      {
        "name": "HttpDispatcher",
        "timeslices": [
          {
            "from": "2016-01-28T18:03:00+00:00",
            "to": "2016-01-28T18:04:00+00:00",
            "values": {
              "average_response_time": 364,
              "calls_per_minute": 99800,
              "call_count": 99770,
              "min_response_time": 3.5,
              "max_response_time": 85000,
              "average_exclusive_time": 0,
              "average_value": 0.364,
              "total_call_time_per_minute": 36300,
              "requests_per_minute": 99800,
              "standard_deviation": 1900,
              "average_call_time": 364
            ...

Voici un exemple de sortie pour un nom de métrique non valide, Foo.

HTTP/1.1 200 OK
etag: "e51782cf7c5a5596139a7f5340c3de23"
Content-Type: application/json
cache-control: max-age=0, private, must-revalidate
{
  "metric_data": {
    "from": "2016-01-28T18:06:33+00:00",
    "to": "2016-01-28T18:36:33+00:00",
    "metrics_not_found": [
      "Foo"                   <---<<< INDICATES THIS METRIC NAME WAS INVALID
    ],
    "metrics_found": [],      <---<<< INDICATES NO VALID METRIC NAMES FOUND
    "metrics": []             <---<<< NO DATA RETURNED
  }
}