実践オブザーバビリティ

Slide 1

Slide 1 text

実践オブザーバビリティプロダクショングレード監視/ログ基盤とその実用例 Mar. 11th, 2022 サイボウズストレージチーム sat 1

Slide 2

Slide 2 text

もくじ 2 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例

Slide 3

Slide 3 text

もくじ 3 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例

Slide 4

Slide 4 text

オブザーバビリティとは ▌システムが外部提供する情報から内部状態を観測できること ▌オブザーバビリティが高いシステムの例 ⚫サービスを提供できているかを観測できる ⚫サービスのレスポンス時間を観測できる ⚫ストレージの容量が足りているかを観測できる 4

Slide 5

Slide 5 text

システムが外部提供する情報 ▌メトリクス: システムの状態を定量化したもの ⚫例: リクエストが一秒あたりに完了した数 ▌ログ: システムに起きたことを記録したもの ⚫例: “<時刻> request completed in 0.3 secs”のような文字列 5

Slide 6

Slide 6 text

オブザーバビリティを高める手段 ▌メトリクス/ログの集約 ▌集約したメトリクスの監視(モニタリング) ▌監視によって検出した異常を通知(アラート) ▌メトリクス/ログの分析、可視化 6

Slide 7

Slide 7 text

もくじ 7 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例

Slide 8

Slide 8 text

サイボウズで開発中のインフラ ▌オンプレのKubernetes(K8s)クラスタ ▌マルチテナント ⚫ 1つのK8sクラスタにあらゆるアプリ(Pod)が同居 8 …

Slide 9

Slide 9 text

監視/ログ基盤に採用したソフトウェア ▌監視基盤 ⚫VictoriaMetrics: メトリクスの集約、監視 ⚫Alertmanager: 通知 ▌ログ基盤 ⚫Loki: ログの集約 ▌可視化、分析 ⚫Grafana: ダッシュボード、VictoriaMetricsとLokiへのクエリ発行 9

Slide 10

Slide 10 text

インフラ構成図 10 Cephクラスタ HDD node HDD ディスクアプリ Loki VictoriaMetrics VictoriaMetrics Grafana AlertManager AlertManager K8sクラスタデータ保存

Slide 11

Slide 11 text

メトリクス/ログの集約、監視 11 Cephクラスタ HDD node HDD ディスクアプリ Loki VictoriaMetrics VictoriaMetrics Grafana ログ集約メトリクス集約、監視メトリクス集約、監視 AlertManager AlertManager K8sクラスタデータ保存

Slide 12

Slide 12 text

有事の際は管理者に通知 12 Cephクラスタ HDD node HDD ディスクアプリ Loki VictoriaMetrics VictoriaMetrics Grafana 通知通知 AlertManager AlertManager K8sクラスタデータ保存やるぞ！

Slide 13

Slide 13 text

状況確認 13 Cephクラスタ HDD node HDD ディスクアプリ Loki VictoriaMetrics VictoriaMetrics Grafana ダッシュボードを見る AlertManager AlertManager K8sクラスタデータ保存

Slide 14

Slide 14 text

トラブルシューティング 14 Cephクラスタ HDD node HDD ディスクアプリ Loki VictoriaMetrics VictoriaMetrics Grafana クエリ発行&結果を分析クエリ発行クエリ発行クエリ発行 AlertManager AlertManager K8sクラスタデータ保存

Slide 15

Slide 15 text

その他Grafanaへのアクセス契機 ▌定期的なダッシュボード確認 ⚫前回確認時以降、変わったところがないか ⚫「何が正常か」を知るのに役立つ ▌インフラユーザからの連絡 ⚫できればなくしたい ⚫問題解決後に、自動検出できるよう改善を検討 15

Slide 16

Slide 16 text

ダッシュボードの例(Cephクラスタ) 16

Slide 17

Slide 17 text

Cephクラスタの容量とIOPS 17

Slide 18

Slide 18 text

成果は全てOSSとして公開 ▌監視基盤 ⚫https://github.com/cybozu-go/neco-apps/tree/main/monitoring ▌ログ基盤 ⚫https://github.com/cybozu-go/neco-apps/tree/main/logging 18

Slide 19

Slide 19 text

もくじ 19 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例

Slide 20

Slide 20 text

工夫点: VictoriaMetricの採用 ▌Prometheus互換 ⚫様々な外部ツールが対応 ▌組み込み機能によってHA構成可能 ⚫構成がシンプルにできる ▌データストアが長期保存向け 20

Slide 21

Slide 21 text

工夫点: 2つの監視基盤 ▌Cephクラスタの障害発生時にCephの情報を得られる 21 Cephクラスタ HDD node HDD ディスク VictoriaMetrics VictoriaMetrics アプリメトリクス集約、監視メトリクス集約、監視障害発生! × データ保存〇データ保存

Slide 22

Slide 22 text

工夫点: 通知の分類 ▌通知を2種類に分け、通知先を変更 ▌効果 ⚫頻繁な通知によるメンバの疲弊を回避 ⚫非critical通知は調査開始後に見られる 22 VictoriaMetrics Criticalな通知 Slack Critical チャネル Warning チャネル非Criticalな通知やるぞ！

Slide 23

Slide 23 text

課題: LokiがCephに依存している ▌Cephクラスタの障害発生時にlokiにアクセスできない ▌Cephクラスタ専用のLokiを導入予定 23 Cephクラスタ HDD node HDD ディスク Loki アプリログ集約、監視障害発生! × データ保存

Slide 24

Slide 24 text

通知が不親切 ▌通知受信後にどうすればいいかわからない ⚫チームメンバーの暗黙知に頼っている ▌対策案: 通知にnext actionを書く 24 VictoriaMetrics ストレージ残量が20%を下回りましただから何? 通知 VictoriaMetrics ストレージ残量が20%を下回ったのでマニュアルのX.Y節通り対処してくださいやるぞ！通知

Slide 25

Slide 25 text

もくじ 25 ▌前提知識 ▌サイボウズの監視/ログ基盤 ▌工夫点と課題 ▌実用例

Slide 26

Slide 26 text

事例: オブジェクトストレージのアクセス障害 ▌前提 ⚫CephはRGWというオブジェクトストレージを提供 ▌問題 ⚫RGWにアクセスできなくなった ▌検出方法 ⚫RGW podの異常終了を示す通知が定期的に発生 26

Slide 27

Slide 27 text

ダッシュボードの確認 ▌アラート発生時からオブジェクト数が増えていない 27 オブジェクト数→ 時間→ オブジェクト数→ 時間→ 正常時問題発生時

Slide 28

Slide 28 text

原因の候補 ▌RGW Pod自らが終了 ⚫何らかのエラーによって異常終了 ▌外部からの強制終了 ⚫例: K8sのprobeへの無応答が続くとシグナルによって強制終了 28

Slide 29

Slide 29 text

切り分け ▌RGW Pod強制終了時のログを見れば何かわかるはず ⚫RGW Podが自ら終了: エラーログが残る ⚫外部から強制終了: シグナル受信ログが残る ▌幸運: Loki上の直近のログだけは見られる ⚫LokiのストレージはCeph上に保存 ⚫古いログはRGWに保存 ⚫直近のデータはブロックデバイスに保存 29

Slide 30

Slide 30 text

RGW podのログを確認 30

Slide 31

Slide 31 text

ログを表示する期間 31

Slide 32

Slide 32 text

Lokiに発行するクエリ(LogQL) 32

Slide 33

Slide 33 text

全RGW Podのログをまとめて表示 33

Slide 34

Slide 34 text

どのPodのログかをどうやって特定? 34 ログの各行をクリックすると…

Slide 35

Slide 35 text

行をクリックすると詳細情報が出る 35

Slide 36

Slide 36 text

出力するログを絞っていく ▌旧 ▌新 ▌出力期間も絞る 36

Slide 37

Slide 37 text

分析結果 ▌各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”という処理が怪しそうシグナルによって終了

Slide 38

Slide 38 text

仮説 ▌Probe失敗によって強制終了させられていた ▌ログに残っていたreshardingという処理が怪しい ▌次のようなことを繰り返していたのでは? 1. resharding処理中はRGW podのprobeが失敗 2. Probeの失敗を繰り返したのでK8sが異常終了させる 3. resharding処理が最初からやり直しに 38

Slide 39

Slide 39 text

その後の流れ ▌仮説は正しかった ⚫K8sのlivenessProbeが失敗し続けていた ▌詳細は別スライドを参照 ⚫ https://speakerdeck.com/sat/kubernetesshi-jian-toraburusiyuteingu 39

Slide 40

Slide 40 text

振り返り: よかったこと ▌監視と通知によって問題を早期検出できた ⚫無ければユーザからのクレームまで気づけなかった可能性も ▌ダッシュボードにより問題の概要が一目でわかった ▌メトリクスとログからトラシューの仮説が立てられた ⚫仮説の検証にも役立った 40

Slide 41

Slide 41 text

振り返り: 改善すべきこと ▌Cephクラスタ専用のLokiが欲しい ▌今回は偶然に助けられた ⚫直近のログにアクセスできなければ調査はさらに難航した ▌次はこうはいかないかもしれない 41

Slide 42

Slide 42 text

これまでの経験を踏まえたTIPS ▌オブザーバビリティ向上の肝は改善の繰り返し ⚫まずは単純な監視/ログ基盤を作る ⚫使い込んで、不備があれば改善 ▌定期的なダッシュボードのチェック重要 ⚫「何が正常か」が肌感覚でわかる ▌一度監視/ログ基盤を導入したら無い状態が想像できなくなる ⚫問題検知/トラシュー速度が全く違う ⚫可用性向上に投資を惜しまないほうがいい 42

Slide 43

Slide 43 text

おわり 43