BetterDB Monitor

Die Überwachungsebene, die Valkey verdient.

BetterDB speichert, was Valkey verwirft – Slowlogs, Befehlsmuster, Client-Aktivitäten, Anomalie-Signale – damit Sie debuggen können, was um 3 Uhr morgens passiert ist, nicht nur, was gerade passiert. Entwickelt für Valkey 8.x mit nativer Unterstützung für COMMANDLOG, CLUSTER SLOT-STATS und I/O-Metriken pro Thread. Für alles andere mit Redis 6+ kompatibel.

Website | Docker Hub | npm | Dokumentation | Blog

BetterDB wird von BetterDB Inc. entwickelt, einem Unternehmen des öffentlichen Nutzens, das unter der OCV Open Charter operiert.

BetterDB Monitor - Key Analytics mit Histogrammen zur Schlüsselgrößenverteilung nach Typ

Schnellstart (Docker)```bash

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

Zeigen Sie mit Ihrem Browser auf `http://localhost:3001`. Um eine bestimmte Instanz zu überwachen:```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

Möchten Sie eine Verbindung zu einer Datenbank auf Ihrem Host-Rechner herstellen? Innerhalb des Containers ist localhost der Container selbst, nicht Ihr Host – verwenden Sie daher host.docker.internal als Datenbank-Host. Bei Docker Desktop (macOS/Windows) funktioniert dies sofort; unter Linux fügen Sie --add-host=host.docker.internal:host-gateway zum docker run-Befehl hinzu, damit der Name aufgelöst wird. Die Ein-Klick-Schaltfläche „Mit lokaler Instanz verbinden“ des Dashboards erkennt dies automatisch und füllt den richtigen Host für Sie vor.

Es werden zwei Image-Varianten veröffentlicht, beide Multi-Arch (linux/amd64, linux/arm64):

Tag	Was es ist
`latest`, `X.Y.Z-no-ai`	Standard-Image – alle Überwachungsfunktionen enthalten, ohne die Abhängigkeiten für den experimentellen lokalen LLM-KI-Assistenten
`X.Y.Z`	Fügt den experimentellen KI-Assistenten hinzu (eigenes Ollama mitbringen; standardmäßig deaktiviert über `AI_ENABLED`)

Siehe Docker-Produktionsbereitstellung für persistenten Speicher, benutzerdefinierte Ports, Lizenzierung und Air-Gapped-Setups.

Schnellstart (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

Dann `kubectl port-forward -n betterdb svc/betterdb-monitor 3001:3001` ausführen und `http://localhost:3001` öffnen, oder das Ingress des Charts aktivieren. PostgreSQL-gestützter Verlauf, Bring-your-own-Secrets und Air-Gapped-Lizenzierung sind alle im [Kubernetes-Leitfaden](https://docs.betterdb.com/kubernetes) und in der [Chart-README](https://github.com/betterdb-inc/monitor/blob/master/charts/betterdb-monitor/README.md) abgedeckt.

## Schnellstart (CLI)

BetterDB Monitor ohne Docker ausführen:```bash
npx @betterdb/monitor

Beim ersten Start führt Sie ein interaktiver Einrichtungsassistent durch die Datenbankverbindung, den Speicher-Backend (SQLite, PostgreSQL oder In-Memory) und die Servereinstellungen. Die Konfiguration wird in ~/.betterdb/config.json gespeichert.```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

Erfordert Node.js >= 20.0.0 sowie eine Valkey- oder Redis-Instanz zur Überwachung. Für SQLite-Speicherung zusätzlich `npm install -g better-sqlite3`.

## Was Sie erhalten

### Alles sehen, alles behalten

- **Historische Analysen** – Slowlogs, Befehlsmuster, Client-Aktivität und Latenz über beliebige Zeiträume abfragen. Die Daten, die früher nach einer Log-Rotation verschwanden.
- **COMMANDLOG-Unterstützung** – Exklusiv für Valkey 8.1+. Große Anfragen und große Antworten, nicht nur die langsamen.
- **MONITOR-Aufnahmesitzungen** – echten Datenverkehr auf Abruf aufzeichnen: Live-Tail, Filtern, Wiedergabe, Export nach JSON/CSV und Abgleich mit dem Verbindungsverlauf.
- **Hot-Key-Tracking** – Top-Keys nach Zugriffshäufigkeit mit Rangbewegung im Zeitverlauf. Key Analytics (Pro, im Early Access kostenlos) fügt Typ-, TTL- und Größenverteilungen aus Live-Stichproben hinzu.
- **Cluster-Sichtbarkeit** – Topologie-Graphen, SLOT-STATS-Heatmaps, CPU- und Key-Verteilung pro Slot.
- **CPU- und I/O-Thread-Metriken** – Sichtbarkeit pro Thread, die kein Redis-Tool bieten kann.
- **Client-Analysen** – genau sehen, welcher Dienst wofür verantwortlich ist, zugeordnet nach Client-Name und -Muster.
- **ACL-Prüfpfad** – nachverfolgen, wer worauf zugegriffen hat, dauerhaft gespeichert für Compliance und Debugging nach Vorfällen.

### Verstehen und handeln

- **Anomalieerkennung** (Pro, im Early Access kostenlos) – automatisches Baseline-Lernen mit korrelierten Ereignissen und Diagnosen in einfacher Sprache. Über 20 Detektoren, keine manuellen Schwellenwerte.
- **Kapazitätsprognose** – prognostizierte Zeit bis zur Obergrenze für Speicher, Operationen/Sekunde, CPU und Fragmentierung.
- **Webhooks** – HMAC-signierte Alarmzustellungen mit Wiederholungsversuchen und vollständigem Zustellprotokoll.
- **Live-Migration** – Wechsel zwischen Redis und Valkey mit einem dreiphasigen Workflow aus Analyse, Ausführung und Validierung.

### Für das KI-Zeitalter gebaut

- **Vektor-Such-Überwachung** – FT.SEARCH-Operationen/Sekunde und Latenz mit Index-Gesundheit pro Index für [valkey-search](https://github.com/valkey-io/valkey-search) und RediSearch. Siehe [docs/vector-ai](https://github.com/betterdb-inc/monitor/blob/master/docs/vector-ai/README.md).
- **Inferenz-Latenz** – p50/p95/p99 pro Index, mit SLA-Verletzungsalarmen (Pro, im Early Access kostenlos).
- **Semantische Cache-Intelligenz** (Pro, im Early Access kostenlos) – Trefferquoten-Gesundheit, Ähnlichkeitsschwellen-Empfehlungen und ein Workflow mit Genehmigen/Ablehnen-Vorschlägen. Beobachtbarkeit des Agentenspeichers inklusive.
- **KI-Traces** – OTLP-Span-Wasserfälle aus Ihrer KI-Anwendung, korreliert mit dem Live-Valkey-Zustand unter jeder Anfrage. Siehe [docs/opentelemetry.md](https://github.com/betterdb-inc/monitor/blob/master/docs/opentelemetry.md).

### Integriert sich in alles

- **MCP-Server** – 60 Tools für Claude Code, Cursor oder jeden MCP-Client über [`@betterdb/mcp`](https://github.com/betterdb-inc/monitor/blob/master/packages/mcp).
- **Prometheus-Endpunkt** – über 100 `betterdb_*`-Metriken. Siehe [docs/prometheus-metrics.md](https://github.com/betterdb-inc/monitor/blob/master/docs/prometheus-metrics.md).
- **OpenTelemetry** – OTLP-Traces aufnehmen und Metriken und Ereignisse an jedes OTLP-Backend spiegeln. Siehe [docs/opentelemetry.md](https://github.com/betterdb-inc/monitor/blob/master/docs/opentelemetry.md).
- **REST-API** – alles in der UI ist ein API-Aufruf, dokumentiert über OpenAPI.

## Zugriff auf Ihre Daten auf Ihre Weise

| Schnittstelle | Details |
|-----------|---------|
| Web-UI | `http://localhost:3001` |
| MCP-Server | `npx @betterdb/mcp` (stdio) – Token unter Einstellungen → MCP-Tokens erstellen |
| Prometheus | `http://localhost:3001/api/prometheus/metrics` |
| REST-API (OpenAPI) | `http://localhost:3001/docs` |
| Health-Check | `http://localhost:3001/api/health` |

> **Hinweis**: In Produktions-Builds (Docker, CLI) werden API-Routen unter dem Präfix `/api` bereitgestellt. In der lokalen Entwicklung (`pnpm dev`) gibt es kein Präfix – z. B. `http://localhost:3001/health`.

## Unterstützte Datenbanken

| Datenbank | Mindestversion | Unterstützte Funktionen |
|----------|----------------|-------------------|
| **Valkey** | 8.0+ | Alle Funktionen einschließlich COMMANDLOG (8.1+) und CLUSTER SLOT-STATS |
| **Redis** | 6+ | Alle Funktionen außer dem Valkey-exklusiven COMMANDLOG und CLUSTER SLOT-STATS |

Das Backend verwendet einen einheitlichen Adapter über den drahtkompatiblen `iovalkey`-Client und erkennt automatisch Valkey vs. Redis anhand der `INFO`-Antwort (`DB_TYPE=auto`). Funktionen wie COMMANDLOG und SLOT-STATS werden pro Version erkannt, und die UI degradiert elegant, wenn eine Funktion nicht verfügbar ist.

Verwaltete Dienste werden ebenfalls unterstützt – Anleitungen für AWS ElastiCache, MemoryDB, Redis Cloud und Upstash finden Sie in [docs/providers](https://github.com/betterdb-inc/monitor/blob/master/docs/providers), und [`@betterdb/agent`](https://github.com/betterdb-inc/monitor/blob/master/packages/agent) erreicht VPC-only-Instanzen über eine ausgehende WebSocket-Verbindung.

## Docker-Produktionsbereitstellung

Das Docker-Image enthält die Überwachungsanwendung (Backend + Frontend). Es erfordert:
1. Eine zu überwachende Valkey/Redis-Instanz
2. Eine PostgreSQL-Instanz für die Datenpersistenz (oder Speicher-Speicherung)

### Mit PostgreSQL-Speicherung ausführen```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

Auf benutzerdefiniertem Port ausführen

Setzen Sie die Umgebungsvariable PORT und passen Sie das -p-Mapping an:```bash docker run -d
--name betterdb-monitor
-p 8080:8080
-e PORT=8080
-e DB_HOST=your-valkey-host
betterdb/monitor

### Mit Host-Netzwerk ausführen (Zugriff auf localhost-Dienste)

Wenn Ihr Valkey und PostgreSQL auf demselben Host laufen:```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

Umgebungsvariablen

Variable	Erforderlich	Standard	Beschreibung
`DB_HOST`	Ja	`localhost`	Valkey/Redis-Host, der überwacht werden soll
`DB_PORT`	Nein	`6379`	Valkey/Redis-Port
`DB_PASSWORD`	Nein	-	Valkey/Redis-Passwort
`DB_USERNAME`	Nein	`default`	Valkey/Redis-ACL-Benutzername
`DB_TYPE`	Nein	`auto`	Datenbanktyp: `auto`, `valkey` oder `redis`
`STORAGE_TYPE`	Nein	`memory`	Speicher-Backend: `memory` oder `postgres`
`STORAGE_URL`	Bedingt	-	PostgreSQL-Verbindungs-URL (erforderlich, wenn `STORAGE_TYPE=postgres`)
`PORT`	Nein	`3001`	HTTP-Port der Anwendung
`NODE_ENV`	Nein	`production`	Node-Umgebung
`ANOMALY_DETECTION_ENABLED`	Nein	`true`	Anomalieerkennung aktivieren
`ANOMALY_PROMETHEUS_INTERVAL_MS`	Nein	`30000`	Prometheus-Zusammenfassungs-Intervall (ms)
`BETTERDB_LICENSE_KEY`	Nein	-	Online-Lizenzschlüssel (Pro/Enterprise), wird über das Netzwerk validiert
`BETTERDB_OFFLINE_LICENSE_FILE`	Nein	-	Pfad zu einer signierten Offline-Lizenz `.jwt` für luftdichte (air-gapped) Hosts (siehe unten)
`BETTERDB_OFFLINE_LICENSE`	Nein	-	Offline-Lizenz-Token als Inline-JWT-String
`BETTERDB_DATA_DIR`	Nein	`/app/data`	Verzeichnis für den persistenten Lizenzstatus (beschreibbares Volume einhängen)
`ENCRYPTION_KEY`	Nein	-	Schlüssel (mind. 16 Zeichen) zum Umschlag-Verschlüsseln gespeicherter Verbindungspasswörter und SSH-Tunnel-Geheimnisse im Ruhezustand. Ohne diesen werden Geheimnisse im Klartext gespeichert
`BETTERDB_SSH_KEY_DIR`	Nein	-	Verzeichnis, in dem serverseitige SSH-Private Keys liegen müssen. Aktiviert die „Server-Dateipfad“-Schlüsselquelle für SSH-Tunnel; der Schlüsselpfad einer Verbindung muss darin aufgelöst werden. Nicht gesetzt deaktiviert dateibasierte Schlüssel (inline eingefügte Schlüssel funktionieren weiterhin)
`BETTERDB_TELEMETRY`	Nein	`true`	Auf `false` setzen, um anonyme Telemetrie zu deaktivieren

Vollständige Referenz, einschließlich KI-, Webhook-Tuning und Health-Gate-Schwellenwerte: docs/configuration.md. Für OTLP-Trace-Ingest und Metrik-/Event-Export siehe docs/opentelemetry.md.

SSH-Tunnel

Verbindungen können eine Datenbank über einen SSH-Bastion-/Jump-Host erreichen, anstatt direkt zu verbinden – nützlich für Valkey/Redis in einem privaten Subnetz, ElastiCache oder MemoryDB. Aktivieren Sie Connect via SSH tunnel beim Hinzufügen einer Verbindung und geben Sie SSH-Host, Port und Benutzername an. Ein einzelner Hop wird unterstützt.

Die Authentifizierung erfolgt entweder über ein Passwort oder einen privaten Schlüssel. Private Schlüssel stammen aus einer von zwei Quellen:

Schlüssel einfügen (inline): Der PEM-Schlüsselinhalt wird mit der Verbindung übermittelt. Er wird im Ruhezustand nur dann verschlüsselt gespeichert, wenn ENCRYPTION_KEY gesetzt ist (Umschlag-Verschlüsselung); ohne diesen Schlüssel wird er im Klartext gespeichert, wie Verbindungspasswörter. Funktioniert überall, einschließlich verwalteter/Cloud-Bereitstellungen.
Server-Dateipfad: Der Schlüssel liegt bereits im Dateisystem des Monitor-Servers und wird per Pfad referenziert. Dafür muss die Umgebungsvariable BETTERDB_SSH_KEY_DIR auf das Verzeichnis gesetzt werden, das die zulässigen Schlüssel enthält, und der referenzierte Pfad muss darin aufgelöst werden, sodass die API niemals dazu gezwungen werden kann, beliebige Dateien zu lesen. Lassen Sie BETTERDB_SSH_KEY_DIR ungesetzt, um diese Option zu deaktivieren.

Optional kann der Host-Key-Fingerprint des SSH-Servers (SHA256:...) auf der Verbindung festgelegt werden; wenn gesetzt, wird der Tunnel verweigert, es sei denn, der Server präsentiert einen passenden Schlüssel, wodurch Man-in-the-Middle-Angriffe auf dem Bastion-Pfad verhindert werden. Wenn leer gelassen, wird die Serveridentität nicht verifiziert (eine Warnung wird protokolliert).

Der Tunnel leitet an die Datenbank über 127.0.0.1 weiter; wenn TLS aktiviert ist, wird das Zertifikat weiterhin gegen den tatsächlichen Datenbank-Hostnamen validiert. Setzen Sie ENCRYPTION_KEY, damit SSH-Passwörter, Schlüssel-Passphrasen und Inline-Schlüssel im Ruhezustand verschlüsselt werden.

Bekannte Einschränkung – Cluster-/Sentinel-Topologien: Nur die von Ihnen konfigurierte Verbindung wird getunnelt. Cluster- und Sentinel-Überwachung verteilt sich auf die anderen Knoten unter Verwendung der Adressen, die diese Knoten bekannt geben (CLUSTER NODES / Sentinel), und diese knotenbezogenen Verbindungen werden direkt hergestellt, nicht über den Tunnel. Wenn die anderen Knoten nur über den Bastion erreichbar sind (z. B. ElastiCache/MemoryDB in einem privaten Subnetz), sind knotenbezogene Ansichten nicht verfügbar. Verwenden Sie SSH-Tunnel für Einzelknoten-/Primärüberwachung oder platzieren Sie den Monitor dort, wo er die Cluster-Knoten direkt erreichen kann.

Lizenzierung & Air-Gapped-Unterstützung

BetterDB Monitor entsperrt Pro/Enterprise-Funktionen auf eine von zwei Arten, je nachdem, ob der Host Internetzugang hat:

Online-Lizenzschlüssel – setzen Sie BETTERDB_LICENSE_KEY. Der Monitor validiert ihn gegen betterdb.com und speichert ein lokal verifiziertes signiertes Token zwischen, sodass Ihre Stufe auch bei kurzen Ausfällen und Neustarts weiter funktioniert.
Offline-/Air-Gapped-Lizenz-Token – für Hosts ohne jeglichen Internetzugang (siehe unten).

So funktioniert Air-Gapped-Lizenzierung

Jede Berechtigung ist ein signiertes RS256-JWT. Der Monitor verifiziert es lokal gegen öffentliche Schlüssel, die im Image eingebettet sind – er muss nie einen Lizenzserver erreichen, um einem Token zu vertrauen. Ein Air-Gapped-Host kann also kostenpflichtige Stufen mit null Konnektivität ausführen:

Melden Sie sich auf einem internetverbundenen Rechner unter betterdb.com/account/licenses an und laden Sie Ihr Offline-Lizenz-Token herunter (.jwt, Pro/Enterprise). Es enthält keine Geheimnisse und kann nicht manipuliert werden – jede Änderung bricht die Signatur.
Übertragen Sie es auf den Air-Gapped-Host, wie auch immer Sie möchten (USB, Konfigurationsmanagement, ein Docker-/Kubernetes-Secret-Mount).
Geben Sie es über BETTERDB_OFFLINE_LICENSE_FILE (Pfad), BETTERDB_OFFLINE_LICENSE (Inline-String) an oder fügen Sie es in der UI unter Settings → License → „Air-gapped environment? Activate an offline license.“ ein.

Wenn ein Offline-Token konfiguriert ist und kein BETTERDB_LICENSE_KEY gesetzt ist, tätigt der Monitor null ausgehende Anfragen – Lizenzprüfungen, Telemetrie und Update-Pings sind alle deaktiviert. Er führt die gewährte Stufe aus, bis das Token abläuft (perpetuelle Lizenzen werden jährlich neu heruntergeladen), und kehrt dann zu Community zurück.```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

Verifizieren mit `GET /api/license/status` → `source: offline-token`, `mode: offline`,
`airGapped: true`.

> **Persistenz:** Ein beschreibbares Volume unter `/app/data` einhängen, damit die Offline-Lizenz und
> das Online-Ausfall-Gnaden-Token Neustarts überstehen. Der Container läuft als **UID 1001**,
> daher muss ein frisch erstelltes Volume entsprechend `chown`ed werden (siehe oben) – andernfalls
> schlägt die Persistenz mit `EACCES … license.jwt` fehl.

Für den vollständigen Ablauf, die Verifizierungs-Reihenfolge und das Schlüsselrotations-Runbook siehe
**[Offline- & Air-Gapped-Lizenzen](https://github.com/betterdb-inc/monitor/blob/master/docs/offline-licenses.md)** und die
**[Konfigurationsreferenz](https://github.com/betterdb-inc/monitor/blob/master/docs/configuration.md#license-configuration)**.

### Docker-Image-Details

- **Basis-Image**: `node:20-alpine`
- **Komprimierte Größe**: ~360MB (`latest` / `-no-ai`) / ~640MB (versioniertes Image mit den lokalen-LLM-Abhängigkeiten des experimentellen AI-Helpers)
- **Plattformen**: `linux/amd64`, `linux/arm64`
- **Enthält**: Backend-API + Frontend-Statikdateien (bereitgestellt von Fastify)
- **Ausgeschlossen**: SQLite-Unterstützung (PostgreSQL- oder Memory-Speicher verwenden)

### Container-Operationen```bash
docker logs -f betterdb-monitor        # follow logs
docker stop betterdb-monitor           # stop
docker rm betterdb-monitor             # remove

Storage-Backends

BetterDB Monitor speichert Audit-Trail-, Analyse-, Capture- und Anomaliedaten in einem von vier Backends:

Backend	Anwendungsfall	Hinweise
`memory`	Testen, ephemere Umgebungen	Standard in Docker; alle Daten gehen beim Neustart verloren
`postgres`	Produktion	`STORAGE_TYPE=postgres` + `STORAGE_URL=postgresql://user:pass@host:port/db`
`turso`	Produktion / serverloses SQLite	`STORAGE_TYPE=turso` + `STORAGE_URL=libsql://...` + `STORAGE_AUTH_TOKEN`; funktioniert in Docker
`sqlite`	Lokale Entwicklung / CLI	Natives Modul aus dem `latest`-Docker-Image entfernt; `STORAGE_SQLITE_FILEPATH` optional

Prometheus-Metriken

Metriken werden unter GET /api/prometheus/metrics im Prometheus-Textformat bereitgestellt: ACL-Audit, Client-Verbindungen, Slowlog-/Commandlog-Muster, Speicher, Durchsatz, Keyspace, Replikation, Cluster-Slot-Statistiken und Node.js-Laufzeitmetriken – alle mit dem Präfix betterdb_.```yaml scrape_configs:

job_name: 'betterdb-monitor' metrics_path: '/api/prometheus/metrics' static_configs:
- targets: ['your-monitor-host:3001']

Vollständige Metrik-Referenz: [docs/prometheus-metrics.md](https://github.com/betterdb-inc/monitor/blob/master/docs/prometheus-metrics.md) und [docs/prometheus-integration.md](https://github.com/betterdb-inc/monitor/blob/master/docs/prometheus-integration.md).

## Entwicklung

### Projektstruktur```
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

Pakete

Dieses Monorepo enthält mehrere eigenständige Pakete. Die vollständige Liste findest du unter packages/.

Paket	Sprache	Registry
`@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	Replay-Harness für das Benchmarking semantischer Caches

Tech-Stack

Backend: NestJS mit Fastify-Adapter, iovalkey für Valkey/Redis-Verbindungen, TypeScript im Strict-Modus. Port 3001.
Frontend: React + TypeScript, Vite, TailwindCSS, Recharts. Dev-Server auf Port 5173.
Monorepo: pnpm-Workspaces + Turborepo.

Lokale Einrichtung

Voraussetzungen: 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

Um stattdessen eine Verbindung zu Redis herzustellen, setzen Sie `DB_PORT=6382` in `.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

Docker-Image-Builds:```bash pnpm docker:build # local build pnpm docker:publish # multi-arch build & push (requires buildx)

### Neue Funktionen hinzufügen

1. Neue Endpunkte in `apps/api/src/` hinzufügen
2. Entsprechende API-Aufrufe in `apps/web/src/api/` hinzufügen
3. Gemeinsame Typen in `packages/shared/src/types/` hinzufügen

### Code-Stil

- TypeScript Strict Mode, explizite Rückgabetypen, kein `any`
- ESLint + Prettier konfiguriert

## Lizenz

- Inhalte unter `docs/` sind unter CC BY-SA 4.0 lizenziert.
- Inhalte unter `proprietary/` unterliegen einer kommerziellen Lizenz (siehe `proprietary/LICENSE`). Diese Funktionen sind während des Early Access kostenlos.
- Alles andere ist [MIT](https://github.com/betterdb-inc/monitor/blob/master/LICENSE).

monitor v0.41.0

Kategorien