
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.
BetterDB Monitor
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.

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,
localhostdésigne le conteneur lui-même, pas votre hôte — utilisez donchost.docker.internalcomme 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 commandedocker runpour 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) :
| Tag | Ce que c'est |
|---|---|
latest, X.Y.Z-no-ai | Image par défaut - toutes les fonctionnalités de surveillance incluses, sans les dépendances pour l'AI Helper local-LLM expérimental |
X.Y.Z | Ajoute 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
| Variable | Requis | Par défaut | Description |
|---|---|---|---|
DB_HOST | Oui | localhost | Hôte Valkey/Redis à surveiller |
DB_PORT | Non | 6379 | Port Valkey/Redis |
DB_PASSWORD | Non | - | Mot de passe Valkey/Redis |
DB_USERNAME | Non | default | Nom d'utilisateur ACL Valkey/Redis |
DB_TYPE | Non | auto | Type de base de données : auto, valkey, ou redis |
DB_TLS | Non | false | Dé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_TYPE | Non | memory | Backend de stockage : memory ou postgres |
STORAGE_URL | Conditionnel | - | URL de connexion PostgreSQL (requis si STORAGE_TYPE=postgres) |
STORAGE_SSL_CA | Non | - | 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_VERIFY | Non | false | Se 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 |
PORT | Non | 3001 | Port HTTP de l'application |
NODE_ENV | Non | production | Environnement Node |
ANOMALY_DETECTION_ENABLED | Non | true | Activer la détection d'anomalies |
ANOMALY_PROMETHEUS_INTERVAL_MS | Non | 30000 | Intervalle de mise à jour du résumé Prometheus (ms) |
BETTERDB_LICENSE_KEY | Non | - | Clé de licence en ligne (Pro/Enterprise), validée via le réseau |
BETTERDB_OFFLINE_LICENSE_FILE | Non | - | Chemin vers une licence hors ligne signée .jwt pour les hôtes air-gapped (voir ci-dessous) |
BETTERDB_OFFLINE_LICENSE | Non | - | Jeton de licence hors ligne sous forme de chaîne JWT en ligne |
BETTERDB_DATA_DIR | Non | /app/data | Répertoire pour l'état de licence persisté (monter un volume inscriptible) |
ENCRYPTION_KEY | Non | - | 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_DIR | Non | - | 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_TELEMETRY | Non | true | Dé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_KEYest 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_DIRsur 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. LaissezBETTERDB_SSH_KEY_DIRnon 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 debetterdb.comet 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 :
- 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. - Transférez-le vers l'hôte air-gapped comme vous le souhaitez (USB, gestion de configuration, un montage de secret Docker/Kubernetes).
- 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 :
| Backend | Cas d'usage | Notes |
|---|---|---|
memory | Tests, environnements éphémères | Par défaut dans Docker ; toutes les données sont perdues au redémarrage |
postgres | Production | STORAGE_TYPE=postgres + STORAGE_URL=postgresql://user:pass@host:port/db |
turso | Production / SQLite serverless | STORAGE_TYPE=turso + STORAGE_URL=libsql://... + STORAGE_AUTH_TOKEN ; fonctionne dans Docker |
sqlite | Développement local / CLI | Module 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.
| Package | Langage | Registre |
|---|---|---|
@betterdb/monitor | TypeScript | npm |
@betterdb/mcp | TypeScript | npm |
@betterdb/agent | TypeScript | npm |
@betterdb/semantic-cache | TypeScript | npm |
betterdb-semantic-cache | Python | PyPI |
@betterdb/agent-cache | TypeScript | npm |
betterdb-agent-cache | Python | PyPI |
cache-benchmark | Python | Harnais de rejeu pour le benchmarking des caches sémantiques |
Stack technique
- Backend : NestJS avec adaptateur Fastify,
iovalkeypour 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).