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 strikes me as inappropriate for a health monitoring application like this to report the results of its monitors to stderr, especially since those errors and warnings often apply to different systems than the one where simplemonitor is running. The only messages I want to see from simplemonitor on stderr are messages about problems simplemonitor itself is experiencing, such as "Couldn't write to pidfile!", "Unknown alerter type %s; valid types are: %s", "Listener thread died :(".
Examples of messages I don't feel should use stderr include:
Interesting, I'd not noticed stuff going to stdout/stderr differently, just because of the ways I'd interacted with it (i.e. both were merged). I agree, there's an argument for stderr just showing simplemonitor's runtime errors (and stdout getting monitor-related ones then?). That should be doable with suitable configuration of the Python logging library, and some small code changes to use the right logging instance at the right time. I'll give it some thought :)
It strikes me as inappropriate for a health monitoring application like this to report the results of its monitors to stderr, especially since those errors and warnings often apply to different systems than the one where simplemonitor is running. The only messages I want to see from simplemonitor on stderr are messages about problems simplemonitor itself is experiencing, such as "Couldn't write to pidfile!", "Unknown alerter type %s; valid types are: %s", "Listener thread died :(".
Examples of messages I don't feel should use stderr include:
Thanks for hearing my opinion. I really appreciate your work on this!
The text was updated successfully, but these errors were encountered: