Bases de données
    Mis à jour le mai 2026
    CouchDB logo

    CouchDB Suivi

    Surveillez en temps réel le débit des requêtes CouchDB, l'état de la réplication, les opérations sur les documents et les indicateurs de compactage, sans aucune configuration.

    Commencer l'essai gratuitConsulter les documents

    Pourquoi surveiller ? CouchDB?

    Apache CouchDB est une base de données NoSQL orientée documents dotée d'une réplication multi-maître. La surveillance de CouchDB garantit une réplication efficace, des performances de requête optimales et un compactage régulier pour votre couche de données distribuée.

    Détection automatique via Xitogent
    Surveillance du taux de requêtes HTTP
    Statut de réplication et suivi du retard
    Opérations de lecture/écriture de documents
    Surveillance de la progression du compactage
    Métriques de construction des index de vues
    Suivi de la taille des bases de données
    Intervalles de collecte d'1 minute
    Seuils d'alerte personnalisables pour chaque métrique
    Intervalles de collecte des métriques d'une minute par défaut
    Qu'est-ce que le monitoring CouchDB ?

    Le monitoring CouchDB, expliqué

    Le monitoring CouchDB détecte les défaillances du scheduler de réplication, les retards de compactage smoosh, le déséquilibre des shards, les blocages de construction d'index de vues et les pics d'erreurs HTTP avant qu'ils ne provoquent des échecs de sync chez les clients PouchDB, de la corruption de documents ou des timeouts de requêtes. Pour les applications mobiles/web offline-first, la synchronisation IoT edge et tout cluster CouchDB multi-master, la visibilité par nœud combinée à la santé des jobs de réplication est ce qui sépare une alerte propre à 60 secondes d'une chasse de plusieurs jours dans les logs fabric. Xitoring découvre automatiquement votre CouchDB, lit les endpoints HTTP natifs et achemine les alertes vers Slack, PagerDuty, Telegram ou votre astreinte existante.

    Indicateurs

    Ce que nous surveillons

    Requêtes/sec

    Taux de requêtes API HTTP.

    Lectures de documents

    Opérations de lecture de documents par seconde.

    Écritures de documents

    Opérations d'écriture de documents par seconde.

    Statut de réplication

    Statut des tâches de réplication actives.

    Taille de la base de données

    Taille de chaque base de données sur disque.

    Statut du compactage

    Indique si le compactage est en cours.

    Open Databases / Open OS Files

    `couchdb.open_databases` et `couchdb.open_os_files`. S'approcher du plafond OS `ulimit -n` provoque des défaillances dures — augmentez `ulimit` et `[couchdb] max_dbs_open` de CouchDB simultanément.

    Progression de construction d'index de vues

    Depuis `/_active_tasks` (type=indexer) : `changes_done`/`total_changes` par design document. Des builds lents ou bloqués bloquent les requêtes qui dépendent de ces vues.

    Progression du compactage

    Depuis `/_active_tasks` (type=database_compaction / view_compaction) : pourcentage de progression. Smoosh gère l'auto-compactage en 3.x — alertez quand une tâche de compactage dure plus longtemps que prévu pour la taille de la base.

    Fabric Read Repairs

    `fabric.read_repairs.success`/`failure`. Reflète l'incohérence de shards corrigée à la volée pendant les lectures. Des read repairs soutenus signalent un nœud désynchronisé ou un mauvais shard.

    Taux de hit du Shard Cache

    `mem3.shard_cache.hit` / (`hit` + `miss`). Le cache interne du cluster pour le routage des shards — un faible taux de hit signifie du churn (changements de composition) ou de la pression mémoire.

    Taille de la base sur disque

    Taille du fichier par base de données, suivie dans le temps. Une croissance régulière entre les compactages est normale ; un pic sans récupération signifie que le compactage ne suit pas le rythme des écritures.

    Déclencheurs et alertes

    Configurables déclencheurs d'alerte

    Configurez des déclencheurs personnalisés dans votre tableau de bord pour être averti dès que les indicateurs d{name}s dépassent les seuils que vous avez définis.

    CouchDB tableau de bord de configuration des déclencheurs de surveillance

    Lag de réplication

    crucial

    Se déclenche lorsque la réplication prend du retard.

    Taux de requêtes

    avertissement

    Alerte sur des schémas de requêtes inhabituels.

    Taille de la base de données

    avertissement

    Se déclenche lorsque la base de données dépasse le seuil de taille.

    Compactage

    avertissement

    Se déclenche lorsque le compactage n'a pas été exécuté récemment.

    01

    Importance de la surveillance CouchDB

    La réplication multi-maître de CouchDB nécessite une surveillance pour garantir la cohérence des données et les performances.

    • Suivre la santé de la réplication entre clusters
    • Surveiller les opérations sur documents pour les performances
    • Détecter les besoins de compactage
    • Garantir la gestion de la taille de la base de données
    Surveillance CouchDB
    Analytique de réplication
    02

    Pourquoi choisir Xitoring

    Surveillance CouchDB sans configuration.

    • Installation en une commande
    • Nœuds mondiaux
    • Tableau de bord unifié
    • Alertes multicanaux
    • Conservation historique
    Vue d'ensemble
    Alertes
    Cas d'usage

    Scénarios courants de monitoring CouchDB

    Où CouchDB fonctionne généralement aujourd'hui — et ce qui pourrait mal tourner si personne ne surveille.

    Applications mobiles et de terrain qui fonctionnent hors ligne

    Les applications de point de vente au détail, de santé et de services sur le terrain synchronisent leurs données avec un serveur central chaque fois qu'elles sont en ligne. Lorsque cette synchronisation échoue silencieusement, le personnel continue de travailler — mais le bureau prend des décisions basées sur des informations obsolètes. Nous détectons l'échec dès qu'il commence afin que les données restent fiables.

    Données provenant d'appareils distants

    Les capteurs et les appareils sur le terrain renvoient leurs lectures à une base de données centrale. Lorsque ce pipeline se bloque, les données s'accumulent sur l'appareil et finissent par être perdues. Nous surveillons le flux de bout en bout afin que tout blocage soit détecté avant qu'une seule lecture ne soit perdue.

    Base de données haute disponibilité pour les applications critiques

    Les applications de production répartissent leur base de données sur plusieurs serveurs afin qu'une seule défaillance ne les mette pas hors service. Mais des déséquilibres subtils entre les serveurs peuvent éroder silencieusement cette protection. Nous les détectons tôt afin que le filet de sécurité reste réel lorsque vous en avez réellement besoin.

    Avant de commencer

    Prérequis pour CouchDB

    Assurez-vous d'avoir tout cela en place — la plupart des installations sont une affaire de 60 secondes une fois ces conditions réunies.

    • CouchDB 2.x ou 3.x en cours d'exécution
    • Identifiants admin avec accès aux endpoints /_node et /_stats
    • Accessibilité réseau de Xitogent vers l'API HTTP de CouchDB
    Guide d'installation

    Commencez par procès-verbal

    1

    Installer Xitogent sur votre serveur

    Si ce n'est pas déjà fait, installez l'agent de monitoring léger Xitogent sur l'hôte qui exécute CouchDB.

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

    Exposer l'endpoint de statistiques CouchDB

    CouchDB expose ses statistiques serveur via son API HTTP à `/_node/_local/_stats` (port 5984 par défaut). Assurez-vous que l'endpoint est accessible depuis l'hôte de l'agent et que l'utilisateur configuré dispose d'un accès en lecture aux endpoints administratifs.

    sudo xitogent integrate
    3

    Activer l'intégration CouchDB

    Utilisez le tableau de bord Xitoring ou la CLI pour activer l'intégration CouchDB. Xitogent détecte automatiquement votre nœud et commence à collecter les métriques de requêtes, réplication et stockage.

    4

    Configurer les seuils d'alerte (facultatif)

    Définissez des seuils personnalisés pour le retard de réplication, le taux de requêtes ou la taille de base de données pour repérer les problèmes de capacité et de réplication avant qu'ils ne deviennent des pannes.

    5

    Vérifier que tout fonctionne

    Exécutez cette commande sur le serveur pour confirmer que Xitogent a bien détecté l'intégration. De nouvelles métriques apparaîtront sur votre tableau de bord dans environ 30 secondes.

    sudo xitogent status
    Comparer

    Vous envisagez des alternatives ?

    Découvrez comment Xitoring se positionne face aux alternatives pour la surveillance de CouchDB — tarifs forfaitaires, intégrations plus poussées et un seul agent pour couvrir tout votre stack.

    Voir toutes les comparaisons

    Souvent a posé des questions

    Quelles versions de CouchDB sont prises en charge ?
    Xitoring prend en charge Apache CouchDB 2.x et 3.x. L'intégration lit les points de terminaison intégrés /_node/_local/_stats et /_active_tasks de CouchDB, qui sont disponibles dans toutes les versions récentes.
    Cette intégration aura-t-elle un impact sur les performances de CouchDB ?
    Non. Xitogent collecte des métriques en interrogeant les points de terminaison HTTP légers de CouchDB dédiés aux statistiques. La charge supplémentaire est négligeable : elle équivaut à un seul appel d'API par intervalle de collecte.
    Est-ce qu'il surveille la réplication de CouchDB ?
    Oui. Xitoring surveille les tâches de réplication en cours, le décalage de réplication et les numéros de séquence des documents. Vous recevrez une alerte si la réplication prend du retard ou s'arrête complètement, ce qui vous aidera à garantir la cohérence des données entre les nœuds.
    Puis-je surveiller plusieurs instances de CouchDB sur un seul serveur ?
    Oui. Si vous exécutez plusieurs instances de CouchDB sur des ports différents, Xitogent peut être configuré pour surveiller chacune d'entre elles de manière indépendante, avec des paramètres de collecte de métriques et des seuils d'alerte distincts.
    Comment fonctionne la surveillance du compactage ?
    Xitoring surveille la date de la dernière compression, la taille actuelle des fichiers de base de données et les tâches de compression en cours. Vous pouvez configurer des alertes qui se déclenchent lorsque la taille des bases de données dépasse un certain seuil ou lorsque la compression n'a pas été effectuée selon le calendrier prévu.
    À quelle fréquence les indicateurs sont-ils collectés ?
    Par défaut, les données sont collectées toutes les minutes. Cet intervalle peut être modifié via le tableau de bord Xitoring ou l'interface de ligne de commande (CLI) afin de répondre à vos besoins en matière de surveillance.
    Comment surveiller le débit de lecture/écriture CouchDB ?
    Lisez `couchdb.database_reads`/`database_writes` pour le taux d'opérations au niveau cluster, plus `couchdb.document_inserts`/`writes` pour le taux au niveau document. Comparez à `couchdb.httpd.requests` pour déduire la répartition lectures/écritures. Pour une décomposition par base, interrogez le `_stats` de chaque base (CouchDB 2.x) ou lisez depuis la surface de métriques par base (CouchDB 3.x).
    Comment détecter un déséquilibre de shards CouchDB ?
    Trois signaux : `mem3.shard_cache.miss` (taux de miss élevé = churn ou mauvaise topologie de shards), `fabric.read_repairs.success`/`failure` (réparations en hausse = incohérence de shards corrigée pendant les lectures), et par nœud `couchdb.open_databases` (distribution inégale = rééquilibrage de shards nécessaire). Utilisez `/_membership` pour confirmer que tous les nœuds participent ; rééquilibrez via `mem3:expand_clusters/0` si le nombre de shards d'un nœud est significativement bas.
    Quelles versions de CouchDB sont prises en charge ?
    Apache CouchDB 2.x et 3.x (3.3, 3.4, 3.5) sont entièrement pris en charge. La 3.4 a ajouté les index covering keys-only Mango (gain p95 10x sur les requêtes couvertes) ; la 3.5 a ajouté la sonde de readiness Clouseau. L'intégration fonctionne aussi avec les déploiements managés via l'API HTTP partagée. Clouseau FTS (port 5985) est traité comme un sidecar séparé — surveillez `connected` pour sa santé.

    Commencer à surveiller CouchDB aujourd'hui

    Configuration en moins de 60 secondes. Aucune carte bancaire requise. Statistiques complètes dès le premier jour.

    Commencer l'essai gratuit

    Continuez à explorer

    Connexes Intégrations