Cloudron Forum

It's not really a monitoring platform, more like : https://trigger.dev/docs/introduction Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI tasks, handle complex background jobs, and build AI agents with built-in queuing, automatic retries, and real-time monitoring. No timeouts, elastic scaling, and zero infrastructure management required. We provide everything you need to build and manage background tasks: a CLI and SDK for writing tasks in your existing codebase, support for both regular and scheduled tasks, full observability through our dashboard, and a Realtime API with React hooks for showing task status in your frontend. You can use Trigger.dev Cloud or self-host on your own infrastructure. But quite interesting to have nontheless!

@humptydumpty to reliably update i ended up always updating the docker tag to the desired version. With the tag updated you just need to run flyctl deploy again.

STATSD_URL=udp://127.0.0.1:8125 So the above is the correct value for Cloudrons?

@vladimir-d DBeaver Database Dashboard? Or you thinking longer timeframe and more detail?

@mdreira said in Lightmeter - Mail server delivery monitoring: What mail server does Cloudron use? Exim? This is what Cloudron uses for smpt: https://haraka.github.io/

Right.. It seems there are many candidates zabbix, netdata, some SNMP thing I forget etc. I prefer simply making sure Cloudron "works" with these existing software. It's why we added a way to open up the firewall as well. Happy to make any more fixes required to make these things work more easily.

@shai There may also be a plugin that does this too - it's worth trying to search on Nextcloud's own store-front for plugins.

@hillside502 yes, would be cool to map home networks and the upcoming Cloudron Multiserver.. and any ActivityPub App federations.

@atrilahiji That'd be the tax monitors, they soon format c: your bank account if you stop pinging their servers

While this has STILL not been addressed by docker upstream, there is a proposed solution that works: https://hub.docker.com/r/willfarrell/autoheal Alternatively a simple cron script checking for unhealthy containers to restart them. @staff what do you think?

If I understand correctly, you are asking for some netdata configuration. I will leave it open anyway in case some of our forum users can help. But maybe it's better suited in their forum.

In the past, I think people have recommended integrating with netdata. I don't have experience with netdata but wanted to throw the idea out there. Other than that, current graphs is rendered using data collected by graphite/carbon.

In Cloudron 5.6, we added a way to whitelist additional incoming ports - https://docs.cloudron.io/networking/#whitelist-ports