Personalizar a raspagem de métricas do Prometheus no serviço gerenciado do Azure Monitor para Prometheus
Este artigo fornece instruções sobre como personalizar a raspagem de métricas para um cluster do Kubernetes com o complemento de métricas no Azure Monitor.
Mapas de configuração
Quatro configmaps diferentes podem ser configurados para fornecer configuração de raspagem e outras configurações para o complemento de métricas. Todos os config-maps devem ser aplicados ao kube-system
namespace para qualquer cluster.
Nota
Nenhum dos quatro configmaps existe por padrão no cluster quando o Managed Prometheus está habilitado. Dependendo do que precisa ser personalizado, você precisa implantar qualquer um ou todos esses quatro configmaps com o mesmo nome especificado, no kube-system
namespace. Os pods AMA-Metrics pegarão esses configmaps depois de implantá-los no kube-system
namespace e serão reiniciados em 2-3 minutos para aplicar as definições de configuração especificadas no(s) configmap(s).
ama-metrics-settings-configmap
Este mapa de configuração tem abaixo configurações simples que podem ser configuradas. Você pode pegar o configmap do repositório do hub git acima, alterar as configurações necessárias e aplicar/implantar o configmap aokube-system
namespace para seu cluster- alias de cluster (para alterar o valor de
cluster
label em cada série/métrica temporal ingerida de um cluster) - ativar/desativar alvos de raspagem padrão - Ative / DESATIVE a raspagem padrão com base nos destinos. A configuração de raspagem para esses destinos padrão já está pré-definida/integrada
- habilitar a raspagem baseada em anotação de pod por namespace
- Listas de manutenção de métricas - essa configuração é usada para controlar quais métricas são listadas para serem permitidas a partir de cada destino padrão e para alterar o comportamento padrão
- Intervalos de raspagem para Default/Pre-DefineTargets.
30 secs
é a frequência de raspagem padrão e pode ser alterada por destino padrão usando este configmap - modo de depuração - ativar esta opção ajuda a depurar problemas de métrica/ingestão ausentes - veja mais sobre solução de problemas
- alias de cluster (para alterar o valor de
ama-metrics-prometheus-config
Este mapa de configuração pode ser usado para fornecer Prometheus scrape config para réplica de addon. O Addon executa uma réplica singleton e qualquer serviço de nível de cluster pode ser descoberto e raspado fornecendo trabalhos de raspagem neste configmap. Você pode pegar o exemplo configmap do repositório do hub git acima, adicionar trabalhos de raspagem que você precisaria e aplicar/implantar o mapa de configuração aokube-system
namespace para seu cluster. Embora isso seja suportado, observe que a maneira recomendada de raspar destinos personalizados é usando recursos personalizadosama-metrics-prometheus-config-node
(Avançado) Este mapa de configuração pode ser usado para fornecer Prometheus scrape config para addon DaemonSet que é executado em cada nó Linux no cluster, e quaisquer alvos de nível de nó em cada nó podem ser raspados fornecendo trabalhos de raspagem neste configmap. Quando você usa este configmap, você pode usar$NODE_IP
a variável em sua configuração de scrape, que é substituída pelo endereço IP do nó correspondente no pod DaemonSet em execução em cada nó. Dessa forma, você tem acesso para raspar qualquer coisa que seja executada nesse nó a partir do addon de métricas DaemonSet. Tenha cuidado ao usar descobertas na configuração de raspagem neste mapa de configuração de nível de nó, pois cada nó no cluster configurará & descobrirá o(s) destino(s) e coletará métricas redundantes. Você pode pegar o exemplo configmap do repositório git hub acima, adicionar trabalhos de raspagem que você precisaria e aplicar/implantar o mapa de configuração no namespace parakube-system
seu clusterama-metrics-prometheus-config-node-windows
(Avançado) Este mapa de configuração pode ser usado para fornecer Prometheus scrape config para addon DaemonSet que é executado em cada nó do Windows no cluster, e os alvos de nível de nó em cada nó podem ser raspados fornecendo trabalhos de raspagem neste configmap. Quando você usa este configmap, você pode usar$NODE_IP
a variável em sua configuração de scrape, que será substituída pelo endereço ip do nó correspondente no pod DaemonSet em execução em cada nó. Dessa forma, você tem acesso para raspar qualquer coisa que seja executada nesse nó a partir do addon de métricas DaemonSet. Tenha cuidado ao usar descobertas na configuração de raspagem neste mapa de configuração de nível de nó, pois cada nó no cluster configurará & descobrirá o(s) destino(s) e coletará métricas redundantes. Você pode pegar o exemplo configmap do repositório git hub acima, adicionar trabalhos de raspagem que você precisaria e aplicar/implantar o mapa de configuração no namespace parakube-system
seu cluster
Definições de recursos personalizados
O complemento de métricas do Azure Monitor dá suporte à raspagem de métricas do Prometheus usando o Prometheus - Pod Monitors e Service Monitors, semelhante ao operador OSS Prometheus. Habilitar o complemento implantará as definições de recursos personalizados do Pod e do Service Monitor para permitir que você crie seus próprios recursos personalizados. Siga as instruções para criar e aplicar recursos personalizados no cluster.
Configurações do complemento de métricas configmap
O ama-metrics-settings-configmap pode ser baixado, editado e aplicado ao cluster para personalizar os recursos prontos para uso do complemento de métricas.
Habilitar e desabilitar destinos padrão
A tabela a seguir tem uma lista de todos os destinos padrão que o complemento de métricas do Azure Monitor pode raspar por padrão e se ele está habilitado inicialmente. Os alvos padrão são raspados a cada 30 segundos. Uma réplica é implantada para raspar destinos em todo o cluster, como kube-state-metrics. Um DaemonSet também é implantado para raspar alvos em todo o nó, como kubelet.
Chave | Type | Ativado(a) | Pod | Description |
---|---|---|---|---|
kubelet | booleano | true |
Linux DaemonSet | Raspe kubelet em cada nó no cluster K8s sem qualquer configuração de raspagem extra. |
cConselheiro | booleano | true |
Linux DaemonSet | Raspe o cadvisor em cada nó do cluster K8s sem nenhuma configuração de raspagem extra. Apenas Linux. |
Kubestate | booleano | true |
Réplica do Linux | Raspe kube-state-metrics no cluster K8s (instalado como parte do complemento) sem qualquer configuração de raspagem extra. |
nodeexporter | booleano | true |
Linux DaemonSet | Raspe métricas de nó sem qualquer configuração de raspagem extra. Apenas Linux. |
Coredns | booleano | false |
Réplica do Linux | Serviço de raspagem de coredns no cluster K8s sem qualquer configuração de raspagem extra. |
kubeproxy | booleano | false |
Linux DaemonSet | Raspe kube-proxy em cada nó Linux descoberto no cluster K8s sem qualquer configuração de scrape extra. Apenas Linux. |
apiserver | booleano | false |
Réplica do Linux | Raspe o servidor de API do Kubernetes no cluster K8s sem nenhuma configuração de raspagem extra. |
windowsexportador | booleano | false |
Windows DaemonSet | Raspe o exportador de janelas em cada nó do cluster K8s sem qualquer configuração de raspagem extra. Apenas Windows. |
windowskubeproxy | booleano | false |
Windows DaemonSet | Raspe windows-kube-proxy em cada nó no cluster K8s sem qualquer configuração de raspagem extra. Apenas Windows. |
PrometheusCollectorHealth | booleano | false |
Réplica do Linux | Raspe informações sobre o recipiente coletor de prometheus, como a quantidade e o tamanho da série temporal raspada. |
Se você quiser ativar a raspagem dos destinos padrão que não estão habilitados por padrão, edite o configmap ama-metrics-settings-configmap
para atualizar os destinos listados em .true
default-scrape-settings-enabled
Aplique o configmap ao cluster.
Habilitar a raspagem baseada em anotação de pod
Para raspar pods de aplicativos sem a necessidade de criar uma configuração personalizada do Prometheus, anotações podem ser adicionadas aos pods. A anotação prometheus.io/scrape: "true"
é necessária para que o pod seja raspado. As anotações prometheus.io/path
e prometheus.io/port
indicam o caminho e a porta em que as métricas estão hospedadas no pod. As anotações para um pod que está hospedando métricas seriam <pod IP>:8080/metrics
:
metadata:
annotations:
prometheus.io/scrape: 'true'
prometheus.io/path: '/metrics'
prometheus.io/port: '8080'
A raspagem desses pods com anotações específicas é desabilitada por padrão. Para habilitar, no ama-metrics-settings-configmap
, adicione o regex para o(s) namespace(s) dos pods com anotações que você deseja raspar como o valor do campo podannotationnamespaceregex
.
Por exemplo, a configuração a seguir raspa pods com anotações somente nos namespaces kube-system
e my-namespace
:
pod-annotation-based-scraping: |-
podannotationnamespaceregex = "kube-system|my-namespace"
Para habilitar a raspagem para pods com anotações em todos os namespaces, use:
pod-annotation-based-scraping: |-
podannotationnamespaceregex = ".*"
Aviso
Raspar as anotações de pod de muitos namespaces pode gerar um volume muito grande de métricas, dependendo do número de pods que têm anotações.
Personalizar métricas coletadas por destinos padrão
Por padrão, para todos os destinos padrão, apenas métricas mínimas usadas nas regras de gravação padrão, alertas e painéis do Grafana são ingeridas conforme descrito em perfil de ingestão mínima. Para coletar todas as métricas dos destinos padrão, atualize as listas de manutenção no configmap de configurações em default-targets-metrics-keep-list
, e defina minimalingestionprofile
como false
.
Para permitir a lista de mais métricas, além das métricas padrão listadas para serem permitidas, para quaisquer destinos padrão, edite as configurações em default-targets-metrics-keep-list
para o trabalho correspondente que você deseja alterar.
Por exemplo, kubelet
é a configuração de filtragem métrica para o kubelet de destino padrão. Use o script a seguir para filtrar as métricas coletadas para os destinos padrão usando a filtragem baseada em regex.
kubelet = "metricX|metricY"
apiserver = "mymetric.*"
Nota
Se você usar aspas ou barras invertidas no regex, você precisa escapar delas usando uma barra invertida como os exemplos "test\'smetric\"s\""
e testbackslash\\*
.
Para personalizar ainda mais os trabalhos padrão para alterar propriedades como frequência de coleta ou rótulos, desative o destino padrão correspondente definindo o valor configmap para o destino como false
. Em seguida, aplique o trabalho usando um configmap personalizado. Para obter detalhes sobre a configuração personalizada, consulte Personalizar a raspagem de métricas do Prometheus no Azure Monitor.
Alias de cluster
O rótulo de cluster anexado a cada série temporal raspada usa a última parte da ID de recurso do Azure Resource Manager do cluster AKS completo. Por exemplo, se o ID do recurso for /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername
, o rótulo do cluster será myclustername
.
Para substituir o rótulo do cluster na série temporal raspada, atualize a configuração cluster_alias
para qualquer cadeia de caracteres no prometheus-collector-settings
configmap ama-metrics-settings-configmap
. Você pode criar esse configmap se ele não existir no cluster ou pode editar o existente se ele já existir no cluster.
O novo rótulo também aparece na lista suspensa de parâmetros de cluster nos painéis do Grafana em vez do padrão.
Nota
Só são permitidos caracteres alfanuméricos. Quaisquer outros caracteres são substituídos por _
. Esta alteração destina-se a garantir que os diferentes componentes que consomem este rótulo aderem à convenção alfanumérica básica.
Se você estiver habilitando regras de gravação e alerta, certifique-se de usar o nome do alias do cluster no parâmetro de nome do cluster do modelo de integração de regras para que as regras funcionem.
Modo de depuração
Aviso
Esse modo pode afetar o desempenho e só deve ser habilitado por um curto período de tempo para fins de depuração.
Para exibir cada métrica que está sendo raspada para fins de depuração, o agente de complemento de métricas pode ser configurado para ser executado no modo de depuração atualizando a configuração enabled
para sob a debug-mode
configuração no configmap ama-metrics-settings-configmap
.true
Você pode criar este configmap ou editar um existente. Para obter mais informações, consulte a seção Modo de depuração em Solucionar problemas da coleção de métricas do Prometheus.
Configurações de intervalo de raspagem
Para atualizar as configurações de intervalo de raspagem para qualquer destino, você pode atualizar a duração na configuração default-targets-scrape-interval-settings
para esse destino no configmap ama-metrics-settings-configmap
. Você tem que definir os intervalos de raspagem no formato correto especificado neste site. Caso contrário, o valor padrão de 30 segundos será aplicado aos destinos correspondentes. Por exemplo - Se você quiser atualizar o intervalo de raspagem para o kubelet
trabalho 60s
, então você pode atualizar a seguinte seção no YAML:
default-targets-scrape-interval-settings: |-
kubelet = "60s"
coredns = "30s"
cadvisor = "30s"
kubeproxy = "30s"
apiserver = "30s"
kubestate = "30s"
nodeexporter = "30s"
windowsexporter = "30s"
windowskubeproxy = "30s"
kappiebasic = "30s"
prometheuscollectorhealth = "30s"
podannotations = "30s"
e aplique o YAML usando o seguinte comando: kubectl apply -f .\ama-metrics-settings-configmap.yaml
Configurar trabalhos de raspagem personalizados do Prometheus
Você pode raspar métricas Prometheus usando Prometheus - Pod Monitors e Service Monitors(Recomendado), semelhante ao operador OSS Prometheus. Siga as instruções para criar e aplicar recursos personalizados no cluster.
Além disso, você pode seguir as instruções para criar, validar e aplicar o configmap para seu cluster. O formato de configuração é semelhante ao arquivo de configuração Prometheus.
Dicas e exemplos de configuração do Prometheus
Aprenda algumas dicas de exemplos nesta seção.
- Configuração usando CRD para configuração de raspagem personalizada
- Arquivo de configuração para configuração de raspagem personalizada
Use os modelos Pod e Service Monitor e siga a especificação da API para criar seus recursos personalizados (PodMonitor e Service Monitor). Observe que a única alteração necessária para as CRs OSS existentes para serem coletadas pelo Managed Prometheus é o grupo de API - azmonitoring.coreos.com/v1. Veja aqui para saber mais
Nota
Quando a configuração de raspagem personalizada não é aplicada devido a erros de validação, a configuração de raspagem padrão continua a ser usada.
Se você quiser usar configurações globais que se aplicam a todos os trabalhos de raspagem e ter apenas Recursos Personalizados , ainda precisará criar um configmap apenas com as configurações globais (as configurações para cada um deles nos recursos personalizados substituirão as da seção global)
Raspar configurações
Atualmente, os métodos suportados de descoberta de destino para recursos personalizados são pod e service monitor
Monitores de pod e serviço
Os alvos descobertos usando pod e monitores de serviço têm rótulos diferentes __meta_*
, dependendo do monitor usado. Você pode usar os rótulos na relabelings
seção para filtrar destinos ou substituir rótulos para os destinos.
Veja os exemplos de Pod e Service Monitor de pod e monitores de serviço.
Rerotulagens
A relabelings
seção é aplicada no momento da descoberta do destino e se aplica a cada destino para o trabalho. Os exemplos a seguir mostram maneiras de usar relabelings
o .
Adicionar uma etiqueta
Adicione um novo rótulo chamado example_label
com o valor example_value
a cada métrica do trabalho. Use __address__
como rótulo de origem somente porque esse rótulo sempre existe e adiciona o rótulo para cada destino do trabalho.
relabelings:
- sourceLabels: [__address__]
targetLabel: example_label
replacement: 'example_value'
Usar rótulos do Pod ou do Service Monitor
Os alvos descobertos usando pod e monitores de serviço têm rótulos diferentes __meta_*
, dependendo do monitor usado. Os __*
rótulos são descartados depois de descobrir os alvos. Para filtrar usando-os no nível de métricas, primeiro mantenha-os usando relabelings
atribuindo um nome de rótulo. Em seguida, use metricRelabelings
para filtrar.
# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
action: replace
targetLabel: kubernetes_namespace
# Keep only metrics with the kubernetes namespace 'default'
metricRelabelings:
- sourceLabels: [kubernetes_namespace]
action: keep
regex: 'default'
Rerotulagem de tarefas e instâncias
Você pode alterar os job
valores e instance
label com base no rótulo de origem, assim como qualquer outro rótulo.
# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
targetLabel: job
# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
targetLabel: instance
Nota
Se você tiver configurações de rerotulagem, certifique-se de que a rerotulagem não filtre os destinos e que os rótulos configurados corretamente correspondam aos destinos.
Reetiquetas métricas
As remarcações métricas são aplicadas após a raspagem e antes da ingestão. Use a seção para filtrar métricas após a metricRelabelings
raspagem. Os exemplos a seguir mostram como fazer isso.
Solte métricas por nome
# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
action: drop
regex: 'example_metric_name'
Mantenha apenas determinadas métricas por nome
# Keep only the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
action: keep
regex: 'example_metric_name'
# Keep only metrics that start with 'example_'
metricRelabelings:
- sourceLabels: [__name__]
action: keep
regex: '(example_.*)'
Renomear métricas
Não há suporte para renomeação de métricas.
Filtrar métricas por rótulos
# Keep metrics only where example_label = 'example'
metricRelabelings:
- sourceLabels: [example_label]
action: keep
regex: 'example'
# Keep metrics only if `example_label` equals `value_1` or `value_2`
metricRelabelings:
- sourceLabels: [example_label]
action: keep
regex: '(value_1|value_2)'
# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metricRelabelings:
- sourceLabels: [example_label_1, example_label_2]
separator: ';'
action: keep
regex: 'value_1;value_2'
# Keep metrics only if `example_label` exists as a label
metricRelabelings:
- sourceLabels: [example_label_1]
action: keep
regex: '.+'
Autenticação Básica
- Raspar configurações usando o arquivo de configuração
- Raspar configurações usando CRD (Pod/Service Monitor)
Se você estiver usando basic_auth
a configuração em sua configuração prometheus, por favor, siga os passos -
- Crie um segredo no namespace kube-system chamado ama-metrics-mtls-secret
O valor para password1 é base64encoded.
A senha da chave1 pode ser qualquer coisa, mas só precisa corresponder ao seu scrapeconfig password_file filepath.
apiVersion: v1
kind: Secret
metadata:
name: ama-metrics-mtls-secret
namespace: kube-system
type: Opaque
data:
password1: <base64-encoded-string>
O segredo ama-metrics-mtls-secret é montado nos contêineres ama-metrics no caminho - /etc/prometheus/certs/ e é disponibilizado para o processo que está raspando métricas prometheus. A chave( ex - password1) no exemplo acima será o nome do arquivo e o valor é base64 decodificado e adicionado ao conteúdo do arquivo dentro do contêiner e o raspador prometheus usa o conteúdo desse arquivo para obter o valor que é usado como a senha usada para raspar o ponto de extremidade.
- No configmap para a configuração de raspagem personalizada, use a seguinte configuração. O campo username deve conter a cadeia de caracteres de nome de usuário real. O campo password_file deve conter o caminho para um arquivo que contém a senha.
basic_auth:
username: <username string>
password_file: /etc/prometheus/certs/password1
Ao fornecer o caminho para o password_file acima, o raspador prometheus usa o conteúdo do arquivo chamado password1 no caminho /etc/prometheus/certs como o valor da senha para a raspagem básica baseada em autenticação.
Se você estiver usando autenticação básica e autenticação tls, consulte a seção abaixo. Para obter mais detalhes, consulte a seção de notas abaixo.
Raspagem baseada em TLS
Se você tiver uma instância do Prometheus servida com TLS e quiser extrair métricas dela, precisará definir o esquema e https
definir as configurações de TLS em seu configmap ou respetivo CRD.
Siga os passos abaixo.
Crie um segredo no namespace kube-system chamado ama-metrics-mtls-secret. Cada par chave-valor especificado na seção de dados do objeto secreto será montado como um arquivo separado neste local /etc/prometheus/certs com nome de arquivo igual à(s) chave(s) especificada(s) na seção de dados. Os valores secretos devem ser codificados em base64 antes de colocá-los na seção de dados, como abaixo.
Abaixo está um exemplo de criação de segredo através do YAML.
apiVersion: v1 kind: Secret metadata: name: ama-metrics-mtls-secret namespace: kube-system type: Opaque data: <certfile>: base64_cert_content <keyfile>: base64_key_content
O segredo ama-metrics-mtls-secret é montado nos contêineres ama-metrics no caminho - /etc/prometheus/certs/ e é disponibilizado para o processo que está raspando métricas prometheus. A chave( ex - certfile) no exemplo acima será o nome do arquivo e o valor é base64 decodificado e adicionado ao conteúdo do arquivo dentro do contêiner e o raspador prometheus usa o conteúdo desse arquivo para obter o valor que é usado como a senha usada para raspar o ponto de extremidade.
Abaixo estão os detalhes sobre como fornecer as configurações de configuração TLS através de um configmap ou CRD.
- Raspar a configuração usando o arquivo de configuração
- Scrape Config usando CRD (Pod/Service Monitor)
- Para fornecer a configuração TLS em um configmap, siga o exemplo abaixo.
tls_config:
ca_file: /etc/prometheus/certs/<certfile> # since it is self-signed
cert_file: /etc/prometheus/certs/<certfile>
key_file: /etc/prometheus/certs/<keyfile>
insecure_skip_verify: false
Autenticação básica e TLS
Se você quiser usar as configurações de autenticação básica e Tls em seu configmap/CRD, apenas certifique-se de que o segredo ama-metrics-mtls-secret inclui todos os arquivos (chaves) na seção de dados com seus valores codificados de base 64 correspondentes, conforme mostrado abaixo.
apiVersion: v1
kind: Secret
metadata:
name: ama-metrics-mtls-secret
namespace: kube-system
type: Opaque
data:
certfile: base64_cert_content # used for Tls
keyfile: base64_key_content # used for Tls
password1: base64-encoded-string # used for basic auth
password2: base64-encoded-string # used for basic auth
Nota
Nota
O caminho /etc/prometheus/certs/ é obrigatório, mas password1 pode ser qualquer string e precisa corresponder à chave para os dados no segredo criado acima. Isso ocorre porque o segredo ama-metrics-mtls-secret é montado no caminho /etc/prometheus/certs/ dentro do contêiner.
O valor codificado base64 é automaticamente decodificado pelos pods do agente quando o segredo é montado como arquivo.
Verifique se o nome secreto é ama-metrics-mtls-secret e está no namespace kube-system .
O segredo deve ser criado e, em seguida, o configmap/CRD deve ser criado no namespace kube-system. A ordem da criação secreta é importante. Quando não há segredo, mas um mapa CRD/config válido, você encontrará erros no log do coletor ->no file found for cert....
Para ler mais sobre as definições de configuração TLS, siga estas configurações.
Próximos passos
Configurar alertas sobre métricas do Prometheus
Consultar métricas do Prometheus
Saiba mais sobre como coletar métricas do Prometheus