Monitoramento do Couchbase

Monitoramento do Couchbase

O Couchbase é um banco de dados distribuído, de alto desempenho, com cache e NoSQL em uma única arquitetura de cluster. Apesar do nome semelhante e da herança compartilhada, o Couchbase é um produto muito diferente do CouchDB ou de qualquer outra oferta NoSQL. É fundamental poder monitorar e traçar o perfil do desempenho do Couchbase juntamente com as métricas do aplicativo. Com o tempo, o monitoramento é o elemento para uma implantação bem-sucedida de qualquer sistema de missão crítica. Isso é verdade em geral e ainda mais importante em ambientes de computação distribuída em particular. É a única maneira de garantir o sucesso a longo prazo. Para esta discussão, queremos nos concentrar no monitoramento, mas é importante observar que fornecemos um registro detalhado do Couchbase para facilitar a solução de problemas do aplicativo. Esses registros são armazenados em '/opt/couchbase/var/lib/couchbase/logs'. Para obter mais informações sobre esses registros, consulte o registrador de voos do Couchbase (https://www.couchbase.com/blog/couchbase-server-recorder/).

O Couchbase fornece um console de administração rico em informações e tudo o que é capturado em nosso console também está disponível por meio de utilitários de linha de comando e de nossa interface REST. Como resultado, não apenas fornecemos as estatísticas necessárias, mas também facilitamos ferramentas de terceiros para monitorar clusters de produção de missão crítica. Embora nosso cluster armazene informações históricas, agregamos os dados ao longo do tempo para economizar espaço, e as ferramentas de terceiros podem fazer pesquisas em intervalos regulares para preservar as informações históricas. 

Práticas recomendadas de monitoramento

Então, vamos nos aprofundar no assunto...

Para monitorar o Couchbase com eficiência, precisamos de duas perspectivas diferentes. O cluster como um todo é composto de nós ou servidores individuais. Cada nó fornece nossa capacidade de computação para qualquer aplicativo que utilize o banco de dados distribuído no cluster. Como resultado, queremos monitorar o consumo de recursos e a capacidade de computação disponível por nó. Em qualquer aplicativo específico, também queremos saber quantas solicitações estão sendo atendidas por meio do cache e ter certeza de que nosso disco é capaz de persistir os dados rapidamente no disco. Ao analisarmos as métricas abaixo, devemos ter em mente que o comportamento do nosso cluster dependerá das demandas do nosso aplicativo. Nosso objetivo é gerenciar um conjunto de trabalho na memória e detectar eventos de alerta antecipado que indiquem a necessidade de nós adicionais no cluster.

Monitoramento de nós

O uso de nossa API REST (http://:8091/pools/default) nos dá uma visão dos recursos de computação consumidos por nó.

1. Estado do nó - (clusterMembership) Como parte do JSON retornado pelo ponto final nodeStatuses, o estado do nó é retornado por meio de clusterMembership. Isso fornece um recurso por nó para monitorar "ativo" a fim de garantir que os nós estejam participando do cluster. Os eventos críticos seriam definidos por "inactiveFailed", mostrando que o nó falhou e que a intervenção do administrador é necessária.
2. Estatísticas do sistema (systemStats) - Informações adicionais estão disponíveis no ponto final, fornecendo estatísticas básicas de consumo de capacidade para CPU (cpu_utilization), SWAP (swap_used) e memória livre (mem_free). Para cada nó do cluster, se algum desses recursos apresentar restrições, será necessário abordar o nó individual e avaliar se outros nós são necessários.
3. Específico do Couchbase (interestingStats) - A seção final fornece informações adicionais sobre os recursos consumidos pelo nó individual. O disco do nó individual consumido pelo Couchbase é definido por couch_docs_actual_disk_size, a memória física usada dentro do nó é definida como memória usada por nó e o número de buscas em segundo plano ep_bg_fetched (dados que não estão no cache e são extraídos do disco) também é medido.

Monitoramento da caçamba

O uso de nossa API REST (http://:8091/pools/default/buckets/stats) fornece informações sobre a integridade do próprio bucket. Um determinado bucket pode estar limitado, embora cada nó individual tenha capacidade adicional de computação para oferecer. Como resultado, manter o controle das estatísticas do bucket fornecerá mais informações sobre a integridade do aplicativo.

1. Operações por segundo (ops) - Essa é uma medida fundamental do número total de get, sets, incrementos e decrementos que ocorrem em um determinado bucket. Embora as exibições não sejam levadas em conta na métrica, elas fornecem uma medida muito rápida da carga por aplicativo. Em resumo, todos os recursos podem ser alocados para o cluster, mas isso forneceria uma visão da carga produzida por um determinado aplicativo.
2. Cache Miss (ep_cache_miss_rate) - Essa métrica é um bom exemplo do que pode ou não ser problemático. Basicamente, a métrica conta a proporção de objetos solicitados encontrados no cache em relação ao que precisa ser buscado no disco. Por exemplo, se dez solicitações entraram no banco de dados e uma solicitação precisou ser recuperada do disco, nossa taxa de falha seria 10%. A verdadeira questão... isso é um problema? Isso depende do que esperamos manter na memória, sendo que o melhor desempenho vem de um cluster que mantém esse número o mais próximo possível de 0.
3. Fragmentação (couch_docs_fragmentation) - O Couchbase armazena em um formato somente de acréscimo no disco; como resultado, precisamos ficar de olho na fragmentação que ocorre em um cluster. É particularmente importante medir isso caso a compactação automática seja definida em uma base programada. Isso forneceria informações sobre se a programação está sendo executada por tempo suficiente e com frequência suficiente para manter a integridade do banco de dados.
4. Conjunto de trabalho (ep_bg_fetched e vb_active_resident_items_ratio) - Você pode usar a ep_cache_miss_ratio mencionada acima em conjunto com a proporção de itens residentes e as métricas de headroom de memória para entender se o seu bucket tem capacidade suficiente para armazenar os objetos mais solicitados na memória. Mais importante ainda, você pode prever a necessidade de nós adicionais para expandir a capacidade de memória do cluster.
5. Drenagem de disco (ep_queue_size) - Uma das métricas mais importantes a serem monitoradas, independentemente do que seu aplicativo esteja fazendo, é a taxa de drenagem. Observe atentamente a quantidade de alterações pendentes na fila. Informações adicionais podem ser encontradas no utilitário de linha de comando abaixo. Do ponto de vista do REST, podemos monitorar o preenchimento da fila (ep_diskqueue_fill) e a rapidez com que a fila está sendo drenada (ep_diskqueue_drain) para acompanhar a tendência ao longo do tempo.

Um grande volume de informações adicionais pode ser monitorado na interface REST. Não abordaremos tudo o que está disponível na API aqui, mas nos concentraremos principalmente nas principais estatísticas para manter um cluster saudável. Além do REST, também podemos executar o monitoramento por script por meio dos utilitários couchbase-cli e cbstats para capturar as operações que ocorrem em cada nó do cluster.

Linha de comando

O CBSTATS pode ser encontrado em '/opt/couchbase/bin' e fornece informações sobre uma série de coisas que estão ocorrendo em um cluster. Abaixo estão algumas das principais métricas e o que elas dizem a você:

1. Ao rastrear o número de conexões abertas e rejeitadas por meio das estatísticas curr_connections e rejected_conns, podemos entender se alguma solicitação de conexão foi rejeitada por esse nó.
2. Sempre que um objeto for solicitado por um aplicativo e não for encontrado no cache, o Couchbase encontrará o objeto no disco. Essa perda de cache requer uma busca em segundo plano e é medida por item buscado no disco por ep_bg_fetched. Se estivermos gerenciando um conjunto de trabalho 100%, isso pode ser um sinal de um cluster sob estresse; alternativamente, isso pode não ser um problema se tivermos um conjunto de trabalho menor. Em ambos os cenários, é importante compreender o que é típico em um ambiente, pois um grande aumento fornecerá um sinal de alerta antecipado.
3. O número de itens enfileirados para persistência é uma área importante a ser monitorada para entender se você tem recursos de E/S adequados para acompanhar o seu aplicativo. Embora seu aplicativo sempre seja servido por meio de nossa camada de cache, um dos grandes benefícios do Couchbase é nossa capacidade de também fornecer durabilidade de dados persistindo no disco. Se essa operação assíncrona ficar sobrecarregada, o desempenho do aplicativo poderá ser afetado. Como resultado, especialmente em sistemas de gravação pesada, será importante ficar de olho em ep_queue_size e ep_flusher_todo. Nunca queremos chegar a 1 milhão de itens e, provavelmente, devemos sinalizar um aviso por volta de 500.000 a 800.000, especialmente se essa for uma tendência de aumento ao longo do tempo.
4. Seguindo a estatística vb_num_eject_replicas, obtemos o número de vezes que o Couchbase ejetou valores de réplica da memória. Isso indica que um bucket específico atingiu sua marca d'água baixa. Embora o simples fato de atingir esse limite possa não ser problemático, uma vez que o cluster está simplesmente liberando recursos de memória, ver esse comportamento de forma consistente ou uma tendência crescente pode ser. Mais importante ainda, essa é uma maneira de evitar cenários de falta de memória (ep_oom_errors/ep_tmp_oom_errors) que nunca queremos ver em nossos clusters de produção.
5. O Couchbase, por padrão, evita cenários de cache obsoletos executando um processo de "aquecimento" na inicialização de um nó. O aquecimento é o processo de leitura de objetos do disco e pré-carregamento do cache. O monitoramento do warmup fornece visibilidade da rapidez com que um nó do Couchbase concluirá seu processo de inicialização e estará disponível para suportar a carga dentro do cluster. O warmup é concluído quando ep_warmup_value_count é igual a vb_active_curr_items; no entanto, a obtenção de informações mais detalhadas pode ser fornecida por ep_warmup_state. Abaixo estão os sete estados de aquecimento. Um nó não será concluído até que esteja em um estado "concluído".
   1. Inicial - Iniciar processos de aquecimento.
   2. EstimateDatabaseItemCount - Estimativa da contagem de itens do banco de dados.
   3. KeyDump - Começa a carregar chaves e metadados, mas não documentos, na RAM.
   4. CheckForAccessLog - Determina se há um registro de acesso disponível. Esse registro indica quais chaves foram lidas ou gravadas com frequência.
   5. LoadingAccessLog - Carrega informações do registro de acesso.
   6. LoadingData - O servidor está carregando dados primeiro para as chaves listadas no registro de acesso ou, se não houver registro disponível, com base nas chaves encontradas durante a fase "Key Dump".
   7. Done (Concluído) - O servidor está pronto para lidar com solicitações de leitura e gravação.
6. Como o Couchbase não é apenas um mecanismo de persistência NoSQL, mas também um cache, queremos entender o consumo de memória do servidor Couchbase ep_engine. Isso pode ser monitorado por mem_used.
7. Vale a pena observar que as estatísticas do cbstats abordadas acima também estão disponíveis em nossa interface REST (http://:8091/pools/default/buckets//stats).
   1. ops, ep_cache_miss_rate, couch_docs_fragmentation, ep_queue_size, vb_active_resident_items_ratio, curr_connections, curr_items_tot, ep_bg_fetched, ep_diskqueue_drain, ep_diskqueue_fill, vb_replica_eject, ep_oom_errors, ep_queue_size, ep_tmp_oom_errors, mem_used, etc

A intenção aqui é fornecer algumas orientações sobre por onde começar a desenvolver uma estratégia de monitoramento do Couchbase. Este é um resumo das práticas recomendadas básicas que vimos os clientes implementarem. Cada cliente é único e métricas adicionais podem ser necessárias com base em seu aplicativo.