Enviar métricas do Prometheus para o espaço de trabalho do Log Analytics com informações do Container
Este artigo descreve como enviar métricas do Prometheus do cluster do Kubernetes monitorado pelo Container insights para um espaço de trabalho do Log Analytics. Antes de executar essa configuração, você deve primeiro garantir que está raspando as métricas do Prometheus do seu cluster usando o serviço gerenciado do Azure Monitor para Prometheus, que é o método recomendado para monitorar seus clusters. Use a configuração descrita neste artigo somente se também quiser enviar esses mesmos dados para um espaço de trabalho do Log Analytics, onde você pode analisá-los usando consultas de log e alertas de pesquisa de log.
Essa configuração requer a configuração do complemento de monitoramento para o agente do Azure Monitor, que é o mesmo usado pelo Container insights para enviar dados para um espaço de trabalho do Log Analytics. Ele requer a exposição do ponto de extremidade de métricas Prometheus por meio de seus exportadores ou pods e, em seguida, a configuração do complemento de monitoramento para o agente do Azure Monitor usado pelo Container insights, conforme mostrado no diagrama a seguir.
Configurações de raspagem do Prometheus (para métricas armazenadas como logs)
A raspagem ativa de métricas do Prometheus é realizada de uma das duas perspetivas abaixo e as métricas são enviadas para o espaço de trabalho de análise de log configurado:
- Em todo o cluster: definido na seção ConfigMap [Prometheus data_collection_settings.cluster].
- Node-wide: Definido na seção ConfigMap [Prometheus_data_collection_settings.node].
Ponto final | Âmbito | Exemplo |
---|---|---|
Anotação do pod | Em todo o cluster | prometheus.io/scrape: "true" prometheus.io/path: "/mymetrics" prometheus.io/port: "8000" prometheus.io/scheme: "http" |
Serviço Kubernetes | Em todo o cluster | http://my-service-dns.my-namespace:9100/metrics http://metrics-server.kube-system.svc.cluster.local/metrics |
URL/ponto final | Por nó e/ou em todo o cluster | http://myurl:9101/metrics |
Quando uma URL é especificada, o Container insights apenas raspa o ponto de extremidade. Quando o serviço Kubernetes é especificado, o nome do serviço é resolvido com o servidor DNS do cluster para obter o endereço IP. Em seguida, o serviço resolvido é raspado.
Âmbito | Chave | Tipo de dados | valor | Description |
---|---|---|---|---|
Em todo o cluster | Especifique qualquer um dos três métodos a seguir para coletar pontos de extremidade para métricas. | |||
urls |
String | Matriz separada por vírgulas | Ponto de extremidade HTTP (endereço IP ou caminho de URL válido especificado). Por exemplo: urls=[$NODE_IP/metrics] . ($NODE_IP é um parâmetro específico de insights de contêiner e pode ser usado em vez de um endereço IP de nó. Deve ser todo em maiúsculas.) |
|
kubernetes_services |
String | Matriz separada por vírgulas | Uma matriz de serviços do Kubernetes para extrair métricas de métricas de kube-state-metrics. Nomes de domínio totalmente qualificados devem ser usados aqui. Por exemplokubernetes_services = ["http://metrics-server.kube-system.svc.cluster.local/metrics",http://my-service-dns.my-namespace.svc.cluster.local:9100/metrics] |
|
monitor_kubernetes_pods |
Boolean | verdadeiro ou falso | Quando definido como true nas configurações de todo o cluster, o agente Container insights raspa pods do Kubernetes em todo o cluster para as seguintes anotações do Prometheus:prometheus.io/scrape: prometheus.io/scheme: prometheus.io/path: prometheus.io/port: |
|
prometheus.io/scrape |
Boolean | verdadeiro ou falso | Permite a raspagem do pod e monitor_kubernetes_pods deve ser definido como true . |
|
prometheus.io/scheme |
String | http | O padrão é raspagem por HTTP. | |
prometheus.io/path |
String | Matriz separada por vírgulas | O caminho do recurso HTTP a partir do qual buscar métricas. Se o caminho da métrica não /metrics for , defina-o com esta anotação. |
|
prometheus.io/port |
String | 9102 | Especifique uma porta a partir da qual raspar. Se a porta não estiver definida, o padrão será 9102. | |
monitor_kubernetes_pods_namespaces |
String | Matriz separada por vírgulas | Uma lista permitida de namespaces para coletar métricas de pods do Kubernetes. Por exemplo, monitor_kubernetes_pods_namespaces = ["default1", "default2", "default3"] |
|
Em todo o nó | urls |
String | Matriz separada por vírgulas | Ponto de extremidade HTTP (endereço IP ou caminho de URL válido especificado). Por exemplo: urls=[$NODE_IP/metrics] . ($NODE_IP é um parâmetro específico de insights de contêiner e pode ser usado em vez de um endereço IP de nó. Deve ser todo em maiúsculas.) |
Em todo o nó ou em todo o cluster | interval |
String | 60 s | O intervalo de coleta padrão é de um minuto (60 segundos). Você pode modificar a coleção para [ prometheus_data_collection_settings.node] e/ou [prometheus_data_collection_settings.cluster] para unidades de tempo como s, m e h. |
Em todo o nó ou em todo o cluster | fieldpass fielddrop |
String | Matriz separada por vírgulas | Você pode especificar determinadas métricas a serem coletadas ou não do ponto de extremidade definindo a listagem permitir (fieldpass ) e não permitir (fielddrop ). Você deve definir a lista de permissões primeiro. |
Configurar o ConfigMaps para especificar a configuração de raspagem do Prometheus (para métricas armazenadas como logs)
Execute as etapas a seguir para configurar o arquivo de configuração do ConfigMap para o cluster. ConfigMaps é uma lista global e pode haver apenas um ConfigMap aplicado ao agente. Você não pode ter outro ConfigMaps anulando as coleções.
Baixe o arquivo YAML do modelo ConfigMap e salve-o como container-azm-ms-agentconfig.yaml. Se você já implantou um ConfigMap em seu cluster e deseja atualizá-lo com uma configuração mais recente, você pode editar o arquivo ConfigMap que você usou anteriormente.
Edite o arquivo YAML do ConfigMap com suas personalizações para raspar as métricas do Prometheus.
Para coletar serviços do Kubernetes em todo o cluster, configure o arquivo ConfigMap usando o seguinte exemplo:
prometheus-data-collection-settings: |- # Custom Prometheus metrics data collection settings [prometheus_data_collection_settings.cluster] interval = "1m" ## Valid time units are s, m, h. fieldpass = ["metric_to_pass1", "metric_to_pass12"] ## specify metrics to pass through fielddrop = ["metric_to_drop"] ## specify metrics to drop from collecting kubernetes_services = ["http://my-service-dns.my-namespace:9102/metrics"]
Execute o seguinte comando kubectl:
kubectl apply -f <configmap_yaml_file.yaml>
.Exemplo:
kubectl apply -f container-azm-ms-agentconfig.yaml
.
A alteração de configuração pode levar alguns minutos para ser concluída antes de entrar em vigor. Todos os pods ama-logs no cluster serão reiniciados. Quando as reinicializações estiverem concluídas, aparecerá uma mensagem semelhante à seguinte e incluirá o resultado configmap "container-azm-ms-agentconfig" created
.
Verificar a configuração da regra
Para verificar se a configuração foi aplicada com êxito a um cluster, use o seguinte comando para revisar os logs de um pod de agente: kubectl logs ama-logs-fdf58 -n=kube-system
.
Se houver erros de configuração dos pods do Azure Monitor Agent, a saída mostrará erros semelhantes ao exemplo a seguir:
***************Start Config Processing********************
config::unsupported/missing config schema version - 'v21' , using defaults
Erros relacionados à aplicação de alterações de configuração também estão disponíveis para revisão. As seguintes opções estão disponíveis para executar a solução de problemas adicionais de alterações de configuração e raspagem de métricas do Prometheus:
A partir de um pod de agente registra usando o mesmo
kubectl logs
comando.De dados em tempo real. Os logs de dados em tempo real mostram erros semelhantes ao exemplo a seguir:
2019-07-08T18:55:00Z E! [inputs.prometheus]: Error in plugin: error making HTTP request to http://invalidurl:1010/metrics: Get http://invalidurl:1010/metrics: dial tcp: lookup invalidurl on 10.0.0.10:53: no such host
Na tabela KubeMonAgentEvents no espaço de trabalho do Log Analytics. Os dados são enviados a cada hora com severidade de aviso para erros de raspagem e gravidade de erro para erros de configuração. Se não houver erros, a entrada na tabela tem dados com informações de gravidade, que não relatam erros. A propriedade Tags contém mais informações sobre o pod e o ID do contêiner no qual o erro ocorreu e também a primeira ocorrência, a última ocorrência e a contagem na última hora.
Para o Azure Red Hat OpenShift v3.x e v4.x, verifique os logs do Azure Monitor Agent pesquisando a tabela ContainerLog para verificar se a coleta de logs do openshift-azure-logging está habilitada.
Os erros impedem que o Azure Monitor Agent analise o arquivo, fazendo com que ele reinicie e use a configuração padrão. Depois de corrigir os erros no ConfigMap em clusters diferentes do Azure Red Hat OpenShift v3.x, salve o arquivo YAML e aplique o ConfigMaps atualizado executando o comando kubectl apply -f <configmap_yaml_file.yaml
.
Para o Azure Red Hat OpenShift v3.x, edite e salve o ConfigMaps atualizado executando o comando oc edit configmaps container-azm-ms-agentconfig -n openshift-azure-logging
.
Consultar dados de métricas do Prometheus
Para exibir as métricas do Prometheus raspadas pelo Azure Monitor e quaisquer erros de configuração/raspagem relatados pelo agente, revise os dados de métricas do Query Prometheus.
Ver métricas Prometheus em Grafana
O Container insights oferece suporte à visualização de métricas armazenadas em seu espaço de trabalho do Log Analytics nos painéis do Grafana. Nós fornecemos um modelo que você pode baixar do repositório do painel do Grafana. Use o modelo para começar e faça referência a ele para ajudá-lo a aprender a consultar outros dados de seus clusters monitorados para visualizar em painéis personalizados do Grafana.