Datadogの『モダンなインフラストラクチャの監視』を読んでみた

お仕事でDatadogをさわることになったので、Datadog社のHPでダウンロードできるモダンなインフラストラクチャの監視を監視の素人が読んでみました。

わたろー

こういうドキュメントをしっかり読むのが得意ではないのですが、Datadogを使っていく上で色々大事そうなことが書いてありました。

この記事はほとんど上記ドキュメントの要約/まとめです。画像の出典も同様となります。読解した上での個人的な感想を記載しています。

第 1 章：絶えざる変化
第 2 章：優れたデータを収集せよ
第 3 章：本当に重要な問題についてアラートを発行する
1. アラートの緊急レベル
2. アラートのためのデータと診断のためのデータ
第 4 章：パフォーマンス問題の調査
第 5 章：時系列グラフによるメトリクスの可視化
第 6 章：サマリーグラフによるメトリクスの視覚化
第 7 章：あらゆる情報を一元化する：ELB の監視方法
1. 主要なELBパフォーマンスメトリクス
第 8 章：あらゆる情報を一元化する：Docker の監視
第 9 章：Datadog は、動的でクラウドスケールの監視ソリューション
まとめ

第 1 章：絶えざる変化

簡単な現状分析という感じでした。

ペットと家畜の違い-よく比喩に使われますね

DevOps
監視におけるモダンなアプローチ-気になったのは、「高度なアラート作成」。設定したしきい値の超過時のアラートはよくある機能ですが、外れ値の自動検出などは高度な監視システムでは提供されるとのこと。
モダンな監視フレームワークの仕組み

第 2 章：優れたデータを収集せよ

わたろー

このへん、よく読んでおくとDatadogで使われる単語が実務でも理解しやすいのではと思いました。

メトリクス-「特定の時点におけるシステム関連の値」

ワークメトリクス-「有用な出力」「システムのトップレベルのヘルス」-例:1秒あたりのリクエスト数
リソースメトリクス-「CPU」「メモリ」「データベース〜も、他のシステムがそのコンポーネントを使用することを要求する場合、リソース」

イベント

「個別かつ不定期に発生する事象」「システムの動作の変化を把握するための重要なコンテキスト」「ある時点で何が起こったのか」
「スケーリングイベント：ホストまたはコンテナの追加または削除」
例:夜間のデータロールアップに失敗した

タグ付け-「データポイントが属するさまざまなすべての範囲を宣言するメタデータ」

範囲、どこで起きたかを示すのがタグのようです。画像の例だったら、file-serverとかで検索できるってことでしょうか。

キー：値タグ

このあたり、使ってみた方が理解しやすそうな説明でした。

「キー：値タグ」と書いてありますが、key:value tag みたいな感じでしょうね。(感じ・・・。)

instance-type:m3.xlarge と宣言したら、キーとしてinstance-typeを宣言し、バリューとしてm3.xlargeを定義する。

この場合、あとから、instance-type:m3.mediumなど追加していって、任意のディメンションを組み合わせられるようです。

監視のためのより良いデータとは

簡単に理解できる-メトリクスやイベントが何を意味してるかすぐわかるように命名されている
粒度-収集の頻度、期間等のバランスがよい
スコープ別のタグ付-任意のスコープ(リージョンなど)で組み合わせて確認できる
長時間の保持-できるだけ長期間。少なくとも1年以上なら季節ごとの違いなどわかる。

第 3 章：本当に重要な問題についてアラートを発行する

タイトルの通りですが、たくさんアラートが飛んでくると、何が重要かわからなくなるので、必要な時に必要なアラートが飛ぶようにしましょう、というお話でした。

アラートの緊急レベル

記録するアラート-重要度低-😅
通知するアラート-重要度中-データストアのディスク容量不足(だけど、すぐに対応必要でない時)-😓
緊急メッセージを送信するアラート-重要度高-webアプリケーションの応答時間等-担当者にすぐ連絡😭

アラートのためのデータと診断のためのデータ

具体的な例が記載されていました。

アラートの緊急度の設定方法については、以下のような観点から見ていきます。

これは本当に問題か？ – テスト環境のメトリクスなど。テストはいらないよね・・・。また、定期的な再起動など、仕組まれたものはもちろん問題じゃないですね。
この問題に対する注意は必要か？
この問題は緊急か？ – 「修正が必要だけど、緊急でやるものではない」場合と、重要なシステムの動作が許容範囲を超過している場合とでは対応がちがいますね。

わたろー

SLOに関わってきそうな部分ですね。

他にも、

症状に関する緊急メッセージ
長時間継続するアラートの定義
早期警戒のサイン

など、システムの面倒をみるのが「人間」であるということをちゃんと意識されているように感じました。

第 4 章：パフォーマンス問題の調査

根本原因の診断について、多くの場合以下の手法が使われている、とのことです。

勘に頼る
推測して検証する

た、たしかに〜って感じですが、「明確な方向性をもったアプローチ」を知りたいところです。具体的にまとめてみました。

ワークメトリクスから最初に取り掛かる

このへんをちゃんと答えられるようにしましょう。

問題が発生しているか？
問題にはどのような特徴があるか？

リソースの詳細な調査 – 最上位のワークメトリクスを調べても原因がわからないとき

物理リソース(CPUやメモリ)
各システムのダッシュボードでリソースを見やすく設定しておく(問題発生の前の準備が大事そうですね) – 上位レベルのアプリケーション用メトリクスにダッシュボード1個、サブシステム別にダッシュボードを1つ設定するのがおすすめ。

利用できるか？利用率が高いか？飽和しているか？

何かを変更したか？

問題が発生する前のコードリリース
問題が発生する前の内部アラート
問題が発生する前のイベント

修正する（そして忘れずに記録する）- 原因がわかったら、修正し、同様の問題を回避するための方法を考える

メトリクスの追い方

インフラの各システムについて、主要なメトリクスを全て表示するダッシュボード設定しておき、関連するイベントを重ね合わせる
最上位のシステムから調査し、ワークメトリクス、リソースメトリクス、関連するイベントを検証していく
問題が見つかれば、根本原因を上記と同様の方法で再帰的に調べていく

第 5 章：時系列グラフによるメトリクスの可視化

空間を横断する集計

ホストごとのリクエストを見ても何が何だかよくわからないけど、アベイラビリティゾーンごとだとよくわかる

折れ線グラフ

使用目的とその例が以下になります。

外れ値を一目で把握する – クラスタにある各ホストのCPUアイドル

時間の経過による重要なメトリクスの推移を明確に伝える – 全Webサービスの平均レイテンシ

個別の逸脱値が許容外になるかを判断する – データベースノード別のディスク容量の使用率

ただ、この部分は実践的な記載となっていて、

表示対象とその理由、例が書いてあってとてもわかりやすかったです。自分で問題対処/システム監視の事前準備のためにダッシュボード作成するときも、リファレンス的に利用できるかと思います。

また、グラフの適切でない使用方法と、その代わりに使用するグラフが画像と共に記載されていました。

積み上げ面グラフ – メトリクスの値が線ではなく2次元のバンドで表示

全部載せようかと思いましたが、数が多かったので、やめておきます・・・涙

とりあえず「どんなものを監視したいときに、どんなダッシュボードが必要かな〜」と考える時に助けになりそうですね！

第 6 章：サマリーグラフによるメトリクスの視覚化

時間を横断する集計 – 例: 過去60分間で各ホストによって報告された最大値

時間を横断する集計 – 例: 過去60分間で各ホストによって報告された最大値

空間を横断する集計 – 例: 各サービスのRedisレイテンシを表示

単一値のサマリー – 例: 状態がOKのホストの現在の数

トップリスト – 例: 過去1時間の各AZのRedisの最大レイテンシ

推移グラフ – 例: 各ログイン方法について過去4時間のデータを昨日の4時間分のデータと比較

ホストマップ – リソース使用率の一覧化

「Datadog独自の視覚化の手法」とのことです。蜂の巣みたいになってて一覧化しやすそうですね。

わたろー

近未来的！

分布 – 例: ホストごとのwebレイテンシ等

第 7 章：あらゆる情報を一元化する：ELB の監視方法

主要なELBパフォーマンスメトリクス

ELBについての簡単な説明と、主要なメトリクスが挙げられていました。実際に利用するときは細かい定義を正しく理解しておく必要がありそうです。

ロードバランサメトリクス
バックエンド関連のメトリクス
CloudWatchで取得できる有用なメトリクスについて
- REQUESTCOUNT
- SURGEQUEULENGTH – ELB側でバッファされたリクエスト(サーバーの性能が足りず、一旦ELBに保持した時など。)
- SPILLOVERCOUNT – 上記のSURGEQUELENGTHの上限を超えて500エラーを返した数
- HTTP_CODE_ELB_4XX*
- HTTP_CODE_ELB_5XX*

ひとめでわかる項目は問題なさそうですが、パッと見知らないメトリクスについては、注意しておく必要があるかなと思います。