Service oriented alerting

SERVICE ORIENTEDSERVICE ORIENTED
ALERTINGALERTING
Vladimir Dobriakov Daniel Fuchs
1infrastructure-as-code.de @enterprise_geek // synyx.de @honnel

HELLO #AWSUGCGN!HELLO #AWSUGCGN!

GETTING STARTEDGETTING STARTED

DEFINITION OF "DONE"DEFINITION OF "DONE"
So ware baut
Unit- und Integrationstest laufen

So ware baut
Akzeptanztests für den fachlichen Usecase
Tests für Performance

So ware baut
Die So ware wird verwendet ;-)

So ware baut
Die So ware wird verwendet ;-)
Usecase & Performance werden in Produktion laufend überwacht

FEHLERSITUATIONENFEHLERSITUATIONEN

FEHLERKATEGORIENFEHLERKATEGORIEN

Known Knowns: Fehlersituation zum Entwicklungszeitpunkt bekannt

Unknown Knowns: Fehlersituation war anderen klar

Known Unknowns: Mögliche Fehlersituation, Schwellwerte unklar

Known Unknowns: Mögliche Fehlersituation, Schwellwerte unklar
Unknown Unknowns: Unbekannte Fehlersituation

{UN}KNOWN {UN}KNOWNS{UN}KNOWN {UN}KNOWNS
Known
Knowns
Unknown
Knowns
Known
Unknowns
Unknown
Unknowns
Monitoring &
Alerting
Health Checks
Logging
ERROR/
WARN
Metriken Tracing
Logging
INFO/
DEBUG

. MONITORINGMONITORING
Laufzeitmetriken werden erfasst (Antwortzeiten, Durchsatz, fachliche
Metriken)

Metriken)
Beobachtung durch einen geübten Metriken-Interpretierer, der bei
Bedarf Alarm schlägt

Metriken)
Beobachtung durch einen geübten Metriken-Interpretierer, der bei
Bedarf Alarm schlägt
ALTERNATIVE: IN SOFTWARE ABGEBILDETALTERNATIVE: IN SOFTWARE ABGEBILDET

SLI SLO SLASLI SLO SLA
SLI: Service Level Indicator
SLO: Service Level Objectives*
SLA: Service Level Agreement*
*hier PO/fachlicher Ansprechpartner involviert

BEISPIEL 1. "COUPON EINLÖSEN"BEISPIEL 1. "COUPON EINLÖSEN"
SLI: Antwortszeiten für HTTP Requests
SLO: Antwortszeiten liegen unter 100ms
SLA: Dieses Ziel ist erfüllt für 99,5% der Requests

BEISPIEL 2. "DURCHSATZ"BEISPIEL 2. "DURCHSATZ"
SLI: Verarbeitete Requests pro Sekunde?
SLO: ???
SLA: ???

BEISPIEL 2. "DURCHSATZ"BEISPIEL 2. "DURCHSATZ"
- record: service:requests:persecond
expr: sum (rate(http_server_requests_count{method="POST", url="/receipts"}[1m]))
- record: expected_wait:seconds
expr: (service:requests:persecond / (receipts_in_queue +1)) # +1 prevent div-by-zero
- alert: Waiting too long
expr: expected_wait > 1800

BEISPIEL 3. KEINE KUNDEN AN DER KASSEBEISPIEL 3. KEINE KUNDEN AN DER KASSE
max(queueLength): 0
max(requestTime): 0

ANOMALY DETECTIONANOMALY DETECTION
"Uns geht es gut aber wir bekommen keine Daten"

ANOMALY DETECTION - F'ANOMALY DETECTION - F'
- record: find_coupon:persecond
expr: sum by(key) (rate(counter_find_coupon[1m]))
- record: find_coupon:decline
expr: ((find_coupon:persecond offset 5m) / (find_coupon:persecond +1))
- alert: sudden decline in transactions
expr: max_over_time(find_coupon:decline[2h]) > 10
AND find_coupon:persecond < 0.5

FEIERABEND IST SICHER…FEIERABEND IST SICHER…

…IN DER BADEWANNE…IN DER BADEWANNE

HANDS ON!HANDS ON!

ALERTING ARCHITEKTUR I.ALERTING ARCHITEKTUR I.
App
App
Datasource
Alertmanager
Alertmanager
OpsGenieApp
Prometheus
Prometheus
Grafana

ALERTING ARCHITEKTUR II.ALERTING ARCHITEKTUR II.
Eigene Metriken
3rd Party
Mircometer
Prometheus
Endpoint
Prometheus
App
Meter Registry

SPRING BOOT & MICROMETERSPRING BOOT & MICROMETER
pom.xml
application.properties
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
management.endpoints.web.exposure.include=…,prom

AUFBAU METRIKAUFBAU METRIK
metric_name{tag="tag value"} value

…/ACTUATOR/PROMETHEUS…/ACTUATOR/PROMETHEUS
# HELP http_server_requests_max
# TYPE http_server_requests_max gauge
http_server_requests_max{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/prom
http_server_requests_max{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/heal
# HELP http_server_requests
# TYPE http_server_requests summary
http_server_requests_count{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/pr
http_server_requests_count{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/he
http_server_requests_count{exception="None",method="GET",outcome="CLIENT_ERROR",status="401",uri="root",}

BEISPIEL: EIGENE METRIKBEISPIEL: EIGENE METRIK
Gauge.builder("receipts_in_queue",
someRepository,
SomeRepository::count)
.description("Number of unprocessed receipts in queue")
.tag("key", "value")
.register(meterRegistry);

METRIK ALA CARTEMETRIK ALA CARTE
Counter: Zähler, wird nur inkrementiert
Gauge: Messwert welcher hoch- und runtergezählt werden kann
Timer: Dauer von Aufrufen
DistributionSummary: Verteilung von Ereignissen
Percentile: Vorberechnet, z. Bsp. 99,5% der Requests sind schneller als
100 ms
Histogramm: Buckets die Aufschluss über die Verteilung im nachhinein
liefern

PROMETHEUSPROMETHEUS
App
App
Datasource
Alertmanager
Alertmanager
OpsGenieApp
Grafana
Prometheus
Prometheus

PROMETHEUS - SCRAPE CONFIGPROMETHEUS - SCRAPE CONFIG
prometheus.yml.j2
scrape_configs:
- job_name: 'myservice'
scheme: https
metrics_path: /actuator/prometheus
static_configs:
- targets:
{% for h in groups['myservice'] | current_stage(inventory_hostname) %}
- '{{ h }}:8443'
{% endfor %}
labels:
stage: "{{ inventory_hostname | stage }}"

PROMETHEUS - RULES CONFIGPROMETHEUS - RULES CONFIG
groups:
- name: errors
rules:
- record: service:requests:persecond
expr: sum by(key) (rate(http_server_requests_count{job="myservice"}[1m]))
- record: service:errors:persecond
expr: sum by(key) (rate(http_server_requests_count{job="myservice",event!="success
- record: service:error_ratio
expr: service:errors:persecond / service:requests:persecond
- alert: ErrorRatioTooHigh
…

PROMETHEUS - RULES CONFIGPROMETHEUS - RULES CONFIG
- alert: ErrorRatioTooHigh
expr: service:error_ratio > 0.01 AND service:errors:persecond > 10
for: 5m
labels:
priority: P1
annotations:
summary: "Error ratio on {{ $labels.key }} exceeds threshold and there is a sign
description: >
Error ratio on {{ $labels.key }} is at {{ $value }}.
http://prometheus…:9090{{ graphLink "service:error_ratio" }}

ALERTMANAGERALERTMANAGER
App
App
Datasource
Alertmanager
Alertmanager
OpsGenieApp
Grafana
Prometheus
Prometheus

ALERTMANAGERALERTMANAGER
route:
receiver: opsgenie-integration
group_wait: 1s # reduce delay for faster feedback
group_by: ['stage', 'alertname', 'job', 'priority']
receivers:
- name: opsgenie-integration
opsgenie_configs:
- api_key: "{{ opsgenie_prometheus_api_key }}"
# In the application specific rule definitions set `labels:` `priority:`
# to create OpsGenie alert with a desired priority.
# Default is `P3`.
{% if inventory_hostname | stage == 'lxprod' %}
priority: P1
{% else %}
priority: P5
{% endif %}
message: '[{{ inventory_hostname | stage }}] {{ '{{' }} template "message" . {{
tags: '{{ inventory_hostname | stage }}, {{ '{{' }} template "tags" . {{ '}}' }}

PROMETHEUS TOOLINGPROMETHEUS TOOLING
Validierung von Prometheus Config, Rules lokal möglich
Metric Endpoints können ebenfalls validiert werden
Unit-Test Support

PROMETHEUS UNIT TESTINGPROMETHEUS UNIT TESTING
RULERULE
groups:
- name: example
rules:
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: P1
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down fo

RULE TESTINGRULE TESTING
rule_files:
- alerts.yml
tests:
- interval: 1m
# Series data.
# This uses expanding notation:
# 'a+bxc' becomes 'a a+b a+(2*b) a+(3*b) … a+(c*b)'
# 'a-bxc' becomes 'a a-b a-(2*b) a-(3*b) … a-(c*b)'
input_series:
- series: 'up{job="prometheus", instance="localhost:9090"}'
values: '1+0x6 0+0x7' # 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
# Unit test for alerting rules.
alert_rule_test:
- eval_time: 12m
alertname: InstanceDown
exp_alerts:
- exp_labels:
severity: P1
instance: localhost:9090
job: prometheus
exp_annotations:
summary: "Instance localhost:9090 down"
description: "localhost:9090 of job prometheus has been down for

PROMQL EXPRESSION TESTINGPROMQL EXPRESSION TESTING
tests:
- interval: 1m
# Series data.
# This uses expanding notation:
# 'a+bxc' becomes 'a a+b a+(2*b) a+(3*b) … a+(c*b)'
# 'a-bxc' becomes 'a a-b a-(2*b) a-(3*b) … a-(c*b)'
input_series:
- series: 'receipts_in_queue{job="prometheus", instance="localhost:9090"}'
values: '10+10x2 30+20x5' # 10 20 30 30 50 70 90 110 130
promql_expr_test:
- expr: receipts_in_queue > 5
eval_time: 4m
exp_samples:
- labels: 'receipts_in_queue{job="prometheus",instance="localhost:9090
value: 50

Möglichkeit Alerts zu testen
Input Serien können definiert werden
Sowohl PromQL als auch Alert testbar
Records helfen beim mocken

FAZITFAZIT
Was zählt: Wie verhält sich die So ware für den Kunden.
Denkt zuerst an Alerting! Instrumentation und Monitoring sind nur Mittel
zum Zweck.
Code-basierter Ansatz von Prometheus und Alertmanager ermöglichen
viele Vorteile.

DANKE!DANKE!
Daniel Fuchs Vladimir Dobriakov
@honnel @enterprise_geek
synyx.de infrastructure-as-code.de

BILDERBILDER
Credits:
"Beigel Bake at Brick Lane" von
,
"Empty Seasonal Area", von ,
von
von
von ,
von ,
von ,
https://www.flickr.com/photos/madmetal/ CC License
https://www.flickr.com/photos/walmart3/
CC License
"Donald Rumsfeld Unknown Unknowns !" Ali
Dashboard, gauge, meter, speed icon Malik Abimanyu
Heartbeat icon Dave Gandy SIL Open Font License
Map icon Ionicons MIT
Notes, record, stationery, taking, writing icon Eucalyp Studio
Creative Commons (Attribution 3.0 Unported)

…UND IN DER PRAXIS?…UND IN DER PRAXIS?
Bekommen wir etwas rein?
Haben wir einen Stausituation?
Wird zu viel abgelehnt?
Wann war der letzte Import?
Antwortzeiten niedrig genug?

Service oriented alerting

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Service oriented alerting

Ähnlich wie Service oriented alerting (20)

Service oriented alerting