Otimize sua ingestão de dados

Uma conta está ingerindo cerca de 20% a mais do que o orçamento havia previsto. Um gerente pediu que eles encontrassem uma maneira de reduzir o consumo. Seu fator de valor mais importante é o ritmo de operação, o desempenho e a confiabilidade.

Seu patrimônio inclui:

• APM(desenvolvimento, preparação, produção)

• Distributed tracing

• Browser

• Monitoramento de infraestrutura de 100 hosts

• Monitoramento K8s (dev, staging, prod)

• Log (dev, preparação, prod - incluindo depuração)

  Plano de otimização

  • Omitir o log de depuração (sabendo que eles podem ser ativados se houver um problema) (economiza 5%)
  • Omitir várias métricas de estado K8s que não são necessárias para exibir o cluster do Kubernetes Explorer (economiza 10%)
  • Solte alguns eventos de Browser personalizados que eles estavam coletando quando estavam fazendo muitos testes A/B de novos recursos (economiza 10%)

  Depois de executar essas mudanças, a equipe ficou 5% abaixo do orçamento e liberou espaço para fazer um piloto de NPM. Seu gerente está satisfeito por não estar perdendo nenhum ritmo de operação significativo e confiabilidade de observabilidade.

  Resultado final

  • 5% abaixo do orçamento original
  • Headroom criado para um piloto NPM que atende aos objetivos de tempo de operação, desempenho e confiabilidade
  • Perda mínima de tempo de operação e observabilidade de confiabilidade

Uma equipe responsável por uma nova plataforma voltada para o usuário com ênfase em monitoramento de Mobile e monitoramento de Browser está 50% acima do orçamento. Eles precisarão dimensionar corretamente sua ingestão, mas são inflexíveis em não sacrificar a observabilidade da experiência de qualquer cliente .

Seu patrimônio inclui:

• Mobile

• Browser

• APM

• Distributed tracing

• Infraestrutura em 30 hosts, incluindo amostras de processos

• Monitoramento Serverless para alguns processos backend assíncronos

• Log de sua função serverless

• Várias integrações na nuvem

  Plano de otimização

  • Omita o log sem servidor (eles são basicamente redundantes em relação ao que obtêm com a integração do Lambda)
  • Diminuir a taxa de amostragem do processo em seus hosts para cada minuto
  • Eliminar dados de amostra do processo em ambientes DEV
  • Desative a integração do EC2, que é altamente redundante com outro monitoramento de infraestrutura fornecido pelo agente de infra-estrutura New Relic.

  Resultado final

  • 5% acima do orçamento original
  • Suficiente para passar pela alta temporada
  • Sem perda de observabilidade da experiência dos clientes

  Depois de executar as mudanças, eles estão agora apenas 5% acima do orçamento original, mas concluem que isso será suficiente para mantê-los durante a alta temporada.

Uma equipe está refatorando um grande monólito Python para quatro microsserviços. O monólito compartilha muita infraestrutura com a nova arquitetura, incluindo um banco de dados de clientes e uma camada de cache. Eles estão 70% acima do orçamento e ainda têm dois meses antes de poderem desativar oficialmente o monólito.

Seu patrimônio inclui:

• Monitoramento K8s (microsserviços)

• Monitoramento de hospedeiro New Relic (monolito)

• APM (microsserviços e monitoramento de host)

• Distributed tracing (microsserviços e monitoramento de host)

• Postgresql (compartilhado)

• Redis (compartilhado)

• MSSQL (futuro banco de dados para a arquitetura de microsserviços)

• Registro do balanceador de carga (microsserviços e monitoramento de host)

  Plano de otimização

  • Configure o log do balanceador de carga para monitor apenas códigos de resposta 5xx (monólito)
  • Taxa de amostragem personalizada em ProcessSample, StorageSample e NetworkSample até 60s para hosts executando o monólito
  • Desative o monitoramento MSSQL, pois atualmente a nova arquitetura não o utiliza.
  • Desative distributed tracing para o monólito, pois é muito menos útil do que será para a arquitetura de microsserviços.

  Resultado Final

  • 1% abaixo do orçamento original
  • Sem perda de inovação e observabilidade do crescimento

O volume de dados gerado pelo agente APM será determinado por diversos fatores:

• A quantidade de tráfego orgânico gerado pelo aplicativo (por exemplo, se todas as coisas forem iguais, um aplicativo sendo chamado um milhão de vezes por dia gerará mais dados do que um sendo chamado mil vezes por dia)

• Algumas das características dos próprios dados de transação subjacentes (comprimento e complexidade dos URLs)

• Se a aplicação está reportando consulta ao banco de dados

• Se o aplicativo possui transação com muitos (ou algum) atributo personalizado

• O volume de erros do aplicativo

• Se o agente aplicativo está configurado para distributed tracing

  Gerenciando volume

  Embora você possa presumir que todas as chamadas para um aplicativo sejam necessárias para dar suporte aos negócios, é possível que você seja mais econômico em sua arquitetura geral. Em um caso extremo você pode ter um perfil de usuário de microsserviços que é chamado a cada 10 segundos pelos seus clientes. Isso ajuda a reduzir a latência se algumas informações do usuário forem atualizadas por outros clientes. Contudo, uma alavanca que temos é reduzir a frequência das chamadas para este serviço para, por exemplo, cada minuto.

  Atributo personalizado

  Qualquer atributo personalizado adicionado usando uma chamada para uma API APM addCustomParameter adicionará um atributo adicional à carga útil da transação. Geralmente são úteis, mas à medida que a lógica e as prioridades do aplicativo mudam, os dados podem se tornar menos valiosos ou até mesmo obsoletos.

  O agente Java captura o seguinte request.headers por padrão:

• request.headers.referer

• request.headers.accept

• request.headers.contentLength

• request.headers.host

• request.headers.userAgent

  Os desenvolvedores também podem usar addCustomParameter para capturar informações adicionais (cabeçalhos potencialmente mais detalhados).

  Para obter um exemplo da configuração avançada disponível em relação ao APM, consulte nossa documentação do agente Java

  Evento de erro

  É possível determinar como os erros serão tratados pelo APM. Isso pode reduzir o volume de dados em alguns casos. Por exemplo, pode haver um erro de grande volume, mas inofensivo, que não pode ser removido no momento.

  Temos a capacidade de collect, ignore ou mark as expected. Para obter mais informações, consulte Gerenciar erros de APM.

  Consulta ao banco de dados

  Um aspecto altamente variável da instância do APM é o número de chamadas de banco de dados e a configuração que definimos. Temos um controle razoável sobre o quão detalhado é o monitoramento da consulta ao banco de dados. Essas consultas aparecerão na página de rastreamento da transação.

  As alterações comuns nas configurações da consulta ao banco de dados incluem:

• Coletando dados brutos de consulta em vez de ofuscar ou desligar a coleta de consulta

• Alterando o limite stack trace

• Ativando a coleta de plano de explicação de consulta

  Para mais detalhes, consulte a página trace da consulta ao banco de dados.

  Configurando limites de eventos

  Nosso APM e agente móvel têm limites de quantos eventos podem ser reportados por ciclo de coleta. Se não houvesse limite, um número muito grande de eventos enviados poderia impactar o desempenho da sua aplicação ou do New Relic. Quando o limite é atingido, o agente inicia a amostragem do evento para fornecer uma amostra representativa do evento ao longo do ciclo de coleta. Agentes diferentes têm limites diferentes.

  Eventos que são limitados e sujeitos a amostragem incluem:

• Evento personalizado relatado via API do agente (por exemplo, o RecordCustomEvent do agente .NET)

• Mobile

• MobileCrash

• MobileHandledException

• MobileRequest

• Span (veja amostragem distributed tracing )

• Transaction

• TransactionError

  A maioria dos agentes possui opções de configuração para alterar o limite de eventos na transação amostrada. Por exemplo, o agente Java usa max_samples_stored. O valor padrão para max_samples_stored é 2000 e o máximo é 10000. Este valor controla quantos eventos amostrados podem ser relatados a cada 60 segundos a partir de uma instância do agente.

  Para obter uma explicação completa dos limites de amostragem de eventos, consulte limites de eventos.

  Você pode compensar o evento amostrado por meio do operador NRQLEXTRAPOLATE .

  Antes de tentar alterar a forma como a amostragem ocorre, leia estas advertências e recomendações:

• Quanto mais eventos você relatar, mais memória seu agente usará.

• Geralmente, você pode obter os dados necessários sem aumentar o limite de relatórios de eventos do agente.

• O limite de tamanho da carga útil é de 1 MB (10 ^ 6 bytes) (compactado), portanto, o número de eventos ainda pode ser afetado por esse limite. Para determinar se o evento está sendo descartado, consulte o log do agente para obter uma mensagem de status 413 HTTP.

  Taxa de amostragem log

  Versões mais recentes do agente de linguagem New Relic APM podem encaminhar o log diretamente para o New Relic. Em alguns casos, você pode querer controlar alguns limites de quão grandes podem ser os picos de registro de cada instância do agente APM.

  Para obter detalhes sobre a amostragem de log do agente APM, consulte encaminhador de logs.

  Rastreamento da transação

  Motores de crescimento

  • Número de serviços conectados
  • Número de chamadas de método de monitor por serviços conectados

  No APM, o rastreamento da transação registra detalhes detalhados sobre a transação da sua aplicação e chamadas de banco de dados. Você pode editar as configurações padrão para rastreamento de transação.

  Isso também é altamente configurável por meio da transação de configuração comercial. O nível e o modo de configurabilidade serão específicos do idioma em muitos casos.

  As configurações de rastreamento da transação disponíveis usando a configuração no lado do servidor serão diferentes dependendo do agente New Relic que você usar. A interface inclui descrições de cada um. As configurações na interface podem incluir:

• Rastreamento e limite de transação

• Registre SQL, incluindo nível de gravação e campos de entrada

• Log SQL e limite stack trace

• Planos e limites de consulta SQL

• Coleta de erros, incluindo código HTTP e classe de erro

• Consulta lenta rastreamento

• Profiler de thread

  Distributed tracing

  A configuração distributed tracing tem algumas diferenças específicas do idioma.

  Distributed tracing pode ser desativado conforme necessário. Este é um exemplo para o agente Java newrelic.yml:

  distributed_tracing:
      enabled: false

  Copiar

  Este é um exemplo de node.js para newrelic.js

  distributed_tracing: {
    enabled: false
  }

  Copiar

  O volume de dados também variará dependendo se você estiver usando o Infinite Tracing.

  Distributed tracing padrão para o agente APM (acima) captura até 10% do seu rastreamento, mas se você quiser que analisemos todos os seus dados e encontremos o rastreamento mais relevante, você pode configurar o Rastreamento Infinito. Esta alternativa ao distributed tracing padrão está disponível para todos os agentes de linguagem APM.

  Os principais parâmetros que podem gerar um pequeno aumento na ingestão mensal são:

• Configurar o monitoramento do observador trace

• Configurar filtro trace de atributo span

• Configurar filtro trace aleatório

Para o Browser agente versão 1211 ou superior, todas as solicitações de rede feitas por uma página são registradas como evento AjaxRequest . Você pode usar as opções de configuração da lista de negações na página de interface de configurações do aplicativo para filtrar quais solicitações registram evento. Independentemente deste filtro, todas as solicitações da rede são capturadas como métricas e disponibilizadas na página AJAX.

Usando a lista de negações

As solicitações podem ser bloqueadas de três maneiras:

• Para bloquear a gravação de todos os eventos AjaxRequest , adicione um asterisco * como curinga.

• Para bloquear a gravação do evento AjaxRequest em um domínio, insira apenas o nome do domínio. Exemplo: example.com

• Para bloquear a gravação do evento AjaxRequest em um domínio e caminho específicos, insira o domínio e o caminho. Exemplo: example.com/path

• O protocolo, a porta, a pesquisa e o hash de aplicação de uma URL são ignorados pela lista de negações.

  Para validar se os filtros adicionados funcionam conforme o esperado, execute uma consulta NRQL para AjaxRequest evento correspondente ao seu filtro.

  Acessando a lista de negações

  Para atualizar a lista de URLs negados que seu aplicativo filtrará na criação do evento, acesse a página da interface de configurações do aplicativo:

1. Acesse one.newrelic.com, e clique em Browser.

2. Selecione um aplicativo.

3. Na navegação à esquerda, clique em App settings [Configurações do aplicativo].

4. Em Ajax request deny list [Lista de negação de solicitação do Ajax], adicione os filtros que você gostaria de aplicar.

5. Selecione Save application settings [Salvar configurações do aplicativo] para atualizar a configuração do agente.

6. Reimplante o agente browser (reiniciando o APM do agente associado ou atualizando a instalação do Browser copiar/colar).

   Validando

   FROM AjaxRequest SELECT * WHERE requestUrl LIKE `%example.com%`

   Copiar

Android

Todas as configurações, incluindo a chamada para invocar o agente, são chamadas no método onCreate da classe MainActivity . Para alterar as configurações, chame a configuração de uma das duas maneiras (se a configuração suportar):

NewRelic.disableFeature(FeatureFlag.DefaultInteractions);
NewRelic.enableFeature(FeatureFlag.CrashReporting);
NewRelic.withApplicationToken(NEW_RELIC_TOKEN).start(this.getApplication());

As configurações de análise habilitam ou desabilitam a coleta de dados de eventos. Esses eventos são reportados ao New Relic e usados na página de Crash analysis .

Também é possível configurar o log do agente para ser mais ou menos detalhado.

iOS

Assim como no Android, a configuração do iOS da New Relic permite ativar e desativar flags de recurso.

As seguintes flags de recurso podem ser configuradas:

Relatório de falhas e erros

• NRFeatureFlag_CrashReporting
• NRFeatureFlag_HandleExceptionEvents
• NRFeatureFlag_CrashReporting

Distributed tracing

• NRFeatureFlag_DistributedTracing

O que é isso?

• NRFeatureFlag_DefaultInteractions
• NRFeatureFlag_InteractionTracing
• NRFeatureFlag_SwiftInteractionTracing

Sinalizadores de recursos de rede

• NRFeatureFlag_ExperimentalNetworkInstrumentation
• NRFeatureFlag_NSURLSessionInstrumentation
• NRFeatureFlag_NetworkRequestEvents
• NRFeatureFlag_RequestErrorEvents
• NRFeatureFlag_HttpResponseBodyCapture

Para mais detalhes, veja flags de recurso.

O arquivo de configuração do agente de infraestrutura da New Relic contém algumas maneiras poderosas de controlar o volume de ingestão. O controle de ingestão mais importante é configurar taxas de amostragem. Existem várias configurações de taxas de amostragem distintas que podem ser ajustadas. Além disso é possível criar expressões regulares para controlar o que é coletado de determinado coletor como para ProcessSample e NetworkSample.

Taxas de amostragem configuráveis

Existem diversas taxas de amostragem que podem ser configuradas na infraestrutura, mas essas são as mais comumente usadas.

| parâmetro | Padrão | Desativar | | --------------------------- | ------- | ------- | | metrics_storage_sample_rate | 5 | -1 | | metrics_process_sample_rate | 20 | -1 | | metrics_network_sample_rate | 10 | -1 | | metrics_system_sample_rate | 5 | -1 | | metrics_nfs_sample_rate | 5 | -1 |

Amostras de processo

As amostras de processo podem ser a fonte única de dados de maior volume do agente de infraestrutura. Isso ocorre porque ele enviará informações sobre qualquer processo em execução em um host. Eles estão desabilitados por padrão, mas podem ser habilitados da seguinte maneira:

enable_process_metrics: true

Isso tem o mesmo efeito que definir metrics_process_sample_rate como -1.

Por padrão, os processos que usam pouca memória são excluídos da amostragem. Para obter mais informações, consulte disable-zero-mem-process-filter.

Você pode controlar a quantidade de dados enviados para o New Relic configurando include_matching_metrics, que permite restringir a transmissão de dados métricos com base nos valores de métrica atributo.

Você inclui dados de métrica definindo valores literais ou parciais para qualquer atributo da métrica. Por exemplo, você pode optar por enviar o host.process.cpuPercent de todos os processos cujo process.name corresponde à expressão regular ^java .

Neste exemplo, incluímos métricas de processo usando nomes e arquivos executáveis:

include_matching_metrics:             # You can combine attributes from different metrics
    process.name:
      - regex "^java"                   # Include all processes starting with "java"
    process.executable:
      - "/usr/bin/python2"              # Include the Python 2.x executable
      - regex "\\System32\\svchost"     # Include all svchost executables

Você também pode usar este filtro para a integração do Kubernetes:

env:
    - name: NRIA_INCLUDE_MATCHING_METRICS
      value: |
        process.name:
          - regex "^java"
        process.executable:
          - "/usr/bin/python2"
          - regex "\\System32\\svchost"

Um exclude_matching_metrics está disponível e funciona de forma semelhante para excluir dados métricos.

Filtro de interface de rede

A configuração usa um mecanismo simples de correspondência de padrões que pode procurar interfaces que começam com uma sequência específica de letras ou números seguindo qualquer um dos padrões:

• {name}[other characters]
• [number]{name}[other characters], onde você especifica o nome usando a opção index-1

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Filtros de interface de rede padrão para Linux:

• Interfaces de rede que começam com dummy, lo, vmnet, sit, tun, tap ou veth
• Interfaces de rede que contêm tun ou tap

Filtros de interface de rede padrão para Windows:

• Interfaces de rede que começam com Loop, isatap ou Local

Para substituir os padrões, inclua seu próprio filtro no arquivo de configuração:

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Atributo personalizado

atributo personalizado são pares de valores principais (semelhantes a tags em outras ferramentas) usados para anotar os dados do agente de infraestrutura. Você pode usar esses metadados para criar conjuntos de filtros, agrupar seus resultados e anotar seus dados. Por exemplo, você pode indicar o ambiente de uma máquina (preparação ou produção), o serviço que a máquina hospeda (serviço de login, por exemplo) ou a equipe responsável por essa máquina.

Exemplo de atributo personalizado de newrelic.yml

custom_attributes:
  environment: production
  service: billing
  team: alpha-team

Eles são poderosos e úteis, mas se os dados não estiverem bem organizados ou se tornarem obsoletos de alguma forma, você deve considerar simplificá-los.

Não é surpreendente que um sistema complexo e descentralizado como o Kubernetes tenha o potencial de gerar muita telemetria rapidamente. Existem algumas boas abordagens para gerenciar a ingestão de dados no Kubernetes. Isso será muito simples se você estiver usando observabilidade como código em sua implantação K8s. É altamente recomendável que você instale este dashboard de análise de ingestão de dados do Kubernetes antes de tomar qualquer decisão sobre a redução da ingestão de K8s. Para obter esse dashboard, consulte o início rápido de integração de infraestrutura.

Intervalo de raspagem

Dependendo dos seus objetivos de observabilidade, você pode considerar ajustar o intervalo de raspagem. O padrão é 15s. Agora o cluster do Kubernetes Explorer só é atualizado a cada 45s. Se o seu uso principal dos dados K8s for para dar suporte às visualizações KCE, você pode considerar alterar o intervalo de coleta para 20s. Essa mudança dos 15 para os 20 anos pode ter um impacto substancial. Para obter mais detalhes sobre como gerenciar isso, consulte nossos documentos de intervalo de raspagem de integração do Helm.

Filtrando namespace

A integração Kubernetes v3 e superior permite filtrar quais namespaces são extraídos, rotulando-os. Por padrão, todos os namespaces são eliminados.

Usamos o namespaceSelector da mesma forma que o Kubernetes. Para incluir apenas o namespace que corresponde a um rótulo, altere o namespaceSelector adicionando o seguinte ao seu values-newrelic.yaml, na seção newrelic-infrastructure :

common:
  config:
    namespaceSelector:
      matchLabels:
        key1 : "value1"

Neste exemplo, apenas o namespace com o rótulo newrelic.com/scrape definido como true será copiado:

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchLabels:
          newrelic.com/scrape: "true"

Você também pode usar expressões de correspondência do Kubernetes para incluir ou excluir namespace. Os operadores válidos são:

• Em
• Não em
• Existe
• Não existe

A estrutura geral da seção matchExpressions é uma ou mais das seguintes linhas:

{key: VALUE, operator: OPERATOR, values: LIST_OF_VALUES}

Aqui está um exemplo completo:

common:
  config:
    namespaceSelector:
      matchExpressions:
      - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

Neste exemplo, o namespace com o rótulo newrelic.com/scrape definido como false será excluído:

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchExpressions:
        - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

Veja uma lista completa das configurações que podem ser modificadas no arquivo README do gráfico.

Como posso saber quais namespaces estão excluídos? [#excluded-namespaces]

Todos os namespaces dentro do cluster são listados graças à amostra K8sNamespace . O atributo nrFiltered determina se os dados relacionados ao namespace serão copiados.

Use esta consulta para saber qual namespace está sendo monitorado:

FROM K8sNamespaceSample SELECT displayName, nrFiltered
WHERE clusterName = INSERT_NAME_OF_CLUSTER SINCE
2 MINUTES AGO

Quais dados estão sendo descartados do namespace excluído? [#namespaces-discarded-data]

Os exemplos a seguir não estarão disponíveis para o namespace excluído:

• K8sContainerSample
• K8sDaemonsetSample
• K8sDeploymentSample
• K8sEndpointSample
• K8sHpaSample
• K8sPodSample
• K8sReplicasetSample
• K8sServiceSample
• K8sStatefulsetSample
• K8sVolumeSample

Métrica do estado de Kube

O cluster do Kubernetes Explorer requer apenas a seguinte métrica de estado do kube (KSM):

• Dados do contêiner
• Dados de cluster
• Dados do nó
• Dados do pod
• Dados de volume
• Dados do servidor API¹
• Dados do gerenciador do controlador¹
• Dados ETCD¹
• Dados do agendador¹

¹ Não coletado em um ambiente Kubernetes gerenciado (EKS, GKE, AKS etc.)

Você pode considerar desabilitar alguns dos seguintes:

• Dados do DaemonSet
• Dados de implantação
• Dados de endpoint
• Dados de namespace
• Dados do ReplicaSet²
• Dados de serviço
• Dados StatefulSet

² Usado no alerta padrão: “ReplicaSet não possui a quantidade desejada de pod”

Exemplo de atualização de métrica de estado em manifesto (Deployment)

$
[spec]
$
  [template]
$
    [spec]
$
      [containers]
$
        [name=kube-state-metrics]
$
        [args]
$
        #- --collectors=daemonsets
$
        #- --collectors=deployments
$
        #- --collectors=endpoints
$
        #- --collectors=namespaces
$
        #- --collectors=replicasets
$
        #- --collectors=services
$
        #- --collectors=statefulsets

Exemplo de atualização de métrica de estado em manifesto (ClusterRole)

$
[rules]
$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - daemonsets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - deployments
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - endpoints
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - namespaces
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - replicasets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - services
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["apps"]
$
#   resources:
$
#   - statefulsets
$
#   verbs: ["list", "watch"]

Configurar lowDataMode no gráfico nri-bundle

Nossos gráficos Helm oferecem suporte à configuração de uma opção para reduzir a quantidade de dados ingeridos ao custo da eliminação de informações detalhadas. Para ativá-lo, defina global.lowDataMode como true no gráfico nri-bundle .

lowDataMode afeta três componentes específicos do gráfico nri-bundle :

1. Aumente o intervalo do agente de infraestrutura de 15 para 30 segundos.
2. A integração do Prometheus OpenMetrics excluirá algumas métricas conforme indicado no documento Helm abaixo.
3. Os detalhes dos rótulos e anotações serão eliminados do log.

Você pode encontrar mais detalhes sobre essa configuração em nosso documento do Helm.

A integração no host da New Relic representa um conjunto diversificado de integração para serviços de terceiros, como Postgresql, MySQL, Kafka, RabbitMQ etc. Não é possível fornecer todas as técnicas de otimização no escopo deste documento, mas podemos fornecer estas técnicas de aplicação geral:

• Gerenciar taxa de amostragem

• Gerencie as partes da configuração que podem aumentar ou diminuir a amplitude da coleção

• Gerencie as partes da configuração que permitem consultas personalizadas

• Gerencie o atributo personalizado do agente de infraestrutura porque eles serão aplicados a todos os dados de integração no host.

  Usaremos alguns exemplos para demonstrar.

  Integração PostgreSQL

  Motores de crescimento

  • Monitor de número de tabelas
  • Monitor de número de índices

  A configuração de integração no host do PostgreSQL fornece estas configurações ajustáveis que podem ajudar a gerenciar o volume de dados:

• interval: O padrão é 15s

• COLLECTION_LIST: lista de tabelas a serem monitor (use ALL para monitor ALL)

• COLLECT_DB_LOCK_METRICS: Colete dblock métrica

• PGBOUNCER: Colete pgbouncer métrica

• COLLECT_BLOAT_METRICS: Colete métricas de inchaço

• METRICS: Defina como true para coletar apenas métricas

• INVENTORY: defina como true para ativar apenas a coleta de inventário

• CUSTOM_METRICS_CONFIG: Arquivo de configuração contendo consulta de coleção personalizada

  Exemplo de configuração:

  integrations:
    - name: nri-postgresql
      env:
        USERNAME: postgres
        PASSWORD: pass
        HOSTNAME: psql-sample.localnet
        PORT: 6432
        DATABASE: postgres
        COLLECT_DB_LOCK_METRICS: false
        COLLECTION_LIST: '{"postgres":{"public":{"pg_table1":["pg_index1","pg_index2"],"pg_table2":[]}}}'
        TIMEOUT:  10
      interval: 15s
      labels:
        env: production
        role: postgresql
      inventory_source: config/postgresql

  Copiar

  Kafka integração

  Motores de crescimento

  • Número de corretores no cluster
  • Número de tópicos no cluster

  A configuração de integração no host do Kafka fornece estas configurações ajustáveis que podem ajudar a gerenciar o volume de dados:

• interval: O padrão é 15s

• TOPIC_MODE: determina quantos tópicos coletamos. As opções são all, none, list ou regex.

• METRICS: Defina como true para coletar apenas métricas

• INVENTORY: defina como true para ativar apenas a coleta de inventário

• TOPIC_LIST: matriz JSON de nomes de tópicos a serem monitor. Somente terá efeito se topic_mode estiver definido como list.

• COLLECT_TOPIC_SIZE: Colete a métrica Tamanho do tópico. As opções são true ou false, o padrão é false.

• COLLECT_TOPIC_OFFSET:Coleta o deslocamento do tópico métrico. As opções são true ou false, o padrão é false.

  Deve-se notar que a coleta de métricas em nível de tópico, especialmente compensações, pode exigir muitos recursos para ser coletada e pode ter um impacto no volume de dados. É muito possível que a ingestão de um cluster aumente em uma ordem de magnitude simplesmente pela adição de novos tópicos Kafka ao cluster.

  Integração MongoDB

  Motores de crescimento

  • Número de monitor do banco de dados

  A integração do MongoDB fornece estas configurações ajustáveis que podem ajudar a gerenciar o volume de dados:

• interval: O padrão é 15s

• METRICS: Defina como true para coletar apenas métricas

• INVENTORY: defina como true para ativar apenas a coleta de inventário

• FILTERS: um mapa JSON de nomes de bancos de dados para uma matriz de nomes de coleções. Se estiver vazio, o padrão é todos os bancos de dados e coleções.

  Para qualquer integração on-host que você usar, é importante estar ciente de parâmetros como FILTERS onde o padrão é coletar métricas de todo o banco de dados. Esta é uma área onde você pode usar suas prioridades de monitoramento para agilizar os dados coletados.

  Exemplo de configuração com intervalos diferentes para métrica e INVENTÁRIO:

  integrations:
    - name: nri-mongodb
      env:
        METRICS: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 15s
      labels:
        environment: production
  
    - name: nri-mongodb
      env:
        INVENTORY: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 60s
      labels:
        environment: production
      inventory_source: config/mongodb

  Copiar

  Integração Elasticsearch

  Motores de crescimento

  • Número de nós no cluster
  • Número de índices no cluster

  A integração do Elasticsearch fornece estas configurações ajustáveis que podem ajudar a gerenciar o volume de dados:

• interval: O padrão é 15s

• METRICS: Defina como true para coletar apenas métricas

• INVENTORY: defina como true para ativar apenas a coleta de inventário

• COLLECT_INDICES: Sinaliza se deve ou não coletar índices métricos.

• COLLECT_PRIMARIES: Sinaliza se deve ou não coletar métrica primária.

• INDICES_REGEX: Filtre quais índices são coletados.

• MASTER_ONLY: Colete métricas de cluster apenas no mestre eleito.

  Exemplo de configuração com intervalos diferentes para METRICS e INVENTORY:

  integrations:
    - name: nri-elasticsearch
      env:
        METRICS: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        REMOTE_MONITORING: true
      interval: 15s
      labels:
        environment: production
  
    - name: nri-elasticsearch
      env:
        INVENTORY: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        CONFIG_PATH: /etc/elasticsearch/elasticsearch.yml
      interval: 60s
      labels:
        environment: production
      inventory_source: config/elasticsearch

  Copiar

  JMX integração

  Motores de crescimento

  • Métrica listada em COLLECTION_CONFIG

  A integração JMX é inerentemente genérica. Isso nos permite extrair métricas de qualquer instância JMX. Temos um bom controle sobre o que é coletado por essa integração. Em alguns ambientes empresariais New Relic, as métricas JMX representam uma proporção relativamente alta de todos os dados coletados.

  A integração JMX fornece estas configurações ajustáveis que podem ajudar a gerenciar o volume de dados:

• interval: O padrão é 15s

• METRICS: Defina como true para coletar apenas métricas

• INVENTORY: defina como true para ativar apenas a coleta de inventário

• METRIC_LIMIT: Número de métricas que podem ser recolhidas por entidade. Se este limite for ultrapassado a entidade não será reportada. Um limite de 0 não implica nenhum limite.

• LOCAL_ENTITY: Coleta todas as métricas da entidade local. Usado somente quando monitoramento localhost.

• COLLECTION_FILES: uma lista separada por vírgulas de caminhos completos para os arquivos de definição da coleção métrica. Para instalação no host, o arquivo de coleta de métricas JVM padrão está em /etc/newrelic-infra/integrations.d/jvm-metrics.yml.

• COLLECTION_CONFIG: configuração da coleção métrica como JSON.

  São as entradas COLLECTION_CONFIG que mais controlam a quantidade de dados ingeridos. Compreender o modelo JMX que você está copiando o ajudará a otimizar.

  COLLECTION_CONFIG exemplo para métrica JVM

  COLLECTION_CONFIG='{"collect":[{"domain":"java.lang","event_type":"JVMSample","beans":[{"query":"type=GarbageCollector,name=*","attributes":["CollectionCount","CollectionTime"]},{"query":"type=Memory","attributes":["HeapMemoryUsage.Committed","HeapMemoryUsage.Init","HeapMemoryUsage.Max","HeapMemoryUsage.Used","NonHeapMemoryUsage.Committed","NonHeapMemoryUsage.Init","NonHeapMemoryUsage.Max","NonHeapMemoryUsage.Used"]},{"query":"type=Threading","attributes":["ThreadCount","TotalStartedThreadCount"]},{"query":"type=ClassLoading","attributes":["LoadedClassCount"]},{"query":"type=Compilation","attributes":["TotalCompilationTime"]}]}]}'

  Copiar

  A omissão de qualquer entrada dessa configuração, como NonHeapMemoryUsage.Init , terá um impacto tangível no volume geral de dados coletados.

  COLLECTION_CONFIG exemplo para métrica do Tomcat

  COLLECTION_CONFIG={"collect":[{"domain":"Catalina","event_type":"TomcatSample","beans":[{"query":"type=UtilityExecutor","attributes":["completedTaskCount"]}]}]}

  Copiar

  Outra integração sem host

  Existem muitas outras integrações no host com opções de configuração que irão ajudá-lo a otimizar a coleta. Alguns comumente usados são:

• NGINX

• MySQL

• Redis

• Apache

• RabbitMQ

  Este é um bom ponto de partida para aprender mais.

Esta seção se concentra no monitoramento de desempenho de rede da New Relic, que depende do agente ktranslate da Kentik. Este agente é bastante sofisticado e é importante compreender totalmente os documentos de configuração avançada antes de grandes esforços de otimização. As opções de configuração incluem:

• mibs_enabled: matriz de todos os MIBs ativos que a imagem docker do KTranslate irá pesquisar. Esta lista será gerada automaticamente durante a descoberta se o atributo discovery_add_mibs for true. Os MIBs não listados aqui não serão pesquisados em nenhum dispositivo no arquivo de configuração. Você pode especificar uma tabela SNMP diretamente em um arquivo MIB usando a sintaxe MIB-NAME.tableName . Exemplo: HOST-RESOURCES-MIB.hrProcessorTable.

• user_tags: valor par principal atributo para dar mais contexto ao dispositivo. tag neste nível será aplicada a todos os dispositivos no arquivo de configuração.

• devices: Seção listando dispositivos a serem monitorados quanto ao fluxo

• traps: configura IP e portas para serem monitorados com traps SNMP (o padrão é 127.0.0.1:1162)

• discovery: configura como o endpoint pode ser descoberto. Nesta seção, o seguinte parâmetro fará o máximo para aumentar ou diminuir o escopo:

  • cidrs: matriz de intervalos IP alvo em notação CIDR.
  • ports: matriz de portas de destino a serem verificadas durante a pesquisa SNMP.
  • debug: indica se o log de nível de depuração deve ser ativado durante a descoberta. Por padrão, está definido como false
  • default_communities: matriz de cadeias de caracteres da comunidade SNMPv1/v2c a serem verificadas durante a pesquisa SNMP. Essa matriz é avaliada em ordem e a descoberta aceita a primeira comunidade que passa.

  Para oferecer suporte à filtragem de dados que não criam valor para suas necessidades de observabilidade, você pode definir o mapa de atributos global.match_attributes.{} e/ou devices.<deviceName>.match_attributes.{} .

  Isso fornecerá filtragem no nível do KTranslate, antes de enviar dados para o New Relic, proporcionando controle granular sobre o monitoramento de coisas como interfaces.

  Para obter mais detalhes, consulte Configuração de monitoramento de desempenho de rede.

Log representam uma das fontes mais flexíveis de telemetria, pois normalmente roteamos o log por meio de uma camada de encaminhamento dedicada com suas próprias regras de roteamento e transformação. Como há uma variedade de forwarders, vamos nos concentrar nos mais usados:

• Agente de linguagem APM (versões recentes)

• Fluentd

• Fluentbit

• Agente New Relic Infrastructure (Fluentbit integrado)

• Logstash

  Amostragem de log do agente APM

  Versões recentes do agente de idiomas da New Relic podem encaminhar log diretamente para a New Relic. Em alguns casos, você pode querer controlar alguns limites de quão grandes podem ser os picos de registro de cada instância do agente APM.

  Podemos habilitar a amostragem com a variável de ambiente NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED

  Ele é configurado simplesmente fornecendo o número máximo de logs que serão armazenados na fila de log do agente APM. Opera com base em uma fila de prioridade personalizada. Todas as mensagens do log têm prioridade. log que ocorrem dentro de uma transação obtém a prioridade da transação.

  A fila de logs é classificada com base na prioridade e na chegada do log . A prioridade mais alta vence e, se necessário, o log mais recente vencerá (mantemos uma contagem para cada entrada na fila). Os logs são adicionados individualmente à fila (mesmo aqueles em uma transação) e quando o limite é atingido, o log no final da fila é empurrado para fora em favor do log mais recente. Na seção de recursos abaixo, há um dashboard de início rápido que ajuda a rastrear o volume de log de maneira simples. O volume log de rastreamento permitirá que você ajuste ou desative a taxa de amostragem para atender às suas necessidades de observabilidade.

  Configurando filtros no Fluentd ou Fluentbit

  A maioria dos encaminhadores gerais fornece um fluxo de trabalho de roteamento bastante completo que inclui filtragem e transformação. O agente de infraestrutura da New Relic fornece alguns padrões muito simples para filtrar logs indesejados. Expressão regular para filtragem de registros. Compatível apenas com as fontes tail, systemd, syslog e tcp (somente com formato nenhum). Este campo funciona de forma semelhante a grep -E em sistemas Unix. Por exemplo, para um determinado arquivo que está sendo capturado, você pode filtrar registros contendo WARN ou ERROR usando:

  - name: only-records-with-warn-and-error
      file: /var/log/logFile.log
      pattern: WARN|ERROR

  Copiar

  Se você tiver configurações pré-escritas do Fluentd para Fluentbit que fazem filtragem ou análise valiosa, você pode importá-las para nossa configuração de log do New Relic. Para fazer isso, use os parâmetros config_file e parsers em qualquer arquivo .yaml na sua pasta logging.d :

• config_file: caminho para um arquivo de configuração existente do Fluent Bit. Qualquer sobreposição de fontes resulta em mensagens duplicadas New Relic no gerenciamento de logdo .

• parsers_file: caminho para um arquivo de analisadores Fluent Bit existente.

  Os seguintes nomes de analisadores são reservados: rfc3164, rfc3164-local e rfc5424.

  Aprender como injetar atributo (ou tag) em seu log em seu pipeline de dados e realizar transformações pode ajudar na eliminação de recursos downstream usando as regras de eliminação do New Relic. Ao aumentar seu log com metadados sobre a origem, podemos tomar decisões centralizadas e facilmente reversíveis sobre o que colocar no backend. No mínimo, certifique-se de que os seguintes atributos estejam presentes em seu log de alguma forma:

• Equipe

• Ambiente (desenvolvimento/estágio/produção)

• Aplicativo

• Data center

• Nível de registro

  Abaixo estão alguns recursos detalhados de roteamento e filtragem:

• Filtros comuns e padrões de roteamento no Fluentd

• Pipeline de dados Fluentbit

• Encaminhando log com o agente New Relic Infrastructure

  Ajustando o conjunto de atributos padrão do agente de infraestrutura

  O agente de infraestrutura adiciona alguns atributos por padrão, incluindo qualquer tag personalizada adicionada ao host. É possível que sua configuração traga muito mais do que isso, incluindo um grande número de tags AWS, que aparecem no New Relic com o formato aws.[attributename]. Esses atributos são importantes para a observabilidade ideal, por isso é altamente recomendável que você avalie suas necessidades de visualização, análise e alertas à luz de quaisquer alterações planejadas na configuração. Por exemplo, o log de um cluster do Kubernetes provavelmente não será útil sem metadados como:

• cluster_name

• pod_name

• container_name

• node_name

A New Relic oferece duas opções principais para enviar métricas do Prometheus para a New Relic. As melhores práticas para gerenciar a ingestão de métricas neste documento serão focadas principalmente na opção 2 - a integração Prometheus OpenMetrics (POMI) - porque este componente foi criado pela New Relic.

Opção 1: integração de gravação remota do Prometheus

Para opções de configuração de raspagem do servidor Prometheus, consulte os documentos de configuração do Prometheus. Essas configurações de raspagem determinam quais métricas são coletadas pelo servidor Prometheus. Ao configurar o parâmetro remote_write , a métrica coletada pode ser gravada no banco de dados New Relic (NRDB) por meio da API métrica New Relic.

Opção 2: integração Prometheus OpenMetrics (POMI)

POMI é uma integração autônoma que extrai métricas de endpoints Prometheus descobertos dinamicamente e estáticos. O POMI então envia esses dados para o NRDB por meio da API métrica New Relic. Essa integração é ideal para clientes que não executam atualmente o Prometheus Server.

POMI: etiqueta de raspar

O POMI descobrirá qualquer endpoint do Prometheus contendo o rótulo ou anotação prometheus.io/scrape=true por padrão. Dependendo do que está implantado no cluster, pode ser um grande número de endpoints e, portanto, um grande número de métricas ingeridas.

Sugere-se que o parâmetro scrape_enabled_label seja modificado para algo personalizado (por exemplo, newrelic/scrape) e que o endpoint do Prometheus seja rotulado ou anotado seletivamente quando a ingestão de dados for de extrema preocupação.

Para obter a configuração de referência mais recente, consulte nri-prometheus-latest.yaml.

Parâmetro de configuração POMI:

# Label used to identify scrapable targets. 
# Defaults to "prometheus.io/scrape"
  scrape_enabled_label: "prometheus.io/scrape"

O POMI descobrirá qualquer endpoint do Prometheus exposto no nível do nó por padrão. Isso normalmente inclui métricas provenientes do Kubelet e do cAdvisor.

Se você estiver executando o New Relic Kubernetes Daemonset, é importante definir require_scrape_enabled_label_for_nodes: true para que o POMI não colete métricas duplicadas.

Para o destino do endpoint pelo New Relic Kubernetes Daemonset, consulte nosso README do Kubernetes no GitHub.

POMI: etiqueta de raspagem para nós

O POMI descobrirá qualquer endpoint do Prometheus exposto no nível do nó por padrão. Isso normalmente inclui métricas provenientes do Kubelet e do cAdvisor.

Se você estiver executando o New Relic Kubernetes Daemonset, é importante definir require_scrape_enabled_label_for_nodes: true para que o POMI não colete métricas duplicadas.

Para o destino do endpoint pelo New Relic Kubernetes Daemonset, consulte nosso README do Kubernetes no GitHub.

Parâmetro de configuração POMI

# Whether k8s nodes need to be labeled to be scraped or not. 
# Defaults to false.
  require_scrape_enabled_label_for_nodes: false

POMI: coexistindo com nri-kubernetes

A integração do Kubernetes da New Relic coleta uma série de métricas prontas para uso. Porém, não coleta todas as métricas possíveis disponíveis de um cluster do Kubernetes.

Na configuração do POMI, você verá uma seção semelhante a esta que desabilitará a coleta de métrica para um subconjunto de métrica que a integração do New Relic Kubernetes já está coletando do Kube State Metrics.

Também é muito importante definir require_scrape_enabled_label_for_node: true para que as métricas do Kubelet e do cAdvisor não sejam duplicadas.

Parâmetro de configuração POMI:

transformations:
    - description: "Uncomment if running New Relic Kubernetes integration"
      ignore_metrics:
        - prefixes:
          - kube_daemonset_
          - kube_deployment_
          - kube_endpoint_
          - kube_namespace_
          - kube_node_
          - kube_persistentvolume_
          - kube_persistentvolumeclaim_
          - kube_pod_
          - kube_replicaset_
          - kube_service_
          - kube_statefulset_

POMI: configurações de solicitação/limite

Ao executar o POMI, é recomendado aplicar os seguintes limites de recursos para cluster que gera aproximadamente 500 mil DPM:

• Limite de CPU: 1 núcleo (1000m)
• Limite de memória: 1Gb 1024 (1G)

A solicitação de recursos para CPU e memória deve ser definida em algo razoável para que o POMI receba recursos suficientes do cluster. Definir isso para algo extremamente baixo (por exemplo cpu: 50m) pode resultar no consumo de recursos do cluster por "vizinhos barulhentos".

Parâmetro de configuração POMI:

spec:
  serviceAccountName: nri-prometheus
  containers:
  - name: nri-prometheus
    image: newrelic/nri-prometheus:2.2.0
    resources:
      requests:
        memory: 512Mi
        cpu: 500m
      limits:
        memory: 1G
        cpu: 1000m

POMI: estimando DPM e cardinalidade

Embora a cardinalidade não esteja associada diretamente à ingestão faturável por GB, a New Relic mantém certos limites de taxa de cardinalidade e pontos de dados por minuto. Ser capaz de visualizar a cardinalidade e o DPM de um cluster Prometheus pode ser muito importante.

Se você já estiver executando o Prometheus Server, poderá executar estimativas de DPM e cardinalidade antes de ativar o POMI ou remote_write.

Pontos de dados por minuto (DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 métricas (cardinalidade alta):

topk(20, count by (**name**, job)({__name__=~".+"}))

Algumas integrações na nuvem da New Relic obtêm dados da API dos provedores de nuvem. Com essa implementação, os dados geralmente são coletados de API de monitoramento, como AWS CloudWatch, Azure Monitor e GCP Stackdriver, e os metadados de inventário são coletados da API de serviços específicos.

Outras integrações na nuvem obtêm seus dados de métricas de streaming (ou métricas "pushed") que são enviadas por meio de um serviço de streaming como o AWS Kinesis.

Polling integração baseada em API

Se você quiser reportar mais ou menos dados da sua integração na nuvem, ou se precisar controlar o uso da API dos provedores de nuvem para evitar atingir limites de taxa e limitação em sua conta de nuvem, você pode alterar as definições de configuração para modificar o quantidade de dados que eles relatam. Os dois controles principais são:

• Alterar frequência de votação

• Alterar quais dados são relatados

  Exemplos de motivos comerciais para querer alterar a frequência das pesquisas incluem:

• Faturamento: se você precisar gerenciar sua fatura do AWS CloudWatch, talvez seja necessário diminuir a frequência de pesquisa. Antes de fazer isso, certifique-se de que nenhuma configuração de alerta definida para sua integração na nuvem seja afetada por essa redução.

• Novos serviços: se você estiver implantando um novo serviço ou configuração e quiser coletar dados com mais frequência, talvez seja necessário aumentar temporariamente a frequência de pesquisa.

  Cuidado

  Alterar as definições de configuração da sua integração pode afetar a condição do alerta e as tendências do gráfico.

  Para obter mais detalhes, consulte Configurar sondagem.

  Métrica de "streaming" ou "push"

  Cada vez mais a integração na nuvem está oferecendo a opção de enviar os dados por meio de um serviço de streaming em vez de usar a pesquisa de API. Isso provou reduzir drasticamente a latência. Um problema que alguns usuários observaram é que não é tão fácil controlar o volume porque a taxa de amostragem não pode ser configurada.

  New Relic para descarte de dados serão bem abordadas na próxima seção. Eles são a principal forma de filtrar métricas de streaming com volume muito alto. No entanto, há algumas coisas que podem ser feitas pelo provedor de nuvem para limitar um pouco o volume do fluxo.

  Por exemplo, na AWS é possível usar chaves de condição para limitar o acesso aos namespaces do CloudWatch*.

  A política a seguir limita o usuário a publicar métricas apenas no namespace denominado MyCustomNamespace:

  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Resource": "*",
      "Action": "cloudwatch:PutMetricData",
      "Condition": {
        "StringEquals": {
          "cloudwatch:namespace": "MyCustomNamespace"
        }
      }
    }
  }

  Copiar

  A política a seguir permite ao usuário publicar métricas em qualquer namespace, exceto CustomNamespace2:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData"
      },
      {
        "Effect": "Deny",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData",
        "Condition": {
          "StringEquals": {
            "cloudwatch:namespace": "CustomNamespace2"
          }
        }
      }
    ]
  }

  Copiar

Todas as regras de descarte do New Relic são implementadas pelo mesmo modelo de dados backend e API. No entanto, o gerenciamento de logs da New Relic fornece uma interface de usuário poderosa que facilita muito a criação e monitor de regras de descarte.

Em nossa seção anterior sobre como priorizar a telemetria, fizemos alguns exercícios para mostrar maneiras pelas quais poderíamos descontinuar determinados dados. Vamos revisitar este exemplo:

Omit debug logs (knowing they can be turned on if there is an issue) (saves 5%)

Método 1: interfacelog

• Identifique o log de nosso interesse usando um filtro na interface log : level: DEBUG.
• Certifique-se de encontrar o log que queremos descartar.
• Verifique algumas sintaxes alternativas, como level:debug e log_level:Debug. Essas variações são comuns.
• Em Manage data, clique em Drop filters e crie e ative um filtro chamado "Remover log de depuração".
• Verifique se a regra funciona.

Método 2: Nossa API NerdGraph

• Crie a consulta NRQL relevante:

  SELECT count(*) FROM Log WHERE `level` = 'DEBUG'

  Copiar
• Certifique-se de encontrar o log que queremos descartar.
• Verifique variações no nome e valor do atributo (Debug vs DEBUG).
• Execute a seguinte instrução NerdGraph e certifique-se de que funciona:

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM Log WHERE `level` = 'DEBUG'"
        description: "Drops DEBUG logs.  Disable if needed for troubleshooting."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Vamos implementar a recomendação: Drop process sample data in DEV environments.

• Crie a consulta relevante:

  SELECT * FROM ProcessSample WHERE `env` = 'DEV'

  Copiar

• Certifique-se de encontrar as amostras de processo que queremos descartar

• Verifique outras variações de env , como ENV e Environment

• Verifique vários de DEV , como Dev e Development

• Use nossa API NerdGraph para executar a seguinte instrução e certifique-se de que funciona:

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM ProcessSample WHERE `env` = 'DEV'"
          description: "Drops ProcessSample from development environments"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  Copiar

Em alguns casos, podemos economizar dados onde temos cobertura redundante. Por exemplo: em um ambiente onde você tem a integração AWS RDS em execução, bem como uma das integrações New Relic no host que monitor SQL banco de dados como nri-mysql ou nri-postgresql você pode descartar algumas métricas sobrepostas.

Para uma exploração rápida, podemos executar uma consulta como esta:

FROM Metric select count(*) where metricName like 'aws.rds%' facet metricName limit max

Isso nos mostrará todos os valores metricName que correspondem ao padrão.

Vemos pelos resultados que há um grande volume de métricas do padrão aws.rds.cpu%. Vamos abandoná-los porque temos outra instrumentação para eles:

• Crie a consulta relevante:

  FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago

  Copiar
• Certifique-se de encontrar as amostras de processo que queremos descartar.
• Use a API NerdGraph para executar a seguinte instrução e certifique-se de que funciona:

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago"
        description: "Drops rds cpu related metrics"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Uma coisa poderosa sobre as regras de descarte é que podemos configurar uma regra que descarta um atributo específico, mas mantém o restante dos dados intactos. Use isto para remover dados privados do NRDB ou para eliminar atributos excessivamente grandes. Por exemplo, o rastreamento de pilha ou grandes pedaços de JSON em registros de log às vezes podem ser muito grandes.

Para definir essas regras de descarte, altere o campo action para DROP_ATTRIBUTES em vez de DROP_DATA.

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT stack_trace, json_data FROM Log where appName='myApp'"
        description: "Drops large fields from logs for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Neste exemplo, aproveitaremos a distribuição relativa de determinados IDs trace para aproximar a amostragem aleatória. Podemos usar o operador rlike para verificar os valores iniciais do atributo trace.id de um intervalo.

O exemplo a seguir poderia eliminar cerca de 25% dos períodos:

SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'

Expressões úteis incluem:

• r'.*0' aproxima 6,25%
• r'.*[0-1]' aproxima 12,5%
• r'.*[0-2]' aproxima 18,75%
• r'.*[0-3]' aproxima 25,0%

Aqui está um exemplo de uma mutação completa:

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'"
        description: "Drops approximately 25% of spans for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Os exemplos anteriores devem mostrar tudo o que você precisa saber para usar essas técnicas em qualquer outro evento ou métrica no NRDB. Se você puder consultá-lo, você pode abandoná-lo. Entre em contato com a New Relic se tiver dúvidas sobre a maneira precisa de estruturar uma consulta para uma regra de eliminação.