監視システムの構成要素

監視サービスは何で構成されているのでしょうか?

構成要素を知ることで、目的に沿った本質的な監視ツールの選定やAWSの監視サービスのキャッチアップに役立つでしょう。

以下は、以前私のブログ『監視アンチパターン5つ』でご紹介した書籍で紹介されていた、機能ベースのコンポーネントが疎結合された監視プラットフォームという一つの監視構成で触れられていたものです。

監視システムの構成要素

まずは以下にツリー状でご紹介します。
これらはモノリシックなツールでも含まれています。

- データ収集
   ├─ 収集方法
   │   ├─ プル型
   │   └─ プッシュ型
   └─ 収集対象
       ├─ メトリクス
       │   ├─ カウンタ
       │   └─ ゲージ
       └─ ログ
           ├─ 非構造化ログ
           └─ 構造化ログ
- データストレージ
   ├─ メトリクスの保存方法
   │   └─ 時系列データベース
   └─ ログの保存方法
       ├─ シンプルな通常のファイル
       └─ 検索エンジン
- 可視化
   ├─ 付属のツールに依存しない
   ├─ 円グラフは使わない
   └─ 視点とスコープが大事
- 分析とレポート
   ├─ SLAへの昇華
   └─ nナイン(99.99%=フォーナイン)
- アラート
   └─ アラート=質問を投げかけるもの

それぞれ解説していきます。

1. データ収集

収集方法

プル型

プル型は、監視サービスがリモートノードに対してノードの情報を送るようにリクエストを送ります。

サービス例:SNMP, Nagios

プッシュ型

プッシュ型は、エージェント(クライアント)が送り先に対して、一定間隔あるいはイベントが発生したタイミングでデータをプッシュ(送信)します。
プッシュ型では、クラウド環境のような分散アーキテクチャではスケールがしやすくなり、多くのケースでプル型よりも柔軟で便利であるようです。

サービス例:syslog, collectd

収集対象

上記では収集方法をご紹介しました。ここでは、収集するデータをご紹介します。

結論、2種類あります。1つはメトリクス、もう一つはログです。

メトリクス

メトリクスには、2つの表現方法があります。

カウンタは増加していくメトリクス、ゲージはある時点の値です。

カウンタ

増加していくメトリクス。イベントの発生回数を数えるメトリクスともいえます。時間と共に増加する一方向性を持ちます。

例えば、車の走行距離計やWebサイトに訪れる累計人数、特定のエラーの発生回数などをカウントします。

カウンタには上限があり、上限に達すると最初に戻り、0から始まります。

ゲージ

ある時点の値。ある時点のみなので、それ単体では過去と未来どちらへの示唆も生み出されません。時系列データベース(TSDB)に保存することで意味を表せます。

ゲージ型は時間と共に増減する両方向性を持ちます。

例えば、CPU使用率やメモリの使用量、ディスクの空き容量などが該当します。

ログ

基本的には連続した文字列のことで、システムやアプリケーションが行った操作の記録や、発生したイベントの履歴をタイムスタンプによって関連付けられたものです。

メトリクスよりもかなり多くの情報を持てますが、多いが故にパース(解析処理)もまた必要になります。

ログには2つのタイプがあります。
構造化ログと非構造化ログです。

収集方法:ログ転送(ほとんどのOSやロギングデーモンでサポートされている⇒複数のシステムのログを一か所で分析できる)

サービス:syslogデーモンなど

非構造化ログ

HTTPリクエストなど、そのまま収集されたものです。例えば以下のようなものです。以下はApacheのHTTPサーバーのログエントリの例です。

127.0.0.1 - frank [10/Oct/2023:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
構造化ログ

JSONなどで構造化されたものです。JSONでは、キーと値のペアにすることで、各フィールドを理解しやすくします。

以下に先ほどの非構造化ログをJSON形式で成形したものを記載しました。

{
  "ip_address": "127.0.0.1",
  "user_id": "frank",
  "timestamp": "10/Oct/2023:13:55:36 -0700",
  "request_line": {
    "method": "GET",
    "resource": "/apache_pb.gif",
    "http_version": "1.0"
  },
  "status_code": 200,
  "response_size": 2326
}

2. データストレージ

収集したデータをどこに保存するか。データのタイプによっては特別な方法で保存することになるようです。

メトリクスの主な保存方法として時系列データベース(TSDB)、ログの主な保存方法としてシンプルな通常のファイル検索エンジンの2つがあります。それぞれご紹介します。

メトリクスの保存方法

時系列データベース

基本的にはタイムスタンプと値のペアで構成される、時系列データ専用のデータベース。
タイムスタンプと値(キーと値)のペアをデータポイントといいます。

大抵のTSBDでは、間引き(roll up)有効期限切れ(age out)が発生します。

間引きは一定期間毎に複数のデータポイントが1つのデータポイントに集約し、データ量を減らす機能です。例えば毎秒収集されるデータポイントを毎分の平均値に集約するなど、平均化するのがよく使われる手法です。

有効期限切れは一定期間経過したデータを自動的に削除する機能です。データの種類や重要性、法的な要件などによって削除対象を設定できます。

サービス:RRD(Round Robin Database), Graphite, Whisper

AWSにおいては、S3バケットにデータをエクスポートして、データのライフサイクルを管理するなどして対応できますね。

ログの保存方法

シンプルな通常のファイル

テキストファイルやバイナリファイルなどの形式で直接ディスクに保存します。

ローカルストレージに保存することもあれば、ログ管理システムやログサーバに保存することもあるでしょう。

書籍では、rsyslogでログを他のsyslogサーバへ転送する例が紹介されていました。

検索エンジン

ElasticSearchSplunkなどがその例です。

検索エンジンに保存されると、インデックスが作成され、これにより大量のログデータから高速に特定の情報を検索したり、複雑なクエリを実行することができるようになります。

3. 可視化

収集・保存したデータを見やすくするコンポーネント。

サービス:Grafana, Smashingなどのダッシュボード製品やフレームワーク。たくさんあるらしい。

付属のツールに依存しない

モノリシックなツール(NagiosやSolar Winds NPMなど)では、付属のダッシュボードがありますが、これは『監視アンチパターン5つ』のアンチパターンの一つ、「1. ツールに依存する」でいえばアンチパターンです。
目的に沿って適切な可視化を行わなければ、監視の本質から逸れてしまいます

円グラフは使わない

円グラフの主な目的はある時点の状態の可視化であり、過程や過程のトレンドといった情報が含まれないため、監視には大抵の場合そぐわないようです。
円グラフではなく棒グラフがよい場合が多いようです。

視点とスコープが大事

最高のダッシュボードは、1つのサービスあるいは1つのプロダクトのステータスを表示することに焦点を絞られるべきだそうです。

また、付属のツールによって作られるのではなく、システムを運用している人たちやそのサービスを最もよく理解している人たちに作られるべきのようです。

4. 分析とレポート

SLAへの昇華

監視データによっては、可視化を超えてSLA(Service Level Agreement)へと昇華すると、更に有益になるでしょう。

nナイン(99.99%=フォーナイン)

可用性は基本的に9の数で表します。
例えばAWSサービスのEC2はマルチAZであれば99.99%フォーナインと読みます。

計算の公式は以下です。

可用性(%) = 稼働時間 / 総運用時間

総運用時間はコンポーネントの稼働時間とダウンタイムの和となり、ダウンタイムが長いと可用性が下がります。

サンプリングエラーとSLA算出の難しさ

標本化定理(ナイキスト・シャノンのサンプリング定理)というものがあるらしく、これによれば「2分間のダウンタイムを計測するには、1分間隔でデータを収集する必要があります。したがって、1秒間のダウンタイムを計測するにあ、1秒未満の間隔でデータを取集する必要があります[1]。」

[1] M. Julian, Practical Monitoring: Effective Strategies for the Real World, p. 27 Translated by 松浦隼人, Tokyo, Japan: オライリー・ジャパン, 2019. (Original work published 2017)

5. アラート

アラートとは質問を投げかけるものです。

監視の目的を理解せずにアラートを構築するのは、またアンチパターンの一つですね。

まとめ

以上、監視システムの構成要素でした。

どの監視システムもこれらで構成されており、逆に言えば、何らかの監視システムや監視ツール(ライブラリなども含む)を理解する際に、これらの構成要素に注目することで、何に長けているのか、何を担当するツールなのかを理解することができます。

それにより、より監視の目的に沿ったツール選定ができるでしょう。

それではまた。

Last modified: 2023-06-28

Author