Retour aux mises à jour
New releaseSep 3, 2026

monitor v0.41.0

Surveillance en temps réel et analyse des slowlogs pour les bases de données Valkey et Redis avec détection d'anomalies, audit des ACL et export des métriques Prometheus.

Partager

BetterDB Monitor

Docker Pulls Docker Image Version Artifact Hub npm npm downloads API Tests License Valkey Redis

La couche de supervision que Valkey mérite.

BetterDB conserve ce que Valkey jette - slowlogs, schémas de commandes, activité des clients, signaux d'anomalie - afin que vous puissiez déboguer ce qui s'est passé à 3h du matin, et pas seulement ce qui se passe maintenant. Conçu pour Valkey 8.x avec prise en charge native de COMMANDLOG, CLUSTER SLOT-STATS et des métriques d'E/S par thread. Compatible avec Redis 6+ pour tout le reste.

Site web | Docker Hub | npm | Documentation | Blog

BetterDB est développé par BetterDB Inc., une société à mission d'intérêt public opérant sous la OCV Open Charter.

BetterDB Monitor - Key Analytics with per-type key size distribution histograms

Démarrage rapide (Docker)```bash

docker run -d --name betterdb -p 3001:3001 betterdb/monitor:latest

Pointez votre navigateur vers `http://localhost:3001`. Pour surveiller une instance spécifique :```bash
docker run -d \
  --name betterdb \
  -p 3001:3001 \
  -e DB_HOST=your-valkey-host \
  -e DB_PORT=6379 \
  -e DB_PASSWORD=your-password \
  betterdb/monitor:latest

Vous connectez-vous à une base de données sur votre machine hôte ? À l'intérieur du conteneur, localhost désigne le conteneur lui-même, pas votre hôte — utilisez donc host.docker.internal comme hôte de la base de données. Sur Docker Desktop (macOS/Windows), cela fonctionne d'emblée ; sur Linux, ajoutez --add-host=host.docker.internal:host-gateway à la commande docker run pour que le nom soit résolu. Le bouton « se connecter à l'instance locale » en un clic du tableau de bord détecte cela automatiquement et pré-remplit le bon hôte pour vous.

Deux variantes d'image sont publiées, toutes deux multi-arch (linux/amd64, linux/arm64) :

TagCe que c'est
latest, X.Y.Z-no-aiImage par défaut - toutes les fonctionnalités de surveillance incluses, sans les dépendances pour l'AI Helper local-LLM expérimental
X.Y.ZAjoute l'AI Helper expérimental (apportez votre propre Ollama ; désactivé par défaut via AI_ENABLED)

Voir Docker Production Deployment pour le stockage persistant, les ports personnalisés, les licences et les configurations en environnement isolé.

Démarrage rapide (Kubernetes / Helm)```bash

helm repo add betterdb https://docs.betterdb.com/charts helm repo update helm install betterdb-monitor betterdb/betterdb-monitor
--namespace betterdb --create-namespace
--set db.host=my-valkey.default.svc.cluster.local
--set db.password=yourpassword

Puis `kubectl port-forward -n betterdb svc/betterdb-monitor 3001:3001` et ouvrez `http://localhost:3001`, ou activez l'ingress du chart. L'historique basé sur PostgreSQL, l'apport de vos propres Secrets et la licence en environnement isolé sont tous couverts dans le [guide Kubernetes](https://docs.betterdb.com/kubernetes) et le [README du chart](https://github.com/betterdb-inc/monitor/blob/master/charts/betterdb-monitor/README.md).

## Démarrage rapide (CLI)

Exécutez BetterDB Monitor sans Docker :```bash
npx @betterdb/monitor

Lors de la première exécution, un assistant de configuration interactif vous guide à travers la connexion à la base de données, le backend de stockage (SQLite, PostgreSQL ou en mémoire) et les paramètres du serveur. La configuration est enregistrée dans ~/.betterdb/config.json.```bash npm install -g @betterdb/monitor # global install betterdb --setup # re-run setup wizard betterdb --port 8080 # override server port betterdb --db-host 1.2.3.4 # override database host betterdb --help # all options

Nécessite Node.js >= 20.0.0 et une instance Valkey ou Redis à surveiller. Pour le stockage SQLite, exécutez également `npm install -g better-sqlite3`.

## Ce que vous obtenez

### Tout voir, tout conserver

- **Analyses historiques** - interrogez les slowlogs, les modèles de commandes, l'activité des clients et la latence sur n'importe quelle plage temporelle. Les données qui disparaissaient auparavant après une rotation des logs.
- **Prise en charge de COMMANDLOG** - exclusivité Valkey 8.1+. Les requêtes volumineuses et les réponses volumineuses, pas seulement les lentes.
- **Sessions de capture MONITOR** - enregistrez le trafic réel à la demande : suivi en direct, filtrage, rejeu, export au format JSON/CSV et recoupement avec l'historique des connexions.
- **Suivi des hot keys** - principales clés par fréquence d'accès avec évolution du classement dans le temps. Key Analytics (Pro, gratuit en accès anticipé) ajoute les distributions de type, TTL et taille à partir d'un échantillonnage en direct.
- **Visibilité du cluster** - graphiques de topologie, heatmaps SLOT-STATS, CPU par slot et distribution des clés.
- **Métriques des threads CPU et I/O** - visibilité par thread qu'aucun outil Redis ne peut fournir.
- **Analyses des clients** - voyez exactement quel service est responsable de quoi, attribué par nom et modèle de client.
- **Piste d'audit ACL** - suivez qui a accédé à quoi, conservé pour la conformité et le débogage post-incident.

### Comprendre et agir

- **Détection d'anomalies** (Pro, gratuit en accès anticipé) - apprentissage automatique de la ligne de base avec événements corrélés et diagnostics en langage clair. Plus de 20 détecteurs, sans seuils manuels.
- **Prévision de capacité** - temps projeté avant saturation pour la mémoire, les ops/sec, le CPU et la fragmentation.
- **Webhooks** - livraisons d'alertes signées HMAC avec nouvelles tentatives et journal complet des livraisons.
- **Migration à chaud** - passez de Redis à Valkey avec un workflow en trois phases : analyse, exécution et validation.

### Conçu pour l'ère de l'IA

- **Observabilité de la recherche vectorielle** - ops/sec et latence de FT.SEARCH avec santé par index pour [valkey-search](https://github.com/valkey-io/valkey-search) et RediSearch. Voir [docs/vector-ai](https://github.com/betterdb-inc/monitor/blob/master/docs/vector-ai/README.md).
- **Latence d'inférence** - p50/p95/p99 par index, avec alertes de violation de SLA (Pro, gratuit en accès anticipé).
- **Intelligence du cache sémantique** (Pro, gratuit en accès anticipé) - santé du taux de succès, recommandations de seuil de similarité et workflow de proposition approuver/rejeter. Observabilité de la mémoire des agents incluse.
- **Traces IA** - cascades de spans OTLP depuis votre application IA, corrélées avec l'état Valkey en direct sous chaque requête. Voir [docs/opentelemetry.md](https://github.com/betterdb-inc/monitor/blob/master/docs/opentelemetry.md).

### Se branche partout

- **Serveur MCP** - 60 outils pour Claude Code, Cursor ou tout client MCP via [`@betterdb/mcp`](https://github.com/betterdb-inc/monitor/blob/master/packages/mcp).
- **Endpoint Prometheus** - plus de 100 métriques `betterdb_*`. Voir [docs/prometheus-metrics.md](https://github.com/betterdb-inc/monitor/blob/master/docs/prometheus-metrics.md).
- **OpenTelemetry** - ingérez des traces OTLP et répliquez les métriques et événements vers n'importe quel backend OTLP. Voir [docs/opentelemetry.md](https://github.com/betterdb-inc/monitor/blob/master/docs/opentelemetry.md).
- **API REST** - tout dans l'interface utilisateur est un appel API, documenté via OpenAPI.

## Accédez à vos données à votre façon

| Interface | Détails |
|-----------|---------|
| Interface web | `http://localhost:3001` |
| Serveur MCP | `npx @betterdb/mcp` (stdio) - créez un token sous Settings → MCP Tokens (requis sur le cloud, facultatif en auto-hébergé) |
| Prometheus | `http://localhost:3001/api/prometheus/metrics` |
| API REST (OpenAPI) | `http://localhost:3001/docs` |
| Vérification de l'état | `http://localhost:3001/api/health` |

> **Remarque** : dans les builds de production (Docker, CLI), les routes API sont servies sous le préfixe `/api`. En développement local (`pnpm dev`), il n'y a pas de préfixe - par exemple `http://localhost:3001/health`.

## Bases de données prises en charge

| Base de données | Version minimale | Fonctionnalités prises en charge |
|----------|----------------|-------------------|
| **Valkey** | 8.0+ | Toutes les fonctionnalités, y compris COMMANDLOG (8.1+) et CLUSTER SLOT-STATS |
| **Redis** | 6+ | Toutes les fonctionnalités sauf COMMANDLOG et CLUSTER SLOT-STATS, exclusifs à Valkey |

Le backend utilise un adaptateur unifié au-dessus du client `iovalkey` compatible au niveau du protocole et détecte automatiquement Valkey vs Redis à partir de la réponse `INFO` (`DB_TYPE=auto`). Les capacités comme COMMANDLOG et SLOT-STATS sont détectées par version, et l'interface utilisateur se dégrade gracieusement lorsqu'une fonctionnalité n'est pas disponible.

Les services managés sont également pris en charge - des guides pour AWS ElastiCache, MemoryDB, Redis Cloud et Upstash se trouvent dans [docs/providers](https://github.com/betterdb-inc/monitor/blob/master/docs/providers), et [`@betterdb/agent`](https://github.com/betterdb-inc/monitor/blob/master/packages/agent) atteint les instances uniquement accessibles via VPC par le biais d'un WebSocket sortant.

## Déploiement Docker en production

L'image Docker contient l'application de surveillance (backend + frontend). Elle nécessite :
1. Une instance Valkey/Redis à surveiller
2. Une instance PostgreSQL pour la persistance des données (ou utilisez le stockage en mémoire)

### Exécution avec stockage PostgreSQL```bash
docker run -d \
  --name betterdb-monitor \
  -p 3001:3001 \
  -e DB_HOST=your-valkey-host \
  -e DB_PORT=6379 \
  -e DB_PASSWORD=your-password \
  -e STORAGE_TYPE=postgres \
  -e STORAGE_URL=postgresql://user:pass@postgres-host:5432/dbname \
  betterdb/monitor

Exécution sur un port personnalisé

Définissez la variable d'environnement PORT et faites correspondre le mappage -p :```bash docker run -d
--name betterdb-monitor
-p 8080:8080
-e PORT=8080
-e DB_HOST=your-valkey-host
betterdb/monitor

### Exécuter avec le réseau de l'hôte (accéder aux services localhost)

Si votre Valkey et PostgreSQL s'exécutent sur le même hôte :```bash
docker run -d \
  --name betterdb-monitor \
  --network host \
  -e DB_HOST=localhost \
  -e DB_PORT=6380 \
  -e DB_PASSWORD=devpassword \
  -e STORAGE_TYPE=postgres \
  -e STORAGE_URL=postgresql://dev:devpass@localhost:5432/postgres \
  betterdb/monitor

Variables d'environnement

VariableRequisPar défautDescription
DB_HOSTOuilocalhostHôte Valkey/Redis à surveiller
DB_PORTNon6379Port Valkey/Redis
DB_PASSWORDNon-Mot de passe Valkey/Redis
DB_USERNAMENondefaultNom d'utilisateur ACL Valkey/Redis
DB_TYPENonautoType de base de données : auto, valkey, ou redis
DB_TLSNonfalseDéfinir sur true pour se connecter à la base de données surveillée via TLS (requis par les fournisseurs managés tels que Aiven ou ElastiCache Serverless)
STORAGE_TYPENonmemoryBackend de stockage : memory ou postgres
STORAGE_URLConditionnel-URL de connexion PostgreSQL (requis si STORAGE_TYPE=postgres)
STORAGE_SSL_CANon-Chemin (ou URL HTTPS de confiance) vers un certificat CA utilisé pour vérifier le serveur PostgreSQL. Pour les fournisseurs managés avec leur propre CA (par ex. Aiven), fournissez le CA du projet ici pour une vérification complète de la chaîne + du nom d'hôte. Prend le pas sur STORAGE_SSL_NO_VERIFY
STORAGE_SSL_NO_VERIFYNonfalseSe connecter à PostgreSQL via TLS sans vérifier le certificat du serveur (chiffré mais non authentifié). Pratique pour les fournisseurs managés qui présentent leur propre CA et imposent sslmode=require lorsque vous ne pouvez pas fournir STORAGE_SSL_CA. Préférez STORAGE_SSL_CA en production
PORTNon3001Port HTTP de l'application
NODE_ENVNonproductionEnvironnement Node
ANOMALY_DETECTION_ENABLEDNontrueActiver la détection d'anomalies
ANOMALY_PROMETHEUS_INTERVAL_MSNon30000Intervalle de mise à jour du résumé Prometheus (ms)
BETTERDB_LICENSE_KEYNon-Clé de licence en ligne (Pro/Enterprise), validée via le réseau
BETTERDB_OFFLINE_LICENSE_FILENon-Chemin vers une licence hors ligne signée .jwt pour les hôtes air-gapped (voir ci-dessous)
BETTERDB_OFFLINE_LICENSENon-Jeton de licence hors ligne sous forme de chaîne JWT en ligne
BETTERDB_DATA_DIRNon/app/dataRépertoire pour l'état de licence persisté (monter un volume inscriptible)
ENCRYPTION_KEYNon-Clé (min 16 caractères) utilisée pour le chiffrement d'enveloppe des mots de passe de connexion stockés et des secrets de tunnel SSH au repos. Sans elle, les secrets sont stockés en clair
BETTERDB_SSH_KEY_DIRNon-Répertoire dans lequel les clés privées SSH côté serveur doivent résider. Active la source de clé « chemin de fichier serveur » pour les tunnels SSH ; le chemin de clé d'une connexion doit se résoudre à l'intérieur. Non défini désactive les clés basées sur fichier (les clés collées en ligne fonctionnent toujours)
BETTERDB_TELEMETRYNontrueDéfinir sur false pour désactiver la télémétrie anonyme

Référence complète, incluant l'IA, le réglage des webhooks et les seuils de health-gate : docs/configuration.md. Pour l'ingestion de traces OTLP et l'export de métriques/événements, voir docs/opentelemetry.md.

Tunnels SSH

Les connexions peuvent atteindre une base de données via un hôte bastion/jump SSH au lieu de se connecter directement — utile pour Valkey/Redis dans un sous-réseau privé, ElastiCache ou MemoryDB. Activez Connect via SSH tunnel lors de l'ajout d'une connexion et fournissez l'hôte SSH, le port et le nom d'utilisateur. Un seul saut est pris en charge.

L'authentification se fait soit par mot de passe, soit par clé privée. Les clés privées proviennent de l'une de deux sources :

  • Coller la clé (en ligne) : le contenu de la clé PEM est soumis avec la connexion. Il est stocké chiffré au repos uniquement lorsque ENCRYPTION_KEY est définie (chiffrement d'enveloppe) ; sans cette clé, il est stocké en clair, comme les mots de passe de connexion. Fonctionne partout, y compris dans les déploiements managés/cloud.
  • Chemin de fichier serveur : la clé réside déjà sur le système de fichiers du serveur de surveillance et est référencée par chemin. Cela nécessite de définir la variable d'environnement BETTERDB_SSH_KEY_DIR sur le répertoire contenant les clés autorisées, et le chemin référencé doit se résoudre à l'intérieur, afin que l'API ne puisse jamais être contrainte de lire des fichiers arbitraires. Laissez BETTERDB_SSH_KEY_DIR non défini pour désactiver cette option.

Vous pouvez éventuellement épingler l'empreinte de clé d'hôte du serveur SSH (SHA256:...) sur la connexion ; lorsqu'elle est définie, le tunnel est refusé à moins que le serveur ne présente une clé correspondante, empêchant les attaques de type man-in-the-middle sur le chemin du bastion. Laissée vide, l'identité du serveur n'est pas vérifiée (un avertissement est journalisé).

Le tunnel transfère vers la base de données via 127.0.0.1 ; lorsque TLS est activé, le certificat est toujours validé par rapport au nom d'hôte réel de la base de données. Définissez ENCRYPTION_KEY pour que les mots de passe SSH, les phrases secrètes de clé et les clés en ligne soient chiffrés au repos.

Limitation connue — topologies cluster/Sentinel : seule la connexion que vous configurez est tunnellisée. La surveillance de cluster et Sentinel se propage aux autres nœuds en utilisant les adresses que ces nœuds annoncent (CLUSTER NODES / Sentinel), et ces connexions par nœud sont établies directement, pas via le tunnel. Si les autres nœuds ne sont accessibles que via le bastion (par ex. ElastiCache/MemoryDB dans un sous-réseau privé), les vues par nœud seront indisponibles. Utilisez les tunnels SSH pour la surveillance mono-nœud/primaire, ou placez le moniteur là où il peut atteindre les nœuds du cluster directement.

Licence et prise en charge air-gapped

BetterDB Monitor débloque les fonctionnalités Pro/Enterprise de l'une de deux manières, selon que l'hôte dispose ou non d'un accès Internet :

  • Clé de licence en ligne - définissez BETTERDB_LICENSE_KEY. Le moniteur la valide auprès de betterdb.com et met en cache un jeton signé vérifié localement, afin que votre niveau continue de fonctionner pendant de courtes pannes et redémarrages.
  • Jeton de licence hors ligne / air-gapped - pour les hôtes sans aucun accès Internet (voir ci-dessous).

Comment fonctionne la licence air-gapped

Chaque droit est un JWT RS256 signé. Le moniteur le vérifie localement par rapport aux clés publiques intégrées dans l'image - il n'a jamais besoin d'atteindre un serveur de licence pour faire confiance à un jeton. Ainsi, un hôte air-gapped peut exécuter des niveaux payants avec une connectivité nulle :

  1. Sur une machine connectée à Internet, connectez-vous sur betterdb.com/account/licenses et téléchargez votre jeton de licence hors ligne (.jwt, Pro/Enterprise). Il ne contient aucun secret et ne peut pas être falsifié - toute modification casse la signature.
  2. Transférez-le vers l'hôte air-gapped comme vous le souhaitez (USB, gestion de configuration, un montage de secret Docker/Kubernetes).
  3. Fournissez-le via BETTERDB_OFFLINE_LICENSE_FILE (chemin), BETTERDB_OFFLINE_LICENSE (chaîne en ligne), ou collez-le dans l'interface sous Settings → License → "Air-gapped environment? Activate an offline license."

Lorsqu'un jeton hors ligne est configuré et qu'aucune BETTERDB_LICENSE_KEY n'est définie, le moniteur n'effectue aucune requête sortante - les vérifications de licence, la télémétrie et les pings de mise à jour sont tous désactivés. Il exécute le niveau accordé jusqu'à l'expiration du jeton (les licences perpétuelles sont re-téléchargées annuellement), puis revient à Community.```bash

fully offline - no network required

docker volume create betterdb-data docker run --rm -v betterdb-data:/d alpine chown 1001:1001 /d # volume writable by UID 1001 (one-time)

docker run -d --name betterdb-monitor -p 3001:3001
-e DB_HOST=your-valkey-host -e DB_PORT=6379 -e DB_PASSWORD=your-password
-v /path/to/betterdb-license.jwt:/run/secrets/betterdb-license.jwt:ro
-e BETTERDB_OFFLINE_LICENSE_FILE=/run/secrets/betterdb-license.jwt
-v betterdb-data:/app/data
betterdb/monitor

Vérifiez avec `GET /api/license/status` → `source: offline-token`, `mode: offline`,
`airGapped: true`.

> **Persistance :** montez un volume inscriptible sur `/app/data` afin que la licence hors ligne et
> le jeton de grâce en cas de panne en ligne survivent aux redémarrages. Le conteneur s'exécute en tant qu'**UID 1001**,
> donc un volume fraîchement créé doit être `chown`é vers celui-ci (comme montré ci-dessus) - sinon
> la persistance échoue avec `EACCES … license.jwt`.

Pour le flux complet, la priorité de vérification et le runbook de rotation des clés, consultez
**[Licences hors ligne et air-gapped](https://github.com/betterdb-inc/monitor/blob/master/docs/offline-licenses.md)** et la
**[Référence de configuration](https://github.com/betterdb-inc/monitor/blob/master/docs/configuration.md#license-configuration)**.

### Détails de l'image Docker

- **Image de base** : `node:20-alpine`
- **Taille compressée** : ~360MB (`latest` / `-no-ai`) / ~640MB (image versionnée avec les dépendances LLM locales de l'AI Helper expérimental)
- **Plateformes** : `linux/amd64`, `linux/arm64`
- **Contient** : API backend + fichiers statiques frontend (servis par Fastify)
- **Exclu** : Support SQLite (utilisez PostgreSQL ou le stockage Memory)

### Opérations sur le conteneur```bash
docker logs -f betterdb-monitor        # follow logs
docker stop betterdb-monitor           # stop
docker rm betterdb-monitor             # remove

Backends de stockage

BetterDB Monitor persiste la piste d'audit, les analyses, les captures et les données d'anomalie dans l'un des quatre backends suivants :

BackendCas d'usageNotes
memoryTests, environnements éphémèresPar défaut dans Docker ; toutes les données sont perdues au redémarrage
postgresProductionSTORAGE_TYPE=postgres + STORAGE_URL=postgresql://user:pass@host:port/db
tursoProduction / SQLite serverlessSTORAGE_TYPE=turso + STORAGE_URL=libsql://... + STORAGE_AUTH_TOKEN ; fonctionne dans Docker
sqliteDéveloppement local / CLIModule natif retiré de l'image Docker latest ; STORAGE_SQLITE_FILEPATH facultatif

Métriques Prometheus

Les métriques sont exposées sur GET /api/prometheus/metrics au format texte Prometheus : audit ACL, connexions client, motifs slowlog/commandlog, mémoire, débit, keyspace, réplication, statistiques de slots de cluster et métriques d'exécution Node.js - toutes préfixées par betterdb_.```yaml scrape_configs:

  • job_name: 'betterdb-monitor' metrics_path: '/api/prometheus/metrics' static_configs:
    • targets: ['your-monitor-host:3001']
Référence complète des métriques : [docs/prometheus-metrics.md](https://github.com/betterdb-inc/monitor/blob/master/docs/prometheus-metrics.md) et [docs/prometheus-integration.md](https://github.com/betterdb-inc/monitor/blob/master/docs/prometheus-integration.md).

## Développement

### Structure du projet```
betterdb-monitor/
├── apps/
│   ├── api/                 # NestJS backend (Fastify)
│   └── web/                 # React frontend (Vite)
├── packages/                # Published packages (see below)
├── docs/                    # Documentation site (Jekyll)
├── docker-compose.yml       # Local Valkey (port 6380) and Redis (port 6382) for testing
└── package.json             # Workspace root

Packages

Ce monorepo fournit plusieurs packages autonomes. Voir packages/ pour la liste complète.

PackageLangageRegistre
@betterdb/monitorTypeScriptnpm
@betterdb/mcpTypeScriptnpm
@betterdb/agentTypeScriptnpm
@betterdb/semantic-cacheTypeScriptnpm
betterdb-semantic-cachePythonPyPI
@betterdb/agent-cacheTypeScriptnpm
betterdb-agent-cachePythonPyPI
cache-benchmarkPythonHarnais de rejeu pour le benchmarking des caches sémantiques

Stack technique

  • Backend : NestJS avec adaptateur Fastify, iovalkey pour les connexions Valkey/Redis, TypeScript en mode strict. Port 3001.
  • Frontend : React + TypeScript, Vite, TailwindCSS, Recharts. Serveur de développement sur le port 5173.
  • Monorepo : pnpm workspaces + Turborepo.

Installation locale

Prérequis : Node.js >= 20.0.0, pnpm >= 9.0.0, Docker.```bash pnpm install cp .env.example .env pnpm docker:dev # local Valkey (6380) and Redis (6382) pnpm dev # web on :5173, api on :3001

Pour se connecter à Redis au lieu de Valkey, définissez `DB_PORT=6382` dans `.env`.```bash
pnpm dev:api           # API only
pnpm dev:web           # frontend only
pnpm docker:dev:down   # stop local databases
pnpm build             # production build
pnpm test              # API tests

Constructions d'images Docker :```bash pnpm docker:build # local build pnpm docker:publish # multi-arch build & push (requires buildx)

### Ajout de nouvelles fonctionnalités

1. Ajoutez de nouveaux endpoints dans `apps/api/src/`
2. Ajoutez les appels API correspondants dans `apps/web/src/api/`
3. Ajoutez les types partagés dans `packages/shared/src/types/`

### Style de code

- Mode strict TypeScript, types de retour explicites, pas de `any`
- ESLint + Prettier configurés

## Licence

- Le contenu sous `docs/` est sous licence CC BY-SA 4.0.
- Le contenu sous `proprietary/` est couvert par une licence commerciale (voir `proprietary/LICENSE`). Ces fonctionnalités sont gratuites pendant l'accès anticipé.
- Tout le reste est sous [MIT](https://github.com/betterdb-inc/monitor/blob/master/LICENSE).

Catégories