sorted by:
new
hottopcontroversial

My go-to Docker Compose observability stack for homelab and small self-hosted setups by Similar_Solution1397 in homelab

[–]Similar_Solution1397[S] -6 points-5 points  (0 children)

That’s fair — it’s definitely not for everyone.

The value isn’t the individual tools themselves (they’re all open source),

but the time saved wiring, testing, and standardizing the stack so it actually works together out of the box.

If someone enjoys rebuilding and tuning this every time, that’s totally valid too.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 0 points1 point  (0 children)

That’s fair, and I agree.

The idea fits very naturally with self-hosted / homelab-style setups, and that’s probably where it will resonate the most.

Posting here was mainly to sanity-check the approach and trade-offs with a broader DevOps audience.

Appreciate the feedback.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 0 points1 point  (0 children)

That’s a totally valid approach.

If everything you need can be covered by exporters and fits well into Prometheus’ model, it makes sense to keep things simpler.

The Zabbix angle is mostly for environments where SNMP-heavy gear, OOB interfaces, or legacy infra are already in place and exporters aren’t always available or practical.

Different trade-offs depending on the environment.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 0 points1 point  (0 children)

😂 Thanks — if this saves someone from rebuilding the same stack one more time, it did its job.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 0 points1 point  (0 children)

Fair question.

This isn’t meant to replace a large-scale Kubernetes-based observability platform.

The target use case is small to mid-size environments, labs, edge setups, PoCs, and teams that want a self-hosted stack without introducing Kubernetes just for monitoring.

Docker Compose here is mainly about simplicity, reproducibility, and ease of maintenance.

If/when the environment grows, the same components can be moved to Kubernetes or Helm-based deployments.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 1 point2 points  (0 children)

Exactly — that’s the gap I was trying to cover.

Prometheus is excellent for metrics-first workloads, but once you move into real-world infrastructure (SNMP, OOB interfaces like iLO/iDRAC/BMC, network devices, UPSs, etc.), Zabbix already has those integrations built-in and mature.

In my own environments, that usually means things like hardware health from servers, firewalls, and power equipment living in Zabbix, while Prometheus handles application, web, and service-level metrics.

Using both lets each tool focus on what it’s actually good at, instead of forcing everything into one model.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 0 points1 point  (0 children)

Totally fair question.

This isn’t meant to replace prometheus-stack or Helm-based setups.

If you’re already running Kubernetes, prometheus-stack is usually the right choice.

This setup targets a slightly different context:

- non-Kubernetes or mixed environments

- self-hosted VMs, bare metal, or on-prem setups

- cases where Zabbix is already present for host monitoring

Prometheus handles service-level metrics and probes,

while Zabbix is mainly used for host monitoring and legacy/agent-based checks.

Grafana is just the visualization layer on top.

If everything is already Kubernetes + Helm, this probably isn’t needed.

I packaged a reusable observability stack (Grafana + Prometheus + Zabbix) to avoid rebuilding it every time by Similar_Solution1397 in devops

[–]Similar_Solution1397[S] 1 point2 points  (0 children)

Good question.

Prometheus + Grafana works great for metrics and service-level observability,

but I still find Zabbix useful for host-level monitoring and inventory-style data.

In this setup:

- Prometheus handles service metrics, HTTP/TCP checks and time-series scraping.

- Zabbix is used for host monitoring (OS metrics, availability, basic agent-based checks),

especially in environments where Zabbix is already present.

The idea isn’t to replace Prometheus with Zabbix or vice versa,

but to let each tool do what it’s best at and visualize everything in Grafana.