O Ops Manager pode emitir métricas de implantação coletadas pelo MongoDB Agent no formato OpenTelemetry (OTel) para um back-end de observabilidade de terceiros enquanto o Ops Manager continua a receber essas métricas. Esse recurso permite integrar suas implantações do MongoDB em uma pilha de observabilidade existente ou em qualquer outra plataforma que aceite o Protocolo OpenTelemetry (OTLP). Você não precisa de pipelines personalizados, processos de sidecar ou agentes de collection adicionais.
A exportação OTel é aditiva e está desabilitada por padrão. A entrega de métricas ao Ops Manager não é alterada de forma alguma: cada sinal continua a ser transmitido no caminho do Ops Manager existente inalterado. Qualquer falha no caminho de exportação do OTel, como um endpoint inacessível, é isolada para que os relatórios ao Ops Manager nunca sejam interrompidos.
Quando você ativa esse recurso, o MongoDB Agent envia métricas por OTLP/HTTP para o endpoint configurado em uma cadência configurável (o padrão é 30 segundos). Cada ciclo envia uma solicitação OTLP por processo monitorado, além de uma solicitação para a auto-saúde do próprio agente, para que seu backend receba várias solicitações pequenas por intervalo em vez de um lote grande. Seu endpoint pode ser um dos seguintes:
Um coletor OpenTelemetry, que pode processar métricas e encaminhá-las para vários destinos.
Uma plataforma de observabilidade que aceita OTLP nativamente (por exemplo, Datadog, Grafana, Dynatrace).
Você configura este recurso através da Configuração de Automação. O MongoDB Agent coleta as métricas exportadas em seu ciclo de coleta existente, portanto, esse recurso não coloca carga extra em seus processos MongoDB monitorados.
Como a exportação OTel difere da integração Prometeus
O caminho de exportação OTel não substitui a integração existente com o Prometheus. Considerando que a integração do Prometheus é baseada em pull, e o MongoDB Agent expõe um endpoint /metrics que seu servidor do Prometheus raspa. O caminho OTel é baseado em push, e o MongoDB Agent envia métricas para seu endpoint OTLP configurado em um temporizador.
As métricas OTel também usam nomes, tipos e unidades diferentes que seguem as convenções semânticas do OpenTelemetry para o MongoDB, portanto, você não pode reutilizar seus painéis Prometheus existentes. Você deve criar novos dashboards, alertas e queries em sua plataforma de observabilidade de destino em relação às métricas exportadas.
Pré-requisitos
Antes de configurar a exportação do OTel, certifique-se de atender aos seguintes requisitos:
Você deve ativar o monitoramento do seu sistema antes de configurar a exportação do OTel. A exportação do OTel reutiliza as amostras que o MongoDB Agent já coleta para monitoramento. Para saber como instalar o MongoDB Agent e ativar o monitoramento, consulte Instalar o MongoDB Agent para monitorar ou fazer backup de sistemas.
Certifique-se de que seu endpoint OTLP possa ser acessado a partir de todos os hosts onde o MongoDB Agent seja executado. O MongoDB Agent envia as métricas diretamente para o endpoint. Verifique suas regras de firewall e políticas de saída antes de ativar esse recurso.
Confirme que você tem acesso
Project Automation Adminpara atualizar a configuração de automação por meio da API do Ops Manager. Para saber mais sobre roles de projeto , consulte Roles do Ops Manager. Para saber mais sobre a API de configuração de automação, consulte Recurso de configuração de automação.Certifique-se de que seu endpoint OTLP ofereça suporte a OTLP/HTTP como um protocolo receptor. Para saber mais sobre como configurar um receptor OTLP/HTTP, consulte a especificação do protocolo OpenTelemetry.
Habilitar exportação OTel
Você configura a exportação do OTel por meio da Configuração de automação. Todas as configurações são transportadas em uma única chave otelConfig sob o additionalParams do módulo de monitoramento. Você pode aplicar essa configuração por meio do fluxo de configuração personalizada existente na interface do Ops Manager, descrito em Configurações personalizadas. Você também pode aplicar esta configuração por meio da API de Configuração de Automação pública.
O exemplo a seguir mostra uma entrada additionalParams que habilita a exportação OTel:
1 "additionalParams": { 2 "otelConfig": "{\"enabled\":true,\"metricsExportIntervalSec\":30,\"backends\":[{\"endpoint\":\"https://collector.example.com:4318\",\"headers\":\"Authorization=Bearer <token>\",\"caCertPath\":\"/etc/ssl/ca.pem\"}]}" 3 }
Para a lista completa de campos otelConfig, consulte Configurações de exportação OpenTelemetry (OTel).
Importante
Um otelConfig mal configurado falha alto em vez de ser silenciosamente ignorado. Se a configuração for inválida, o MongoDB Agent impedirá que o módulo de monitoramento seja iniciado. O MongoDB Agent tenta novamente a configuração a cada 30 segundos até receber uma configuração válida. Portanto, um otelConfig inválido afeta o monitoramento como um todo, não apenas o caminho do OTel. O agente registra essa falha com um prefixo Otel: e a apresenta no relatório de status do agente ao Ops Manager.
As alterações de configuração entram em vigor na próxima vez que o módulo de monitoramento for reiniciado. O Ops Manager aciona essa reinicialização automaticamente quando você altera as propriedades relevantes da Configuração de automação.
Aviso
Se você configurar um endpoint http://, o MongoDB Agent enviará métricas por uma conexão não criptografada. O Ops Manager não consegue detectar se um endpoint é um destino de produção, portanto, nenhuma proteção impede a exportação insegura na produção. Use um endpoint https:// para sistemas de produção.
Sistemas do Kubernetes
Para implantações gerenciadas pelos Controladores MongoDB para Kubernetes (MCK), a exportação OTel usa o mesmo mecanismo de Configuração de Automação. O operador mantém a Configuração de automação. O operador grava suas configurações OTel nos hosts do agente por meio de atualizações de recursos personalizados. Você não precisa de nenhuma configuração específica do Kubernetes separada.
Métricas exportadas
Este recurso exporta os grupos de métricas na tabela a seguir por OTLP. Os nomes, tipos e unidades de métricas seguem as convenções semânticas do OpenTelemetry para o MongoDB, usando um padrão de nomenclatura mongodb.* consistente.
Grupo de métricas | Fonte | Cobertura |
|---|---|---|
Server status |
| Contadores de operações (incluindo replicados), latências de operações, conexões, memória, rede, cursores, documentos inseridos, atualizados, excluídos e retornados, estatísticas de cache WiredTiger, profundidade de tickets e filas, aquisição de bloqueio , espera e contagens de deadlock, leituras e gravações ativas , alertas, controle de fluxo, direcionamento de query, exclusões de time-to-live (TTL), falhas de página, tempo de atividade e integridade. |
Estatísticas do banco de dados |
| Armazenamento por banco de dados, tamanho dos dados, objeto, índices e estatísticas de visualização. |
Atividade de collection |
| Tempo agregado por operação. |
Replicação |
| Tamanho e janela do oplog, atraso de replicação e integridade dos membros. |
Fragmentação | Config metadata | Contagens de chunks e distribuição de dados entre shards. |
Auto-saúde do agente | Tempo de execução do agente | Tempo de atividade, memória e goroutines do MongoDB Agent , publicados sob o namespace |
Esse recurso exporta métricas de contador como valores cumulativos com um carimbo de data/hora de início derivado do tempo de atividade mongod. Uma reinicialização mongod é exibida como uma redefinição de contador padrão, portanto, os cálculos de taxa permanecem corretos entre reinicializações.
Desatualização e vida útil da série
O MongoDB Agent reexporta séries de contadores inalteradas enquanto um processo está temporariamente inacessível, de modo que uma lacuna na coleção não seja interpretada incorretamente como uma redefinição de contador.
O MongoDB Agent exporta séries point-in-time, como
mongodb.health, somente enquanto são recentes, de modo que um processo inacessível fique em silêncio em vez de manter um valor obsoleto.O MongoDB Agent descarta uma série após 20 minutos sem uma nova amostra, e a série desaparece do seu backend. Considere esse comportamento ao criar alertas com base nos dados ausentes.
Configure dashboards em sua plataforma de observabilidade
Você deve criar novos painéis em sua plataforma de observabilidade de destino em relação às métricas exportadas. O Ops Manager não envia painéis pré-criados e você não pode reutilizar painéis existentes criados para a integração com o Prometheus, a interface do Ops Manager ou outra integração de terceiros com o MongoDB .
Considere esta orientação ao configurar painéis:
Crie novos dashboards em vez de portar os existentes. Os nomes de métricas emitidos pelo OTLP seguem uma convenção de nomenclatura
mongodb.*que difere dos nomes do exportador Prometheus e dos identificadores de métricas internos do Ops Manager.Use atributos de recursos para filtragem e agrupamento. Cada métrica carrega atributos de recursos que identificam o processo monitorado e o projeto. Use esses atributos como dimensões primárias para painéis, alertas e agrupamentos do dashboard.
Aplique funções detaxa para conter métricas. Os contadores são cumulativos. Aplique funções como
rate()ouincrease(), ou seus equivalentes em sua plataforma, a métricas do tipo contador.Recrie seus alertas. A exportação do OTel não carrega as regras de alerta existentes definidas no Prometheus, no Ops Manager ou em outra integração de terceiros. Defina novas regras de alerta em sua plataforma de destino em relação aos nomes de métricas e atributos de recursos do OTel.
Limitações
Um backend por sistema. Esse recurso é compatível com exatamente um backend de OTLP. Configurar mais de um backend resulta em um erro grave. Para distribuir métricas para vários destinos, configure um OpenTelemetry Connector como seu destino de exportação e roteie para mais backends por meio de sua configuração de pipeline.
Somente métricas. Esse recurso exporta apenas métricas por OTLP. O caminho de exportação do OTel não inclui os seguintes sinais, que continuam a fluir para o Ops Manager inalterados:
Registros (entradas de profiler , registros de host e registros de agente ) e rastreamentos
Métricas de processo do MongoDB Search
Métricas do sistema no nível do host (CPU, memória, disco e rede)
histogramas de latência por coleção
Sem buffer para destinos inacessíveis. O MongoDB Agent tenta novamente ou descarta uma exportação com falha de acordo com a política do exportador. Esse recurso não fornece fila de armazenamento e encaminhamento. A entrega ao gerente de operações não é afetada em todos os casos.