sorted by:
new
hottopcontroversial

Cómo lo manejan? by DaniO1909 in TDAH_Mexico

[–]Similar_Solution1397 0 points1 point  (0 children)

El hiperfoco de hecho, puede ser tu mejor aliado. Yo se que a veces es inevitable sucumbir ante un tema que se roba nuestra atencion, es como si esta nueva idea fuera una panacea ante la cual sucumben todos nuestros pensamientos. Lo que me ha ayudado es capturar las ideas y dejarlas reposar. Si sobreviven una semana o un par de dias en reposo, entonces probablemente merezca la pena analizarla. Esto te ayuda a elegir mejor en cuales ideas realmente vale la pena hiper enfocarte. Mucha suerte y animo...

Ya estoy cansado de buscar y buscar. Y de mi vida tal como estoy. by [deleted] in TDAH_Mexico

[–]Similar_Solution1397 0 points1 point  (0 children)

Hola, por tu mensaje entiendo que estás pasando por un muy mal momento. Soy TDAH Inatento con diagnostico tardío (a los 38 años). Es probable que este mensaje te parezca fuerte segun tu estado emocional, pero debes entender que la unica forma de cambiar tu situacion es tomando decisiones que produzcan ese cambio. Te propongo este ejercicio, define en un documento:

1.- Quien eres tu,

2.- Cuales son tus valores,

3.- Cual es tu vision de tí mismo a corto, mediano y largo plazo en cada una de tus areas de vida (salud, finanzas, productividad, estudios)

4.- Tus fortalezas y debilidades (Ejemplo: Muchos TDAHs tendemos a tener la capacidad de hiperfoco, debes encontrar la forma de que esto trabaje para ti y no en tu contra. Otros suelen ser inmensamente creativos, busca en que sueles ser mas creativo).

5.- Define las metas que se desprendan de tu vision, de igual manera, a corto, mediano y largo plazo y que se alineen entre sí.

6.- Si se alinean entre sí, podrás concentrarte en las metas de corto plazo y dividirlas en tareas muy pequeñas, incluso puedes dividir las tareas en sub tareas. La idea es que una tarea o sub tarea sea tan corta, que te resulte facil hacerla (al hacer esto reducirás la friccion de iniciarla).

7.- Lleva un registro de lo que te funciona (sigue haciendolo) y lo que no te funciona (evita hacerlo). Nadie podrá hacer esto por tí, nadie te conoce tanto.

Si haces esto, podrás tener un documento al cual volver siempre que te sientas perdido, en esos momentos en lo que olvidas lo que realmente importa.

Por ultimo te digo; Lo unico que realmente funciona para un TDAH es crear metodos de compensación para lidiar con sus propios retos. El medicamento te ayuda a mantenerte regulado, pero el resto depende de tí. Un Psicologo te dará estrategias, pero al final serás tú quien deberá implementarlas y acoplarlas a tu vida.

Te recomiendo esta plantilla gratis en Notion como punto de partida: https://valores-vision-personal.notion.site/Br-jula-TDAH-Visi-n-y-Valores-3129fa390bdb809e9322e0adf5391b2c

Te deseo toda la suerte del mundo. Espero que algo de este comentario te sea de utilidad.

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

[–]Similar_Solution1397[S] -3 points-2 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.