Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
D
docs
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Administrator
docs
Commits
2e3299c4
Commit
2e3299c4
authored
Jan 26, 2016
by
Fabian Reinartz
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add clients.md file
parent
26665917
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
52 additions
and
1 deletion
+52
-1
alertmanager.md
content/docs/alerting/alertmanager.md
+1
-1
clients.md
content/docs/alerting/clients.md
+51
-0
No files found.
content/docs/alerting/alertmanager.md
View file @
2e3299c4
...
...
@@ -54,7 +54,7 @@ Inhibitions are configured through the Alertmanager's configuration file.
## Silences
Silences are a straightforward way to simply mute alerts for a given time.
A silence is configured based on matchers, just
as
the routing tree. Incoming
A silence is configured based on matchers, just
like
the routing tree. Incoming
alerts are checked whether they match all the equality or regular expression
matchers of an active silence.
If they do, no notifications will be send out for that alert.
...
...
content/docs/alerting/clients.md
0 → 100644
View file @
2e3299c4
---
title
:
Clients
sort_rank
:
5
nav_icon
:
sliders
---
# Sending alerts
__
**Disclaimer**
: Prometheus automatically takes care of sending alerts
generated by its configured
[
alerting rules
](
../rules
)
. It is highly
recommended to configure alerting rules in Prometheus based on time series
data rather than implementing a direct client.__
The Alertmanager listens for alerts on an API endpoint at
`/api/v1/alerts`
.
Clients are expected to continously re-send alerts as long as they are still
active (usually on the order of 30 seconds to 3 minutes).
Clients can push a list of alerts to that endpoint via a POST request of
the following format:
```
[
{
"labels": {
"<labelname>": "<labelvalue>",
...
},
"annotations": {
"<labelname>": "<labelvalue>",
},
"startsAt": "<rfc3339>",
"endAt": "<rfc3339>"
"generatorURL": "<generator_url>"
},
...
]
```
The labels are used to identify identical instances of an alert and to perform
deduplication. The annotations are always set to those received most recently
and are not identifying an alert.
Both timestamps are optional. If
`startsAt`
is omitted, the current time
is assigned by the Alertmanager.
`endsAt`
is only set if the end time of an
alert is known. Otherwise it will be set to a configurable timeout period from
the time since the alert was last received.
The
`generatorURL`
field is a unique back-link which identifies the causing
entity of this alert in the client.
Alertmanager also supports a legacy endpoint on
`/api/alerts`
which is
compatible with Prometheus versions 0.16.2 and lower.
\ No newline at end of file
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment