What’s emitted
The metrics server on
FP_METRICS_PORT (default 9145) is not access-logged
on purpose — Prometheus scrapes every ~15s would otherwise dominate the
log stream.
A Caddy access log line looks like:
Cache-Status response header tells you whether Souin served from
cache (hit) or fell through to PHP (miss).
Recommended: Vector DaemonSet
Vector is a vendor-neutral agent maintained by Datadog. A single DaemonSet ships to Loki, Datadog, both, or any other supported sink. This is the recommended path because it keeps the FrankenPress chart free of backend-specific glue.1
Install the Vector Helm chart in DaemonSet mode
2
Provide a `vector.yaml` config
The example below tails container logs cluster-wide, parses Caddy’s JSON
access log, and ships to both Loki and Datadog. Drop whichever sink
you don’t want.
vector-values.yaml
3
Verify in your backend
Generate traffic against the site, then check Loki Explore (filter
{source="caddy_access"}) or Datadog Logs (source:caddy_access).
You should see one entry per request with status, duration, uri,
and resp_headers fields.Alternative: Grafana Alloy / Promtail (Loki only)
If you’re a Loki-only shop and already run Grafana Alloy (or its predecessor Promtail), no FrankenPress-specific config is needed. The defaultdiscovery.kubernetes + loki.source.kubernetes pipeline tails all pod
logs in the cluster. Filter by namespace or by the
app.kubernetes.io/name=site label in your Alloy config to scope to
FrankenPress sites.
Alternative: Datadog Agent (autodiscovery)
If you run the Datadog Agent DaemonSet with log autodiscovery, set pod annotations on the FrankenPress release:site segment of the annotation key is the container name in the
deployment template (it’s not configurable). The Datadog Agent will
auto-tag each line with source:caddy and service:site so its
default Caddy log pipeline applies.
What’s not shipped
- Subchart logs. The chart’s bundled
mariadb,redis, andminiosubcharts each write their own logs to their own pod stdout. A cluster-side shipper picks those up automatically — they’re not FrankenPress’s concern. Production deploys typically disable the subcharts and use external services (RDS, DragonflyDB Operator, AWS S3) whose logs live wherever that operator/service writes them. - wp-cron Job logs. The
wpCronCronJob writes to its own pod stdout; a DaemonSet-mode shipper captures those lines too. - Prometheus scrape access logs. Suppressed on purpose (see above).
If you want them, add a
logblock inside the:{$FP_METRICS_PORT}server in a forkedCaddyfile— but you almost certainly don’t.