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: 30skubernetes: 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:
- TLS
- OAuth2
- Cabeçalho de autorização
- Autenticação Básica
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"
static_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"