Aufbau einer Überwachungslösung für Vektordatenbanken mit Prometheus und Grafana

VectorAI DB stellt eine native /metrics Endpunkt im Prometheus-/OpenMetrics-Format auf Port 6573. In diesem Tutorial wird dieser Endpunkt in einen Docker-Compose-Stack mit Prometheus und Grafana eingebunden, ein „ dashboard “ mit vier Panels erstellt, das Sie direkt importieren können, und acht Alarmregeln aus der Überwachungsdokumentation von VectorAI DB konfiguriert. Bevor Sie mit der Einrichtung beginnen, erfahren Sie hier, was diese Metriken tatsächlich erfassen.

Was misst die Vector-Datenbanküberwachung?

Die Überwachung der Vector-Datenbank bedeutet, wichtige Signale im Auge zu behalten, um sicherzustellen, dass Ihre Datenbank wie erwartet funktioniert. Zu diesen Signalen gehören die Latenz der „ abfragen “, die Speicherauslastung, die Auslastung der „ CPU “, der Zustand der Indizes und die Qualität der Abrufe. Jedes dieser Signale entspricht einer bestimmten Metrik auf Ihrer VectorAI-DB-Instanz.

Die Abfragelatenz ist die Zeit, die Ihre Suche nach den k-nächsten Nachbarn benötigt, um Ergebnisse zu liefern. Da die Vektorsuche auf Ähnlichkeit statt auf exakten Übereinstimmungen basiert, ist dies der erste Wert, auf den Ihr „ SLA “ achtet. VectorAI DB erfasst diesen Wert über actian_vectorai_rest_responses_duration_seconds (S. 95/S. 99 pro Endpunkt). Bei Speicherengpässen oder während einer Index-Neuerstellung kann die Latenz deutlich über den normalen Basiswert hinaus ansteigen, manchmal von etwa 20 ms auf 500 ms.

Das actian_vectorai_memory_resident_bytes Diese Kennzahl gibt an, wie viel RAM Ihre Vektorindizes beanspruchen. Eine weitere wichtige Kennzahl ist actian_vectorai_process_major_page_faults_total. Ein stetiger Anstieg deutet hier auf eine hohe Speicherauslastung hin und kann darauf hindeuten, dass das Betriebssystem Seiten aus dem festplattengestützten Speicher abruft, was in der Regel zu einer Verlängerung der Latenz bei „ abfragen “ führt.

actian_vectorai_process_threads gibt bei Ähnlichkeitsberechnungen die Thread-Anzahl an. Eine steigende Thread-Anzahl unter Last spiegelt die Prozessorauslastung wider, und in Kombination mit den Metriken zur Systemauslastung ( CPU ) aus dem Prometheus-Node-Exporter erhalten Sie so ein umfassendes Bild.

Mit „Index Health“ erhalten Sie einen „ Erkenntnis “ in die Vorgänge im Hintergrund. Der actian_vectorai_collection_running_optimizations und actian_vectorai_rebuild_running Die Kennzahlen zeigen an, wann Neuaufbauten stattfinden. actian_vectorai_rebuild_failed_total erfasst alle Fehler und actian_vectorai_rebuild_duration_seconds zeigt, wie lange der Neuaufbau dauert.

VectorAI DB stellt den Recall – also den Prozentsatz der tatsächlich zurückgegebenen nächsten Nachbarn – nicht als Echtzeit-Kennzahl zur Verfügung. Überprüfen Sie diesen Wert offline anhand eines beschrifteten Testdatensatzes und verwenden Sie stattdessen die Latenz und die Fehlerquote.

Was Sie entwickeln werden

Um VectorAI DB in die Produktion zu überführen, muss man in der Lage sein, zu zeigen, wie sich das System unter Last verhält, wie man einen beeinträchtigten Zustand erkennt und wie man vor einem Vorfall benachrichtigt wird. Die Überwachung ist besonders wichtig für RAG-Workloads (Retrieval-Augmented Generation), die große Sprachmodelle nutzen, da Latenzspitzen oder Indexfehler die Qualität der KI-Antworten beeinträchtigen können. Die richtige Überwachungskonfiguration informiert Sie darüber, wann die Latenz zunimmt, wann sich Speicherbelastung aufbaut und wann Index-Neuerstellungen fehlschlagen – noch bevor dies bei den Nutzern spürbar wird.

VectorAI DB bietet eine /metrics Endpunkt auf Port 6573 im Prometheus-/OpenMetrics-Format, sodass Sie keine zusätzlichen Exporter oder Agenten für die Anwendung benötigen metrics. Der optionale Prometheus-Node-Exporter erfasst die „ CPU “ und den Speicher auf Host-Ebene, falls Sie systemweite Einblicke benötigen, die über die von VectorAI DB direkt bereitgestellten Informationen hinausgehen.

In diesem Tutorial verbinden Sie diesen Endpunkt mit einem Docker-Compose-Stack, der aus VectorAI DB, Prometheus und Grafana besteht. Sie erstellen ein vierfeldiges Dashboard unter dashboard , das Sie sofort importieren können, und richten acht Alarmregeln ein, basierend auf der Überwachungsdokumentation von VectorAI DB.

Am Ende verfügen Sie über einen „ dashboard “ und konfigurierte Benachrichtigungsregeln, die auf Ihrer eigenen Instanz ausgeführt werden.

Was der Metrics-Endpunkt über die Leistung von Vektordatenbanken aussagt

VectorAI DB stellt seine Kennzahlen unter folgender Adresse bereit: GET /metrics über den REST-API-Port (Standard: 6573) im Prometheus-/OpenMetrics-Format. Dieser Endpunkt verfügt über keine Authentifizierung. Wenn Sie ihn daher in einem öffentlichen Netzwerk verfügbar machen, sollten Sie ihn mit einer Firewall oder einem Reverse-Proxy sowie Zugriffskontrollen schützen.

Alle Kennzahlen beginnen mit dem actian_vectorai_ Präfix. In der folgenden Tabelle sind die wichtigsten Kennzahlen in sechs Kategorien aufgeführt, wobei jeweils ihr Typ sowie die Aussagekraft hinsichtlich des Systemzustands und der Ressourcennutzung angegeben sind.

Den Stack einrichten

Voraussetzungen

Bevor Sie beginnen, installieren Sie bitte Folgendes:

• • Docker und Docker Compose
  • Python .10 oder höher
  • VectorAI DB (Registrieren Sie sich für die Community-Edition)
  • actian-vectorai-client Python SDK: pip install actian-vectorai-client

Stellen Sie sicher, dass Ihr Computer über mindestens 8 GB RAM (empfohlen werden 16 GB) und 10 GB Festplattenspeicher verfügt.

Wenn Sie Windows verwenden, führen Sie alle Befehle in WSL2 aus. Um WSL2 einzurichten, führen Sie folgenden Befehl aus: wsl --install in PowerShell, dann nutzen Sie für dieses Tutorial das Ubuntu-Terminal.

Projektstruktur

Erstellen Sie ein Projektverzeichnis und eine Ordnerstruktur:

mkdir -p vectorai-observability/{prometheus,grafana,scripts}
cd vectorai-observability

touch docker-compose.yml prometheus/prometheus.yml prometheus/alert_rules.yml scripts/load_test.py

Ihr Projektverzeichnis sollte wie folgt aussehen:

vectorai-observability/

├── docker-compose.yml

├── prometheus/

│   ├── prometheus.yml

│   └── alert_rules.yml

├── grafana/

└── scripts/

    └── load_test.py

Ihr „ Beobachtbarkeit “-Stack wird als drei Docker-Compose-Dienste ausgeführt: VectorAI DB (REST/Metriken auf Port 6573, gRPC auf Port 6574 und die lokale Benutzeroberfläche auf Port 6575), Prometheus (Port 9090) und Grafana (Port 3000).

services:
  vectorai:
    image: actian/vectorai:latest
    platform: linux/amd64
    container_name: vectorai
    ports:
      - "6573:6573"
      - "6574:6574"
      - "6575:6575"
    volumes:
      - ./local_data:/var/lib/actian-vectorai
    environment:
      - ACTIAN_VECTORAI_ACCEPT_EULA=YES
    restart: unless-stopped

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus/alert_rules.yml:/etc/prometheus/alert_rules.yml
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
    restart: unless-stopped
    depends_on:
      - vectorai

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    restart: unless-stopped
    depends_on:
      - prometheus

volumes:
  grafana_data:

Füge dies hinzu zu prometheus/prometheus.yml. Bei Docker-Compose-Bereitstellungen ermittelt Prometheus VectorAI DB anhand des Dienstnamens. Wenn Sie VectorAI DB als eigenständigen Container außerhalb des Compose-Netzwerks ausführen, verwenden Sie host.docker.internal:6573 stattdessen als Scrape-Ziel:

global:
  scrape_interval: 15s

rule_files:
  - "alert_rules.yml"

scrape_configs:
  - job_name: "vectorai"
    scrape_interval: 15s
    static_configs:
      - targets: ["vectorai:6573"]

docker compose up -d

Weiter zu localhost:9090/targets. Die vectorai Der Auftrag sollte angezeigt werden 1/1 UP mit einer Scrape-Dauer von unter 20 ms. Wenn es anzeigt, DOWN, überprüfen Sie, ob Port 6573 offen ist und keine Firewall die Verbindung blockiert.

Weiter zu localhost:3000 und melden Sie sich mit Ihren Administrator-Zugangsdaten an. Gehen Sie anschließend zu „Verbindungen“, wählen Sie „Datenquellen“ aus, klicken Sie auf „Neue Datenquelle hinzufügen“, wählen Sie „Prometheus“ aus und geben Sie als URL Folgendes ein: http://prometheus:9090, legen Sie diese als Standard fest und speichern Sie die Einstellung.

Die Vektordatenbank erstellen Dashboard

Das „ dashboard “ erfasst vier wichtige Kennzahlen: Anfragerate, p95-Latenz, Fehlerquote und Speicherauslastung. Anhand dieser Kennzahlen können Sie die Indizierungs- und Suchleistung optimieren. Fügen Sie die folgenden PromQL-Abfragen in die Datei „grafana/dashboard.json“ ein, während Sie die einzelnen Panels in Grafana erstellen.

Abbildung 1: Anzahl der REST-Anfragen nach Endpunkt

Dieses Diagramm zeigt den Durchsatz von „ abfragen “ pro Endpunkt im Zeitverlauf. Erstellen Sie ein Zeitreihendiagramm mit diesem PromQL- abfragen:

sum by (endpoint) (rate(actian_vectorai_rest_responses_total[5m]))

Stellen Sie das Format der Legende auf {{endpoint}}. Es zeigt den Durchsatz für jeden Endpunkt an, sodass Sie erkennen können, welche Routen die Auslastung beeinflussen, und Muster bei der „ abfragen “ erkennen können, bevor sie sich auf die Leistung auswirken.

Abbildung 2: REST-Latenz (S. 95) pro Endpunkt

Dies ist das primäre Latenzsignal für die Überwachung von „ SLA “. Prometheus-Histogramm-Metriken actian_vectorai_rest_responses_duration_seconds automatisch offenlegen _bucket Serie, und genau das ist histogram_quantile für Abfragen. Erstellen Sie ein Zeitreihen-Panel:

histogram_quantile(0.95, sum by (le, endpoint) (rate(actian_vectorai_rest_responses_duration_seconds_bucket[5m])))

Stellen Sie das Format der Legende auf {{endpoint}}. Wenn die Latenz zunimmt, während die Anfragerate konstant bleibt, könnte dies auf Speicherengpässe oder eine Indexneuerstellung hindeuten, die die Suchleistung beeinträchtigt.

Abbildung 3: gRPC-Fehlerquote

Das „ Python “-SDK kommuniziert über gRPC, sodass die Fehlerüberwachung auf der gRPC-Ebene erfolgt. Erstellen Sie ein Statistik-Dashboard mit folgendem Code:

sum(rate(actian_vectorai_grpc_responses_fail_total[5m]))
/
(sum(rate(actian_vectorai_grpc_responses_total[5m])) > 0 or vector(1))

Die Funktion „ abfragen “ gibt einen Bruch zwischen 0 und 1 zurück. Legen Sie die Schwellenwerte auf 0,01 für Grün, 0,05 für Gelb und alle Werte über 0,05 für Rot fest, oder stellen Sie die Grafana-Einheit auf percent (0-1) um die Werte automatisch als Prozentsätze anzuzeigen. Die Anzeige wechselt von Grün zu Gelb, sobald sich die Fehlerquote der 5-Prozent-Marke nähert, und zu Rot, sobald diese überschritten wird. So lassen sich fehlerhafte Erfassungs abfragen en oder Verbindungsausfälle erkennen, bevor sie sich verschlimmern.

Panel 4: Speicherbelastung

Dieses Panel verfolgt zwei Signale, die zusammen anzeigen, ob der Motor innerhalb sicherer Grenzen der Speicherauslastung arbeitet. Erstellen Sie ein Zeitreihen-Panel mit zwei Abfragen:

# RSS: RAM consumed by vector indexes
actian_vectorai_memory_resident_bytes

# Early warning signal for disk paging
rate(actian_vectorai_process_major_page_faults_total[5m])

Stellen Sie die Beschriftungen der Legende auf RSS und Major Page Faults/s. Wenn die Fehlerrate steigt, während der RSS-Wert nahe an seiner Obergrenze liegt, greift der Motor auf die Festplatte zurück, wodurch die Latenzzeit bald zunimmt.

Nachdem Sie alle vier Felder eingerichtet haben, öffnen Sie die Einstellungen unter „ Dashboard “, wechseln Sie zu „JSON-Modell“ und kopieren Sie den Inhalt. Speichern Sie diesen unter grafana/dashboard.json. Diese Datei befindet sich ebenfalls in der GitHub-Repo, sodass Sie das Repo klonen und sofort in Grafana importieren können.

Warnregeln konfigurieren

Fügen Sie die folgenden Warnregeln hinzu zu prometheus/alert_rules.yml. Prometheus lädt sie beim Start automatisch über die rule_files Richtlinie in prometheus.yml.

groups:
  - name: vectorai
    rules:
      - alert: VectorAIHighRESTErrorRate
        expr: >
          sum(rate(actian_vectorai_rest_responses_fail_total[5m]))
          /
          sum(rate(actian_vectorai_rest_responses_total[5m]))
          > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB REST error rate above 5%"
          description: "{{ $value | humanizePercentage }} of REST requests are returning errors."

      - alert: VectorAIHighRESTLatency
        expr: >
          histogram_quantile(0.95, sum by (le) (rate(actian_vectorai_rest_responses_duration_seconds_bucket[5m])))
          > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB REST p95 latency above 2s"
          description: "REST p95 latency is {{ $value }}s."

      - alert: VectorAIHighGRPCErrorRate
        expr: >
          sum(rate(actian_vectorai_grpc_responses_fail_total[5m]))
          /
          sum(rate(actian_vectorai_grpc_responses_total[5m]))
          > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB gRPC error rate above 5%"
          description: "{{ $value | humanizePercentage }} of gRPC calls are failing."

      - alert: VectorAIRecoveryModeActive
        expr: actian_vectorai_app_status_recovery_mode == 1
        for: 0m
        labels:
          severity: critical
        annotations:
          summary: "VectorAI DB is in recovery mode"
          description: "The engine has entered recovery mode and requires immediate attention."

      - alert: VectorAIHighMemoryUsage
        expr: actian_vectorai_memory_resident_bytes > 0.8 * 8589934592  # Replace with your memory limit in bytes
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB memory usage above 80%"
          description: "RSS is {{ $value | humanize }}B, exceeding 80% of available memory."

      - alert: VectorAIMajorPageFaultsRising
        expr: rate(actian_vectorai_process_major_page_faults_total[5m]) > 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB major page faults rising"
          description: "Sustained major page faults indicate memory pressure and potential disk paging."

      - alert: VectorAIFileDescriptorExhaustion
        expr: actian_vectorai_process_open_fds > 0.8 * 65536  # Replace with your system fd limit
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB file descriptors approaching limit"
          description: "Open file descriptors at {{ $value }}, approaching 80% of system limit."

      - alert: VectorAIRebuildFailures
        expr: rate(actian_vectorai_rebuild_failed_total[1h]) > 0
        for: 0m
        labels:
          severity: warning
        annotations:
          summary: "VectorAI DB index rebuild failure detected"
          description: "One or more index rebuilds have failed in the last hour."

Zwei Regeln verwenden umgebungsspezifische Werte, die Sie vor der Bereitstellung festlegen müssen. VectorAIHighMemoryUsage wird ausgelöst, wenn RSS 80 % des verfügbaren Speichers überschreitet; ersetzen Sie daher 8589934592 mit Ihrer tatsächlichen Speichergrenze in Byte. VectorAIFileDescriptorExhaustion wird ausgelöst, wenn offene Dateideskriptoren 80 % des Systemlimits erreichen; ersetzen Sie daher 65536 mit der Ausgabe von ulimit -n auf Ihrem Host.

VectorAIRecoveryModeActive und VectorAIRebuildFailures Verwendung for: 0m, was bedeutet, dass sie sofort ausgelöst werden, anstatt auf das Andauern eines Zustands zu warten. Fehler im Wiederherstellungsmodus und beim Neuaufbau müssen sofort nach ihrem Auftreten behoben werden, nicht erst nach Ablauf eines Zeitfensters von fünf Minuten.

Überprüfen Sie, ob alle acht Regeln fehlerfrei geladen wurden, indem Sie zu folgender Seite navigieren: localhost:9090/alerts.

Unter Last validieren

Führen Sie das Lasttest-Skript aus, um realen abfragen -Datenverkehr für Ihre VectorAI-DB-Instanz zu erzeugen. Fügen Sie Folgendes zu scripts/load_test.py:

import random
import time
from concurrent.futures import ThreadPoolExecutor
from actian_vectorai import VectorAIClient, VectorParams, Distance

COLLECTION = "load_test"
DIMENSION = 128
TOTAL_QUERIES = 1000
RPS = 50
DURATION = 60

def random_vector(dim):
    return [random.uniform(-1, 1) for _ in range(dim)]

def run_query(client):
    try:
        client.points.search(
            collection_name=COLLECTION,
            vector=random_vector(DIMENSION),
            limit=10
        )
    except Exception as e:
        print(f"Query error: {e}")

def main():
    with VectorAIClient("localhost:6574") as client:
        try:
            client.collections.create(
                name=COLLECTION,
                vectors_config=VectorParams(size=DIMENSION, distance=Distance.Cosine)
            )
            print(f"Created collection: {COLLECTION}")
        except Exception as e:
            print(f"Collection {COLLECTION} already exists, continuing... ({e})")

        print(f"Running {TOTAL_QUERIES} queries at {RPS} req/s for {DURATION}s...")
        interval = 1.0 / RPS
        start = time.time()
        count = 0

        with ThreadPoolExecutor(max_workers=10) as executor:
            while count < TOTAL_QUERIES and (time.time() - start) < DURATION:
                executor.submit(run_query, client)
                count += 1
                time.sleep(interval)

        elapsed = time.time() - start
        print(f"Done. {count} queries in {elapsed:.1f}s ({count/elapsed:.1f} req/s)")

if __name__ == "__main__":
    main()

Führen Sie es dann aus:

python scripts/load_test.py

Das Skript stellt über gRPC auf Port 6574 eine Verbindung zur VectorAI-Datenbank her, erstellt eine 128-dimensionale Sammlung und sendet 60 Sekunden lang 1.000 zufällige Vektorabfragen mit einer Rate von 50 Anfragen pro Sekunde. Während der Ausführung des Skripts steigt der Datenverkehr im Anforderungsraten-Panel an, die p95-Latenz stabilisiert sich und die gRPC-Fehlerquote bleibt bei null.

Um das Fenster „Fehlerquote“ anzuzeigen, rufen Sie unter abfragen eine Sammlung auf, die nicht existiert:

from actian_vectorai import VectorAIClient

with VectorAIClient("localhost:6574") as client:
    try:
        client.points.search(
            collection_name="nonexistent_collection",
            vector=[0.1]*128,
            limit=5
        )
    except Exception as e:
        print(f"Error: {e}")

Das Dashboard zur gRPC-Fehlerquote zeigt sofort einen sprunghaften Anstieg an. Diese Sequenz veranschaulicht Ihrem Team, wie das System aussieht, wenn es einwandfrei funktioniert und wenn ein Fehler auftritt.

Drei Überwachungsszenarien

Der Anstieg der Anfragerate, den Sie während des Lasttests beobachtet haben, entspricht dem Spitzenaufkommen bei einer Produktempfehlungs-Engine. Wenn dieser Anstieg mit einer steigenden p95-Latenz einhergeht, steht der Vektorindex unter Speicherbelastung. Das Speicherbelastungs-Dashboard erkennt dies, bevor es zu einem „ Nutzer “ kommt.

Fehler beim Neuaufbau des Indexes in einem Abrufsystem für medizinische Bilddaten verschlechtern die Abrufgenauigkeit unbemerkt, ohne dass eine Fehlermeldung ausgegeben wird. Das gRPC-Fehlerquoten-Dashboard erfasst diese Fehler zwar nicht, aber actian_vectorai_rebuild_failed_total und die VectorAIRebuildFailures Alarm wird ausgelöst. Der Alarm wird innerhalb einer Stunde nach Auftreten eines Fehlers ausgelöst, und die Überwachung actian_vectorai_rebuild_duration_seconds informiert Sie, wenn Index-Neuindizierungen, die durch neue „ Dateneingang “ oder Modellaktualisierungen ausgelöst werden, länger dauern als erwartet.

Das Diagramm zur gRPC-Fehlerquote stieg sprunghaft auf 0.952 In unserem Test führte eine Serie von 20 aufeinanderfolgenden fehlgeschlagenen Anfragen bei einer niedrigen Basisrate erfolgreicher Anfragen dazu, dass das Verhältnis nahe an 1 heranrückte. Genau dieses Signal erkennt eine Pipeline zur Betrugserkennung, wenn Authentifizierungsfehler Echtzeit-Transaktionsabfragen verhindern. Der Abgleich von Transaktionsvektoren mit bekannten Betrugssignaturen erfordert eine Latenz von unter 100 ms abfragen . Wenn diese Anzeige rot wird, ist die Pipeline bereits gefährdet.

Strukturierte Protokollierung konfigurieren

Fügen Sie Ihrer VectorAI-DB-Konfiguration Folgendes hinzu, um JSON-formatierte Protokolle zu aktivieren, die mit Elasticsearch, Loki oder Datadog kompatibel sind.

Protokollierung:
  Format: json
  Stufe: info

Passen Sie die Protokollierungsstufe an Ihre Umgebung an:

Das Ausführen auf den Stufen „Debug“ oder „Trace“ in der Produktionsumgebung erzeugt eine große Menge an Protokolldaten und kann die Datenbankleistung beeinträchtigen. Verwenden Sie diese Stufen nur für die kurzfristige Fehlerbehebung und wechseln Sie anschließend wieder zur Stufe „Info“ zurück.

Zum Abschluss

Sie verfügen nun über eine Überwachungslösung, die anzeigt, wann sich die Latenz bei der Vektorsuche, die Speicherauslastung oder gRPC-Fehler verändern, noch bevor die Nutzer dies bemerken. Prometheus erfasst Live-Metriken über Port 6573; Ihr vierteiliges Grafana- dashboard , deckt die relevanten Signale ab; und acht Alarmregeln werden ausgelöst, sobald eines dieser Signale einen von Ihrem Team festgelegten Schwellenwert überschreitet.

Den GitHub-Repo So erhalten Sie den vollständigen Stack: docker-compose.yml, prometheus/prometheus.yml, prometheus/alert_rules.yml, grafana/dashboard.json, und scripts/load_test.py. Importieren Sie die JSON-Datei „ dashboard “ in Grafana, und schon ist der Stack einsatzbereit.

Weitere Informationen zum Metrik-Endpunkt und zur Überwachungskonfiguration finden Sie in der Dokumentation zur VectorAI-DB-Überwachung.

Über den Autor

Über Tahiya Chowdhury

Tahiya Chowdhury ist Produktmanagerin für Actian Zen und VectorAI DB und leitet dort die Strategie für die branchenweit leistungsstärkste Edge-Datenplattform. Auf der Grundlage ihrer Erfahrungen bei MongoDB und Goldman Sachs hat sich Tahiya auf die Entwicklung von Produkten spezialisiert, die die Schnittstelle zwischen den Anforderungen großer Unternehmen und der Arbeitsgeschwindigkeit moderner Entwickler bilden. Ihr großes Anliegen ist es, die Komplexität der Dateninfrastruktur zu reduzieren und Entwicklungsteams dabei zu unterstützen, schneller vom Prototyp zur Produktion zu gelangen.