Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
実践オブザーバビリティ
Satoru Takeuchi
PRO
March 11, 2022
Technology
2
700
実践オブザーバビリティ
Observability Conference 2022の発表スライドです
https://event.cloudnativedays.jp/o11y2022/talks/1357
Satoru Takeuchi
PRO
March 11, 2022
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
仮想記憶 ~確認編~
sat
PRO
0
25
C言語を知らない人がびっくりしそうなC言語の特徴 ~変数定義編~
sat
PRO
1
52
仮想記憶 ~概念編~
sat
PRO
2
39
ゆく年くる年2022
sat
PRO
0
170
Capacity-aware Dynamic Volume Provisioning For LVM-based Local Storage
sat
PRO
2
190
Rook/Cephストレージシステムを開発しながらupstream OSSに成果を還元してきた取り組み
sat
PRO
2
500
俺とサブウーファー
sat
PRO
0
150
Revealing BlueStore Corruption Bugs in Containerized Ceph Clusters
sat
PRO
1
120
『Linuxのしくみ』増補改訂版発売記念イベント ~ Linuxのしくみのしくみ ~
sat
PRO
2
680
Other Decks in Technology
See All in Technology
創業1年目のスタートアップでAWSコストを抑えるために取り組んでいること / How to Keep AWS Costs Down at a Startup
yuj1osm
3
2.2k
CSS Variable をもっと活用する / Kyoto.js 18
spring_raining
2
850
Stripe / Okta Customer Identity Cloud(旧Auth0) の採用に至った理由 〜モリサワの SaaS 戦略〜
tomuro
0
130
CUEとKubernetesカスタムオペレータを用いた新しいネットワークコントローラをつくってみた
hrk091
1
280
オブザーバビリティのベストプラクティスと弥生の現状 / best practices for observability and YAYOI’s current state
yayoi_dd
0
100
AWS re:Invent 2022で発表された新機能を試してみた ~Cloud OperationとSecurity~ / New Cloud Operation and Security Features Announced at AWS reInvent 2022
yuj1osm
1
210
Bill One 開発エンジニア 紹介資料
sansantech
PRO
0
120
Logbii(ログビー) 会社紹介
logbii
0
140
立ち止まっても、寄り道しても / even if I stop, even if I take a detour
katoaz
0
630
Raspberry Pi Camera 3 介紹
piepie_tw
PRO
0
150
データベースの発表には RDBMS 以外もありますよ
maroon1st
0
240
オンプレk8sとEKSの並行運用の実際
ch1aki
0
280
Featured
See All Featured
Facilitating Awesome Meetings
lara
33
4.6k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
101
6.2k
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
128
8.8k
Building a Modern Day E-commerce SEO Strategy
aleyda
6
4.5k
Designing for Performance
lara
600
65k
Building Your Own Lightsaber
phodgson
96
4.9k
Building an army of robots
kneath
301
40k
Embracing the Ebb and Flow
colly
75
3.6k
A Modern Web Designer's Workflow
chriscoyier
689
180k
The Invisible Customer
myddelton
113
12k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
349
27k
Making Projects Easy
brettharned
102
4.8k
Transcript
実践オブザーバビリティ プロダクショングレード監視/ログ基盤とその実用例 Mar. 11th, 2022 サイボウズ ストレージチーム sat 1
もくじ 2 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例
もくじ 3 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例
オブザーバビリティとは ▌システムが外部提供する情報から内部状態を観測できること ▌オブザーバビリティが高いシステムの例 ⚫サービスを提供できているかを観測できる ⚫サービスのレスポンス時間を観測できる ⚫ストレージの容量が足りているかを観測できる 4
システムが外部提供する情報 ▌メトリクス: システムの状態を定量化したもの ⚫例: リクエストが一秒あたりに完了した数 ▌ログ: システムに起きたことを記録したもの ⚫例: “<時刻> request
completed in 0.3 secs”のような文字列 5
オブザーバビリティを高める手段 ▌メトリクス/ログの集約 ▌集約したメトリクスの監視(モニタリング) ▌監視によって検出した異常を通知(アラート) ▌メトリクス/ログの分析、可視化 6
もくじ 7 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例
サイボウズで開発中のインフラ ▌オンプレのKubernetes(K8s)クラスタ ▌マルチテナント ⚫ 1つのK8sクラスタにあらゆるアプリ(Pod)が同居 8 …
監視/ログ基盤に採用したソフトウェア ▌監視基盤 ⚫VictoriaMetrics: メトリクスの集約、監視 ⚫Alertmanager: 通知 ▌ログ基盤 ⚫Loki: ログの集約 ▌可視化、分析
⚫Grafana: ダッシュボード、VictoriaMetricsとLokiへのクエリ発行 9
インフラ構成図 10 Cephクラスタ HDD node HDD ディスク アプリ Loki VictoriaMetrics
VictoriaMetrics Grafana AlertManager AlertManager K8sクラスタ データ保存
メトリクス/ログの集約、監視 11 Cephクラスタ HDD node HDD ディスク アプリ Loki VictoriaMetrics
VictoriaMetrics Grafana ログ集約 メトリクス集約、監視 メトリクス集約、監視 AlertManager AlertManager K8sクラスタ データ保存
有事の際は管理者に通知 12 Cephクラスタ HDD node HDD ディスク アプリ Loki VictoriaMetrics
VictoriaMetrics Grafana 通知 通知 AlertManager AlertManager K8sクラスタ データ保存 やるぞ!
状況確認 13 Cephクラスタ HDD node HDD ディスク アプリ Loki VictoriaMetrics
VictoriaMetrics Grafana ダッシュボードを見る AlertManager AlertManager K8sクラスタ データ保存
トラブルシューティング 14 Cephクラスタ HDD node HDD ディスク アプリ Loki VictoriaMetrics
VictoriaMetrics Grafana クエリ発行&結果を分析 クエリ発行 クエリ発行 クエリ発行 AlertManager AlertManager K8sクラスタ データ保存
その他Grafanaへのアクセス契機 ▌定期的なダッシュボード確認 ⚫前回確認時以降、変わったところがないか ⚫「何が正常か」を知るのに役立つ ▌インフラユーザからの連絡 ⚫できればなくしたい ⚫問題解決後に、自動検出できるよう改善を検討 15
ダッシュボードの例(Cephクラスタ) 16
Cephクラスタの容量とIOPS 17
成果は全てOSSとして公開 ▌監視基盤 ⚫https://github.com/cybozu-go/neco-apps/tree/main/monitoring ▌ログ基盤 ⚫https://github.com/cybozu-go/neco-apps/tree/main/logging 18
もくじ 19 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例
工夫点: VictoriaMetricの採用 ▌Prometheus互換 ⚫様々な外部ツールが対応 ▌組み込み機能によってHA構成可能 ⚫構成がシンプルにできる ▌データストアが長期保存向け 20
工夫点: 2つの監視基盤 ▌Cephクラスタの障害発生時にCephの情報を得られる 21 Cephクラスタ HDD node HDD ディスク VictoriaMetrics
VictoriaMetrics アプリ メトリクス集約、監視 メトリクス集約、監視 障害発生! × データ保存 〇 データ保存
工夫点: 通知の分類 ▌通知を2種類に分け、通知先を変更 ▌効果 ⚫頻繁な通知によるメンバの疲弊を回避 ⚫非critical通知は調査開始後に見られる 22 VictoriaMetrics Criticalな通知 Slack
Critical チャネル Warning チャネル 非Criticalな通知 やるぞ!
課題: LokiがCephに依存している ▌Cephクラスタの障害発生時にlokiにアクセスできない ▌Cephクラスタ専用のLokiを導入予定 23 Cephクラスタ HDD node HDD ディスク
Loki アプリ ログ集約、監視 障害発生! × データ保存
通知が不親切 ▌通知受信後にどうすればいいかわからない ⚫チームメンバーの暗黙知に頼っている ▌対策案: 通知にnext actionを書く 24 VictoriaMetrics ストレージ残量が20%を下回りました だから何?
通知 VictoriaMetrics ストレージ残量が20%を下回ったので マニュアルのX.Y節通り対処してください やるぞ! 通知
もくじ 25 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例
事例: オブジェクトストレージのアクセス障害 ▌前提 ⚫CephはRGWというオブジェクトストレージを提供 ▌問題 ⚫RGWにアクセスできなくなった ▌検出方法 ⚫RGW podの異常終了を示す通知が定期的に発生 26
ダッシュボードの確認 ▌アラート発生時からオブジェクト数が増えていない 27 オブジェクト数→ 時間→ オブジェクト数→ 時間→ 正常時 問題発生時
原因の候補 ▌RGW Pod自らが終了 ⚫何らかのエラーによって異常終了 ▌外部からの強制終了 ⚫例: K8sのprobeへの無応答が続くとシグナルによって強制終了 28
切り分け ▌RGW Pod強制終了時のログを見れば何かわかるはず ⚫RGW Podが自ら終了: エラーログが残る ⚫外部から強制終了: シグナル受信ログが残る ▌幸運: Loki上の直近のログだけは見られる
⚫LokiのストレージはCeph上に保存 ⚫古いログはRGWに保存 ⚫直近のデータはブロックデバイスに保存 29
RGW podのログを確認 30
ログを表示する期間 31
Lokiに発行するクエリ(LogQL) 32
全RGW Podのログをまとめて表示 33
どのPodのログかをどうやって特定? 34 ログの各行をクリックすると…
行をクリックすると詳細情報が出る 35
出力するログを絞っていく ▌旧 ▌新 ▌出力期間も絞る 36
分析結果 ▌各RGW podは以下ログの出力&終了を繰り返していた NOTICE: resharding operation on bucket index detected,
blocking … received signal: Terminated from Kernel …) UID: 0 … NOTICE: resharding operation on bucket index detected, blocking … received signal: Terminated from Kernel …) UID: 0 … 37 “resharding”という処理が怪しそう シグナルによって終了
仮説 ▌Probe失敗によって強制終了させられていた ▌ログに残っていたreshardingという処理が怪しい ▌次のようなことを繰り返していたのでは? 1. resharding処理中はRGW podのprobeが失敗 2. Probeの失敗を繰り返したのでK8sが異常終了させる 3.
resharding処理が最初からやり直しに 38
その後の流れ ▌仮説は正しかった ⚫K8sのlivenessProbeが失敗し続けていた ▌詳細は別スライドを参照 ⚫ https://speakerdeck.com/sat/kubernetesshi-jian-toraburusiyuteingu 39
振り返り: よかったこと ▌監視と通知によって問題を早期検出できた ⚫無ければユーザからのクレームまで気づけなかった可能性も ▌ダッシュボードにより問題の概要が一目でわかった ▌メトリクスとログからトラシューの仮説が立てられた ⚫仮説の検証にも役立った 40
振り返り: 改善すべきこと ▌Cephクラスタ専用のLokiが欲しい ▌今回は偶然に助けられた ⚫直近のログにアクセスできなければ調査はさらに難航した ▌次はこうはいかないかもしれない 41
これまでの経験を踏まえたTIPS ▌オブザーバビリティ向上の肝は改善の繰り返し ⚫まずは単純な監視/ログ基盤を作る ⚫使い込んで、不備があれば改善 ▌定期的なダッシュボードのチェック重要 ⚫「何が正常か」が肌感覚でわかる ▌一度監視/ログ基盤を導入したら無い状態が想像できなくなる ⚫問題検知/トラシュー速度が全く違う ⚫可用性向上に投資を惜しまないほうがいい 42
おわり 43