Alerter Configuration

The pgEdge AI DBA Workbench Alerter supports configuration through YAML files and command-line flags.

Configuration Precedence

The alerter applies configuration settings in the following order; later sources override earlier ones:

1. Default values built into the application.
2. Configuration file settings (YAML format).
3. Command-line flag overrides.

Configuration File

The alerter searches for its configuration file in the following locations:

• /etc/pgedge/ai-dba-alerter.yaml (system-wide).
• <binary-directory>/ai-dba-alerter.yaml (alongside the executable).

You can specify a custom path using the -config flag.

A complete example configuration file is available at ai-dba-alerter.yaml in the project repository.

Command-Line Flags

The alerter accepts the following command-line flags:

In the following example, the alerter starts with debug logging and a custom configuration file:

./ai-dba-alerter -debug \
    -config /etc/ai-workbench/alerter.yaml

In the following example, the alerter connects to a specific database without a configuration file:

./ai-dba-alerter \
    -db-host db.example.com \
    -db-name ai_workbench \
    -db-user alerter \
    -db-password secret

Configuration File Reference

The configuration file uses YAML format. The following sections describe all available options.

Datastore Connection (datastore)

The datastore section configures the connection to the AI DBA Workbench PostgreSQL datastore.

The sslmode option accepts the following values:

• disable disables SSL encryption.
• allow attempts non-SSL first and falls back to SSL.
• prefer attempts SSL first and falls back to non-SSL.
• require requires SSL without certificate verification.
• verify-ca requires SSL and verifies the server certificate.
• verify-full requires SSL and verifies the certificate and hostname.

In the following example, the datastore section configures a secure connection with certificate verification:

datastore:
  host: db.example.com
  database: ai_workbench
  username: ai_workbench
  password_file: /etc/ai-workbench/password.txt
  port: 5432
  sslmode: verify-full
  sslcert: /etc/ai-workbench/client-cert.pem
  sslkey: /etc/ai-workbench/client-key.pem
  sslrootcert: /etc/ai-workbench/ca-cert.pem

Connection Pool (pool)

The pool section configures the database connection pool.

Threshold Evaluation (threshold)

The threshold section configures threshold-based alert evaluation.

Anomaly Detection (anomaly)

The anomaly section configures the tiered anomaly detection system.

Tier 1: Statistical Analysis

The anomaly.tier1 section configures z-score-based statistical detection.

Tier 2: Embedding Similarity

The anomaly.tier2 section configures pgvector-based similarity search for pattern matching.

Tier 3: LLM Classification

The anomaly.tier3 section configures LLM-based classification for complex anomalies.

Baseline Calculation (baselines)

The baselines section configures baseline metric calculation for anomaly detection.

Correlation (correlation)

The correlation section configures alert correlation across metrics.

LLM Providers (llm)

The llm section configures LLM providers for tier 3 anomaly detection and embedding generation.

Ollama Configuration

The llm.ollama section configures the local Ollama provider.

OpenAI Configuration

The llm.openai section configures the OpenAI provider.

The openai provider works with any server that implements the OpenAI-compatible API. Set base_url to point at a local inference server. The API key is optional when using a custom base URL.

The following local inference servers are compatible:

• Docker Model Runner uses http://localhost:12434/engines/llama.cpp/v1 as the default endpoint.
• llama.cpp uses http://localhost:8080/v1 as the default endpoint.
• LM Studio uses http://localhost:1234/v1 as the default endpoint.
• EXO uses http://localhost:52415/v1 as the default endpoint.

In the following example, the llm.openai section configures a local llama.cpp server:

llm:
  reasoning_provider: openai
  openai:
    base_url: http://localhost:8080/v1
    reasoning_model: my-local-model

Anthropic Configuration

The llm.anthropic section configures the Anthropic provider.

Gemini Configuration

The llm.gemini section configures the Google Gemini provider.

Voyage Configuration

The llm.voyage section configures the Voyage provider for embeddings.

Notifications (notifications)

The notifications section configures the notification delivery system for sending alerts through external channels.

The secret_file option specifies a file containing the same plain text secret used by the server component. The alerter uses this secret to decrypt notification channel credentials that the server encrypted. The alerter and the server must reference the same secret file.

In the following example, the notifications section enables delivery with custom retry settings:

notifications:
  enabled: true
  secret_file: /etc/ai-workbench/ai-dba-server.secret
  process_interval_seconds: 30
  max_retry_attempts: 5
  retry_backoff_minutes: [5, 15, 30]
  http_timeout_seconds: 60

API Key Management

Store API keys for LLM providers in files with restricted permissions. The alerter reads API keys from the paths specified in the api_key_file options.

In the following example, the commands create an API key file with secure permissions:

echo "sk-your-api-key-here" \
    > /etc/ai-workbench/openai-api-key.txt
chmod 600 /etc/ai-workbench/openai-api-key.txt

The corresponding configuration references the key file:

llm:
  embedding_provider: openai
  reasoning_provider: openai
  openai:
    api_key_file: /etc/ai-workbench/openai-api-key.txt
    embedding_model: text-embedding-3-small
    reasoning_model: gpt-4o

Signal Handling

The alerter responds to Unix signals for operational control:

• SIGINT and SIGTERM trigger a graceful shutdown.
• SIGHUP reloads the configuration file without restarting the process.

In the following example, the kill command reloads the configuration:

kill -HUP $(pidof ai-dba-alerter)