Files
serverAppConfigs/shared/prometheus/prometheus.yml
T
Frank af05c890fd observability: LLM alerting rules, evaluated but not yet delivered
The scraped metrics have no rules over them, so every graph was read after the
fact by a human. This adds shared/prometheus/rules/llm-fleet.yml, loaded via
rule_files and installed by the same copier that ships prometheus.yml (a rule
file nothing loads evaluates nothing, and Prometheus reports no error for it):

  LlmKvPoolSaturated      kv pool > 90% for 10m — the 122,636-token wall
  LlmRequestsQueueing     waiting > 0 for 10m — MAXSEQS=4 reached
  LlmPrefixCacheCollapse  reuse < 20% for 15m with traffic — the thrash signature
  LlmEndpointDown         scrape target down 2m — both replicas gone
  LlmLatencyHigh          p95 end-to-end > 60s for 10m — what an operator feels
  job:llm_prefix_cache_reuse:rate5m — recording rule shared by the alert and the
                          dashboard, so the two cannot drift

Every threshold is tied to something measured on this fleet, not to a guess,
and the file says plainly at the top that **nothing is notified**: there is no
Alertmanager here, so a firing alert reaches Prometheus' /alerts page, the
ALERTS metric and the dashboard panel added alongside it — and nowhere else.
Choosing how Frank actually gets paged is his call, not a missing config line.

Seam covers the silent failure mode: rules exist, the config references the
directory, the deployer installs it, and the dashboard graphs ALERTS.
2026-09-16 06:45:03 -07:00

85 lines
2.7 KiB
YAML

# Prometheus configuration for the homelab.
# Deployed to /opt/prometheus/config/prometheus.yml on Dankclaw.
global:
scrape_interval: 15s
scrape_timeout: 10s
evaluation_interval: 15s
# Alerting and recording rules for the LLM fleet. They evaluate and expose state
# through /alerts, the ALERTS metric and the Grafana dashboard; nothing is
# notified, because this stack has no Alertmanager (see the rules file header).
rule_files:
- /etc/prometheus/rules/*.yml
scrape_configs:
# Prometheus itself
- job_name: "prometheus"
static_configs:
- targets: ["localhost:9090"]
# Host metrics — both hosts
- job_name: "node-dankclaw"
static_configs:
- targets: ["192.168.0.143:9100"]
- job_name: "node-dankserver"
static_configs:
- targets: ["192.168.0.235:9100"]
# Gitea metrics (quadlet on an isolated network; use the published LAN port)
- job_name: "gitea"
static_configs:
- targets: ["192.168.0.143:3000"]
metrics_path: "/metrics"
# Grafana metrics
- job_name: "grafana"
static_configs:
- targets: ["grafana:3000"]
metrics_path: "/metrics"
# Loki metrics
- job_name: "loki"
static_configs:
- targets: ["loki:3100"]
metrics_path: "/metrics"
# ComfyUI (no native /metrics; probe the UI)
- job_name: "comfyui"
metrics_path: "/"
static_configs:
- targets: ["comfyui:8188"]
# Blackbox-style probes for service up/down (published LAN ports;
# gitea and comfyui are covered by their own jobs above)
- job_name: "services"
metrics_path: "/"
static_configs:
- targets:
- "192.168.0.143:8081" # SearXNG (via the Gluetun tunnel)
- "192.168.0.143:3005" # OpenWebUI
# LLM fleet. Scraped on the LAN addresses, not the guarded vhosts: these are
# machine clients and Prometheus cannot solve an Anubis challenge.
# frank-medium is vLLM, and its series are the ones that explain behaviour
# under load — vllm:kv_cache_usage_perc (how full the per-card pool is),
# vllm:num_requests_waiting (queue depth), the request-latency histograms,
# and the prefix-cache pair vllm:prefix_cache_hits_total over
# vllm:prefix_cache_queries_total (their rates give the hit rate, which says
# whether pinned conversations are actually being reused).
# frank-large is llama.cpp and exposes throughput counters under llamacpp:.
- job_name: "frank-medium"
metrics_path: "/metrics"
static_configs:
- targets: ["192.168.0.235:7770"]
labels:
service: frank-medium
- job_name: "frank-large"
metrics_path: "/metrics"
static_configs:
- targets: ["192.168.0.143:7770"]
labels:
service: frank-large