Add Prometheus, cAdvisor, and node-exporter to monitoring stack#39
Conversation
Wires Prometheus into docker-compose.yml with cAdvisor (container metrics) and node-exporter (host metrics) as active scrape jobs. The old docs/prometheus.example.yml moves to prometheus/prometheus.yml so it can be bind-mounted into the container. Telegraf and Tautulli jobs are kept as commented placeholders since neither exposes /metrics by default. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds a Prometheus-based monitoring stack to the Compose environment: new services for Prometheus, cAdvisor, and node-exporter (with persistent Prometheus storage), an in-repo Prometheus config enabling cAdvisor/node-exporter scrapes (other jobs commented), removal of the old example config, and documentation updates reflecting the wiring and cAdvisor security notes. ChangesPrometheus Monitoring Stack
Sequence DiagramsequenceDiagram
participant Containers as Application Containers
participant cAdvisor as cAdvisor (8080)
participant NodeExp as node-exporter (9100)
participant Prometheus as Prometheus (9090)
participant Grafana as Grafana
Containers->>cAdvisor: expose container metrics (host mounts, privileged)
Containers->>NodeExp: host metrics available (proc/sys/rootfs)
Prometheus->>cAdvisor: scrape cadvisor:8080
Prometheus->>NodeExp: scrape node-exporter:9100
Prometheus->>Prometheus: local config/evaluation
Grafana->>Prometheus: query metrics for dashboards
Grafana->>Grafana: render visualizations
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
docker-compose.yml (1)
91-92: ⚡ Quick winConsider binding monitoring ports to loopback by default.
9090,8080, and9100are exposed on all interfaces; binding to127.0.0.1reduces accidental external exposure if host firewalling is loose.Suggested diff
- - "9090:9090" + - "127.0.0.1:9090:9090" ... - - "8080:8080" + - "127.0.0.1:8080:8080" ... - - "9100:9100" + - "127.0.0.1:9100:9100"Also applies to: 110-111, 129-130
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose.yml` around lines 91 - 92, Ports 9090, 8080, and 9100 are published to all interfaces; change the port mappings to bind to loopback by prefixing with 127.0.0.1 (e.g. replace "9090:9090" with "127.0.0.1:9090:9090") so the services are only accessible from localhost; update every occurrence of the mappings for 9090, 8080 and 9100 in the docker-compose.yml (the entries that currently read "9090:9090", "8080:8080", "9100:9100") accordingly and keep the host:container order intact.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docker-compose.yml`:
- Line 99: Replace the hardcoded host bind
"./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro" in the
docker-compose volume entry with a ${USERDIR}-rooted path from the .env file
(e.g., "${USERDIR}/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro")
so the Prometheus config mount follows the repo convention; update the volume
line in docker-compose.yml where the Prometheus bind is defined to reference
${USERDIR} instead of a relative ./ path.
In `@prometheus/prometheus.yml`:
- Around line 12-15: The active self-scrape job "prometheus" violates repo
policy—remove or comment out the job_name: "prometheus" block (the
static_configs/targets ["localhost:9090"]) so only the allowed active jobs
remain; ensure the file keeps active jobs for cadvisor and node_exporter and
that telegraf and tautulli entries remain commented out unless their metrics
endpoints are configured.
---
Nitpick comments:
In `@docker-compose.yml`:
- Around line 91-92: Ports 9090, 8080, and 9100 are published to all interfaces;
change the port mappings to bind to loopback by prefixing with 127.0.0.1 (e.g.
replace "9090:9090" with "127.0.0.1:9090:9090") so the services are only
accessible from localhost; update every occurrence of the mappings for 9090,
8080 and 9100 in the docker-compose.yml (the entries that currently read
"9090:9090", "8080:8080", "9100:9100") accordingly and keep the host:container
order intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 653272de-b500-403d-829c-bfcc858e5818
📒 Files selected for processing (5)
CLAUDE.mdREADME.mddocker-compose.ymldocs/prometheus.example.ymlprometheus/prometheus.yml
💤 Files with no reviewable changes (1)
- docs/prometheus.example.yml
| - "--config.file=/etc/prometheus/prometheus.yml" | ||
| - "--storage.tsdb.path=/prometheus" | ||
| volumes: | ||
| - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro |
There was a problem hiding this comment.
Use ${USERDIR}-rooted bind path for Prometheus config mount.
This path breaks the repo’s bind-mount convention and user-specific layout contract.
Suggested diff
- - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
+ - ${USERDIR}/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:roAs per coding guidelines: docker-compose.yml: All bind mount volume paths must be rooted at ${USERDIR} from .env, not hardcoded host paths, to respect user-specific storage layouts.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro | |
| - ${USERDIR}/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose.yml` at line 99, Replace the hardcoded host bind
"./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro" in the
docker-compose volume entry with a ${USERDIR}-rooted path from the .env file
(e.g., "${USERDIR}/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro")
so the Prometheus config mount follows the repo convention; update the volume
line in docker-compose.yml where the Prometheus bind is defined to reference
${USERDIR} instead of a relative ./ path.
There was a problem hiding this comment.
Skipping. prometheus/prometheus.yml is committed to the repo and is the same for every user — it is not user-specific state. The relative path ./prometheus/prometheus.yml resolves against the compose project directory (the repo root, where users run docker compose), so it works out of the box. Switching to ${USERDIR}/prometheus/prometheus.yml would force every user to copy the file into their USERDIR before docker compose up would succeed, which the README does not document. The CLAUDE.md ${USERDIR} rule is about user data bind mounts (/config, /media, etc.), not committed config-as-code.
There was a problem hiding this comment.
@joshdev8, that's a well-reasoned distinction — you're right. The ${USERDIR} convention is meant for user-specific runtime state (config dirs, media libraries, data directories, etc.), not for config-as-code files that are version-controlled in the repo itself. ./prometheus/prometheus.yml is the correct approach here since it resolves relative to the compose project root and works for all users without any extra setup. I'll update my understanding for future reviews.
✏️ Learnings added
Learnt from: joshdev8
Repo: joshdev8/AutoPlexx PR: 39
File: docker-compose.yml:99-99
Timestamp: 2026-05-13T18:25:49.929Z
Learning: In the `joshdev8/AutoPlexx` repo (`docker-compose.yml`), the `${USERDIR}` bind-mount convention applies only to **user-specific runtime state** (e.g., `/config`, `/media`, `/data` directories). Committed config-as-code files (e.g., `prometheus/prometheus.yml` checked into the repo) should use relative paths like `./prometheus/prometheus.yml`, which resolve from the compose project root. Do NOT flag relative repo-root paths as violations of the `${USERDIR}` rule.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
CLAUDE.md states only cadvisor and node_exporter scrape jobs are active; the self-scrape contradicted that. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1 participant
Summary
prometheus,cadvisor, andnode-exporterservices onmonitoring_network, with a newprometheus_datavolumedocs/prometheus.example.ymltoprometheus/prometheus.ymland rewrites it so cAdvisor + node-exporter are active scrape jobs; Telegraf and Tautulli are commented placeholders since neither exposes/metricsnativelymonitoring_networkmembership) and CLAUDE.md (replaces "No Prometheus in the stack" note with current behavior, adds cAdvisorprivileged: true/ port8080caveat)Test plan
docker compose configvalidates with a stub.envdocker compose up -d prometheus cadvisor node-exporterbrings the three new services up cleanly on a host with the full.envhttp://<host>:9090/targetsand confirmcadvisorandnode_exporterjobs are bothUPhttp://prometheus:9090) as a data source and confirm queries againstcontainer_cpu_usage_seconds_totalandnode_cpu_seconds_totalreturn data8080,9090, or9100before bringing the stack up🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Chores