筆者の英語力が著しく乏しいため、全面的に翻訳サービスを活用しています。前後の文脈と筆者の監視に関する経験による主観が多く含まれています。翻訳及びコメントに関して、Datadog社は関係ありません。引用に関しては、Datadog社へ確認し許可をいただいています。)2016年に作成されています。82ページ、9つの章で構成されています。この本では、現代のインフラストラクチャとアプリケーションを監視するための効果的なフレームワークを概説します。)各章(Chapter)は、以下の内容となっています。各タイトルリンクから各章へ移動出来るようにしています。長い内容となりますので、ご興味のある部分へ移動していただいても結構です。Monitoring構成としては、以下のようになっています。前半部分に監視の要素について解説されています。私のようになんとなく監視をやっている人間には、改めて理解することが多く、とても参考になる内容です。過去数年間で、ITインフラストラクチャの性質は劇的に変化しました。)インフラストラクチャは、クラウドサービスの登場、そしてコンテナ技術とコンテナを管理するk8sなどのオーケストレーションサービスによって、インフラストラクチャの拡張・縮小に柔軟性がもたらされ、動的に変化するものとなっていると解説されています。その中で、興味深ったのが、次のグラフ(絵?)となります。)インフラストラクチャの変化にともない、関係する要素(周辺環境)も増加(変化)していることが改めて理解ができます。上段の二つは、Microserviceやコンテナなど既存の方法では運用負荷が高いまたは最適に監視出来ないケースがあったり、CI/CDやDevOpsがホットなテーマとなり、モニタリングの果たす役割は増えていると感じます。)クラウド時代における監視の考え方として、最近よく用いられる「ペットと家畜」です。動的に変化するインフラストラクチャに対して、既存のホストレベルに焦点を当てるのではなく、サービスとして捉えることが重要となっています。モニタリングへの新しいアプローチの中心的な機能は、以下の5つとなる。)この章の最後に、変化したインフラストラクチャへのモニタリングとして必要な機能を紹介しています。Data正しい監視データを取得するために、監視データについて説明がされています。個人的には、ここはオススメしたい章です。何をするために、データを取得するかを定義しています。誤報を最小限に抑えながら、潜在的な問題に対する自動アラートを生成する。パフォーマンスの原因を素早く調査し解決する。必要な時にデータがないと余計にコストがかかるケースがある。データ自体は安いので、必要なデータは可能な限り取得した方が良い。)障害などで調査する必要があるタイミングで、必要なデータがないと調査が難航するという経験がある方には納得の内容ではないでしょうか。ログ保存には注意が必要です。備えあれば憂いなしとあらゆるデータを永遠に保存する方針ではなく、記載があったように収集するデータを精査することが大切です。どのデータが必要なのかについては、続きで紹介されています。分類することが出来ます。ある特定時点でのシステムの状況を表します。2つの分類があります。ような観点が異なるモニタリングが存在します。表す意味を理解して、選定することは重要だと思います。システムの健全性を表す。)4つのサブタイプに分類することが出来ると説明されています。その一方で、マイクロサービスなどの上位レベルでの視点から見ると、一つのシステムも、リソースとして捉えることで出来る。)システム(サービス)を一つのリソースとして捉えることで、新しいアーキテクチャ(マイクロサービスなど)に対して効果的なモニタリングが行えるようになります。(どこまで監視すべきかなどの悩みが、少しスッキリして考えることが出来るのではないでしょうか)それぞれのリソースに対して、4つの分野があると説明されています。システム変化を理解するためのコンテキストとなる。単一データとしても意味をなしている。特定EC2のダウンを気にするのではなく、特定サービスへ気を配る方が良い。Tagを付けることで、サービスやロールやAZなど必要なレベルのMetricsとして監視することが出来るようになる。)ここで紹介されていた監視データ(MetricsやEvents)については、既存インフラストラクチャでも行われている内容でもありました。Metricsへ付与します。(上記の例では、右端)付与されたTagを利用して、データポイントをフィルタリングやグループ化することで、先ほどの必要なレベルのMetricsを作成することが出来ると紹介されています。付与されている例です。サービスの状況を監視することが出来るというわけです。利用して構造化していきます。付けて、ディメンションを作成します。いう属性でグループ化されています。ZONEも同様の見方です。指しており、特定EC2を気にすることなく、同じ属性の状況を把握することができます。縦のラインで考えると、同じAZでDBの状況を監視することができます。like良いデータには、以下のような4つの特徴があると説明されています。何が起きているかを把握出来る期間保存する。Matters監視データを精査し収集出来ていると仮定して、それらから何をAlertすべきかに話は進んでいきます。アラートが狼少年と化している担当者の方には是非一緒に見ていただきたい章となっています。自動アラートは、モニタリングにとって必要不可欠です。素早く問題を検知、復旧に必要な手がかりを教えてくれる。アラートは必ずしも効果的ではなく、時にはノイズとして問題になる。全てのアラートが同じ緊急度ではない。)以下の3種類に分けることが出来ると続きます。SEVERITY)サービスへ直接的な影響がない。重大な問題が発生した際、調査用として有用なコンテキストとなる可能性がある。SEVERITY)次の段階では、対応が必要となるアラート(Warningとして利用することがあるのではないかと思います)メールやチャットに送信するのが最適な方法です。SEVERITY)最も緊急性の高いアラートです。正しく、エスカレーションされることが必要です。Diagnostics監視データには、アラート用と分析・診断用がある。Urgency)で、紹介したアラートタイプ別の例です。以下のように整理することで、監視データごとに必要な対応が可視化されます。LIEアラートの緊急度や対処方法を検討する際には、以下の3つの質問が有効と説明されています。いった内容を定期的に見直すこと(もしくは文化)が非常に大切ではないかと個人的には思います。スループット、レスポンス、エラー率などサービスに近い内容が即時対応が必要とされます。symptoms(症状)。アラートを受けた後、プロセス停止など明瞭な原因と対応(起動)で、継続的な調査へのアプローチとダッシュボードの活用を説明しています。監視システムは、異常を検知しアラート通知するだけではなく、根本的な原因を分析するのをサポートまでを目的としています。述べられているように、上位レベルで見れば、システムも一つのリソースである。各システムは、下位レベルの各リソースがサポートしている。その関係に着目すると、根本的な原因の追究を手助けしてくれる。具体的には、以下のプロセスが紹介されています。四角い枠を一つのシステムやサービスと考えると理解が進みます。metricsまず、「何が問題なのか」を明確にします。わかると、原因または調査の方法性が見えてきます。調べてわからない場合は、次に使用するリソース(物理的なリソースだけではなく、外部リソースとして他システムも含める)を調べます。事前にダッシュボードを作成することで、関連リソースの把握を手助けしてくれる。関連するアラートやイベントを調べます。問題が発生する前に、コードリリースやアラート、その他イベントが記録されていないかを確認します。it)問題を修正できれば完了です。同様の問題が発生し得るのであれば、対応を検討します。THEMとはいえ、シンプルなアーキテクチャであれば問題ありませんが、多様な場合は、即座に関係性の把握は難しいものです。そのため、ダッシュボードを作成することで、事前に可視化しておく内容が紹介されています。)ダッシュボードは事前に作成しておきましょう。物理的なリソースだけではなく、上位レベルでのシステムをリソースやそのリソースの主要な物理的リソースを含めて、作成しておきましょう。イベントデータがあれば、相関分析のために、関連グラフに重ねましょう。METRICS標準的なモニタリングのフレームワークを利用することで体系的にアプローチすることができます。インフラストラクチャ内の各システムに対して、関連するイベントをオーバーレイして、その主要なメトリックすべてを表示するダッシュボードを事前に設定します。症状を示している最高レベルのシステムから作業を開始し、その作業とリソースのメトリック、および関連するイベントを検討することによって、問題の原因を調査します。問題のあるリソースが検出された場合は、根本的な問題が発見されて修正されるまで、同じ調査パターンをそのリソース(およびその構成リソース)に適用します。Chapter6までは、Metricsを可視化する方法としてグラフの種類と効果的な利用方法について述べられています。具体例を見ていただくことで、理解が出来る内容となっています。なんとなく折れ線一択であった私には、ユースケースはもちろん、アンチケース(もっと効果的に可視化できるグラフの紹介)が参考になりました。Graphs折れ線グラフは、メトリックデータをビジュアルに変換する最も簡単な方法です。Graphs帯で表現する以外は、折れグラフに似ています。帯にすることで、複数のデータを時系列で表示することができます。Graphs棒グラフはカウントを表すのに最適です。表現するのに効果的です。Maps時間とともに変化するメトリックの値の分布を示します。各セルの濃淡は、その特定の期間中にその特定の値を報告するエンティティの数に対応します。個々のホストまたはコンテナレベルで集計されていないメトリックをグラフ化するためによく使用されます。ヒートマップは時間の経過とともに変化を示し、分布グラフは特定の時間枠のスナップショットです。6では、要約グラフを説明しています。Time最新の値を表示する。時間の経過ともに、再計算される。つけることで、インフラストラクチャにとらわれない集計することが可能です。Summaries特定のメトリッククエリの現在の値を表示します。最新の値、またはタイムウィンドウ全体のすべてのクエリ値から計算された集計を表示します。)Toplistsメトリック値でランク付けできます。非常に簡単なので、トップリストは高レベルのステータスボードに特に役立ちます。Graphsトップリストには最近のメトリック値の概要が表示されますが、変更グラフはメトリックの現在値と過去のある時点の値を比較します。変更グラフは2つの異なる時間枠をパラメータとして取ることです。Mapsインフラストラクチャ全体、またはその一部をひと目で確認するための独自の方法です。(視覚化タイプはDatadogに固有のものです。)Distributionsインフラストラクチャのセグメント全体にわたるメトリックの値のヒストグラムを示します。ヒートマップは時間の経過とともに変化を示すのに対して、分布は時間枠の要約であるということです。ヒートマップと同様に、ディストリビューションは特定のメトリックをレポートする多数のエンティティを手軽に視覚化するので、個々のホストまたはコンテナレベルでメトリックをグラフ化するためによく使用されます。ELBChapter7では、ELB(CLB)を監視するケースでのナレッジが説明されています。「ロードバランスのMetrics」と「バックエンドインスタンスのMetrics」を見る必要があります。OnRequestCountロードバランサーが完了したリクエストの数このMetricsのピーク・ボトムを把握することで、インフラストラクチャやDNSなども問題を捉えることが出来る。合計数キューがたくさんになるとリクエストを拒否する。SpilloverCountSurgeQueueLengthが限界に達して拒否された件数。Gateway):ロードバランサが正しく動作していない。Unavailable):バックエンドインスタンスかロードバランサが正しく動作していない。Timeout):ロードバランサのタイムアウト値を超えている。PICTUREELBのパフォーマンスとバックエンドインスタンスの状況は、関係があります。バックエンドインスタンスのリソース監視を行うことは有益です。バックエンドインスタンスから返されるHTTPコードは、ELBにおいて高いレベルでの洞察を提供します。ELB、EC2、ElastiCache、RDS、およびその他のAWSサービス、さらに100を超える追加のテクノロジから監視データを収集します。一般的なコラボレーションおよびコミュニケーションツールの組み込みサポートにより、PagerDuty、Slackなどを使用して高度なアラートを作成してチームに送信することができます。ELBCloudWatchへの読み取り権限を付与することで、容易に開始できる。ELB」というダッシュボードが作成されるこのダッシュボードには、上記で説明したMetricsが表示されている。DASHBOARDS他のリソースからのMetricsを追加することも出来る。METRICSバックエンドインスタンスであるEC2のMetricsも、アクセスが可能です。カスタムダッシュボードに、ELBとEC2のMetricsを並べることで、全体的な把握が可能です。介さないMetricsの取得も可能です。エージェントを利用することで、CPUやメモリなどの情報も取得が可能です。StatsDの拡張機能であるDogStatsDを用いて、アプリケーションレベルの情報も取得が可能です。DockerChapter8では、Dockerを監視するケースでのナレッジが説明されています。いくつかの運用の問題を解決してくれるが、利用することで別の問題を抱える。非常に急速に変化するため、監視や理解が難しい。CONTAINER?軽量化された仮想ランタイムです。オーケストレーションやネットワークなどの課題に対しての取り組みは進んでいる。監視の課題に対しては、あまり理解されていない。CONTAINERSコンテナの採用された理由には、以下の大きな2つの要因があります。SCALEコンテナテクノロジーを利用すると、簡単にデプロイすることが可能です。他のシステムへ影響を与えることなく、スケールすることが可能です。)コンテナテクノロジーを利用することで、依存関係からの解放される以前は、ファイルに記述し共有ライブラリへ変化したが、その影響もあり、依存関係が複雑化していきました。同ホストで実行されている他のソフトウェアの影響を受けないパッケージへと変化することで、依存関係から解放された。COMPLEXITYコンテナは、小さなホストです。ホストであれば、従来の監視方法が適用出来ると思われえるが、そうではない。)アプリケーションスタックは、左から右へと変化している。ホスト思考はやめて、レイヤーやタグを中心に考えることで、コンテナ監視がシンプルになる。)関係する要素を、同じダッシュボードで可視化することで、良い効果的な監視とする。小さなホストとして捉えることも出来ます。そのため、通常ホストと同様リソースを消費しますが、取得できるMetricsは異なったものとなります。コンテナはシステムCPUとユーザーCPUの使用状況を報告します。コンテナのパフォーマンスが低下しているときは、CPUを確認することが効果的です。コンテナでは、nice、idle、iowait、またはirqのCPU時間を報告しません。CPUシェアやスロットルの調整により、解消することもある。各Metricsを報告します。パフォーマンスまたは安定性の問題を調査するのに役立つ可能性がある追加のメトリックには、ページフォルトが含まれます。ページフォルトは、セグメンテーションフォルトまたはメモリではなくディスクからのデータのフェッチを表します(それぞれpgfaultおよびpgmajfault)。従来のホストと同様に、パフォーマンスの問題がある場合に最初に検討する必要があるメトリックには、メモリの可用性とスワップの使用量などがあります。)ブロックデバイスごとに、Dockerは次の2つのメトリクスを4つのカウンタに分解してレポートします。Oメトリックに加えて、ホストのキューとサービス時間を追跡することをお勧めします。