5.21.1 Reload Alertmanager
- Description
-
Reload the Alertmanager definition file (jpc_alertmanager.yml) and reflect it in the operation of Alertmanager.
Reloading Alertmanager is faster than restarting Alertmanager and maintains the state it was in when the notification failed.
- Special Notes on API Operation
-
-
All definition fields are reloaded.
-
If you leave an alert in a normal state and change the threshold of the alert rule to become unhealthy, the alert becomes unhealthy.
-
If you leave an alert in an abnormal state and change the threshold of the alert rule to become normal, the alert becomes normal.
-
If you reload an incorrect definition file, all definition entries will not be updated.
-
- Format
-
- Request line
POST /-/reload HTTP/1.1
- Request header
-
Header name
Setup values
Host
Specifies value of the header for Alertmanager host to which API is connected, in the following format:
Host name or IP address:Port number
":Port number" is optional.
-
Host name or IP address
Specifies host name or IPv4 address of Alertmanager.
-
Port number
Specifies port number to use when connecting to Alertmanager.
This header is not optional.
-
- Request message body
-
None
- Response message body
-
If the reload is successful, there is no response.
If the reload fails, a message indicating the cause of the failure (the value output by Alertmanager) is set.
- Status codes
-
Status code
Message
Description
200
OK
Reloaded successfully.
Other than 200
Other than OK
Reload failed.
- Examples
-
The following is an example of using this API using the OSS curl command.
On successful reload:
>curl --request POST "http://localhost:20714/-/reload" >
On reload failure:
>curl --request POST "http://localhost:20714/-/reload" failed to reload config: yaml: line 11: could not find expected ':' >