Como monitorar seu ambiente MongoDB com Prometheus e Grafana

Como monitorar seu ambiente MongoDB com Prometheus e Grafana

O MongoDB é uma das soluções de NoSQL mais utilizadas na atualidade. Ele é um tipo de banco baseado em documentos assim como o AWS DocumentDB, Couchbase Server e Apache CouchDB, entre outros.

E como toda solução de TI precisamos ter um sistema de monitoramento capaz de sustentar 3 importantes pontos:

  1. Observabilidade do Ambiente
  2. Monitoramento do Ambiente
  3. Análise dos Dados

Observabilidade do Ambiente: ou seja,  a capacidade de algo ser observável. Um sistema ser capaz de ser observável está relacionado a sua capacidade de expor métricas e dados relacionados a elementos internos de comportamento do servidor ou serviço.

Monitoramento do Ambiente: tendo a observabilidade garantida precisamos agrupar esses dados de forma que possamos ter uma visão monitorada de períodos, o que nos vai permitir entender o comportamento do sistema ao longo do tempo.

Análise dos Dados: como resultado do monitoramento podemos estudar possíveis customizações de performance ou gerenciamento de recursos baseado no estudo dos dados coletados em determinados períodos. Essa etapa de análise normalmente é feita por um equipe dedicada e especializada, mas em tempos de soluções em Cloud e Automação podemos passar essa ação para própria plataforma. Como por exemplo, o serviço CloudWatch da AWS que utilizamos para coletar o consumo de CPU das máquinas em um grupo de auto scaling , tomando a decisão de fazer o scale up/down dependendo da métrica monitorada.

Nesse post utilizaremos a solução Prometheus e Grafana para entregar os dois primeiros pontos, Observabilidade e Monitoramento, sobre um ambiente comum de ReplicaSet do MongoDB. Uma observação importante, os passos aqui utilizados também podem ser aplicados para monitorar um ambiente de Sharding do MongoDB, os exporters utilizados conseguem identificar a função da instâncias dentre as roles do MongoDB em Sharding, como: MongoS, ConfigServers e Shard Servers.

Arquitetura da Solução

A arquitetura do sistema é relativamente simples, dentro das máquinas onde as instâncias do MongoDB estão executando iremos instalar dois exporters, o Node Exporter e MongoDB Exporter, para esse último utilizaremos a versão do projeto Percona. Cada exporter irá fornecer um endpoint para coleta das métricas, aqui temos nosso primeiro ponto, a observabilidade onde estaremos expondo o estado interno do MongoDB e do servidor onde ele está executando. Já passando para o Prometheus iremos coletar tais métricas e disponibilizar para o Grafana criar as Dashboards, tendo aqui nosso segundo ponto: o monitoramento.

Claramente precisaremos também de uma camada de alertas para que esse Monitoramento seja funcional, mas esse é um tópico para outro post 🙂

Primeiro Passo: Criar um usuário de Monitoramento para o MongoDB Exporter

Para que o MongoDB Exporter consiga coletar os dados do MongoDB, precisamos criar um usuário para que ele tenha acesso. Claro que esse acesso deve ser reduzido, portanto precisamos limitar nossa consulta a ações de leitura somente. A própria documentação do MongoDB sugere que liberemos somente as roles clusterMonitor para database admin e a role read para local. O comando que segue pode ser utilizado dentro da database admin para criar tal acesso:

> use admin
> db.createUser({"user":"mongodb_exporter","pwd":"4linux", roles:[{role:"clusterMonitor",db:"admin"},{role:"read",db:"local"}]})

Desta maneira teremos um usuário “mongodb_exporter” com a senha “4linux”, capaz de acessar a instância e coletar as métricas que precisamos.

Segundo Passo: Instalando o MongoDB Exporter

O pacote com o binário do MongoDB Exporter pode ser baixado no link abaixo:

https://github.com/percona/mongodb_exporter/releases/download/v0.11.0/mongodb_exporter-0.11.0.linux-amd64.tar.gz

Assim que descompactar esse tar.gz teremos o binário mongodb_exporter. Nesse momento tome um tempo e busque instalar esse binário como um serviço do systemd. Caso esteja utilizando containers não esqueça de ver as configurações necessárias para alocar o exporter em um container.

Assim que tiver o serviço ou container precisaremos informar a string de conexão desse exporter. No caso iremos exportar uma variável de ambiente chamada MONGODB_URI que contêm os dados para o exporter acessar o banco de dados:

export  MONGODB_URI='mongodb://mongodb_exporter:4linux@localhost:27017

Essa URI de conexão pode ser passada diretamente ao binário com o parâmetro –mongodb.uri=’mongodb://mongodb_exporter:4linux@localhost:27017′.

Para validarmos basta acessar o endereço do servidor na porta IP:9216/metrics

Terceiro Passo: Configurar o Prometheus para consultar o endpoint dos Exporters

A job do Prometheus é bem simples de ser configurada. Edite o arquivo do prometheus localizado sobre /etc/prometheus/prometheus.yml e crie a job que segue:


- job_name: mongodb_exporter
static_configs:
- targets: ['IP_DO_SERVIDOR-00:9216']
- targets: ['IP_DO_SERVIDOR-01:9216']
- targets: ['IP_DO_SERVIDOR-02:9216']
- targets: ['IP_DO_SERVIDOR-03:9216']


Adicione quantas entradas targets forem necessárias para monitorar todos os exporters.

Acesse o endereço do seu Prometheus e sobre a aba Status > Targets visualize se os targets aparecem com status UP.

Caso contrário, verifique se o serviço está ativo para o mongodb_exporter, e se consegue abrir a conexão com os dados do novo usuário do banco utilizado pelo exporter.

 

Quarto Passo: Montar o DashBoard no Grafana

Para o Dashboard do Grafana claro que podemos criar algo customizado para cada métrica, mas para esse post ter uma conclusão e não se estender longamente sobre a linguagem PromQL e como realizar corretamente todas as consultas do Prometheus, vamos utilizar uma Dashboard Pronta.

Importar uma Dashboard da comunidade é bem simples, acesse https://grafana.com/grafana/dashboards e busque por  MongoDB Cluster Summary e MongoDB Overview  feitos pelo usuário nasskach. Recomendo esses Dashboards por estarem mais atualizadas quanto a versão do exporter que estamos utilizando.

O MongoDB Cluster Summary irá mostrar um Overview de todo o cluster, separado em instâncias MongoS, ReplicaSet e Sharding. Essa dashboard é excelente para um visão geral. Agora o MongoDB Overview mostrará mais detalhes de cada instância.

MongoDB Overview:

 

MongoDB Cluster Summary:

Claro que mesmo com o import dessa dashboard ainda podemos inserir nossas customizações. Mas até esse momento já temos um ambiente monitorado com Prometheus e Grafana.

 

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA

Anterior Presidente da Microsoft reconhece erro histórico sobre open source
Próxima Guia completo sobre PromQL: a linguagem de consulta do Prometheus

About author

Julio Ballot
Julio Ballot 8 posts

Júlio Rangel Ballot, atua como Consultor de TI em Software Livre, formado em Engenharia de Computação pela Universidade de Taubaté. Possui experiência em Administração de Sistemas Open Source e ferramentas voltadas a práticas DevOps, com ênfase em CI/CD (Continuous Integration / Continuous Delivery), atuando há 13 anos na área de Tecnologia da Informação. Detém expertise como instrutor de cursos voltados ao Sistema Operacional Linux, sendo certificado LPIC-2, LPIC - DevOps Tools Engineer, Exin DevOps Master e MongoDB Administrator.

View all posts by this author →

Você pode gostar também

Banco de Dados

O ‘Elefante’ faz aniversário.

No dia 8 de julho de 2024, o PostgreSQL comemora informalmente 28 anos de vida. O evento que serviu de base para a escolha desta data foi que em 8

Infraestrutura TI

Realizando videoconferências no Rocket.Chat

Introdução Rocket.Chat Rocket.Chat, é uma plataforma de chat Open Source lançada no final de 2014. Após a aplicação estar pronta seu código não foi prontamente aberto. A abertura do código

Banco de Dados

Migração eficiente de instância MySQL para AWS RDS: Guia passo a passo

O desafio Recentemente recebemos um desafio de migrarmos uma instância MySQL com 1.7TB para a AWS RDS. A migração deveria obedecer os seguintes requisitos: Migrar integralmente todas as databases; A