• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.

Criar um problema

Configurar o agente Prometheus

Configurar o agente Prometheus

Você precisa colocar os exemplos abaixo na seção config do agente. Consulte o método de instalação que você conhecia e que é o seu caso.

Para configurar o agente usando Helm, você deve configurar seu values.yaml de uma destas duas maneiras:

Dica

Você precisa adicionar sua New Relic no arquivo values.yaml.

Defina qual endpoint raspar

Por padrão, o agente New Relic Prometheus usa duas anotações para descobrir o destino: newrelic.io/scrape: "true" e prometheus.io/scrape: "true".

Todos os destinos no cluster anotados com newrelic.io/scrape: "true" são descobertos e extraídos por padrão. O destino anotado com prometheus.io/scrape: "true" será raspado ou não dependendo da configuração.

Scrape métrica somente da Prometheus integração

O agente Prometheus pode ser configurado para extrair métricas da integração mais popular no Kubernetes. Dê uma olhada na lista de integração contendo um conjunto de dashboards e para iniciar o monitoramento pronto para uso.

Essa lista é definida no values.yaml do gráfico de comando do agente Prometheus da New Relic. Você pode modificar essa lista, mas alguns podem não funcionar imediatamente com rótulos ou valores personalizados.

Durante a atualização, novos filtros de integração poderão estar disponíveis. Portanto, a quantidade de dados extraídos pode aumentar, dependendo dos serviços do seu cluster, após uma atualização envolvendo filtros de integração. Você pode evitar isso salvando uma lista fixa de app_values em seu arquivo values.yaml . Por exemplo:

app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb"]

Além disso, pode acontecer que uma nova versão dos filtros de integração faça com que um destino que já foi eliminado por um trabalho seja eliminado uma segunda vez. Para receber uma notificação em caso de dados duplicados (e evitar totalmente a eliminação duplicada), você pode criar um alerta com base na seguinte consulta:

FROM Metric select uniqueCount(job) facet instance, cluster_name limit 10 since 2 minutes ago

Se algum valor for diferente de 1, você terá dois ou mais trabalhos extraindo a mesma instância no mesmo cluster.

Raspe métrica de todo o destino

Se você precisar raspar todos os destinos anotados com prometheus.io/scrape: "true", será necessário executar uma das seguintes ações, dependendo do método de instalação escolhido:

  • Se você usou a instalação guiada, selecione a opção Scrape all Prometheus endpoints .

  • Se você usou o Helm, adicione os seguintes valores na configuração do agente prometheus:

    kubernetes:
    integrations_filter:
    enabled: false

Descoberta de destino do Kubernetes

Os jobs Kubernetes descobrem o destino e coletam o destino de acordo com a configuração target_discovery. Se dentro da configuração target_discovery você definir pod e endpoints como true, o Prometheus criará regras para descobrir qualquer pod ou endpoint no cluster que tenha uma porta exposta.

Use o parâmetro de configuração target_discovery.filter para filtrar o destino que o Prometheus coleta. Use os rótulos label e annotations para filtrar pelas condições atuais e o operador AND para todas as condições.

O exemplo a seguir coleta apenas Pods e Endpoints com a anotação newrelic.io/scrape: "true" e o rótulo k8s.io/app com postgres ou mysql como valores. Para o endpoint, a anotação deve estar presente no serviço relacionado a ele. As regexes são ancoradas, ou seja, se você configurar scrape: 'true', o Prometheus avalia true como ^true$. Para evitar isso, use .*true.* para que também corresponda a a-true-example.

kubernetes:
jobs:
- job_name_prefix: example
integrations_filter:
enabled: false
target_discovery:
pod: true
endpoints: true
filter:
annotations:
# <string>: <regex>
newrelic.io/scrape: 'true'
label:
# <string>: <regex>
k8s.io/app: '(postgres|mysql)'

Dica

Se você não adicionar um valor ao rótulo ou à anotação, o filtro verificará apenas se ele existe.

Configurar destino estático

O agente prometheus define um trabalho de destino estático para extrair autométrica por padrão, mas você pode configurar destino estático adicional incluindo trabalhos adicionais.

O exemplo a seguir inclui um trabalho adicional para raspar um servidor gerenciado separadamente e o trabalho autométrico para continuar reportando a métrica do agente prometheus, conforme definido por padrão.

static_targets:
jobs:
- job_name: managed-exporter
targets:
- "managed_exporter.your-company.tld:5432"
- job_name: self-metrics
skip_sharding: true # sharding is skipped to obtain self-metrics from all Prometheus servers.
targets:
- "localhost:9090"
extra_metric_relabel_config:
- source_labels: [__name__]
action: keep
regex: "\
prometheus_agent_active_series|\
prometheus_target_interval_length_seconds|\
prometheus_target_scrape_pool_targets|\
prometheus_remote_storage_samples_pending|\
prometheus_remote_storage_samples_in_total|\
prometheus_remote_storage_samples_retried_total|\
prometheus_agent_corruptions_total|\
prometheus_remote_storage_shards|\
prometheus_sd_kubernetes_events_total|\
prometheus_agent_checkpoint_creations_failed_total|\
prometheus_agent_checkpoint_deletions_failed_total|\
prometheus_remote_storage_samples_dropped_total|\
prometheus_remote_storage_samples_failed_total|\
prometheus_sd_kubernetes_http_request_total|\
prometheus_agent_truncate_duration_seconds_sum|\
prometheus_build_info|\
process_resident_memory_bytes|\
process_virtual_memory_bytes|\
process_cpu_seconds_total"

Cuidado

Se você modificar a seção static_targets e não incluir o trabalho autométrico, as métricas do agente não serão informadas.

Intervalo de raspagem de destino

Por padrão, o agente do Prometheus coleta todos os destinos da métrica a cada 30 segundos, conforme definido em common.scrape_interval para todos os trabalhos de extração na configuração. Você pode alterar isso usando a tecla scrape_interval nessa seção.

Este exemplo mostra dois trabalhos do Kubernetes com intervalos de raspagem diferentes:

common:
scrape_interval: 30s
kubernetes:
jobs:
# this job will use the default scrape_interval defined in common.
- job_name_prefix: default-targets-with-30s-interval
target_discovery:
pod: true
filter:
annotations:
newrelic.io/scrape: 'true'
- job_name_prefix: slow-targets-with-60s-interval
scrape_interval: 60s
target_discovery:
pod: true
filter:
annotations:
newrelic.io/scrape_slow: 'true'

Transformações métricas e de rótulos

Você pode aplicar transformações métricas e de rótulos em qualquer seção de configuração, mas configurá-las em nível de gravação remota torna a filtragem ou transformações mais amplas.

Se você defini-los no nível newrelic_remote_write, os filtros serão aplicados a todas as métricas que estão sendo enviadas para New Relic. Se você defini-los em qualquer outra seção, eles se aplicam à métrica extraída daquela seção. O processo de filtro métrico acontece após a métrica ter sido retirada do destino.

Você pode usar o parâmetro extra_metric_relabel_config para aplicar os filtros, que adiciona entradas do parâmetro metric_relabel_config . Este parâmetro está presente em static_targets.jobs, kubernetes.jobs e no parâmetro extra_write_relabel_configs para newrelic_remote_write.

Aqui está um exemplo de como usá-lo em diferentes partes do arquivo de configuração YAML:

static_targets:
- name: self-metrics
urls:
- 'http://static-service:8181'
extra_metric_relabel_config:
# Drop metrics with prefix 'go_' for this target.
- source_labels: [__name__]
regex: 'go_.+'
action: drop
newrelic_remote_write:
extra_write_relabel_configs:
# Drop all metrics with the specified name before sent to New Relic.
- source_labels: [__name__]
regex: 'metric_name'
action: drop

Exemplos de trechos de arquivo YAML

Adicione um desses exemplos no arquivo de configuração YAML da seção de transformações de métricas e rótulos .

Para filtrar métricas

Para adicionar ou remover rótulos métricos

Importante

Os nomes dos rótulos métricos devem estar em conformidade com o Prometheus DataModel.

Configuração de autorização de destino

Alguns destinos precisam de autorização de acesso para serem raspados, como banco de dados No-SQL para buscar dados que o usuário conectado tem acesso, ou exportadores que expõem dados sensíveis em seu endpoint métrico. Todos os métodos de autorização suportados pelo Prometheus podem ser configurados nas seções static_targets e kubernetes .

Conforme explicado no guia de instalação, criamos uma configuração para o Prometheus baseada em nosso YAML. Esta parte da configuração foi passada para o Prometheus como está em nosso YAML, portanto, você deve consultar a documentação do Prometheus:

Aqui estão alguns exemplos para lidar com destinos que necessitam de autorização de acesso:

kubernetes:
jobs:
- job_name_prefix: skip-verify-on-https-targets
target_discovery:
pod: true
filter:
annotations:
newrelic.io/scrape: 'true'
- job_name_prefix: bearer-token
target_discovery:
pod: true
filter:
label:
k8s.io/app: my-app-with-token
authorization:
type: Bearer
credentials_file: '/etc/my-app/token'
startic_targets:
jobs:
- job_name: mtls-target
scheme: https
targets:
- 'my-mtls-target:8181'
tls_config:
ca_file: '/etc/my-app/client-ca.crt'
cert_file: '/etc/my-app/client.crt'
key_file: '/etc/my-app/client.key'
- job_name: basic-auth-target
targets:
- 'my-basic-auth-static:8181'
basic_auth:
password_file: '/etc/my-app/pass.htpasswd'
Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.