Bases de dados
    Atualizado maio de 2026
    CouchDB logo

    CouchDB Monitorização

    Monitorize as taxas de pedidos do CouchDB, o estado da replicação, as operações de documentos e as métricas de compactação em tempo real, sem necessidade de configuração.

    Por que monitorizar CouchDB?

    O Apache CouchDB é uma base de dados NoSQL orientada para documentos com replicação multimestre. A monitorização do CouchDB garante uma replicação eficaz, um desempenho ideal nas consultas e uma compactação atempada para a sua camada de dados distribuída.

    Deteção automática via Xitogent
    Monitorização da taxa de pedidos HTTP
    Estado da replicação e acompanhamento de lag
    Operações de leitura/escrita de documentos
    Monitorização do progresso de compactação
    Métricas de construção de índices de vistas
    Acompanhamento do tamanho da base de dados
    Intervalos de recolha de 1 minuto
    Limiares de alerta personalizáveis para cada métrica
    Intervalos de recolha de métricas de 1 minuto de raiz
    O que é a monitorização do CouchDB?

    Monitorização do CouchDB, explicada

    A monitorização do CouchDB deteta falhas no scheduler de replicação, backlogs de compactação smoosh, desequilíbrio de shards, paragens na construção de índices de views e picos de erros HTTP antes que provoquem falhas de sincronização em clientes PouchDB, corrupção de documentos ou timeouts em queries. Para apps mobile/web offline-first, sincronização de IoT no edge e qualquer cluster CouchDB multi-master, a visibilidade por nó combinada com a saúde dos jobs de replicação é o que separa um alerta limpo de 60 segundos de uma caça de vários dias pelos logs do fabric. O Xitoring deteta automaticamente o seu CouchDB, lê endpoints HTTP nativos e encaminha alertas para Slack, PagerDuty, Telegram ou o seu on-call existente.

    Métricas

    O que monitorizamos

    Pedidos/s

    Taxa de pedidos à API HTTP.

    Leituras de documentos

    Operações de leitura de documentos por segundo.

    Escritas de documentos

    Operações de escrita de documentos por segundo.

    Estado da replicação

    Estado das tarefas de replicação ativas.

    Tamanho da base de dados

    Tamanho de cada base de dados em disco.

    Estado da compactação

    Indica se a compactação está em execução.

    Bases de dados abertas / Ficheiros do SO abertos

    `couchdb.open_databases` e `couchdb.open_os_files`. Aproximar-se do limite do `ulimit -n` do SO provoca falhas duras — aumente em conjunto o `ulimit` e o `[couchdb] max_dbs_open` do CouchDB.

    Progresso da construção de índices de views

    De `/_active_tasks` (type=indexer): `changes_done`/`total_changes` por documento de design. Construções lentas ou paradas bloqueiam queries que dependem dessas views.

    Progresso da compactação

    De `/_active_tasks` (type=database_compaction / view_compaction): percentagem de progresso. O smoosh trata da compactação automática na 3.x — alerte quando uma tarefa de compactação demora mais do que o esperado para o tamanho da base de dados.

    Read Repairs do Fabric

    `fabric.read_repairs.success`/`failure`. Reflete a correção em tempo real de inconsistências de shards durante leituras. Read repairs sustentados sinalizam um nó fora de sincronização ou um shard com problemas.

    Taxa de acertos da cache de shards

    `mem3.shard_cache.hit` / (`hit` + `miss`). A cache interna do cluster para encaminhamento de shards — uma taxa de acertos baixa significa churn (alterações de membership) ou pressão de memória.

    Tamanho da base de dados em disco

    Tamanho do ficheiro por base de dados, acompanhado ao longo do tempo. Crescimento estável entre compactações é normal; subir e não recuperar significa que a compactação não está a acompanhar o ritmo de escritas.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dCouchDB ultrapassarem os limites que definiu.

    CouchDB painel de controlo da configuração dos gatilhos de monitorização

    Lag de replicação

    crítico

    Dispara quando a replicação fica atrasada.

    Taxa de pedidos

    aviso

    Alerta sobre padrões de pedidos invulgares.

    Tamanho da base de dados

    aviso

    Dispara quando a base de dados excede o limite de tamanho.

    Compactação

    aviso

    Dispara quando a compactação não corre há algum tempo.

    01

    Importância da monitorização do CouchDB

    A replicação multi-master do CouchDB requer monitorização para garantir a consistência dos dados e o desempenho.

    • Acompanhar a saúde da replicação entre clusters
    • Monitorizar operações sobre documentos para o desempenho
    • Detetar necessidades de compactação
    • Garantir a gestão do tamanho da base de dados
    Monitorização do CouchDB
    Analítica de replicação
    02

    Porquê escolher Xitoring

    Monitorização CouchDB sem configuração.

    • Instalação num único comando
    • Nós globais
    • Dashboard unificado
    • Alertas multicanal
    • Retenção histórica
    Visão geral
    Alertas
    Casos de uso

    Cenários comuns de monitorização do CouchDB

    Onde o CouchDB normalmente é executado hoje — e o que poderia correr mal se ninguém estivesse a monitorizar.

    Aplicações móveis e de campo que funcionam offline

    Aplicações de ponto de venda de retalho, saúde e serviços de campo sincronizam os seus dados com um servidor central sempre que estão online. Quando essa sincronização falha silenciosamente, a equipa continua a trabalhar — mas o escritório está a tomar decisões com base em informações desatualizadas. Detetamos a falha no momento em que começa para que os dados permaneçam fiáveis.

    Dados a fluir de dispositivos remotos

    Sensores e dispositivos no campo enviam as suas leituras de volta para uma base de dados central. Quando esse pipeline fica preso, os dados acumulam-se no dispositivo e acabam por ser perdidos. Monitorizamos o fluxo de ponta a ponta para que qualquer bloqueio seja detetado antes que uma única leitura seja perdida.

    Base de dados de alta disponibilidade para aplicações críticas

    As aplicações de produção distribuem a sua base de dados por vários servidores para se manterem online durante interrupções. Mas desequilíbrios subtis entre servidores podem corroer silenciosamente essa proteção. Detetamo-los precocemente para que a rede de segurança permaneça real quando realmente precisar dela.

    Antes de começar

    Pré-requisitos para CouchDB

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • CouchDB 2.x ou 3.x em execução
    • Credenciais de admin com acesso aos endpoints /_node e /_stats
    • Acessibilidade de rede do Xitogent à API HTTP do CouchDB
    Guia de configuração

    Comece a minutos

    1

    Instalar o Xitogent no seu servidor

    Se ainda não o fez, instale o leve agente de monitorização Xitogent no host que executa o CouchDB.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Expor o endpoint de estatísticas do CouchDB

    O CouchDB fornece estatísticas do servidor através da sua API HTTP em `/_node/_local/_stats` (porta 5984 por predefinição). Garanta que o endpoint é acessível a partir do host do agente e que o utilizador configurado tem acesso de leitura aos endpoints administrativos.

    sudo xitogent integrate
    3

    Ativar a integração do CouchDB

    Use o painel do Xitoring ou a CLI para ativar a integração do CouchDB. O Xitogent deteta automaticamente o seu nó e começa a recolher métricas de pedidos, replicação e armazenamento.

    4

    Configurar limiares de alerta (opcional)

    Defina limiares personalizados para atraso de replicação, taxa de pedidos ou tamanho da base de dados para apanhar problemas de capacidade e replicação antes que se tornem indisponibilidades.

    5

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status

    Frequentemente perguntas feitas

    Quais são as versões do CouchDB suportadas?
    Xitoring é compatível com o Apache CouchDB 2.x e 3.x. A integração lê os pontos de extremidade integrados do CouchDB /_node/_local/_stats e /_active_tasks, que estão disponíveis em todas as versões recentes.
    A integração afetará o desempenho do CouchDB?
    Não. A Xitogent recolhe métricas através da leitura dos pontos de extremidade de estatísticas HTTP leves do CouchDB. A sobrecarga é insignificante — equivale a uma única chamada de API por intervalo de recolha.
    Monitoriza a replicação do CouchDB?
    Sim. O Xitoring monitoriza as tarefas de replicação ativas, o atraso na replicação e os números de sequência dos documentos. Será alertado caso a replicação fique atrasada ou pare completamente, ajudando-o a manter a consistência dos dados entre os nós.
    É possível monitorizar várias instâncias do CouchDB num único servidor?
    Sim. Se executar várias instâncias do CouchDB em portas diferentes, o Xitogent pode ser configurado para monitorizar cada uma delas de forma independente, com recolha de métricas e limiares de alerta distintos.
    Como funciona a monitorização da compactação?
    Xitoring monitoriza a data da última compactação, os tamanhos atuais dos ficheiros da base de dados e as tarefas de compactação ativas. Pode configurar alertas para serem acionados quando as bases de dados ultrapassarem um limite ou quando a compactação não for executada dentro do calendário previsto.
    Com que frequência são recolhidos os indicadores?
    Por predefinição, as métricas são recolhidas a intervalos de 1 minuto. Este intervalo pode ser ajustado através do painel de controlo do Xitoring ou da CLI, de modo a corresponder aos seus requisitos de monitorização.
    Como monitorizo o throughput de leitura/escrita no CouchDB?
    Leia `couchdb.database_reads`/`database_writes` para a taxa de operações ao nível do cluster, mais `couchdb.document_inserts`/`writes` para a taxa ao nível do documento. Compare com `couchdb.httpd.requests` para deduzir a divisão entre leituras/escritas. Para detalhe por base de dados, consulte o `_stats` de cada base (CouchDB 2.x) ou leia a superfície de métricas por base (CouchDB 3.x).
    Como deteto desequilíbrio de shards no CouchDB?
    Três sinais: `mem3.shard_cache.miss` (taxa de misses alta = churn ou topologia de shards errada), `fabric.read_repairs.success`/`failure` (repairs em aumento = inconsistências de shards a ser corrigidas durante leituras) e `couchdb.open_databases` por nó (distribuição desigual = é necessário rebalancear shards). Use `/_membership` para confirmar que todos os nós participam; faça rebalanceamento via `mem3:expand_clusters/0` se a contagem de shards de um nó for significativamente baixa.
    Que versões do CouchDB são suportadas?
    Apache CouchDB 2.x e 3.x (3.3, 3.4, 3.5) são totalmente suportadas. A 3.4 introduziu índices Mango keys-only covering (ganho de 10x em p95 para covered queries); a 3.5 introduziu a sonda de readiness do Clouseau. A integração também funciona com implementações geridas via a API HTTP partilhada. O Clouseau FTS (porta 5985) é tratado como um sidecar separado — monitorize `connected` para a sua saúde.

    Comece a monitorizar CouchDB hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações