You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was done "on purpose" at the time as the db connection is essential for the dispatcher to work. The idea was to let it crash and let systemd (or any other supervisor) restart it in a clean state when db is available again.
It looks like you are using Horus in a very interesting way, I would love to hear more about it :) Feel free to contact me by PM (my email is in my profile.)
I handled this feature with "systemd" and it works fine.
We also use the "tags" field of the "devices" table which allows you to add labels. This feature works well but does not expose the labels in the "pingmetrics" metrics. It exposes tags only in the results of the "snmpmetrics" metric.
Examples:
champs "tags": {Communaute="TEST", location="TEST"} for devices "xxxxxxxxxxxxxx"
Hello,
I did the following test.
I stop the "Horus" database and I notice the dispatcher process drops when it no longer has access to its database.
We must restart the "dispatcher" process for the "Horus" polling to resume when the database is available again.
Can we tell the dispacter not to stop even if he no longer has access to his base ?
Process start with option:
/data/horus/cmd/bin/horus-dispatcher -l 1 -c postgres://horus:x.x.x.x@x.x.x.x/horus?sslmode=disable -d 3 --log /logs/horus
Logs:
[F] 2021-11-16 08:39:53.083835 db.go:74 - db lock conn ping: driver: bad connection
Br,
Christophe.
The text was updated successfully, but these errors were encountered: