Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
今 SLI/SLO の監視をするなら Sloth が良さそうという話
Search
kanata
August 04, 2022
Technology
2
970
今 SLI/SLO の監視をするなら Sloth が良さそうという話
3-shake SRE Tech Talk #4 (
https://3-shake.connpass.com/event/253028/
) の登壇資料です。LT です。
kanata
August 04, 2022
Tweet
Share
More Decks by kanata
See All by kanata
ISUCON で使えるツールを作った
shotakitazawa
0
1.2k
CloudNative Days を支える CI/CD ワークフローの変遷
shotakitazawa
2
1.7k
OpenFlow について
shotakitazawa
0
67
Kubernetes で Pod ができるまで
shotakitazawa
3
930
Spinnaker で Blue-Green Deployment やってみた
shotakitazawa
1
1.3k
Other Decks in Technology
See All in Technology
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
430
Platform Engineering for Software Developers and Architects
syntasso
1
520
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
210
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
140
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
300
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
140
Terraform Stacks入門 #HashiTalks
msato
0
360
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
arthur1
5
480
IBC 2024 動画技術関連レポート / IBC 2024 Report
cyberagentdevelopers
PRO
1
110
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
100
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Thoughts on Productivity
jonyablonski
67
4.3k
Typedesign – Prime Four
hannesfritz
40
2.4k
Adopting Sorbet at Scale
ufuk
73
9.1k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Music & Morning Musume
bryan
46
6.2k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Producing Creativity
orderedlist
PRO
341
39k
Transcript
今 SLI/SLO の監視をするなら Sloth が良さそうという話 北澤 祥太 / kanata 1
北澤 祥太 / kanata / かなた @kanatakita ShotaKitazawa 趣味: ラーメン、スノボ、自宅鯖構築、イベント裏方
最近: Kubernetes custom controller の実装など $ whoami 2 よく使う アイコン
今日話すこと・話さないこと 話すこと • Sloth というツールで何が出来るのか • Sloth を使うと何が嬉しいのか 話さないこと •
Sloth を実際のプロダクト開発・運用に利用する話 ◦ SLO Review 等のプロセスについて ◦ 特定のプロダクトの特性起因の苦労話について ◦ etc. • 自作の自動化ツールについてのあれこれ 3
今日話すこと・話さないこと 話すこと • sloth というツールで何が出来るのか • sloth を使うと何が嬉しいのか 話さないこと •
sloth を実際のプロダクト開発・運用に利用する話 ◦ SLO Review 等のプロセスについて ◦ 特定のプロダクトの特性起因の苦労話について ◦ etc. • 自作の自動化ツールについてのあれこれ 4 🙇 🙇 🙇
Sloth - Easy and simple Prometheus SLO generator 一言で表すと •
yaml を書くだけで、いい感じの Alerting Rules を出力してくれたり Grafana Dashboard で SLI/SLO をモニタリングできるようになるツール 前提 • Prometheus / Grafana を利用していること • SLI の元となるメトリクスが取得できていること https://github.com/slok/sloth 5
Sloth の設定例 (1/2) 6 https://github.com/slok/sloth/blob/v0.10.0/examples/getting-started.yml version: "prometheus/v1" service: "myservice" labels:
owner: "myteam" repo: "myorg/myservice" tier: "2" slos: - name: "requests-availability" objective: 99.9 description: "Common SLO based on availability for HTTP request responses." sli: events: error_query: sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[{{.window}}])) total_query: sum(rate(http_request_duration_seconds_count{job="myservice"}[{{.window}}])) (snip…) {{.window}} にはデフォルトで 5m, 30m, 1h, 2h, 6h, 1d, 3d, 30d が入る 生成される Rules に付与するラベルを指定 目標値を指定 total, error 条件となるクエリを定義
Sloth の設定例 (2/2) 7 https://github.com/slok/sloth/blob/v0.10.0/examples/getting-started.yml slos: - (snip…) alerting: name:
MyServiceHighErrorRate labels: category: "availability" annotations: summary: "High error rate on 'myservice' requests responses" page_alert: labels: severity: pageteam routing_key: myteam ticket_alert: labels: severity: "slack" slack_channel: "#alerts-myteam" 生成される Alerting Rules に付与するラベルを指定 Page レベルの Alerting Rules に付与するラベルを指定 Ticket レベルの Alerting Rules に付与するラベルを指定
Recording Rules の生成 8 sloth.yml rules.yml $ sloth generate -i
sloth.yml --- # Code generated by Sloth (v0.10.0): https://github.com/slok/sloth. # DO NOT EDIT. groups: - name: sloth-slo-sli-recordings-myservice-requests-availability rules: - record: slo:sli_error:ratio_rate5m expr: | (sum(rate(http_request_duration_seconds_count{ job="myservice",code=~"(5..|429)"}[5m]))) / (sum(rate(http_request_duration_seconds_count{ job="myservice"}[5m]))) labels: owner: myteam repo: myorg/myservice sloth_id: myservice-requests-availability sloth_service: myservice sloth_slo: requests-availability sloth_window: 5m tier: "2" - record: slo:sli_error:ratio_rate30m (snip…)
SLO のアラーティング • 以下の閾値の Multiwindow, Multi-Burn-Rate のアラートルールを自動生成 • What advantage
of Multiwindow, Multi-Burn-Rate Alerts? ◦ エラーバジェットの消費速度の傾き (Burn Rate) を用いるため精度が高い ◦ システムを復旧させたのにアラートが止まない問題 (Burn Rate ベースのアラートの特徴) を軽減 詳しくは https://sre.google/workbook/alerting-on-slos/ 9 Severity Long window Short window Burn rate Page 1 day 2 hours 1 3 days 6 hours 1 Ticket 1 hour 5 minutes 14.4 6 hours 30 minutes 6 time window が 1 日, 2 時間のどちらに おいても burn rate が 1 を超える場合に発火
Grafana Dashboard • Sloth が出力する Recording Rules のみを参照する Grafana Dashboard
が提供されている 10 https://sloth.dev/introduction/dashboards/ 現在の Burn rate 残りの Error Budget SLI の推移 Burn Rate の推移 Error Budget の burn down chat
Sloth による一元管理 before after 11 dashboard.json rules.yaml sloth.yml dashboard.json rules.yaml
👍 シングルバイナリで可搬性が高い 👍 validate サブコマンドがあるので CI に組み込みやすい
痒いところに手が届く機能 Recording Rules 用クエリの最適化 • time window の大きい Recording Rule
は、元となるメトリクスの rate 30d を取らず time window の小さい Recording Rule の rate 30d を取る ▪ 多量のデータポイントの読み込まずに算出可能 様々な入力/出力フォーマットに対応 • v0.10.0 現在、以下に対応 ◦ 入力: default, K8s CustomResource, OpenSLO ◦ 出力: Prometheus Recording Rules, K8s CustomResource (for Prometheus Operator) SLI 算出のためのプラグイン機構 • https://github.com/slok/sloth-common-sli-plugins 12
Have a good SRE-Life with Sloth! 13