feat: add monitoring-stack LXC

[Watashi199]

Scripts which are clearly AI generated and not further revised by the Author of this PR (in terms of Coding Standards and Script Layout) may be closed without review.

✍️ Description

Adds a new monitoring-stack script set for ProxmoxVED.

This PR introduces:

• a new CT entry for monitoring-stack
• a bare-metal install flow for Grafana, Prometheus, Alertmanager, Loki, Alloy, and prometheus-node-exporter
• Grafana datasource provisioning and baseline monitoring configuration
• an update_script() flow that backs up managed config, upgrades the installed packages, restores the managed files, and restarts the stack

The container exposes Grafana, Prometheus, and Alertmanager on the CT IP. Loki, Alloy, and node exporter remain local-only inside the container.

🔗 Related PR / Issue

Link: #

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows Code_Audit.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any scripts in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

📋 Additional Information (optional)

Validated with:

• bash -n ct/monitoring-stack.sh install/monitoring-stack-install.sh
• jq empty json/monitoring-stack.json
• git diff --check -- ct/headers/monitoring-stack ct/monitoring-stack.sh install/monitoring-stack-install.sh json/monitoring-stack.json

Also tested manually with:

• fresh install from Watashi199/codex/monitoring-stack-lxc-v2 on a clean Debian 13 unprivileged CT
• systemctl is-active grafana-server prometheus prometheus-alertmanager prometheus-node-exporter loki alloy
• curl -I http://127.0.0.1:3000
• curl -I http://127.0.0.1:9090/-/ready
• curl -I http://127.0.0.1:9093/-/ready
• curl -s http://127.0.0.1:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, health: .health}'
• update flow validation using PHS_SILENT=1 against the latest branch version
• post-update validation confirming services restart correctly and /opt/monitoring-stack/.env remains present
• CT reboot validation confirming all monitoring services come back automatically

---

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

Required for 🆕 New script submissions.
Pull requests that do not meet these requirements may be closed without review.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

• https://grafana.com/
• https://grafana.com/docs/
• https://github.com/grafana/grafana
• https://github.com/grafana/grafana/releases
• https://github.com/prometheus/prometheus
• https://github.com/prometheus/alertmanager
• https://github.com/grafana/loki
• https://github.com/grafana/alloy

[CrazyWolf13]

Thanks for the PR,

Though those apps are all available as single LXC, I see no real reason to complicate the setup and put all into one LXC.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 42be08ac61

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restart packaged services after writing managed configs

When apt install starts any of these packaged services during installation, these enable --now calls are no-ops for already-active units, so the Prometheus, Alertmanager, Loki, Alloy, and node_exporter configs written earlier are not loaded until a reboot or manual restart. In that case Prometheus can keep the package default scrape setup and node_exporter can remain on the package default listener instead of the intended 127.0.0.1:${NODE_EXPORTER_PORT}; reload systemd after replacing package units and restart the services here.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Use Alertmanager's Discord receiver for Discord webhooks

When DISCORD_WEBHOOK_URL is supplied at install time, this config sends Alertmanager's generic webhook JSON directly to Discord. Discord incoming webhooks do not accept that payload shape; Alertmanager has a discord_configs receiver for this case, otherwise users who configure the advertised Discord webhook URL will silently lose alert notifications.

Useful? React with 👍 / 👎.

[Watashi199]

those are all available as single LXC, I see no reason to complicate the setup and put all into one LXC.

That is fair feedback.

The intention was not to replace the existing single-app LXCs, but to offer a ready-to-use monitoring bundle for users who want the stack preconfigured together.

I also assumed this could be acceptable since bundled setups are not completely new here, for example with the arr-stack approach and similar discussions around multi-service helper scripts.

That said, I understand the concern about complexity and reduced modularity. If this is not a direction the project wants to support for monitoring, I’m fine with dropping the PR.

[github-actions]

@Watashi199 Closing stale PR due to inactivity (no commits for 7 days after stale label).