-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signal handling #152
Comments
I wonder if this should be something we add to the https://github.com/prometheus/exporter-toolkit. |
I think this issue is also related to prometheus/node_exporter#2356. IMO it's better to graceful shutdown the server instead of exiting 0 directly, and then return to the caller of @SuperQ how do you think? If that's the proper way to fix this issue, I can open a PR. |
Yes, I would like add a helper for signal handling here. I've been working on a top level toolkit package that will make the whole bootstrap setup easier. |
I was about to open a proposal for I did a scan of Prometheus components and didn't find any of them implementing graceful shutdown, except for the Push Gateway. The PG does it quite nicely. Adding the above function would allow to very easily add graceful shutdown to exporters like in the Push Gateway: quitCh := make(chan struct{})
quitHandler := func(w http.ResponseWriter, r *http.Request) { // handler not required but is good demo
fmt.Fprintf(w, "Requesting termination... Goodbye!")
close(quitCh)
}
mux := ...
server := &http.Server{Handler: mux}
go web.ShutdownServerOnQuit(server, quitCh, logger)
err := web.ListenAndServe(server, webConfig, logger)
// In the case of a graceful shutdown, do not log the error.
if err == http.ErrServerClosed {
level.Info(logger).Log("msg", "HTTP server stopped")
} else {
level.Error(logger).Log("msg", "HTTP server stopped", "err", err)
} @SuperQ this could be very easily added to the work you are doing for the top-level package in |
That looks pretty good. Although we don't use http server mux consistently across exporters. |
Ah, the mux part is just an example :). All this function needs is an http.Server instance, a webconfig and a logger. Just like the existing ListenAndServe() function. Would you like me to open a PR to add it to the 'web'' module? |
I'm wondering if it would be better in the top level toolkit package, rather than the web package. What do you think @roidelapluie ? |
Would like to see signal processing for SIGQUIT and SIGTERM in subsequent versions for proper systemd unit operation. Currently, the systemd unit transitions to a failed state after stopping the service.
Here is a short patch for version 0.21.0:
The text was updated successfully, but these errors were encountered: