Monitoring Modern Infractructure（eBook provided by Datadog）を読んでみた #datadog

こんにちは　園部です。

みなさん。噂の「 入門 監視 」は、もう読みましたか？

空前の「監視ブーム」に影響を受け、今回は Datadog社 Blog にて、公開・提供されている Monitoring Modern Infractructure（英語） を読んでみました。

今回の英文翻訳と内容について；
- 筆者の英語力が著しく乏しいため、全面的に翻訳サービスを活用しています。
- 前後の文脈と筆者の監視に関する経験による主観が多く含まれています。
- 翻訳及びコメントに関して、Datadog社は関係ありません。あくまで個人の内容です。
- 引用に関しては、Datadog社へ確認し許可をいただいています。

この本について

（引用： Datadog社 Blog より）

2016年に作成されています。
82ページ、9つの章で構成されています。

In this eBook, we outline an effective framework for monitoring modern infrastructure and applications, however large or dynamic they may be.

訳： この本では、現代のインフラストラクチャとアプリケーションを監視するための効果的なフレームワークを概説します。
（引用： Monitoring Modern Infractructure（英語） より）

各章（Chapter）は、以下の内容となっています。 各タイトルリンクから各章へ移動出来るようにしています。長い内容となりますので、ご興味のある部分へ移動していただいても結構です。

構成としては、以下のようになっています。

Chapter１では、インフラストラクチャにおける環境の変化と監視の考え方
Chapter2-4では、監視の基本的な部分（データ、アラート、パフォーマンス調査）について解説
Chapter5-6は、可視化としてグラフ種別やユースケースを説明
Chapter7-8では、ELB（CLB）とDockerをテーマに監視例
Chapter9では、Datadogが提供する Modern Infractructure 紹介

前半部分に監視の要素について解説されています。私のようになんとなく監視をやっている人間には、改めて理解することが多く、とても参考になる内容です。（Chapter1-6）

後半部分は、具体的な例を用いて、監視すべきポイントや Metrics、Alert が解説されており、特にDocker部分は参考となる方も多いのではないでしょうか？（Chapter7-8）

Chapter1: Constant Change

In the past several years, the nature of IT infrastructure has changed dramatically.

訳： 過去数年間で、ITインフラストラクチャの性質は劇的に変化しました。
（引用： Monitoring Modern Infractructure（英語） より）

インフラストラクチャは、クラウドサービスの登場、そしてコンテナ技術とコンテナを管理するk8sなどのオーケストレーションサービスによって、インフラストラクチャの拡張・縮小に柔軟性がもたらされ、動的に変化するものとなっていると解説されています。
その中で、興味深ったのが、次のグラフ（絵？）となります。

（引用： Monitoring Modern Infractructure（英語） P2 より）

インフラストラクチャの変化にともない、関係する要素（周辺環境）も増加（変化）していることが改めて理解ができます。 （グラフに、データソースや値はありませんが、理解は出来る方も多いのではないでしょうか）

• 左上：インフラストラクチャの要素数
• 右上：変更の頻度
• 左下：関連するエンジニア
• 右下：ツール数

特に、上段の二つは、Microserviceやコンテナなど既存の方法では運用負荷が高いまたは最適に監視出来ないケースがあったり、CI/CDやDevOpsがホットなテーマとなり、モニタリングの果たす役割は増えていると感じます。

Pets vs Cattle

訳： ペットと家畜
（引用： Monitoring Modern Infractructure（英語） P3 より）

クラウド時代における監視の考え方として、最近よく用いられる「ペットと家畜」です。
動的に変化するインフラストラクチャに対して、既存のホストレベルに焦点を当てるのではなく、サービスとして捉えることが重要となっています。

（引用： はじめてのDatadog ）

Modern Approaches to Monitoring

The core features of a modern monitoring system are outlined below.

訳： モニタリングへの新しいアプローチの中心的な機能は、以下の5つとなる。
（引用： Monitoring Modern Infractructure（英語） P4 より）

この章の最後に、変化したインフラストラクチャへのモニタリングとして必要な機能を紹介しています。

Chapter2: Collecting the Right Data

正しい監視データを取得するために、監視データについて説明がされています。
個人的には、ここはオススメしたい章です。

何をするために、データを取得するかを定義しています。

1. Generate automated alerts for potential problems while minimizing false alarms

訳： 誤報を最小限に抑えながら、潜在的な問題に対する自動アラートを生成する。

2. Quickly investigate and get to the bottom of performance issues

訳： パフォーマンスの原因を素早く調査し解決する。
（引用： Monitoring Modern Infractructure（英語） P6 より）

Collecting data is cheap, but not having it when you need it can be expensive, so you should instrument everything, and collect all the useful data you reasonably can.

訳： 必要な時にデータがないと余計にコストがかかるケースがある。データ自体は安いので、必要なデータは可能な限り取得した方が良い。
（引用： Monitoring Modern Infractructure（英語） P6 より）

障害などで調査する必要があるタイミングで、必要なデータがないと調査が難航するという経験がある方には納得の内容ではないでしょうか。

ただし　data is cheap　には限度があります。特にログ保存には注意が必要です。
備えあれば憂いなしとあらゆるデータを永遠に保存する方針ではなく、記載があったように収集するデータを精査することが大切です。

では、どのデータが必要なのかについては、続きで紹介されています。

Most monitoring data falls into one of two categories: metrics and events.

訳： モニタリングデータは、 Metrics（メトリクス） と Events（イベント） に分類することが出来ます。
（引用： Monitoring Modern Infractructure（英語） P6 より）

Metrics

Metrics capture a value pertaining to your systems at a specific point in time

（中略）

There are two important categories of metrics in our framework: work metrics and resource metrics.

訳： Metrics は、ある特定時点でのシステムの状況を表します。
Metrics も、2つの分類があります。
（引用： Monitoring Modern Infractructure（英語） P7 より）

誤解を恐れずに言うと、継続的に健全なサービスを提供するという大きな目的では同じでも BlackBox Monitoring と WhiteBox Monitoring のような観点が異なるモニタリングが存在します。
そのため、何を監視したいのかを定め、各 Metrics の表す意味を理解して、選定することは重要だと思います。

（参考サイト： Black Box vs. White Box Monitoring: What You Need To Know ）

（引用： Monitoring Modern Infractructure（英語） P7 より）

Work Metrics

Work metrics indicate the top-level health of your system by measuring its useful output

訳： Work Metrics は、システムの健全性を表す。
（引用： Monitoring Modern Infractructure（英語） P7 より）

４つのサブタイプに分類することが出来ると説明されています。

• throughput
• success
• error
• performance（※ 多くの場合は「待ち時間」が該当）

例： Web Server（上段） と Data Store（下段）

Resource Metrics

Most components of your software infrastructure serve as a resource to other systems.
Some resources are low-level—for instance, a server’s resources include such physical components as CPU, memory, disks, and network interfaces.
But a higher-level component, such as a database or a geolocation microservice, can also be considered a resource if another system requires that component to produce work.

訳： サーバ単体リソースとして、CPU、メモリ、ディスク、ネットワークインターフェース があげられる。その一方で、マイクロサービスなどの上位レベルでの視点から見ると、一つのシステムも、リソースとして捉えることで出来る。
（引用： Monitoring Modern Infractructure（英語） P8 より）

システム（サービス）を一つのリソースとして捉えることで、新しいアーキテクチャ（マイクロサービスなど）に対して効果的なモニタリングが行えるようになります。
（どこまで監視すべきかなどの悩みが、少しスッキリして考えることが出来るのではないでしょうか）

それぞれのリソースに対して、4つの分野があると説明されています。

• utilization（稼働率）
• saturation（飽和度）
• errors（失敗）
• availability（可用性）

例： Resource Metrics 項目

Other Metrics

WorkでもResourceでもないMetrics 例： キャッシュヒット数やデータベースのロック数など

Events

In addition to metrics, which are collected more or less continuously, some monitoring systems can also capture events: discrete, infrequent occurrences that provide crucial context for understanding changes in your system’s behavior.

訳： イベントは、連続的に収集されるシステムのデータ（値） システム変化を理解するためのコンテキストとなる。また、単一データとしても意味をなしている。
（引用： Monitoring Modern Infractructure（英語） P9 より）

例： イベント種類

例： ログでのイベント

Tagging

After all, you don’t care if a specific EC2 instance goes down, but you do care if latency for a given service, category of customers, or geographical region goes up.

Tagging your metrics enables you to reorient your monitoring along any lines you choose.
By adding tags to your metrics you can observe and alert on metrics from different availability zones, instance types, software versions, services, roles—or any other level you may require.

訳： 特定EC2のダウンを気にするのではなく、特定サービスへ気を配る方が良い。
Metrics へTagを付けることで、サービスやロールやAZなど必要なレベルのMetricsとして監視することが出来るようになる。
（引用： Monitoring Modern Infractructure（英語） P10 より）

ここで紹介されていた監視データ（MetricsやEvents）については、既存インフラストラクチャでも行われている内容でもありました。 当初の課題である動的に変化するインフラストラクチャへ対するアプローチとして、ここで紹介されている Tag がキーとなってきます。

WHAT’S A METRIC TAG?

（引用： Monitoring Modern Infractructure（英語） P10 より）

様々な属性に関するメタデータを Tag として Metricsへ付与します。
（上記の例では、右端）
付与されたTagを利用して、データポイントをフィルタリングやグループ化することで、先ほどの必要なレベルのMetricsを作成することが出来ると紹介されています。

以下の例では、[FILE-SERVER]というシンプルな Tag が付与されている例です。
[FILE-SERVER] のTag でグループ化を行えば、[FILE-SERVER] サービスの状況を監視することが出来るというわけです。

（引用： Monitoring Modern Infractructure（英語） P11 より）

CREATING NEW DIMENSIONS WITH KEY: VALUE TAGS

Tag を利用して構造化していきます。
Metrics に、Key:Value の Tag を付けて、ディメンションを作成します。
参考： ディメンション【dimension】 とは？

以下の例では、INSTANCE TYPE というディメンションに対して、b3.medium、t2.small、c3.large という属性でグループ化されています。ROLEやAVAILABILITY ZONEも同様の見方です。
色が変わっている部分は、INSTANCE TYPE:t2.small かつ AVAILABILITY ZONE:us-east-1a を指しており、特定EC2を気にすることなく、同じ属性の状況を把握することができます。また例えば、縦のラインで考えると、同じAZでDBの状況を監視することができます。

What good data looks like

良いデータには、以下のような4つの特徴があると説明されています。

Chapter3: Alerting on What Matters

監視データを精査し収集出来ていると仮定して、それらから何をAlertすべきかに話は進んでいきます。
アラートが狼少年と化している担当者の方には是非一緒に見ていただきたい章となっています。

Automated alerts are essential to monitoring.

They allow you to spot problems　anywhere in your infrastructure, so　that you can rapidly identify their　causes and minimize service degradation and disruption.

But alerts aren’t always as effective as they could be.
In particular, real problems are often lost in a sea of noisy alarms.

訳： 自動アラートは、モニタリングにとって必要不可欠です。素早く問題を検知、復旧に必要な手がかりを教えてくれる。 ただしアラートは必ずしも効果的ではなく、時にはノイズとして問題になる。
（引用： Monitoring Modern Infractructure（英語） P14 より）

Levels of Alerting Urgency

Not all alerts carry the same degree of urgency.

訳： 全てのアラートが同じ緊急度ではない。
（引用： Monitoring Modern Infractructure（英語） P15 より）

以下の３種類に分けることが出来ると続きます。

ALERTS AS RECORDS (LOW SEVERITY)

• サービスへ直接的な影響がない。
• 重大な問題が発生した際、調査用として有用なコンテキストとなる可能性がある。

ALERTS AS NOTIFICATIONS (MODERATE SEVERITY)

• 次の段階では、対応が必要となるアラート
  （Warningとして利用することがあるのではないかと思います）
• メールやチャットに送信するのが最適な方法です。

ALERTS AS PAGES (HIGH SEVERITY)

• 最も緊急性の高いアラートです。
• 正しく、エスカレーションされることが必要です。

Data for Alerts, Data for Diagnostics

監視データには、アラート用と分析・診断用がある。
（引用： Monitoring Modern Infractructure（英語） P16 より）

上記（Levels of Alerting Urgency）で、紹介したアラートタイプ別の例です。
以下のように整理することで、監視データごとに必要な対応が可視化されます。

（引用： Monitoring Modern Infractructure（英語） P16 より）

WHEN TO LET A SLEEPING ENGINEER LIE

アラートの緊急度や対処方法を検討する際には、以下の3つの質問が有効と説明されています。
こういった内容を定期的に見直すこと（もしくは文化）が非常に大切ではないかと個人的には思います。

• Is this issue real?（本当に問題とすべきか？通知する必要はあるのか？）
• Does this issue require attention?（常に注意を払うべきなのか？自動で対応できないか？メール等の通知のみで良いか？）
• Is this issue urgent?（本当に緊急を要する内容なのか？）

PAGE ON SYMPTOMS（即時対応とするアラートとは？）

In general, a page is the most appropriate kind of alert when the system you are responsible for stops doing useful work with acceptable throughput, latency, or error rates.

訳： スループット、レスポンス、エラー率などサービスに近い内容が即時対応が必要とされます。
（引用： Monitoring Modern Infractructure（英語） P18 より）

The distinction between work metrics and resource metrics introduced in chapter 2 is often useful for separating symptoms and causes: work metrics are usually associated with symptoms and resource metrics with causes.

訳： Work Metrics は、symptoms（症状）。Resource Metrics は、cause（原因） を表している。
（引用： Monitoring Modern Infractructure（英語） P18 より）

Chapter4: Investigating Performance Issues

このChapter では、アラートを受けた後、プロセス停止など明瞭な原因と対応（起動）で、継続的な調査へのアプローチとダッシュボードの活用を説明しています。

The responsibilities of a monitoring system do not end with symptom detection. Once your monitoring system has notified you of a real symptom that requires attention, its job is to help you diagnose the root cause.

訳： 監視システムは、異常を検知しアラート通知するだけではなく、根本的な原因を分析するのをサポートまでを目的としています。
（引用： Monitoring Modern Infractructure（英語） P20 より）

IT’S RESOURCES ALL THE WAY DOWN

Chapter2 で述べられているように、上位レベルで見れば、システムも一つのリソースである。
各システムは、下位レベルの各リソースがサポートしている。その関係に着目すると、根本的な原因の追究を手助けしてくれる。

具体的には、以下のプロセスが紹介されています。
四角い枠を一つのシステムやサービスと考えると理解が進みます。

（引用： Monitoring Modern Infractructure（英語） P22 より）

1. Start at the top with work metrics

• まず、「何が問題なのか」を明確にします。
• 発生している問題の Work Metrics を調べます。
• Metrics がわかると、原因または調査の方法性が見えてきます。

2. Dig into resources

• 最上位の WorkMetrics を調べてわからない場合は、次に使用するリソース（物理的なリソースだけではなく、外部リソースとして他システムも含める）を調べます。
• 事前にダッシュボードを作成することで、関連リソースの把握を手助けしてくれる。
• 対象リソースが、利用できない・飽和しているなどであれば、そのリソースに対して、再帰的に 1. へ戻り、調べます。

3. Did something change?

• Metrics に関連するアラートやイベントを調べます。
• 問題が発生する前に、コードリリースやアラート、その他イベントが記録されていないかを確認します。

4. Fix it (and don’t forget it)

• 問題を修正できれば完了です。
• 同様の問題が発生し得るのであれば、対応を検討します。

BUILD DASHBOARDS BEFORE YOU NEED THEM

とはいえ、シンプルなアーキテクチャであれば問題ありませんが、多様な場合は、即座に関係性の把握は難しいものです。
そのため、ダッシュボードを作成することで、事前に可視化しておく内容が紹介されています。

（引用： Monitoring Modern Infractructure（英語） P23 より）

• ダッシュボードは事前に作成しておきましょう。
• 物理的なリソースだけではなく、上位レベルでのシステムをリソースやそのリソースの主要な物理的リソースを含めて、作成しておきましょう。
• イベントデータがあれば、相関分析のために、関連グラフに重ねましょう。

FOLLOW THE METRICS

標準的なモニタリングのフレームワークを利用することで体系的にアプローチすることができます。

• インフラストラクチャ内の各システムに対して、関連するイベントをオーバーレイして、その主要なメトリックすべてを表示するダッシュボードを事前に設定します。
• 症状を示している最高レベルのシステムから作業を開始し、その作業とリソースのメトリック、および関連するイベントを検討することによって、問題の原因を調査します。
• 問題のあるリソースが検出された場合は、根本的な問題が発見されて修正されるまで、同じ調査パターンをそのリソース（およびその構成リソース）に適用します。

Chapter5: Visualizing Metrics with Timeseries Graphs

ここから Chapter6までは、Metricsを可視化する方法としてグラフの種類と効果的な利用方法について述べられています。具体例を見ていただくことで、理解が出来る内容となっています。

むしろ、なんとなく折れ線一択であった私には、ユースケースはもちろん、アンチケース（もっと効果的に可視化できるグラフの紹介）が参考になりました。

Line Graphs

折れ線グラフは、メトリックデータをビジュアルに変換する最も簡単な方法です。

（引用： Monitoring Modern Infractructure（英語） P26 より）

折れ線グラフが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P26 より）

折れ線グラフ以外が良いケース

（引用： Monitoring Modern Infractructure（英語） P27 より）

Stacked Area Graphs

帯で表現する以外は、折れグラフに似ています。
帯にすることで、複数のデータを時系列で表示することができます。

（引用： Monitoring Modern Infractructure（英語） P28 より）

積み上げグラフが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P28 より）

積み上げグラフ以外が良いケース

（引用： Monitoring Modern Infractructure（英語） P29 より）

Bar Graphs

棒グラフはカウントを表すのに最適です。
Sparse Metrics を表現するのに効果的です。

（引用： Monitoring Modern Infractructure（英語） P29 より）

棒グラフが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P30 より）

棒グラフ以外が良いケース

（引用： Monitoring Modern Infractructure（英語） P31 より）

Heat Maps

時間とともに変化するメトリックの値の分布を示します。
各セルの濃淡は、その特定の期間中にその特定の値を報告するエンティティの数に対応します。
個々のホストまたはコンテナレベルで集計されていないメトリックをグラフ化するためによく使用されます。 ヒートマップは時間の経過とともに変化を示し、分布グラフは特定の時間枠のスナップショットです。

（引用： Monitoring Modern Infractructure（英語） P32 より）

ヒートマップが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P32 より）

ヒートマップ以外が良いケース

（引用： Monitoring Modern Infractructure（英語） P32 より）

Chapter6: Visualizing Metrics with Summary Graphs

Chapter 5 では、時系列グラフを、Chapter 6では、要約グラフを説明しています。

Aggregation Across Time

最新の値を表示する。
時間の経過ともに、再計算される。

Aggregation Across Space

Metrics にTag をつけることで、インフラストラクチャにとらわれない集計することが可能です。

Single-Value Summaries

特定のメトリッククエリの現在の値を表示します。
最新の値、またはタイムウィンドウ全体のすべてのクエリ値から計算された集計を表示します。

（引用： Monitoring Modern Infractructure（英語） P36 より）

単一値サマリが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P37 より）

Toplists

メトリック値でランク付けできます。
非常に簡単なので、トップリストは高レベルのステータスボードに特に役立ちます。

（引用： Monitoring Modern Infractructure（英語） P38 より）

トップリストが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P38 より）

Change Graphs

トップリストには最近のメトリック値の概要が表示されますが、変更グラフはメトリックの現在値と過去のある時点の値を比較します。
変更グラフは2つの異なる時間枠をパラメータとして取ることです。

（引用： Monitoring Modern Infractructure（英語） P39 より）

変化グラフが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P39 より）

Host Maps

インフラストラクチャ全体、またはその一部をひと目で確認するための独自の方法です。
（視覚化タイプはDatadogに固有のものです。）

（引用： Monitoring Modern Infractructure（英語） P40 より）

ホストマップが活躍するケース

（引用： Monitoring Modern Infractructure（英語） P41 より）

Distributions

インフラストラクチャのセグメント全体にわたるメトリックの値のヒストグラムを示します。
ヒートマップは時間の経過とともに変化を示すのに対して、分布は時間枠の要約であるということです。
ヒートマップと同様に、ディストリビューションは特定のメトリックをレポートする多数のエンティティを手軽に視覚化するので、個々のホストまたはコンテナレベルでメトリックをグラフ化するためによく使用されます。

（引用： Monitoring Modern Infractructure（英語） P42 より）

分布図が活躍するケース

（引用： Monitoring Modern Infractructure（英語） P42 より）

Chapter7: Putting It All Together: How to Monitor ELB

Chapter7では、ELB（CLB）を監視するケースでのナレッジが説明されています。

Key ELB Performance Metrics

There are two broad categories of ELB performance
metrics to monitor:

— Load balancer metrics
— Backend-related metrics

訳： ELBに関するパフォーマンスを監視するには 「ロードバランスのMetrics」と「バックエンドインスタンスのMetrics」を見る必要があります。
（引用： Monitoring Modern Infractructure（英語） P44 より）

LOAD BALANCER METRICS

（引用： Monitoring Modern Infractructure（英語） P45 より）

Load balancer metrics 一覧

（引用： Monitoring Modern Infractructure（英語） P45 より）

Metrics to Alert On

• RequestCount
  • ロードバランサーが完了したリクエストの数
  • このMetricsのピーク・ボトムを把握することで、インフラストラクチャやDNSなども問題を捉えることが出来る。
• SurgeQueueLength
  • リクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数
  • キューがたくさんになるとリクエストを拒否する。
• SpilloverCount
  • SurgeQueueLengthが限界に達して拒否された件数。
• HTTPCode_ELB_5XX
  • 502 (Bad Gateway):ロードバランサが正しく動作していない。
  • 503 (Service Unavailable):バックエンドインスタンスかロードバランサが正しく動作していない。
  • 504 (Gateway Timeout):ロードバランサのタイムアウト値を超えている。

Backend-Related Metrics

（引用： Monitoring Modern Infractructure（英語） P47 より）

Backend-related metrics 一覧

（引用： Monitoring Modern Infractructure（英語） P47 より）

Metrics to Alert On

• Latency
  • ELBではなく、バックエンドインスタンスのアプリケーションの待ち時間

Metric to Watch

• BackendConnectionErrors
  • ELBとバックエンドインスタンス間のエラー
  • ネットワークかバックエンドインスタンスに問題があるケースが多い

ABOUT TIMEOUTS

• ユーザーとELB、ELBとバックエンドインスタンスの二つの接続がある
• ELBはアイドルタイムアウト設定で調整し、バックエンドインスタンスはキープアライブを有効に利用する
• アイドルタイムアウト < キープアライブ の長さで設定する

HOST METRICS FOR A FULL PICTURE

• ELBのパフォーマンスとバックエンドインスタンスの状況は、関係があります。
• バックエンドインスタンスのリソース監視を行うことは有益です。
• バックエンドインスタンスから返されるHTTPコードは、ELBにおいて高いレベルでの洞察を提供します。

Monitoring ELB with Datadog

Datadog collects monitoring data from ELB, EC2, ElastiCache, RDS, and other AWS services, plus more than 100 additional technologies. Built-in support for popular collaboration and communication tools enables you to create and send advanced alerts to your team using PagerDuty, Slack, and more.

訳： ELB、EC2、ElastiCache、RDS、およびその他のAWSサービス、さらに100を超える追加のテクノロジから監視データを収集します。
一般的なコラボレーションおよびコミュニケーションツールの組み込みサポートにより、PagerDuty、Slackなどを使用して高度なアラートを作成してチームに送信することができます。
（引用： Monitoring Modern Infractructure（英語） P50 より）

INTEGRATE DATADOG AND ELB

• CloudWatchへの読み取り権限を付与することで、容易に開始できる。

KEEP AN EYE ON ALL KEY ELB METRICS

• 「AWS ELB」というダッシュボードが作成される
• このダッシュボードには、上記で説明したMetricsが表示されている。

CUSTOMIZE YOUR DASHBOARDS

• 他のリソースからのMetricsを追加することも出来る。

CORRELATE ELB WITH EC2 METRICS

• バックエンドインスタンスであるEC2のMetricsも、アクセスが可能です。
• カスタムダッシュボードに、ELBとEC2のMetricsを並べることで、全体的な把握が可能です。

NATIVE METRICS FOR MORE PRECISION

• CloudWatch を介さないMetricsの取得も可能です。
• datadog エージェントを利用することで、CPUやメモリなどの情報も取得が可能です。
• StatsDの拡張機能であるDogStatsDを用いて、アプリケーションレベルの情報も取得が可能です。

Chapter8: Putting It All Together: Monitoring Docker

Chapter8では、Dockerを監視するケースでのナレッジが説明されています。

The Docker monitoring problem

Containers address several important operational problems; that is why Docker is taking the infrastructure world by storm.

But there is a problem: containers come and go so frequently, and change so rapidly, that they can be an order of magnitude more difficult to monitor and understand than physical or virtual hosts.

訳： Docker は、いくつかの運用の問題を解決してくれるが、利用することで別の問題を抱える。
Docker は、非常に急速に変化するため、監視や理解が難しい。
（引用： Monitoring Modern Infractructure（英語） P55 より）

WHAT IS A CONTAINER?

軽量化された仮想ランタイムです。

A significant architectural shift toward containers is underway, and as with any architectural shift, that means new operational challenges. The well-understood challenges include orchestration, networking, and configuration—in fact there are many active projects addressing these issues.

The significant operational challenge of monitoring containers is much less well- understood.

訳： オーケストレーションやネットワークなどの課題に対しての取り組みは進んでいる。
監視の課題に対しては、あまり理解されていない。
（引用： Monitoring Modern Infractructure（英語） P55 より）

DOCKER MONITORING IS CRUCIAL

（引用： Monitoring Modern Infractructure（英語） P55 より）

従来の監視の方法とレイヤー

（引用： Monitoring Modern Infractructure（英語） P56 より）

Docker の場合は、コンテナレイヤーの監視が従来の方法では不足している

A QUICK OVERVIEW OF CONTAINERS

• コンテナの採用された理由には、以下の大きな2つの要因があります。
  • a pattern for scale
  • escape from dependency hell

A PATTERN FOR SCALE

• コンテナテクノロジーを利用すると、簡単にデプロイすることが可能です。
• 他のシステムへ影響を与えることなく、スケールすることが可能です。

ESCAPE FROM DEPENDENCY HELL

（引用： Monitoring Modern Infractructure（英語） P57 より）

• コンテナテクノロジーを利用することで、依存関係からの解放される
• 以前は、ファイルに記述し共有ライブラリへ変化したが、その影響もあり、依存関係が複雑化していきました。
• 同ホストで実行されている他のソフトウェアの影響を受けないパッケージへと変化することで、依存関係から解放された。

CONTAINER CHALLENGE: MASSIVE OPERATIONAL COMPLEXITY

• コンテナは、小さなホストです。 ホストであれば、従来の監視方法が適用出来ると思われえるが、そうではない。

HOST PROLIFERATION

（引用： Monitoring Modern Infractructure（英語） P58 より）

• アプリケーションスタックは、左から右へと変化している。

METRICS EXPLOSION

• コンテナを利用するとMetrics が膨大な数へと増えていく
• コンテナは、ライフサイクルがとても早い

HOST-CENTRIC MONITORING

• ホスト中心の考え方では、非常に苦しい監視運用となることが想像されます

GOAL: SIMPLIFY MONITORING

If you forget about hosts and recenter your monitoring around layers and tags, the complexity falls away and your operations will be sane and straightforward.

訳： ホスト思考はやめて、レイヤーやタグを中心に考えることで、コンテナ監視がシンプルになる。
（引用： Monitoring Modern Infractructure（英語） P61 より）

LAYERS

（引用： Monitoring Modern Infractructure（英語） P61 より）

• アプリケーション層は、APM
• Hypervisor層は、CloudWatch
• 二つの中間層は、Infrastructure

（引用： Monitoring Modern Infractructure（英語） P62 より）

関係する要素を、同じダッシュボードで可視化することで、良い効果的な監視とする。

TAGS

• 多くのケースで、リソースにはTagが付いている（AWS）
• 特定ホストやコンテナなど具体的な視点ではなく、Tagによりグループ化された抽象的な視点にフォーカスする
• Tag を利用することで、クエリなどで、詳細な条件を指定できる

IN A NUTSHELL

Therefore, for effective Docker usage:

1. Monitor all layers of your stack together, so that you can see what is happening everywhere, at the same time, with no gaps
2. Tag your containers so that you can monitor them as queryable sets rather than as individuals

Key Docker resource metrics

• Docker は小さなホストとして捉えることも出来ます。そのため、通常ホストと同様リソースを消費しますが、取得できるMetricsは異なったものとなります。

（引用： Monitoring Modern Infractructure（英語） P64 より）

STANDARD METRICS

• Docker コンテナはシステムCPUとユーザーCPUの使用状況を報告します。
• コンテナのパフォーマンスが低下しているときは、CPUを確認することが効果的です。
• Docker コンテナでは、nice、idle、iowait、またはirqのCPU時間を報告しません。

THROTTLING

• CPUには余裕があるにも関わらず、処理に限界がある場合は、Throttling を確認する。
• CPUシェアやスロットルの調整により、解消することもある。

MEMORY

（引用： Monitoring Modern Infractructure（英語） P65 より）

• メモリに関する 各Metricsを報告します。
• パフォーマンスまたは安定性の問題を調査するのに役立つ可能性がある追加のメトリックには、ページフォルトが含まれます。ページフォルトは、セグメンテーションフォルトまたはメモリではなくディスクからのデータのフェッチを表します（それぞれpgfaultおよびpgmajfault）。
• 従来のホストと同様に、パフォーマンスの問題がある場合に最初に検討する必要があるメトリックには、メモリの可用性とスワップの使用量などがあります。

I/O

（引用： Monitoring Modern Infractructure（英語） P65 より）

• ブロックデバイスごとに、Dockerは次の2つのメトリクスを4つのカウンタに分解してレポートします。読み取りと書き込み、同期と非同期のI / Oです。
• ブロックI/Oは共有されているので、上記のコンテナ固有のI / Oメトリックに加えて、ホストのキューとサービス時間を追跡することをお勧めします。
• コンテナが使用しているブロックデバイスでキューの長さやサービス時間が増加していると、コンテナのI / Oが影響を受けます。

NETWORK

（引用： Monitoring Modern Infractructure（英語） P66 より）

• インバウンドとアウトバウンドのネットワークトラフィックのための別々のMetrics として分けられます。

How iHeartRadio monitors Docker（Example）

• iHeartRadio 社が、Docker を採用した際に抱えた監視課題を例として取り上げています。
• iHeartRadio 社は、順調に導入したが、コンテナレベルのモニタリングが可能な監視サービスを利用していなかった。
• Datadogを導入することで課題が解決する
• 各課題に対して、Datadog導入方法と合わせて説明しています。

Chapter9: Datadog Is Dynamic, Cloud-Scale Monitoring

Datadog was built to meet the unique needs of modern, cloud-scale infrastructure

訳： Datadog は、Monitoring Modern Infrastructure を提供する。
（引用： Monitoring Modern Infractructure（英語） P73 より）

Comprehensive monitoring

• すぐに、Datadogは150以上の一般的な技術から監視データを集めます。
• Datadogエージェントには、事実上すべてのアプリケーションからカスタムメトリックスを収集できる軽量メトリックス集計サーバーも含まれています。

Flexible aggregation

• Datadogのタグ付けに対するネイティブサポートにより、メトリックとイベントをその場で集約して、最も重要なビューを生成できます。
• タグ付けを使用すると、ホストではなくサービスを監視できるため、ユーザーやビジネスに直接影響を与えるパフォーマンス指標に集中できます。

Effortless scaling

• Datadogは、数十、数百、数千のホストがあるかどうかにかかわらず、インフラストラクチャに合わせて自動的に拡張されます。 Datadogは、新しいホストとコンテナーがオンラインになると、それらをサービスとともに自動的に登録します。
• ディスカバリーは、コンテナー化されたサービスがどこで稼働していても継続的にモニターできます。

Sophisticated alerting

• Datadogは、アラートをトリガーするために、事実上あらゆるタイプの監視データを使用できます。
• 固定または動的なメトリックしきい値、外れ値、イベント、ステータスチェックなどについて警告することができます。

Collaboration baked in

• 簡単に共有できるダッシュボード、グラフ、および注釈付きのスナップショットを使用して、チームが同じページに留まるのを支援します。
• PagerDuty、Slack、HipChatなどの業界をリードするコラボレーションツールとシームレスに統合されているため、データの監視に関する会話をできる限り簡単に行うことができます。

さいごに

ここまで読んでいただき、ありがとうございます。
本人もこんなに長くなるとは思わず、まだまだ理解できていないことが如実に現れています。。
一つでもどなたかのお役に立てれば幸いです。

それでは、みなさん Happy monitoring!