Extraia dados de métrica de fração de tempo

Um tipo de dados New Relic são os dados métricos de fração de tempo. Existem várias maneiras de consultar dados de métrica de fração de tempo:

• Você pode consultar dados de métrica de fração de tempo do APM via NRQL (e portanto através de nossa API NerdGraph).
• Você pode consultar quaisquer dados de métrica de fração de tempo através da API REST

Este documento explica como fazer isso com a API REST. Observe que a API não se destina à extração de dados em massa de pontos de dados minuto a minuto.

Dados baseados em tempo

Todos os valores de tempo retornados pela API REST e pelo API Explorer são UTC (Tempo Universal Coordenado). Certifique-se de ajustar os valores de tempo para coleta de dados conforme necessário.

Considerações sobre intervalo de tempo

A API usa o mesmo mecanismo para solicitar dados que a interface: depende do intervalo de tempo dos dados que você solicita. O objetivo é otimizar o número de pontos de dados retornados e fornecer um gráfico e relatório de fácil digestão.

Por exemplo:

• Se você solicitar dados de um intervalo de tempo

  three hours or less

  , a API retornará os valores de dados de um minuto coletados originalmente.

• Se você aumentar o intervalo de tempo para

  greater than three hours

  , os valores dos dados retornados serão uma média de dois minutos.

• Se você aumentar o intervalo de tempo para

  over six hours

  , os valores dos dados retornados serão uma média de cinco minutos e assim por diante.

Tabela de agendamento de agregação de dados

Aqui está um resumo da recuperação do valor da métrica para os intervalos de tempo disponíveis.

Quando o horário de início de um intervalo de tempo solicitado for superior a oito dias, os dados foram agregados ou calculados em média para períodos de uma hora devido ao planejamento de agregação de dados. Isto significa que, para qualquer período de uma hora, apenas um único valor de dados estará disponível. A obtenção de dados em menos de um período de hora no intervalo de tempo causaria sobreamostragem, resultando no retorno de valores duplicados. Retornar apenas dez valores evita sobreamostragem e apresenta um gráfico mais suave, o que elimina um efeito de "platô" possivelmente enganoso.

Controlando a saída do período de tempo

Às vezes, a granularidade dos dados de saída pode ser muito fina ou o período de tempo para os dados retornados pode ser muito curto. Para controlar isso, inclua o parâmetro period= no comando de consulta como o número de seconds que você deseja que cada período relate. Certifique-se de que suas especificações sigam nossos cronogramas de agregação de dados.

Example #1: Seguindo a tabela da New Relic que resume a granularidade dos dados coletados, a chamada de API a seguir normalmente retornaria dados em períodos de 30 minutos, já que a solicitação é de 4 dias (from=2018-02-13 e to=2018-02-17). Ao adicionar period=3600, os dados serão retornados em 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'

Você não pode especificar um período menor que o padrão para o intervalo de tempo solicitado. Por exemplo:

• No exemplo de comando acima, você pode solicitar períodos de 1 hora, pois é maior que a granularidade padrão (meia hora) para o intervalo de tempo.

• No exemplo de comando acima, você

  cannot

  solicita períodos de 1 minuto, pois é menor que a granularidade padrão (meia hora) para o intervalo de tempo.

Example #2: Se você solicitar um intervalo > 7 dias, mas ≤ 3 semanas, onde o período padrão é de 3 horas, você poderá especificar períodos como 6, 12 ou 24 horas. No entanto, você não pode solicitar períodos de 1 hora, porque é menor que o padrão (3 horas).

Retenção de dados

O tempo que os dados ficam disponíveis depende da retenção de dados para tipos específicos de dados.

Extraindo dados de métrica de fração de tempo inexistentes

Podem surgir situações em que sejam solicitados nomes de métricas inexistentes. Por exemplo:

• Os dados da métrica de fração de tempo não foram criados para uma aplicação, mas existem para outra. Quando a mesma consulta de extração de métrica for usada em ambos os aplicativos, ela não será localizada para um deles.
• O nome da métrica foi especificado incorretamente.

Uma resposta bem-sucedida incluirá um código de status 200 e metadados sobre a solicitação. Os metadados conterão os nomes das métricas solicitadas e o status da solicitação desses nomes.

Aqui está um exemplo de saída para um nome 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
            ...

Aqui está um exemplo de saída para um nome de métrica invá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
  }
}