Monitoraggio e creazione di avvisi | Guida all'amministrazione

documentation.suse.com › Documentazione di SUSE Enterprise Storage 6 › Guida all'amministrazione › Funzionamento di un cluster › Monitoraggio e creazione di avvisi

ContenutoContenuto

Guida all'amministrazione

Navigazione←→

Si applica a SUSE Enterprise Storage 6

7 Monitoraggio e creazione di avvisi #

7.1 Variabili del pillar
7.2 Grafana
7.3 Prometheus
7.4 Alertmanager

In SUSE Enterprise Storage 6, DeepSea non distribuisce più uno stack di monitoraggio e creazione di avvisi sul Salt master. Gli utenti devono definire il ruolo Prometheus per Prometheus e Alertmanager e il ruolo Grafana per Grafana. Quando si assegnano più nodi con ruolo Prometheus o Grafana, viene distribuita una configurazione ad alta disponibilità.

Prometheus è il kit di strumenti per la creazione di avvisi e il monitoraggio.
Alertmanager gestisce gli avvisi inviati dal server Prometheus.
Grafana è il software di visualizzazione e creazione di avvisi.
Il prometheus-node_exporter è il servizio in esecuzione su tutti i Salt minion.

La configurazione di Prometheus e le destinazioni di scrape (esportazione daemon) vengono impostate automaticamente da DeepSea. DeepSea inoltre distribuisce un elenco di avvisi di default, ad esempio health error, 10% OSDs down o pgs inactive.

7.1 Variabili del pillar #

Il pillar di Salt è un archivio di chiavi-valori che fornisce informazioni e valori di configurazione ai minion. È disponibile per tutti i minion, con contenuti differenti per ciascuno. Il pillar di Salt è precompilato con valori di default e può essere personalizzato in due modi diversi:

/srv/pillar/ceph/stack/global.yml: per modificare le variabili del pillar per tutti i nodi.
/srv/pillar/ceph/stack/CLUSTER_NAME/minions/HOST: per modificare le configurazioni di specifici minion.

Le seguenti variabili del pillar sono disponibili di default per tutti i nodi:

  monitoring:
  alertmanager:
    config: salt://path/to/config
    additional_flags: ''
  grafana:
    ssl_cert: False # self-signed certs are created by default
    ssl_key: False # self-signed certs are created by default
  prometheus:
    # pass additional configration to prometheus
    additional_flags: ''
    alert_relabel_config: []
    rule_files: []
    # per exporter config variables
    scrape_interval:
      ceph: 10
      node_exporter: 10
      prometheus: 10
      grafana: 10
    relabel_config:
      alertmanager: []
      ceph: []
      node_exporter: []
      prometheus: []
      grafana: []
    metric_relabel_config:
      ceph: []
      node_exporter: []
      prometheus: []
      grafana: []
    target_partition:
      ceph: '1/1'
      node_exporter: '1/1'
      prometheus: '1/1'
      grafana: '1/1'

7.2 Grafana #

Tutto il traffico è cifrato tramite Grafana. È possibile fornire i propri certificati SSL o crearne uno autofirmato.

Grafana utilizza le seguenti variabili:

ssl_cert
ssl_key

Per ulteriori informazioni su come fornire i propri certificati SSL, consultare la Sezione 22.9.1.2, «Certificati firmati dalla CA»; per sapere come creare un certificato autofirmato, consultare la Sezione 22.9.1.1, «Certificati firmati da se stessi».

7.3 Prometheus #

La configurazione basata sull'utilità di esportazione che può essere trasmessa tramite il pillar. Questi gruppi effettuano la mappatura alle utilità di esportazione che forniscono dati. L'utilità di esportazione del nodo è presente su tutti i nodi; Ceph viene esportato dai nodi Ceph Manager, mentre Prometheus e Grafana vengono esportati dai rispettivi nodi Prometheus e Grafana.

Prometheus utilizza le seguenti variabili:

scrape_interval: consente di modificare l'intervallo di scrape, ossia la frequenza con cui un'utilità di esportazione deve essere sottoposta a scrape.
target_partition: consente di partizionare le destinazioni di scrape quando vengono distribuite più istanze di Prometheus e alcune istanze effettuano lo scrape solo di una parte di tutte le istanze dell'utilità di esportazione.
relabel_config: consente di riscrivere dinamicamente il gruppo di etichette di una destinazione prima che venga sottoposta a scrape. Per ogni configurazione di scrape, è possibile configurare più fasi di rietichettatura.
metrics_relabel_config: applicata ai campioni come ultimo passaggio prima dell'acquisizione.

7.4 Alertmanager #

Alertmanager gestisce gli avvisi inviati dal server Prometheus. Si occupa di deduplicarli, raggrupparli e instradarli al ricevitore corretto. Si incarica anche della disattivazione degli avvisi. Alertmanager è configurato tramite i flag della riga di comando e un file di configurazione che definisce le regole di inibizione, nonché l'instradamento e i ricevitori delle notifiche.

7.4.1 File di configurazione #

La configurazione di Alertmanager è differente per ogni distribuzione. Pertanto, DeepSea non fornisce alcun valore di default correlato. È necessario fornire il proprio file di configurazione alertmanager.yml. Il pacchetto alertmanager per default installa un file di configurazione /etc/prometheus/alertmanager.yml che può fungere da esempio di configurazione. Se si preferisce che sia DeepSea a gestire la configurazione di Alertmanager, aggiungere la chiave seguente al proprio pillar, ad esempio nel file /srv/pillar/ceph/stack/ceph/minions/YOUR_SALT_MASTER_MINION_ID.sls:

Per un esempio completo del file di configurazione di Alertmanager, consultare l'Appendice B, Avvisi di default di SUSE Enterprise Storage 6.

monitoring:
 alertmanager_config:
   /path/to/your/alertmanager/config.yml

Il file di configurazione di Alertmanager è scritto in formato YAML e segue lo schema descritto di seguito. I parametri tra parentesi sono facoltativi. Per i parametri non di tipo elenco viene utilizzato il valore di default. Nello schema vengono utilizzati i seguenti segnaposto generici:

DURATION: Una durata corrispondente all'espressione regolare [0-9]+(ms|[smhdwy])
LABELNAME: Una stringa corrispondente all'espressione regolare [a-zA-Z_][a-zA-Z0-9_]*
LABELVALUE: Una stringa di caratteri Unicode.
FILEPATH: Un percorso valido nella directory di lavoro attuale.
BOOLEAN: Un valore booleano che può assumere i valori "true" o "false".
STRING: Una normale stringa.
SECRET: Una normale stringa che rappresenta un segreto, ad esempio una password.
TMPL_STRING: Una stringa ampliata in base a un modello prima dell'uso.
TMPL_SECRET: Una stringa segreta ampliata in base a un modello prima dell'uso.

Esempio 7.1: Configurazione globale #

I parametri nella configurazione global: sono validi in tutti gli altri contesti di configurazione. Fungono inoltre da default per altre sezioni di configurazione.

global:
# the time after which an alert is declared resolved if it has not been updated
[ resolve_timeout: DURATION | default = 5m ]

# The default SMTP From header field.
[ smtp_from: TMPL_STRING ]
# The default SMTP smarthost used for sending emails, including port number.
# Port number usually is 25, or 587 for SMTP over TLS
# (sometimes referred to as STARTTLS).
# Example: smtp.example.org:587
[ smtp_smarthost: STRING ]
# The default host name to identify to the SMTP server.
[ smtp_hello: STRING | default = "localhost" ]
[ smtp_auth_username: STRING ]
# SMTP Auth using LOGIN and PLAIN.
[ smtp_auth_password: SECRET ]
# SMTP Auth using PLAIN.
[ smtp_auth_identity: STRING ]
# SMTP Auth using CRAM-MD5.
[ smtp_auth_secret: SECRET ]
# The default SMTP TLS requirement.
[ smtp_require_tls: BOOL | default = true ]

# The API URL to use for Slack notifications.
[ slack_api_url: STRING ]
[ victorops_api_key: STRING ]
[ victorops_api_url: STRING | default = "https://victorops.example.com/integrations/alert/" ]
[ pagerduty_url: STRING | default = "https://pagerduty.example.com/v2/enqueue" ]
[ opsgenie_api_key: STRING ]
[ opsgenie_api_url: STRING | default = "https://opsgenie.example.com/" ]
[ hipchat_api_url: STRING | default = "https://hipchat.example.com/" ]
[ hipchat_auth_token: SECRET ]
[ wechat_api_url: STRING | default = "https://wechat.example.com/cgi-bin/" ]
[ wechat_api_secret: SECRET ]
[ wechat_api_corp_id: STRING ]

# The default HTTP client configuration
[ http_config: HTTP_CONFIG ]

# Files from which custom notification template definitions are read.
# The last component may use a wildcard matcher, e.g. 'templates/*.tmpl'.
templates:
[ - FILEPATH ... ]

# The root node of the routing tree.
route: ROUTE

# A list of notification receivers.
receivers:
- RECEIVER ...

# A list of inhibition rules.
inhibit_rules:
[ - INHIBIT_RULE ... ]

Esempio 7.2: ROUTE #

Un blocco ROUTE definisce un nodo in un albero di instradamento. I parametri non specificati vengono ereditati dal nodo superiore. Ogni avviso fa il proprio ingresso nell'albero di instradamento in corrispondenza dell'instradamento di livello superiore configurato, che deve corrispondere a tutti gli avvisi. Successivamente, attraversa i nodi secondari. Se l'opzione continue è impostata su "false", l'attraversamento si interrompe dopo il primo nodo secondario corrispondente. Impostando l'opzione su "true" su un nodo corrispondente, l'avviso continua la ricerca della corrispondenza sui nodi affini successivi. Se non trova corrispondenza con alcun nodo secondario, l'avviso viene gestito in base ai parametri di configurazione del nodo attuale.

[ receiver: STRING ]
[ group_by: '[' LABELNAME, ... ']' ]

# If an alert should continue matching subsequent sibling nodes.
[ continue: BOOLEAN | default = false ]

# A set of equality matchers an alert has to fulfill to match a node.
match:
 [ LABELNAME: LABELVALUE, ... ]

# A set of regex-matchers an alert has to fulfill to match a node.
match_re:
 [ LABELNAME: REGEX, ... ]

# Time to wait before sending a notification for a group of alerts.
[ group_wait: DURATION | default = 30s ]

# Time to wait before sending a notification about new alerts
# added to a group of alerts for which an initial notification has
# already been sent.
[ group_interval: DURATION | default = 5m ]

# Time to wait before re-sending a notification
[ repeat_interval: DURATION | default = 4h ]

# Possible child routes.
routes:
 [ - ROUTE ... ]

Esempio 7.3: INHIBIT_RULE #

Una regola di inibizione disattiva un avviso di destinazione corrispondente a un gruppo di matcher quando esiste un avviso di origine corrispondente a un altro gruppo di matcher. Entrambi gli avvisi devono condividere gli stessi valori di etichetta per i nomi di etichetta nell'elenco equal.

Gli avvisi possono corrispondere e quindi disabilitarsi a vicenda. Evitare di scrivere regole di inibizione in cui un avviso corrisponde sia all'origine che alla destinazione.

# Matchers that need to be fulfilled for the alerts to be muted.
target_match:
 [ LABELNAME: LABELVALUE, ... ]
target_match_re:
 [ LABELNAME: REGEX, ... ]

# Matchers for which at least one alert needs to exist so that the
# inhibition occurs.
source_match:
 [ LABELNAME: LABELVALUE, ... ]
source_match_re:
 [ LABELNAME: REGEX, ... ]

# Labels with an equal value in the source and target
# alert for the inhibition to take effect.
[ equal: '[' LABELNAME, ... ']' ]

Esempio 7.4: HTTP_CONFIG #

HTTP_CONFIG consente di configurare il client HTTP utilizzato dal ricevitore per comunicare con i servizi API.

Si noti che le opzioni basic_auth, bearer_token e bearer_token_file sono mutualmente esclusive.

# Sets the 'Authorization' header with the user name and password.
basic_auth:
[ username: STRING ]
[ password: SECRET ]

# Sets the 'Authorization' header with the bearer token.
[ bearer_token: SECRET ]

# Sets the 'Authorization' header with the bearer token read from a file.
[ bearer_token_file: FILEPATH ]

# TLS settings.
tls_config:
# CA certificate to validate the server certificate with.
[ ca_file: FILEPATH ]
# Certificate and key files for client cert authentication to the server.
[ cert_file: FILEPATH ]
[ key_file: FILEPATH ]
# ServerName extension to indicate the name of the server.
# http://tools.ietf.org/html/rfc4366#section-3.1
[ server_name: STRING ]
# Disable validation of the server certificate.
[ insecure_skip_verify: BOOLEAN | default = false]

# Optional proxy URL.
[ proxy_url: STRING ]

Esempio 7.5: RECEIVER #

Il ricevitore è una configurazione con nome per una o più integrazioni di notifica.

Anziché aggiungere nuovi ricevitori, si consiglia di implementare integrazioni di notifica personalizzate utilizzando il ricevitore webhook (consultare l'Esempio 7.15, «WEBHOOK_CONFIG»).

# The unique name of the receiver.
name: STRING

# Configurations for several notification integrations.
email_configs:
[ - EMAIL_CONFIG, ... ]
hipchat_configs:
[ - HIPCHAT_CONFIG, ... ]
pagerduty_configs:
[ - PAGERDUTY_CONFIG, ... ]
pushover_configs:
[ - PUSHOVER_CONFIG, ... ]
slack_configs:
[ - SLACK_CONFIG, ... ]
opsgenie_configs:
[ - OPSGENIE_CONFIG, ... ]
webhook_configs:
[ - WEBHOOK_CONFIG, ... ]
victorops_configs:
[ - VICTOROPS_CONFIG, ... ]
wechat_configs:
[ - WECHAT_CONFIG, ... ]

Esempio 7.6: EMAIL_CONFIG #

# Whether to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = false ]

# The email address to send notifications to.
to: TMPL_STRING

# The sender address.
[ from: TMPL_STRING | default = global.smtp_from ]

# The SMTP host through which emails are sent.
[ smarthost: STRING | default = global.smtp_smarthost ]

# The host name to identify to the SMTP server.
[ hello: STRING | default = global.smtp_hello ]

# SMTP authentication details.
[ auth_username: STRING | default = global.smtp_auth_username ]
[ auth_password: SECRET | default = global.smtp_auth_password ]
[ auth_secret: SECRET | default = global.smtp_auth_secret ]
[ auth_identity: STRING | default = global.smtp_auth_identity ]

# The SMTP TLS requirement.
[ require_tls: BOOL | default = global.smtp_require_tls ]

# The HTML body of the email notification.
[ html: TMPL_STRING | default = '{{ template "email.default.html" . }}' ]
# The text body of the email notification.
[ text: TMPL_STRING ]

# Further headers email header key/value pairs. Overrides any headers
# previously set by the notification implementation.
[ headers: { STRING: TMPL_STRING, ... } ]

Esempio 7.7: HIPCHAT_CONFIG #

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = false ]

# The HipChat Room ID.
room_id: TMPL_STRING
# The authentication token.
[ auth_token: SECRET | default = global.hipchat_auth_token ]
# The URL to send API requests to.
[ api_url: STRING | default = global.hipchat_api_url ]

# A label to be shown in addition to the sender's name.
[ from:  TMPL_STRING | default = '{{ template "hipchat.default.from" . }}' ]
# The message body.
[ message:  TMPL_STRING | default = '{{ template "hipchat.default.message" . }}' ]
# Whether this message will trigger a user notification.
[ notify:  BOOLEAN | default = false ]
# Determines how the message is treated by the alertmanager and rendered inside HipChat. Valid values are 'text' and 'html'.
[ message_format:  STRING | default = 'text' ]
# Background color for message.
[ color:  TMPL_STRING | default = '{{ if eq .Status "firing" }}red{{ else }}green{{ end }}' ]

# Configuration of the HTTP client.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Esempio 7.8: PAGERDUTY_CONFIG #

Le opzioni routing_key e service_key si escludono a vicenda.

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = true ]

# The PagerDuty integration key (when using 'Events API v2').
routing_key: TMPL_SECRET
# The PagerDuty integration key (when using 'Prometheus').
service_key: TMPL_SECRET

# The URL to send API requests to.
[ url: STRING | default = global.pagerduty_url ]

# The client identification of the Alertmanager.
[ client:  TMPL_STRING | default = '{{ template "pagerduty.default.client" . }}' ]
# A backlink to the notification sender.
[ client_url:  TMPL_STRING | default = '{{ template "pagerduty.default.clientURL" . }}' ]

# The incident description.
[ description: TMPL_STRING | default = '{{ template "pagerduty.default.description" .}}' ]

# Severity of the incident.
[ severity: TMPL_STRING | default = 'error' ]

# A set of arbitrary key/value pairs that provide further details.
[ details: { STRING: TMPL_STRING, ... } | default = {
 firing:       '{{ template "pagerduty.default.instances" .Alerts.Firing }}'
 resolved:     '{{ template "pagerduty.default.instances" .Alerts.Resolved }}'
 num_firing:   '{{ .Alerts.Firing | len }}'
 num_resolved: '{{ .Alerts.Resolved | len }}'
} ]

# The HTTP client's configuration.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Esempio 7.9: PUSHOVER_CONFIG #

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = true ]

# The recipient user key.
user_key: SECRET

# Registered application’s API token.
token: SECRET

# Notification title.
[ title: TMPL_STRING | default = '{{ template "pushover.default.title" . }}' ]

# Notification message.
[ message: TMPL_STRING | default = '{{ template "pushover.default.message" . }}' ]

# A supplementary URL displayed together with the message.
[ url: TMPL_STRING | default = '{{ template "pushover.default.url" . }}' ]

# Priority.
[ priority: TMPL_STRING | default = '{{ if eq .Status "firing" }}2{{ else }}0{{ end }}' ]

# How often the Pushover servers will send the same notification (at least 30 seconds).
[ retry: DURATION | default = 1m ]

# How long your notification will continue to be retried (unless the user
# acknowledges the notification).
[ expire: DURATION | default = 1h ]

# Configuration of the HTTP client.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Esempio 7.10: SLACK_CONFIG #

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = false ]

# The Slack webhook URL.
[ api_url: SECRET | default = global.slack_api_url ]

# The channel or user to send notifications to.
channel: TMPL_STRING

# API request data as defined by the Slack webhook API.
[ icon_emoji: TMPL_STRING ]
[ icon_url: TMPL_STRING ]
[ link_names: BOOLEAN | default = false ]
[ username: TMPL_STRING | default = '{{ template "slack.default.username" . }}' ]
# The following parameters define the attachment.
actions:
[ ACTION_CONFIG ... ]
[ color: TMPL_STRING | default = '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}' ]
[ fallback: TMPL_STRING | default = '{{ template "slack.default.fallback" . }}' ]
fields:
[ FIELD_CONFIG ... ]
[ footer: TMPL_STRING | default = '{{ template "slack.default.footer" . }}' ]
[ pretext: TMPL_STRING | default = '{{ template "slack.default.pretext" . }}' ]
[ short_fields: BOOLEAN | default = false ]
[ text: TMPL_STRING | default = '{{ template "slack.default.text" . }}' ]
[ title: TMPL_STRING | default = '{{ template "slack.default.title" . }}' ]
[ title_link: TMPL_STRING | default = '{{ template "slack.default.titlelink" . }}' ]
[ image_url: TMPL_STRING ]
[ thumb_url: TMPL_STRING ]

# Configuration of the HTTP client.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Esempio 7.11: ACTION_CONFIG per SLACK_CONFIG #

# Provide a button to tell Slack you want to render a button.
type: TMPL_STRING
# Label for the button.
text: TMPL_STRING
# http or https URL to deliver users to. If you specify invalid URLs, the message will be posted with no button.
url: TMPL_STRING
#  If set to 'primary', the button will be green, indicating the best forward action to take
#  'danger' turns the button red, indicating a destructive action.
[ style: TMPL_STRING [ default = '' ]

Esempio 7.12: FIELD_CONFIG per SLACK_CONFIG #

# A bold heading without markup above the value text.
title: TMPL_STRING
# The text of the field. It can span across several lines.
value: TMPL_STRING
# A flag indicating if value is short enough to be displayed together with other values.
[ short: BOOLEAN | default = slack_config.short_fields ]

Esempio 7.13: OPSGENIE_CONFIG #

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = true ]

# The API key to use with the OpsGenie API.
[ api_key: SECRET | default = global.opsgenie_api_key ]

# The host to send OpsGenie API requests to.
[ api_url: STRING | default = global.opsgenie_api_url ]

# Alert text (maximum is 130 characters).
[ message: TMPL_STRING ]

# A description of the incident.
[ description: TMPL_STRING | default = '{{ template "opsgenie.default.description" . }}' ]

# A backlink to the sender.
[ source: TMPL_STRING | default = '{{ template "opsgenie.default.source" . }}' ]

# A set of arbitrary key/value pairs that provide further detail.
[ details: { STRING: TMPL_STRING, ... } ]

# Comma separated list of team responsible for notifications.
[ teams: TMPL_STRING ]

# Comma separated list of tags attached to the notifications.
[ tags: TMPL_STRING ]

# Additional alert note.
[ note: TMPL_STRING ]

# Priority level of alert, one of P1, P2, P3, P4, and P5.
[ priority: TMPL_STRING ]

# Configuration of the HTTP.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Esempio 7.14: VICTOROPS_CONFIG #

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = true ]

# The API key for talking to the VictorOps API.
[ api_key: SECRET | default = global.victorops_api_key ]

# The VictorOps API URL.
[ api_url: STRING | default = global.victorops_api_url ]

# A key used to map the alert to a team.
routing_key: TMPL_STRING

# Describes the behavior of the alert (one of 'CRITICAL', 'WARNING', 'INFO').
[ message_type: TMPL_STRING | default = 'CRITICAL' ]

# Summary of the alerted problem.
[ entity_display_name: TMPL_STRING | default = '{{ template "victorops.default.entity_display_name" . }}' ]

# Long explanation of the alerted problem.
[ state_message: TMPL_STRING | default = '{{ template "victorops.default.state_message" . }}' ]

# The monitoring tool the state message is from.
[ monitoring_tool: TMPL_STRING | default = '{{ template "victorops.default.monitoring_tool" . }}' ]

# Configuration of the HTTP client.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Esempio 7.15: WEBHOOK_CONFIG #

È possibile utilizzare il ricevitore webhook per configurare un ricevitore generico.

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = true ]

# The endpoint for sending HTTP POST requests.
url: STRING

# Configuration of the HTTP client.
[ http_config: HTTP_CONFIG | default = global.http_config ]

Alertmanager invia richieste HTTP POST nel seguente formato JSON:

{
 "version": "4",
 "groupKey": STRING, // identifycation of the group of alerts (to deduplicate)
 "status": "<resolved|firing>",
 "receiver": STRING,
 "groupLabels": OBJECT,
 "commonLabels": OBJECT,
 "commonAnnotations": OBJECT,
 "externalURL": STRING, // backlink to Alertmanager.
 "alerts": [
   {
     "status": "<resolved|firing>",
     "labels": OBJECT,
     "annotations": OBJECT,
     "startsAt": "<rfc3339>",
     "endsAt": "<rfc3339>",
     "generatorURL": STRING // identifies the entity that caused the alert
   },
   ...
 ]
}

Il ricevitore webhook consente l'integrazione con i seguenti meccanismi di notifica:

DingTalk (https://github.com/timonwong/prometheus-webhook-dingtalk)
Bot IRC (https://github.com/multimfi/bot)
JIRAlert (https://github.com/free/jiralert)
Phabricator / Maniphest (https://github.com/knyar/phalerts)
prom2teams: inoltra le notifiche a Microsoft Teams (https://github.com/idealista/prom2teams)
SMS: supporta più provider (https://github.com/messagebird/sachet)
Bot Telegram (https://github.com/inCaller/prometheus_bot)
Trap SNMP (https://github.com/SUSE/prometheus-webhook-snmp)

Esempio 7.16: WECHAT_CONFIG #

# Whether or not to notify about resolved alerts.
[ send_resolved: BOOLEAN | default = false ]

# The API key to use for the WeChat API.
[ api_secret: SECRET | default = global.wechat_api_secret ]

# The WeChat API URL.
[ api_url: STRING | default = global.wechat_api_url ]

# The corp id used to authenticate.
[ corp_id: STRING | default = global.wechat_api_corp_id ]

# API request data as defined by the WeChat API.
[ message: TMPL_STRING | default = '{{ template "wechat.default.message" . }}' ]
[ agent_id: STRING | default = '{{ template "wechat.default.agent_id" . }}' ]
[ to_user: STRING | default = '{{ template "wechat.default.to_user" . }}' ]
[ to_party: STRING | default = '{{ template "wechat.default.to_party" . }}' ]
[ to_tag: STRING | default = '{{ template "wechat.default.to_tag" . }}' ]

7.4.2 Avvisi personalizzati #

È possibile definire condizioni di avviso personalizzate per l'invio di notifiche a un servizio esterno. Prometheus utilizza un proprio linguaggio di espressioni per definire gli avvisi personalizzati. Di seguito è riportato un esempio di regola con un avviso:

groups:
- name: example
 rules:
  # alert on high deviation from average PG count
  - alert: high pg count deviation
   expr: abs(((ceph_osd_pgs > 0) - on (job) group_left avg(ceph_osd_pgs > 0) by (job)) / on (job) group_left avg(ceph_osd_pgs > 0) by (job)) > 0.35
   for: 5m
   labels:
    severity: warning
    type: ses_default
   annotations:
   description: >
    OSD {{ $labels.osd }} deviates by more then 30% from average PG count

La clausola opzionale for specifica il tempo di attesa da parte di Prometheus tra il primo rilevamento di un nuovo elemento vettore di output espressione e il conteggio di un avviso come in fase di emissione. In questo caso, Prometheus verifica che l'avviso continui a essere attivo per 5 minuti prima di emetterlo. Gli elementi in sospeso sono attivi, ma non sono ancora in fase di emissione.

La clausola labels specifica un gruppo di etichette aggiuntive allegate all'avviso. Se sono in conflitto, vengono sovrascritte. Le etichette possono essere basate su un modello (per maggiori dettagli sulla definizione in base a un modello, consultare la Sezione 7.4.2.1, «Modelli»).

La clausola annotations specifica le etichette informative. È possibile utilizzarle per memorizzare informazioni aggiuntive, come le descrizioni degli avvisi o i collegamenti a runbook. Le annotazioni possono essere basate su un modello (per maggiori dettagli sulla definizione in base a un modello, consultare la Sezione 7.4.2.1, «Modelli»).

Per aggiungere i propri avvisi personalizzati a SUSE Enterprise Storage 6,

posizionare i file YAML con avvisi personalizzati nella directory /etc/prometheus/alerts

oppure

fornire un elenco di percorsi ai file con avvisi personalizzati nel Pillar utilizzando la chiave monitoring:custom_alerts. DeepSea Stage 2 o il comando salt SALT_MASTER state.apply ceph.monitoring.prometheus aggiunge i file di avviso nella posizione corretta.
Esempio 7.17: Aggiunta di avvisi personalizzati a SUSE Enterprise Storage #
Nel Salt master è presente un file con avvisi personalizzati in /root/my_alerts/my_alerts.yml. Se si aggiunge
monitoring: custom_alerts: - /root/my_alerts/my_alerts.yml
al file /srv/pillar/ceph/cluster/YOUR_SALT_MASTER_MINION_ID.sls, DeepSea crea il file /etc/prometheus/alerts/my_alerts.yml e riavvia Prometheus.

7.4.2.1 Modelli #

È possibile utilizzare modelli per i valori di annotazioni ed etichette. La variabile $labels Include le coppie chiave/valore etichetta di un'istanza di avviso, mentre $value contiene il valore sottoposto a valutazione di un'istanza di avviso.

Il seguente esempio inserisce il valore e l'etichetta di un elemento in fase di emissione:

{{ $labels.LABELNAME }}
{{ $value }}

7.4.2.2 Ispezione degli avvisi al runtime #

Se è necessario verificare quali avvisi sono attivi, sono disponibili diverse opzioni:

Andare alla scheda Alerts di Prometheus. La scheda mostra i gruppi di etichette esatti per i quali sono attivi gli avvisi definiti. Inoltre, Prometheus memorizza le serie temporali sintetiche per gli avvisi in sospeso e in fase di emissione. Le serie hanno il seguente formato:
```
ALERTS{alertname="ALERT_NAME", alertstate="pending|firing", ADDITIONAL_ALERT_LABELS}
```
Il valore di esempio è 1 se l'avviso è attivo (in sospeso o in fase di emissione). La serie è contrassegnata con "stale" se l'avviso è inattivo.
Nell'interfaccia web di Prometheus, all'indirizzo URL http://PROMETHEUS_HOST_IP:9090/alerts, ispezionare gli avvisi e il relativo stato (INACTIVE, PENDING o FIRING).
Nell'interfaccia web di Alertmanager, all'indirizzo URL http://:PROMETHEUS_HOST_IP9093/#/alerts, ispezionare gli avvisi e, se necessario, disattivarli.

7.4.3 Ricevitore delle trap SNMP #

Se si desidera ricevere notifiche sugli avvisi di Prometheus tramite trap SNMP, è possibile installare il ricevitore di trap SNMP Prometheus Alertmanager tramite DeepSea. A tale scopo, è necessario abilitarlo utilizzando la chiave monitoring:alertmanager_receiver_snmp:enabled. La configurazione del ricevitore deve essere impostata utilizzando la chiave monitoring:alertmanager_receiver_snmp:config. DeepSea Stage 2 o il comando salt SALT_MASTER state.apply ceph.monitoring.alertmanager installano e configurano il ricevitore nella posizione appropriata.

Esempio 7.18: Configurazione delle trap SNMP #

monitoring:
 alertmanager:
   receiver:
      snmp:
        enabled: True
        config:
          host: localhost
          port: 9099
          snmp_host: snmp.foo-bar.com
          snmp_community: private
          metrics: True

Fare riferimento al manuale del ricevitore all'indirizzo https://github.com/SUSE/prometheus-webhook-snmp#global-configuration-file. per maggiori dettagli sulle opzioni di configurazione.

Stampa pagina