search

RIPE-NCC / ripe-atlas-probe-measurements

RIPE Atlas probe measurement source code
Other
41 stars 18 forks source link

perd: make command run less verbose #12

Open Ansuel opened 2 years ago

Ansuel commented 2 years ago

The default log level is 8. We currently run each perd job and log their execution with log level 8. This seems to be an info log and including it in the error level seems wrong and probably an oversight when the code was implemented.

Signed-off-by: Christian Marangi ansuelsmth@gmail.com

Ansuel commented 2 years ago

@michel-stam no idea if you guys already fixed this in internal repo but currently atlas seems too spammy about this... another solution would be permit to make the log level configurable via the arch scripts.

michel-stam commented 2 years ago

Hey Christian,

The logging has not been fixed currently, but good suggestion, Ill discuss it internally if anyone objects. Seems fairly trivial.

As to the repo, I'm waiting for an internal ok to have the CICD pipeline auto-push repos to GitHub when we release. This is what is currently holding up us updating the repo.

Bear with me, I'm on top of it.

Cheers,

Michel

michel-stam commented 2 years ago

Hey @Ansuel ,

I've merged your log request. Seems no more than fair, its only useful for debugging purposes. Looking forward to what you have in mind for the log levels, but bear in mind that I would like to give that entire script a very critical look. Especially on software probes I would like to look more at systemd units, for OpenWRT I'm thinking on procd init scripts.

Thanks!

Michel

Ansuel commented 2 years ago

@michel-stam ideally we should find a way to make the log output universal enough to be configurable from both procd and systemd. But some changes are required before that as some tools still ignore any kind of log level configuration. I pushed a pr that should improve the situation but it's less trivial than this ahahhaha

michel-stam commented 2 years ago

hey @Ansuel ,

I agree, but some plumbing will be necessary, as you already say.

As an aside: The current -provisional- idea when talking to the other devs is to re-evaluate the entire protocol, and consider something like MQTT over websockets over HTTPS, using JSON messages.

I have converted some messages to JSON, which will be visible once I'm able to push the internal repo.

As said, this is very early days, nothing is set in stone yet, but since you're starting to move into this area I would like you to be aware of this.