Monitoramento do Couchbase

VISÃO GERAL

Há vários anos, escrevi um blog que reflete a quantidade de clientes que monitoram seus clusters do Couchbase (https://www.couchbase.com/blog/monitoring-couchbase-cluster). Embora datadas, as informações ainda são relevantes e estaremos atualizando esse original. As estatísticas e métricas descritas nessa visão geral são frequentemente consumidas por estruturas de monitoramento para medir a integridade e o desempenho do Couchbase para casos de uso específicos. Desde então, frequentemente encontramos pessoas pedindo exemplos de implementações que consomem essas estatísticas. Normalmente, a necessidade real das equipes de desenvolvimento não são estruturas de monitoramento mais amplas, mas scripts simples que podem ser aproveitados. Muitas vezes, as equipes multifuncionais estão diagnosticando problemas em configurações de "sala de guerra" e querem maneiras simples de digerir eventos recentes em um cluster.

O objetivo aqui não é fornecer um modelo abrangente, mas delinear uma implementação simples que consome métricas do Couchbase por meio de nossa API REST e ferramentas de linha de comando. Quando tivermos algo que possa digerir essas métricas regularmente, precisaremos armazená-las em algum lugar. Neste passo a passo, armazenaremos essas métricas em um bucket do Couchbase e usaremos o N1QL para entender o que está acontecendo em um determinado cluster. Há outras maneiras de visualizar esse tipo de informação (http://www.couchbase.com/blog/2016/march/http-packages.couchbase.com-releases-4.5.0-dp1-couchbase-server-enterprise_4.5.0-dp1-windows_amd64.exe.md5), mas, neste exemplo, vamos nos concentrar no monitoramento do Couchbase e nas consultas N1QL associadas.

DIGERIR INFORMAÇÕES

Eu queria fornecer um exemplo que fosse relevante e útil para as equipes digerirem e usarem. Muitas vezes, o uso do Python é familiar para as pessoas e pode ser facilmente implementado em uma variedade de sistemas. Obviamente, esses mesmos métodos poderiam ser aproveitados no shell ou em praticamente qualquer linguagem, mas o Python parecia ser a opção natural para uma discussão generalizada.

O código completo pode ser encontrado aqui ... pythonlab/MonitorStats.py ... mas analisaremos alguns dos detalhes e as diferentes maneiras de coletar informações do Couchbase.

A primeira coisa que precisamos estabelecer é onde podemos encontrar os binários locais do Couchbase, que é tudo o que o binPath está fazendo para nós.

A interface de usuário administrativa é um ótimo recurso do Couchbase e é instalada por padrão em todos os nós de um cluster do Couchbase; no entanto, essa interface foi projetada para fornecer uma visão do "que está acontecendo agora" no cluster. As estatísticas são agregadas ao longo do tempo pelo cluster e não fornecem informações granulares para revisar "o que aconteceu" no cluster. Como a womo estamos consumindo estatísticas que são criadas em tempo real pelo cluster do Couchbase, precisamos de um local para armazenar os resultados. Embora possa haver outras opções, usaremos o Couchbase para armazenar nossas estatísticas históricas. O cluster que estamos usando para armazenar estatísticas será controlado por seedNode e seedBucket (um SDK do Couchbase só precisa de um nó e do nome do bucket para criar uma conexão com todos os nós em um cluster).

 Esse script seria executado localmente em cada nó do cluster e capturaria um perfil estatístico da integridade desse nó e sua visão do cluster. Como resultado, o cluster que estamos monitorando será definido como "localhost" e usaremos a API REST do Couchbase para determinar o nome do host local.

Tudo é orientado pela compreensão de qual nó o script está sendo executado e quantos nós compõem o cluster. Aqui, capturaremos essas informações e conduziremos a parte restante do script de monitoramento.

Para o script restante, agora podemos consumir estatísticas específicas de algumas maneiras diferentes. Aqui, extrairemos informações do utilitário cbstats do Couchbase ou diretamente de nossa API REST. Aqui estamos usando o cbstats para obter a utilização da memória de um nó e usar um cliente REST Python (solicitações) para obter a fila de drenagem para medir o desempenho do cluster na obtenção de dados persistentes no disco. Essas são algumas das estatísticas mais importantes a serem monitoradas em um cluster do Couchbase.

O script real demonstra informações adicionais, mas, em última análise, capturamos tudo em um documento JSON e definimos um TTL por 30 dias.

Com os dados de monitoramento no Couchbase, podemos consumir coisas por meio da nossa linguagem de consulta N1QL para procurar anomalias. Os dados em si estão usando um modelo de dados de série temporal baseado em um registro de data e hora; como resultado, podemos consultar as coisas que estão acontecendo no cluster e a CHAVE (meta.id) nos mostrará o período de tempo em questão. Talvez precisemos ser inteligentes com relação aos índices necessários para dar suporte à análise, mas para uma plataforma de combate a incêndios é muito viável aproveitar a linguagem de consulta N1QL do Couchbase.

CONCLUSÃO:

Isso não é algo que deva ser colocado em produção, mas deve fornecer uma diretriz sobre como monitorar um ambiente do Couchbase. Há muita coisa disponível por meio da interface REST e do cbstats, e tudo isso pode ser consumido e monitorado de forma semelhante.