Extração de métricas de banco de dados do Couchbase Capella com o Prometheus

Nesta publicação do blog, a primeira de uma série, mostraremos como configurar um servidor Prometheus e conectá-lo ao seu banco de dados Couchbase Capella para coletar métricas.

O que é o Prometheus?

Prometeu é um kit de ferramentas de monitoramento e alerta de sistemas de código aberto muito popular, com uma comunidade de desenvolvedores e usuários muito ativa. Ele foi originalmente desenvolvido em SoundCloudmas agora é um projeto autônomo de código aberto, mantido independentemente de qualquer empresa, e se juntou ao Fundação para computação nativa em nuvem em 2016 como o segundo projeto hospedado, depois de Kubernetes.

O que é o Couchbase Capella?

Couchbase Capella é a nossa oferta de banco de dados como serviço (DBaaS) totalmente gerenciado, a maneira mais fácil e rápida de começar a usar o Couchbase e de eliminar os esforços contínuos de gerenciamento de banco de dados. Seu banco de dados Capella contém um alvo de raspagem nativo do Prometheus, permitindo que você conecte seus sistemas de monitoramento do Prometheus (ou compatíveis com o Prometheus) para coletar métricas.

Pré-requisitos

Para seguir as etapas deste guia, você precisará de uma instalação funcional do Docker (que usaremos para implantar o Prometheus), um banco de dados Capella e alguns utilitários de shell comuns.

Observação: Não faz parte do escopo desta postagem mostrar como instalar e configurar o Docker. Há muitos tutoriais por aí, incluindo o do próprio Docker Introdução ao Docker. Neste ponto, assumiremos que você o instalou e testou com sucesso (por exemplo, com Olá, mundo!).

No momento em que este artigo foi escrito, a versão mais recente do Prometheus era a 2.46. As etapas aqui foram executadas usando o Rancher Desktop 1.9.1, com o mecanismo de contêineres definido como dockerd (moby) e usando a CLI do docker fornecida. A expectativa é que as etapas funcionem como estão em qualquer instalação atual do Docker ou em uma pilha equivalente, como o containerd com a CLI nerdctl.

Por fim, os comandos compartilhados aqui são adequados para ambientes de desenvolvimento autônomos e de curta duração. É claro que você deve seguir as práticas recomendadas locais de rede e segurança, quando apropriado.

Executando um servidor Prometheus no Docker

Vamos começar imediatamente e executar o contêiner mais recente do Prometheus (prom/prometheus) com suas configurações padrão.

O execução do docker tem muitas opções, mas, neste exemplo, usaremos apenas um -p / -publicar para expor a porta do Prometheus (cujo padrão é 9090) para que possamos acessá-lo em nosso navegador local, e um -rm para garantir que o contêiner seja limpo ao sair.

Por padrão, o contêiner em execução permanecerá "anexado", transmitindo os logs para a saída padrão (neste caso, o seu terminal). Vamos fazer isso na primeira execução para garantir que ele seja iniciado corretamente:

A menos que você veja algum erro na saída do console, agora você deve ter um servidor Prometheus em execução em http://localhost:9090/. Abra-o em uma janela do navegador e você verá algo parecido com isto:

Agora, volte para a janela do terminal e pressione Ctrl+C para matar o contêiner em execução e, em seguida, iniciá-lo novamente, mas dessa vez usando um -d / -destaque para colocá-lo em segundo plano e liberar nosso terminal:

Em caso de sucesso, o Docker imprimirá o ID do contêiner e você também poderá encontrá-lo com docker ps. Como você precisará dele para algumas das etapas posteriores, vamos filtrar (com -f / -filtro) a saída de docker ps para mostrar apenas o ID do contêiner que desejamos, com base nas portas de rede que estamos usando (neste caso, estamos publicando a porta 9090):

Podemos adicionar um -q / -silencioso para somente produza o ID do contêiner e use o resultado em outro comando. Por exemplo, para visualizar os logs do contêiner do Prometheus que acabou de iniciar:

Esse comando produzirá algo semelhante a quando você iniciou o servidor Prometheus pela primeira vez, quando o contêiner ainda estava conectado ao terminal. Você pode usar a mesma técnica com (por exemplo) execução de docas (se quiser iniciar um shell em um contêiner em execução), ou matar o docker (para enviar um sinal ao contêiner).

Vamos dar uma olhada mais profunda no servidor Prometheus em que você está executando http://localhost:9090/. Se você navegar para Status -> MetasVocê pode ver que já existe um trabalho em execução:

Esse servidor do Prometheus foi configurado para fazer scraping em si como um alvo, o que pode ser confirmado pela visualização de sua configuração (Status -> Configuração):

Você pode ver no exemplo acima que há um trabalho chamado prometeuque tem como alvo localhost:9090/metrics (alvos + metrics_path). Veja Configuração do Prometheus para monitorar a si mesmo para obter um exemplo de configuração.

Antes de voltarmos ao nosso terminal, vamos dar uma olhada rápida nas métricas que estão sendo extraídas no trabalho acima. Se você clicar em Graph, verá que o Navegador de expressõesque permite que você insira expressões PromQL (consulte Consulta ao Prometheus para obter uma visão geral) e visualizar os resultados.

Observe o Navegador de expressões destina-se apenas ao uso adhoc - a recomendação é usar Grafana como uma solução de gráficos completa, e analisaremos isso em um post futuro. Enquanto isso, como um exemplo rápido, este é o número de séries temporais atualmente armazenadas em seu próprio banco de dados (prometheus_tsdb_head_series):

Se quisermos adicionar nosso banco de dados Capella como um Scrape Job em nosso servidor Prometheus, isso significa que precisamos fazer alterações na configuração que vimos acima, mas a configuração está incorporada à nossa imagem de contêiner. Assim que tivermos uma configuração final, poderemos reconstruir a imagem, mas, por enquanto, seria muito mais conveniente se pudéssemos aplicar novas opções de configuração e testar sem tanto esforço.

Vamos usar o recurso -v / -volume que permite montar um arquivo ou diretório local no contêiner. O arquivo de configuração do Prometheus no contêiner é /etc/prometheus/prometheus.yml - Se esse fosse o único arquivo de que precisássemos, poderíamos simplesmente montar o arquivo diretamente, mas precisaremos de mais alguns, então, em vez disso, montaremos um diretório.

Em seu diretório de trabalho, crie um subdiretório que usaremos para manter nossa configuração (prometheus.yml) e outros arquivos associados.

Agora precisamos de uma cópia do arquivo de configuração com o qual possamos trabalhar. Como sempre, há mais de uma maneira de fazer isso, mas, de longe, a mais simples é usar o arquivo docker cp para copiar /etc/prometheus/prometheus.yml do seu contêiner em execução, para um arquivo local:

Agora, mate o contêiner em execução no momento:

Em seguida, inicie um novo contêiner, desta vez montando seu prometeu diretório como /etc/prometheus/ no contêiner:

Se, como o autor, você estiver se perguntando como saber se o servidor Prometheus está realmente usando sua cópia do prometheus.yml ou não, você pode verificar as montagens dentro do contêiner para ter certeza de que /etc/prometheus/ é especificamente montado com:

Você também pode fazer uma pequena alteração na configuração (por exemplo, o nome do trabalho de raspagem existente), e isso deve ser refletido no console (em http://localhost:9090/config).

Por fim, nesta seção, como faremos algumas alterações no nosso arquivo de configuração, seria bom se não precisássemos recriar o contêiner para aplicar as alterações. O Prometheus tem um método de API incorporado para isso, discutido em Configuração, mas o -web.enable-lifecycle não está ativada por padrão no contêiner oficial. Felizmente (pelo menos para os usuários de MacOS e Linux), existe a opção de enviar um SIGHUP com matar o docker (resultando em uma mensagem "Carregando arquivo de configuração" nos registros):

Em resumo, até agora, temos um servidor Prometheus em execução, sabemos como verificar seus logs, procurar as métricas que ele está extraindo e como atualizar e recarregar sua configuração, facilitando a inclusão do nosso banco de dados Capella como alvo de extração.

Adição de um banco de dados Capella ao seu servidor Prometheus

Agora que temos um servidor Prometheus, vamos dar uma olhada em como adicionar um banco de dados Couchbase Capella.

Pré-requisitos

Para cada banco de dados do qual você deseja coletar métricas, você precisará:

• • O nome do host de conexão
  • Credenciais de usuário com o acesso apropriado ao banco de dados
  • Um certificado de segurança
  • Um ou mais endereços IP permitidos

Nome do host da conexão

Esse é o nome do host de sua string de conexão. Vá para a seção Conectar em seu banco de dados na interface do usuário do Capella e copie tudo após o couchbases:// prefixo do esquema. O que estamos usando em nossos exemplos é: cb.plmvshfqolmyxvpt.cloud.couchbase.com.

Credenciais do usuário

Um conjunto de credenciais (nome de usuário/senha) que tem Ler Acesso para Todos os baldes e Todos os escopos em seu banco de dados (como observado, o requerido external_stats_reader só é concedida quando uma função A credencial do banco de dados recebe acesso de leitura a todos Compartimentos em um banco de dados). Se você não tiver um, poderá criar um a partir de Configurações -> Acesso ao banco de dados -> Criar acesso ao banco de dados (consulte Configurar credenciais do banco de dados). Em nossos exemplos, usaremos metrics_user / metrics_Passw0rd.

Certificado de segurança

O certificado de segurança do seu banco de dados. Em seu banco de dados, vá para Configurações -> Certificado de segurançae clique em Download. Isso lhe dará um arquivo de texto formatado em PEM com o nome do seu cluster (no nosso caso bravetimbernerslee-root-certificate.txt). Na verdade, o mesmo certificado de assinatura é usado para todos os bancos de dados Capella, portanto, você só precisa fazer o download uma vez e pode usar o mesmo certificado raiz para verificar todos os seus bancos de dados Capella. Para esse fim, renomeamos nosso arquivo de certificado local para couchbase-cloud-root-certificate.pem para maior clareza, e copiado em nosso prometeu (em um subdiretório chamado certificados) para que o Prometheus possa acessá-lo mais tarde.

Endereços IP permitidos

Antes que qualquer cliente possa se conectar a um banco de dados Capella, o endereço IP do cliente deve ser adicionado à lista de endereços IP do banco de dados. Lista de IPs permitidos. Para seguir as etapas aqui, você provavelmente desejará adicionar seu endereço IP atual e, nesse caso, poderá usar a opção Adicionar meu IP botão. Para uma implantação de produção, você precisará do endereço IP público do(s) seu(s) servidor(es) Prometheus.

Definição de uma nova configuração de raspagem

Vamos começar dando uma olhada no trabalho existente, que diz ao Prometheus para fazer o scraping de si mesmo.

Se ignorarmos as configurações globais e os padrões, o resultado será o seguinte:

Se você consultar a documentação do Configuração de raspagem você pode ver que essa é essencialmente a menor definição possível de um trabalho. Não há TLS, nem autenticação, apenas um nome e um único destino (que, com os padrões adicionados, torna-se http://localhost:9090/metrics).

Além disso, se estiver interessado, você pode testar isso carregando esse URL no navegador ou usando enrolar na CLI. A saída resultante está no texto do Prometheus Formato da exposição.

Nosso novo trabalho precisará de um nome - ele precisa ser exclusivo em todas as definições de raspagem, o que vale a pena ter em mente se você estiver planejando adicionar vários bancos de dados Capella. No nosso exemplo, usaremos o componente exclusivo do Connection Hostname para diferenciar, o que nos dará:

Sabemos que precisaremos nos autenticar para acessar o endpoint de métricas, usando as credenciais acima:

Toda a comunicação da Capella é criptografada com TLS, portanto, precisaremos adicionar um tls_config usando o certificado que baixamos anteriormente:

E, em relação a isso, esquema O padrão é httpportanto, precisaremos:

A última coisa que precisamos fazer é informar ao Prometheus o(s) nome(s) de host/endereço(s) a ser(em) usado(s) para se conectar ao seu banco de dados, também conhecido como alvos.

No prometeu acima, um único nome de host é fornecido usando o static_config parâmetro. Como o nome sugere, essa é uma maneira de definir estaticamente um ou mais alvose elas não serão atualizadas ou renovadas a menos que o servidor Prometheus seja reiniciado ou que seu arquivo de configuração seja recarregado.

Nesse caso, não há problema, pois o nome do host (localhost) nunca será alterado. Isso também pode ser gerenciável se você tiver nomes de host que mudam ocasionalmente e só são atualizados em circunstâncias controladas (por exemplo, um período de manutenção programado em que você pode atualizar a configuração do Prometheus ao mesmo tempo).

Mas e se os nomes de host mudarem com frequência e o momento dessas mudanças estiver fora do seu controle? Se o aplicativo que você está monitorando estiver hospedado em qualquer tipo de ambiente de nuvem, onde há escalonamento sob demanda, substituição de servidor em caso de falha, upgrades automatizados, você precisará de um método muito mais flexível para especificar seu alvos.

É aí que entra o Service Discovery.

Descoberta de serviços

O Prometheus Service Discovery (SD) é um mecanismo que permite que o servidor Prometheus descubra (e atualize) dinamicamente a lista de alvos a serem monitorados para um aplicativo ou serviço específico. No momento em que este artigo foi escrito, havia 28 mecanismos diferentes, incluindo opções genéricas, como Arquivo- e Baseado em HTTP Service Discovery, bem como implementações específicas para um grande número de plataformas e aplicativos de nuvem (consulte o Prometheus documentação de configuração para obter a lista completa).

Vamos examinar essas duas opções genéricas em relação ao seu banco de dados Couchbase Capella.

Descoberta de serviço baseada em arquivo (file_sd_configs) é onde um ou mais nomes de arquivos são fornecidos ao Prometheus, cada arquivo contendo zero ou mais static_config entradas. O Prometheus aplicará qualquer alvos que encontrar nesses arquivos, e carregará automaticamente todas as alterações quando os arquivos forem atualizados.

Esse mecanismo é útil, pois você pode usá-lo para se conectar a qualquer sistema arbitrário, desde que consiga colocar os detalhes do host em um arquivo formatado corretamente (manualmente ou por meio de qualquer automação apropriada). No entanto, é preciso garantir que a automação para atualizar o(s) arquivo(s) seja confiável.

Descoberta de serviço baseada em HTTP (http_sd_configs) é semelhante ao File-based, pois fornece uma interface genérica, com uma carga útil contendo zero ou mais static_config mas usa uma conexão HTTP para buscar a carga útil em vez de ler um arquivo local. Isso elimina a dependência de qualquer automação ou intervenção humana e, desde que o aplicativo de destino forneça a API relevante, seria preferível à opção baseada em arquivo.

No momento em que este artigo foi escrito, estávamos no processo de atualização do patrimônio do Capella do Couchbase Server 7.1 para o 7.2 (consulte Atualização de um banco de dados para obter mais detalhes). O Server 7.1 fornece apenas uma API básica de descoberta de serviço baseada em arquivo, mas no Server 7.2 adicionamos o SD baseado em HTTP, bem como o SD baseado em arquivo aprimorado.

Vamos examinar primeiro o método de descoberta de serviço baseado em arquivo no Server 7.1. Sinta-se à vontade para pular uma seção se já estiver executando o Server 7.2.

Descoberta de serviço baseada em arquivo no Couchbase Server 7.1

O ponto de extremidade é prometheus_sd_config.yamlSe você estiver usando o Capella Root Certificate, precisará se autenticar com as mesmas credenciais mencionadas acima e fornecer o certificado raiz do Capella que baixamos anteriormente.

Primeiro, usaremos apenas enrolar e transmitir o resultado para o nosso terminal:

Para o nosso cluster, isso dá:

Aqui podemos ver a limitação da API atual do Service Discovery - ela sempre retornará a porta insegura (8091), o que não é útil para nós no Capella, pois toda a comunicação é feita pela porta segura (18091). Esse problema foi corrigido com os aprimoramentos no Server 7.2, mas até que eles estejam disponíveis, precisamos adicionar uma etapa extra para atualizar esses números de porta.

Para fins desta demonstração, usaremos apenas o pipe sedmas você pode fazer o que for mais apropriado para seu ambiente:

Para o nosso cluster, isso agora dá:

Agora que temos a saída correta, podemos redirecioná-la para um arquivo a ser usado posteriormente em nossa definição de trabalho.

Em nosso diretório de trabalho, usaremos um subdiretório para manter nossos alvos juntos, nomeando os arquivos após o nome do trabalho (em nosso caso capella-plmvshfqolmyxvpt):

Isso é bom para a nossa demonstração, mas, obviamente, você deve se certificar de que seja robusto e adequado ao seu próprio ambiente, adicionando tratamento de erros conforme apropriado. E, o mais importante, você precisará programar essa execução regularmente para garantir que a lista de alvos seja atualizada com todas as alterações de topologia à medida que elas ocorrerem (execução uma vez por minuto via cron por exemplo, seria suficiente).

Agora podemos pegar tudo o que temos acima e adicionar nosso file_sd_configse nosso novo trabalho tem a seguinte aparência:

Descoberta de serviço baseada em HTTP no Couchbase Server 7.2

No Server 7.2, adicionamos um novo ponto de extremidade (prometheus_sd_config) e, da mesma forma que acima, você precisará se autenticar com as credenciais que criou e fornecer o certificado raiz do Capella que baixamos anteriormente.

Primeiro, usaremos enrolar e transmitir o resultado para o nosso terminal. Na nova API, a saída padrão é JSON, portanto, estamos enviando o piping para jq para maior clareza:

Para o nosso cluster atualizado (em que os nomes de host foram alterados durante o processo de atualização), isso dá:

Essa saída é exatamente o que o Prometheus está esperando, portanto, podemos usar os argumentos que usamos no comando enrolar e usá-los em um comando http_sd_configs configuração de raspagem em nosso novo trabalho do Prometheus:  

Executando seu novo trabalho

Neste ponto, você deve ter tudo o que precisa para adicionar o novo trabalho de raspagem ao seu servidor Prometheus. Se você ainda estiver usando o Couchbase Server 7.1, será o file_sd_configs (com todas as etapas necessárias para criar o alvos e, se você estiver executando o Server 7.2, o arquivo http_sd_configs versão baseada em.

Adicione o novo trabalho ao seu prometheus.ymle, em seguida, recarregue a configuração com o comando matar que usamos anteriormente:

Em seguida, você pode verificar os registros para ter certeza de que a configuração foi carregada de forma limpa:

Lembre-se de que você está procurando um Carregando o arquivo de configuração e, desde que sua configuração seja válida, você deverá ver uma mensagem de registro Carregamento concluído do arquivo de configuração imediatamente após a mensagem. Se a recarga não for bem-sucedida, você precisará resolver os problemas e tentar novamente. Depois disso, vamos voltar e examinar o console do Prometheus em http://localhost:9090/.

Primeiro, vamos dar uma olhada em nossa nova configuração (Status -> Configuração), que deve mostrar o trabalho extra que acabamos de adicionar.

Esta é a configuração completa usando o File-based Service Discovery:

E aqui está um snippet mostrando o scrape baseado em HTTP:

Agora, se olharmos para Status -> MetasSe o cluster estiver em um local seguro, ele deverá mostrar todos os nós de seu banco de dados Capella. Por exemplo, este é o nosso cluster antes da atualização para o Server 7.2:

Da mesma forma, se as Metas não forem o que você esperava, Status -> Descoberta de serviço lhe mostrará de onde vem cada endpoint. Aqui está o status do Service Discovery para o nosso cluster atualizado, no qual estamos usando o HTTP SD (cortado para mostrar apenas os primeiros nós):

Agora que adicionamos nosso banco de dados Capella, como podemos verificar se estamos realmente recebendo algo útil?

Primeiro, se revisitarmos o gráfico anterior, poderemos ver que o número de séries temporais que estão sendo armazenadas (prometheus_tsdb_head_series) cresceu consideravelmente:

Em seguida, podemos confirmar que de fato temos algumas métricas do Couchbase Server capturadas. Temos o amostra de viagem carregado em nosso banco de dados, que contém pouco mais de 63.000 itens. Se consultarmos kv_curr_items podemos ver que cada um de nossos três nós do Data Service tem aproximadamente 21.000 itens cada:

Conclusão

Neste artigo, mostramos como executar um servidor Prometheus simples em seu ambiente de desenvolvimento local e como você pode adicionar seu banco de dados Couchbase Capella para que possa começar a monitorá-lo. Nas próximas publicações desta série, mostraremos o que você pode fazer com essas métricas, agora que já as tem.

Como sempre, agradecemos todo e qualquer feedback. Sinta-se à vontade para entrar em contato conosco deixando um comentário aqui, ou você pode nos encontrar em nosso Fórunsou nosso Discórdia.