Extraer datos de intervalo de tiempo de métrica

Un tipo de datos de New Relic son los datos de intervalo de tiempo de métrica. Hay varias formas de consultar intervalo de tiempo de datos métricos:

• Puedes consultar los datos de intervalo de tiempo de métrica APM a través de NRQL (y por lo tanto a través de nuestra API NerdGraph).
• Puedes consultar cualquier dato de intervalo de tiempo de métrica a través de la API REST

Este documento explica cómo hacer esto con la API REST. Tenga en cuenta que la API no está diseñada para la extracción masiva de datos minuto a minuto.

Datos basados en el tiempo

Todos los valores de tiempo devueltos por la API REST y el Explorador de API son UTC (hora universal coordinada). Asegúrese de ajustar los valores de tiempo para la recopilación de datos según sea necesario.

Consideraciones sobre el rango de tiempo

La API utiliza el mismo mecanismo para solicitar datos que la UI: depende del rango de tiempo para los datos que solicita. El objetivo es optimizar la cantidad de puntos de datos devueltos y proporcionar un gráfico e informe fácilmente digeribles.

Por ejemplo:

• Si solicita datos de un rango de tiempo de

  three hours or less

  , la API devuelve los valores de datos de un minuto recopilados originalmente.

• Si aumenta el intervalo de tiempo a

  greater than three hours

  , los valores de datos devueltos serán un promedio de dos minutos.

• Si aumenta el intervalo de tiempo a

  over six hours

  , los valores de datos devueltos serán un promedio de cinco minutos, y así sucesivamente.

Tabla de programación de agregación de datos

A continuación se muestra un resumen de la recuperación del valor de la métrica para los rangos de tiempo disponibles.

Cuando la hora de inicio de un rango de tiempo solicitado tiene más de ocho días, los datos se han agregado o promediado en períodos de una hora debido al programa de agregación de datos. Esto significa que para cualquier período de una hora, solo hay un valor de datos disponible. La obtención de datos en menos de un período de una hora en el rango de tiempo provocaría un sobremuestreo, lo que provocaría que se devolvieran valores duplicados. Devolver sólo diez valores evita el sobremuestreo y presenta un gráfico más fluido, lo que elimina un efecto de "meseta" posiblemente engañoso.

Controlar la salida del período de tiempo

A veces, la granularidad de los datos de salida puede ser demasiado fina o el período de tiempo para los datos devueltos puede ser demasiado corto. Para controlar esto, incluya el parámetro period= en el comando de consulta como el número de seconds que desea que informe cada período de tiempo. Asegúrese de que sus especificaciones sigan nuestros programas de agregación de datos.

Example #1: Siguiendo la tabla de New Relic que resume la granularidad de los datos recopilados, la siguiente llamada API normalmente devolvería datos en períodos de 30 minutos, ya que la solicitud es por 4 días (from=2018-02-13 y to=2018-02-17). Al agregar period=3600, los datos se devolverán como períodos de 60 minutos.

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'

No puede especificar un período menor que el predeterminado para el rango de tiempo que está solicitando. Por ejemplo:

• En el ejemplo de comando anterior, puede solicitar períodos de 1 hora, ya que es mayor que la granularidad predeterminada (media hora) para el rango de tiempo.

• En el ejemplo de comando anterior,

  cannot

  solicita períodos de 1 minuto, ya que es menor que la granularidad predeterminada (media hora) para el rango de tiempo.

Example #2: Si solicita un rango > 7 días pero ≤ 3 semanas, donde el período predeterminado es 3 horas, puede especificar períodos como 6, 12 o 24 horas. Sin embargo, no puede solicitar períodos de 1 hora porque es menos que el valor predeterminado (3 horas).

Retención de datos

El tiempo que los datos están disponibles depende de la retención de datos para tipos de datos específicos.

Extracción de datos de intervalo de tiempo de métrica inexistentes

Pueden surgir situaciones en las que se soliciten nombres métricos inexistentes. Por ejemplo:

• Los datos de intervalo de tiempo de métrica no se han creado para una aplicación, pero existen para otra. Cuando se utiliza la misma consulta de extracción métrica en ambas aplicaciones, no se ubicará para una.
• El nombre de la métrica se especificó incorrectamente.

Una respuesta exitosa incluirá un código de estado 200 y metadatos sobre la solicitud. Los metadatos contendrán los nombres de las métricas solicitadas y el estado de la solicitud de esos nombres.

A continuación se muestra un ejemplo de resultado para un nombre de métrica válido, 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
            ...

A continuación se muestra un ejemplo de resultado para un nombre de métrica no válido, 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
  }
}