Zenn
🤖

ストーリーでわかる！監視と可観測性

2023/04/09に公開
監視
GPT-4
OpenAI
ChatGPT
可観測性
tech

はじめに

この記事では物語を通して監視と可観測性の概要を説明します。舞台は近未来の幼稚園。好き勝手遊んだり喧嘩したりする子供たち（個別のサービスやリソース）、その子たちを見守る保育士（システム管理者）、監視・可観測性のための2体のロボットたちの関係を通して監視・可観測性がどんなものなのかという雰囲気をつかむことができます。

著者はシステム管理が本職ではありません（小さいシステムを独学の手法で管理してた程度です）。本記事は著者の学習もかねてChatGPTに相談しながら作り上げたものです。本職の方から見たら、おかしな点が含まれるかもしれませんが、ご了承ください。あくまで監視・可観測性の概要の雰囲気をつかむ（＝「監視・可観測性完全に理解した」の状態になる」ためのコンテンツと割り切っていただければと思います。

物語に登場するキャラクター紹介

項目名 内容
名前 メトくん
役割 園児や幼稚園の監視を行うロボット
製品名 メトワッチ
趣味 園児たちの健康をチェックすること
好きな色 ピンク
好きな食べ物 データ団子
特技 バイタルデータを瞬時に測ること
項目名 内容
名前 オブちゃん
役割 複雑なトラブルが発生時に可観測性を確保するロボット
製品名 オブノート
趣味 トレースして複雑な問題の原因を見つけること
好きな色 蛍光色
好きな食べ物 データパスタ
特技 多種多様な関係者が関わるトラブルの原因究明
項目名 内容
名前 はる先生
年齢 28 歳
役割 園児たちの保育士、見守り担当(システム管理者)
趣味 アクアリウム飼育、ハイキング
好きな食べ物 パンケーキ、フルーツゼリー
嫌いな食べ物 キムチ
座右の銘 「笑顔は最高の薬」

第 1 節 設定&概要（近未来の幼稚園での監視の始まり）

近未来のある幼稚園では、園児たちの健康や幼稚園設備の安全を守るため、2つのロボットが導入されました。メトくん（製品名：メトワッチ）は、園児たちのバイタルデータや幼稚園設備の状態を監視し、オブちゃん（製品名：オブノート）は、複雑なトラブルが発生した際に可観測性を確保するために活躍しています。

設定(見立て)

キャラ メタファー
幼稚園 システム・製品
園児・幼稚園の設備 各種(マイクロ)サービス・リソース
保育士(はな先生) システム管理者
メトくん 監視ツール
オブちゃん 可観測性ツール
園児のバイタルデータ メトリクス
幼稚園でのトラブル(喧嘩、体調不良、設備不良) イベント、障害
園児の行動履歴・幼稚園の設備の状態 ログ

第 2 節 メトリクス監視

メトくんは、園児のバイタルデータ（体温、心拍、顔色など）や幼稚園の設備の状態（老朽化度合い、水道の水圧、遊具の状態など）をリアルタイムで収集し、はる先生に報告します。

はる先生：「メトくん、子どもたちの様子はどう？」

メトくん：「えっとぉ、みんなの体温とか心拍とか顔色とか、僕がリアルタイムでチェックしてるよ！それに、幼稚園の設備の状態も見てるんだ！」

メトくんは、Prometheusという監視ツールを使っています。以下に、メトくんが利用する監視設定ファイルとアラートルール設定ファイルの例を示します。

# 監視設定ファイル:
global:
  scrape_interval: 15s # データを収集する間隔

scrape_configs:
  - job_name: "kindergarten_metrics" # 監視対象の種類
    static_configs:
      - targets: ["kid1:9100", "kid2:9100", "kid3:9100"] # 監視対象の園児3名

# アラートルール設定ファイル:
groups:
  - name: kindergarten_rules
    rules:
      - alert: HighTemperature # 高熱アラート
        expr: kid_temperature_celsius > 38 # 体温が38℃を超えたらアラート
        for: 1m # 1分間続いたらアラート
        labels:
        severity: critical # アラートの重要度
        annotations:
        summary: "高熱が続いています ({{ $labels.instance }})" # アラートの内容
      - alert: LowWaterPressure # 水圧低下アラート
        expr: water_pressure_psi < 30 # 水圧が30 psi未満ならアラート
        for: 5m # 5分間続いたらアラート
        labels:
        severity: warning # アラートの重要度
        annotations:
        summary: "水道の水圧が低下しています ({{ $labels.instance }})" # アラートの内容

この設定により、メトくんは各園児の体温や幼稚園の設備の水圧を定期的にチェックし、問題が発生した場合はアラートを発行します。

はる先生：「ねぇ、メトくん。この設定ファイルにあるように、もし子供たちの体温が38℃を超えたり、水道の水圧が30 psi未満になったら、どうなるのだったかしら？」

メトくん：「うん、そんなときは僕がはる先生たちにアラートを送るんだよ！体温が高い子には『高熱が続いています』って教えるし、水道の水圧が低いと『水道の水圧が低下しています』って警告するよ！」

メトリクス監視について

メトリクス（Metrics）は、システムやサービスの状態や性能を定量的に表す数値データのことです。メトリクスは監視対象となるシステムやサービスが生成し、これらのデータを解析することでシステムの健全性や問題点を把握できます。一般的なメトリクスには、CPU使用率、メモリ使用量、ディスク容量、ネットワーク帯域使用率、レスポンスタイム、リクエスト数などがあります。

メトリクス監視は、これらの数値データを定期的に収集し、閾値を設定して異常検知やアラート通知を行います。また、過去のデータと比較することで、システムのパフォーマンスの変化やトレンドを把握することが可能です。これにより、システム管理者はリソースの調整や問題の早期発見、性能最適化に役立てることができます。

ただし、メトリクス監視だけではシステム内部の詳細な状態や問題の原因特定には限界があります。ログ監視やトレースなど、他の監視手法と組み合わせることで、より包括的な監視とシステム管理が可能となります。メトリクス監視はシステムやサービスの健全性を維持するための重要な手段であり、適切な設定と運用が求められます。

第 3 節 イベント監視(未来の幼稚園での運動会)

春の運動会のシーズンが近づいてきました。幼稚園長は、園児たちが安全に楽しく運動会を行えるよう、監視ロボット「メトくん」を活用してイベント監視を始めました。運動会では、園児たちが疲れやすく、ケガやトラブルが起こりやすいという特性があるため、はる先生だけでは十分な対応が難しいのです。

はる先生：「メトくん、運動会が近づいてきたわね。子どもたちが無事に運動会を楽しめるよう、一緒に監視していこうね」

メトくん：「うん、はる先生！僕がしっかりイベント監視をするから、大丈夫だよ！」

イベント監視では、メトくんが園児たちのトラブルイベント（ケガや喧嘩）や、幼稚園の設備のトラブルイベント（設備の故障や破損、浸水）をリアルタイムで検出し、はる先生に通知します。これにより、はる先生は素早く対応でき、園児たちの安全や幼稚園の運営に大きく貢献します

メトくん：「はる先生、ぼくがイベント監視で検出したら、すぐにお知らせするね。それで、はる先生がすぐに対応できるようになるんだ！」

はる先生：「ありがとう、メトくん。あなたがいるおかげで、私たちも安心して運動会を迎えられそうよ」

# イベント監視用の設定ファイル (event-monitoring.yaml)

# イベント監視を行う対象
targets:
  - name: 子供たち
    type: 園児
  - name: 幼稚園施設
    type: 施設

# イベント監視のルール
rules:
  - name: ケガや喧嘩が発生した場合
    event_type: トラブルイベント
    condition: 園児同士のケガや喧嘩が発生
    action: 通知

  - name: 設備の故障や破損が発生した場合
    event_type: トラブルイベント
    condition: 幼稚園の設備の故障や破損が発生
    action: 通知

# アラートルール設定ファイル (alert-rules.yaml)

groups:
  - name: event_alerts
    rules:
      # 園児同士のケガや喧嘩が発生した場合のアラートルール
      - alert: ChildTroubleEvent
        expr: event_type == "トラブルイベント" AND condition == "園児同士のケガや喧嘩が発生" # 発動条件
        for: 1m # 1 分間の条件を満たした場合にアラートを発生させる
        labels:
          severity: critical # アラートの重要度
        annotations:
          summary: "園児同士のケガや喧嘩が発生しました。"

      # 設備の故障や破損が発生した場合のアラートルール
      - alert: FacilityTroubleEvent
        expr: event_type == "トラブルイベント" AND condition == "幼稚園の設備の故障や破損が発生" # 発動条件
        for: 1m # 1 分間の条件を満たした場合にアラートを発生させる
        labels:
          severity: critical # アラートの重要度
        annotations:
          summary: "幼稚園の設備の故障や破損が発生しました。"

イベント監視は、メトリクス監視とは異なり、特定のイベントが発生したときに通知を行うものです。メトリクス監視では、園児のバイタルデータや幼稚園の設備の状態を一定の間隔で監視し、異常があれば保育士に通知します。しかし、イベント監視では、具体的なトラブルや故障が発生した瞬間に保育士に通知することで、迅速な対応が可能となります。

イベント監視について

イベント監視は、システムやアプリケーションが発行する特定のイベントや状態変化を検出し、それらを監視・管理するプロセスです。イベントには、システムエラー、セキュリティ違反、リソース障害、アプリケーションの状態変化など、さまざまな種類があります。イベント監視は、これらのイベントをリアルタイムまたは定期的にチェックし、事前に定義されたアクションを実行します。アクションには、アラート通知、自動的な問題解決プロセスの開始、エスカレーション手順の実行などが含まれます。

イベント監視の主な目的は、システムの健全性やセキュリティを維持し、問題が発生した場合に迅速に対応できるようにすることです。イベント監視は、システム管理者にリアルタイムの情報を提供し、彼らがシステムの状態を監視し、適切な対策を講じるのに役立ちます。

メトリクス監視とイベント監視におけるアラートの違い

メトリクス監視とイベント監視は、システムやサービスの状況を監視する方法の違いから、アラートにも違いがあります。

  • メトリクス監視におけるアラート
    • メトリクス監視では、システムやサービスのパフォーマンス指標（メトリクス）を定期的に収集し、それらの値が予め設定した閾値を超えた場合にアラートを発することが一般的です。例えば、CPU使用率が80%を超える、メモリ使用量が1GBを超える、レスポンスタイムが500ミリ秒を超えるなど、数値ベースの条件でアラートが発生します。
  • イベント監視におけるアラート
    • イベント監視では、システムやサービスが発生させる特定のイベント（例：エラーメッセージ、システム障害、特定のアクションなど）に対して監視を行い、そのイベントが発生した際にアラートを発することが一般的です。イベント監視は、数値ベースのメトリクスでは捉えられない問題や状況に対してアラートを発することができます。

第 4 節 ログ監視と監視の限界

近未来の幼稚園では、メトくんを使ったメトリクス監視やイベント監視が一般的になっていますが、ログ監視も重要な役割を果たしています。ログ監視では、園児の行動履歴や幼稚園の設備の履歴などが詳細に記録されています。はる先生は、これらのログデータを目視で確認し、園児や設備の状況を把握できます。

メトくん：「ねぇねぇはる先生、今日のお昼休みになんとなく園児たちが元気がなかったみたいだけど、どうしてだろう？」

はる先生：「そうね、メトくん。ログデータを見てみましょうか」

ログデータを確認すると、園児たちが元気がなかった理由が分かりました。実は、前日の遊びが長引いて、みんなが十分な睡眠をとれていなかったからでした。

はる先生：「メトくん、ログデータを見ると、昨日の遊びが長引いて、みんなが十分な睡眠をとれていなかったみたいね」

メトくん：「ほんとうだ！ログデータってすごいね！」

ログ監視の重要性

ログ監視は、メトリクス監視やイベント監視とは異なる観点からシステムの状態を把握できます。メトリクス監視では、園児のバイタルデータや幼稚園の設備の状態などの数値的な情報を収集し、イベント監視では、園児のトラブルイベントや幼稚園の設備のトラブルイベントなどの特定の瞬間を捉えます。一方、ログ監視では、園児の発言や行動、幼稚園の設備の検査履歴や修理履歴など、より詳細な情報を取得できます。

これにより、はる先生は、園児や設備の問題が発生した際に、その原因を特定しやすくなります。また、ログデータを遡ることで、問題が発生する前の状況も把握できるため、問題の発生を予防することも可能です。

ログ監視の大変さ

はる先生：「メトくん、このログデータにはたくさんの情報があるけど、どれが重要なのかな？」

メトくん：「うーん、確かにたくさんの情報があって、どれが大事なのか分からないね。でも、パターンマッチングやフィルタリングの機能があるから、効率的にログデータを分析できるよ！」

ログ監視はいいことだけではありません。まず、ログデータの量は通常膨大なため、そのままでははる先生がすべてのデータを把握するのは困難です。さらに、ログデータには多くのノイズが含まれており、問題の特定が困難な場合があります。例えば、園児同士の些細な言い争いや、設備の一時的な不調など、本来対処が不要な情報もログデータに含まれています。これらのノイズを適切に除外しながら、重要な情報を見つけ出すことは、はる先生にとって大変な負担となります。
このような問題に対応するために、監視ツールにはパターンマッチングやフィルタリングの機能がついており、効率的にログデータを分析し、問題の特定や対処に集中することを支援しています。

監視の限界

ただ、ログデータはテキスト形式であり、後で述べるトレース用のデータのように構造化されていないため、複雑な解析に向いていません。また、特定のパターンに当てはまらない問題や、新たな問題が発生した際には、対処が難しい場合があります。これはログ監視に限らずメトリクス監視やイベント監視も含めた監視全般に言えることです。

このような複雑な問題に対応するためには、可観測性が重要となります。可観測性を確保することで、はる先生は、園児や幼稚園の設備で発生する複雑なトラブルに対処しやすくなります。次の節では、可観測性の概念とその実現方法について詳しく解説します。

第 5 節 複雑な問題に対処するための可観測性

オブちゃんの登場

さて、前節ではメトくんを使った監視の限界について触れました。そこで登場するのが、可観測性を確保するロボット「オブノート」です。本文中では園児たちから「オブちゃん」という愛称で呼ばれています。オブちゃんは、複雑な問題に対処する際に有効なツールで、メトくんと連携することで幼稚園全体の状態をより深く理解できます。

複雑なトラブルの発生

ある日、園児たちが水遊びをしていると、突然水道の水が出なくなりました。保育士はメトくんを使って園児たちと設備の状況を調べましたが、原因が特定できませんでした。そこで、オブちゃんを使って、より詳細な情報を取得することにしました。

オブちゃん：「メト、さっきから何パニくってんだ？」

メトくん：「オブちゃん、助けて！ボク、複雑すぎてどうしても原因がわからないんだ…」

はる先生：「オブちゃん、お願いします。私たちも力になりますので、一緒に問題を解決しましょうね」

オブちゃん：「しゃーねーなー。解析するか」

オブちゃんを活用した可観測性の確保

オブちゃんは、メトくんが収集したメトリクスやイベント情報に加え、園児たちや施設の関係性や因果関係を可視化するトレース機能を持っています。

オブちゃんは、設備の全体像や園児たちの動きを追跡し、問題の根本原因を特定しようとしました。トレース機能を利用して、水道設備の不具合を探索的に調査しました。

オブちゃん：「この蛇口だけ出なくなってんのか。いつからだ？」
(直近1週間のデータ収集）
オブちゃん：「特に気になるところはないな。他の蛇口のデータと比較するか」
(最新の全蛇口の状態データ収集）
オブちゃん：「似てるけど蛇口の形状が2種類に分かれてるな。形状に起因するのか？」
(問題の形状の蛇口と同じ形状の蛇口に絞って過去のデータを取得）
オブちゃん：「このタイプの蛇口の保守は3年か。で、メンテナンスデータはと。。。ん？問題の蛇口だけメンテナンス記録が5年も前だぞ！！」

オブちゃんの分析により問題の蛇口の老朽化が原因であることが突き止められました。蛇口のタイプは2種類あり「メンテナンスが10年毎でよいもの」「メンテナンスが3年毎に必要なもの」でした。問題となった蛇口は後者のタイプで本来3年単位で行われるべきメンテナンスが5年以上も行われていませんでした。早速オブちゃんがメンテナンス会社に問い合わせたところ、訪問チェックが行われました。業者からの説明としては「10年毎のタイプの蛇口と間違われてメンテナンスされなかったのだろう」とのことでした。
ともあれ、オブちゃんの分析をきっかけに問題を解決できました。

人間が見ることを目的としたテキストデータだった監視データとは異なり、今回オブちゃんが解析に使ったトレースデータはツールによる分析を前提とした構造化データでした。
そのため、オブちゃんは探索的かつ複雑な情報収集・フィルタリング・分析を行うことができたのです（この例では"蛇口のタイプ"と"最後にメンテナンスされた日付"という条件の組み合わせを使っています）。

可観測性が出てきた理由

近年、クラウドサービスが急速に普及し、AWS、GCP、Azureなどのプラットフォームが主流となっています。その影響でシステムの構築・運用が大きく変化し、マイクロサービスアーキテクチャやIaCのような新たなノウハウ・技術が登場してきました。これらの技術により、システムのスケーリングや変更が容易になりましたが、一方でシステム全体の複雑さが増しています。

マイクロサービスアーキテクチャでは、システムが複数の独立したサービスに分割され、各サービスがそれぞれ独立して開発・運用されます。これにより、システム全体の柔軟性が向上しますが、サービス間の相互依存や通信が増えることで、問題の原因究明が難しくなっています。

また、IaCを用いることで、インフラ構成のバージョン管理や自動化が可能になります。これにより、インフラのスケーリングや変更が容易になりますが、同時に構成の複雑さが増し、意図しない変更やバグの発生リスクも高まります。

これらの技術の発展により、システムはより複雑かつ動的なものになっており、従来の監視ツールだけでは十分なシステム管理ができなくなっています。監視ツールは既知の問題や指標をもとに動作しますが、現代のシステムでは予測できないような複雑な問題が頻繁に発生しています。

そこで、探索的に問題を分析し、システムの内部状態を理解するための新しいアプローチである可観測性が登場しました。可観測性はシステム全体の見通しを改善し、複雑な問題に対処するために必要な情報を提供します。これにより、従来の監視だけでは対応できなかった問題にも対処することが可能になり、システム管理がより効果的に行えるようになりました。

第 6 節 監視のアンチパターン

ある日、幼稚園でお遊戯会が開催されることになりました。はる先生は、園児たちが安全に楽しめるように、メトくんを使って監視を行いました。しかし、監視方法に問題があり、いくつかのアンチパターンが発生しました。

アンチパターン1: 過剰な監視

お遊戯会の当日、はる先生はメトくんを使って園児たちのバイタルデータや行動を監視しましたが、過剰な監視が行われてしまいました。

メトくん：「ぼく、今日はみんなのお遊戯をしっかり見てるよ！でも、ちょっと心配だから、体温とか心拍数もチェックしておこうかな」

園児たちは、メトくんによる過剰な監視にストレスを感じ、楽しむどころではありませんでした。

オブちゃん：「おいメト、落ち着け。過剰な監視はかえって園児たちにストレスだぜ」

対策: 適切な監視範囲と頻度を設定する

はる先生は、メトくんに対して適切な監視範囲と頻度を設定することにしました。

はる先生：「メトくん、お遊戯会の時は、体温や心拍数をチェックするのは、定期的に一度だけにしましょう。それ以外の時は、園児たちが楽しんでいる様子を見ていてね」

メトくん：「わかったよ、はる先生！過剰な監視はストレスになるんだね。これからは、うまく監視するよ！」

この対策により、園児たちもストレスを感じることなくお遊戯会を楽しむことができました。

監視システムでは、適切な監視範囲と頻度を設定することが重要です。過剰な監視は、システムに対する負荷を引き起こすことがあります。適切な監視範囲と頻度を設定することで、効果的な監視が実現されます。ただし、範囲や対象を広げてしまうとアンチパターン1に陥ってしまうため、注意が必要です。

アンチパターン 2: 監視の範囲が狭い

一方で、お遊戯会の舞台全体をカバーしていない監視が行われました。これにより、はる先生は一部の園児の様子しか把握できず、トラブルが発生する可能性が高まりました。

メトくん：「あれっ、あそこにいる園児たちの様子がよく見えないなぁ…」

はる先生：「メトくん、監視の範囲が狭いわね。全員を見渡せるように設定を変えましょう」

# メトくん設定ファイル
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "園児"
    static_configs:
      - targets:['園児A', '園児B'] # 監視対象が限定的（前提：見るべき園児はもっといる）

対策: 監視範囲を適切な範囲に広げる

はる先生：「メトくん、もう少しほかの子たちの様子も監視しましょうかしら」

メトくん：「うん、わかったよ！」

はる先生とメトくんは、メトくんの設定を変更して、お遊戯会の舞台上の園児たち全体をカバーできるようにしました。これにより、園児たちの様子を監視でき、トラブルを未然に防ぐことができました。

メトくん：「ほら、これでみんなの様子が見えるよ！」

はる先生：「すごいわね、メトくん。これで安心してお遊戯会を楽しめるわ」

監視の範囲を広げるポイント

  • 監視対象の全体像を把握し、重要な部分がカバーされているか確認する
  • 監視ツールの設定や配置を調整し、監視範囲を適切に広げる
  • 定期的に監視範囲を見直し、状況の変化に対応できるようにする

監視の範囲が狭いと一部の問題に気づけないため、適切な対応ができなくなることがあるということです。監視範囲を広げることで、問題が発生するリスクを減らすことができます。

アンチパターン 3: 不適切なアラート設定

ある日、近未来の幼稚園で監視ロボットのメトくんが、園児たちの健康状態を監視していました。しかし、メトくんが設定されていたアラートの閾値が適切でなく、ちょっとした体温の変化でもアラートが鳴ってしまい、保育士たちが大変なことになっていました。

メトくん：「あれっ？またアラートが鳴っちゃった…。でも、この子は元気そうなのになぁ…」

はる先生：「メトくん、アラートがちょっと敏感すぎるかもしれないわね。私たちも状況を把握しきれなくなってしまう。もう少し適切な閾値に設定し直さないと」

メトくん：「そうだね、はる先生。アラート設定は重要だけど、適切な閾値にしないと意味がないんだ。アラート疲れになっちゃうし、本当に大事な時に対応できなくなるからね」

そこで、はる先生はメトくんのアラート設定を見直し、適切な閾値に調整しました。これにより、本当に重要なアラートだけが鳴るようになり、保育士たちは効率的に対応できるようになりました。

このように、不適切なアラート設定が原因でアラート疲れが発生すると、保育士たちが本当に重要なアラートに対応できなくなってしまいます。適切なアラート設定を行うことで、アラート疲れを防ぎ、効率的な対応ができるようになります。

第 7 節 可観測性のアンチパターン

ある日、近未来の幼稚園で複雑な問題が発生しました。園児たちが遊んでいると、突然遊具が壊れてしまい、園児たちがパニックになってしまいます。

アンチパターン1: 場当たり的な解析

オブちゃんは早速原因を調べるために、遊具の周りのすべての情報を集め始めます。しかし、その情報量はあまりにも多く、オブちゃんはどこから手を付けていいかわからなくなってしまいます。

オブちゃん：「うーん、これだけの情報があっても、何が原因なのかわからないぞ」

はる先生：「落ち着いて、オブちゃん。まず今自分が「分かっている事」「分かっていない事」を把握した方がいいわね。そのうえで仮説を立てて検証するためにデータを収集・分析すると着実に「分かっている事」が増えて問題の解決に近づけると思うわ」

可観測性が取り扱うような複雑なシステムにおいて、出会う障害は大抵の場合はこれまでに出会ったことがないような障害です。そのような複雑な問題に取り組む場合は探索的なアプローチが重要となります。
テストの分野では「探索的テスト」というテスト手法があります。このような手法の考え方を学んでみるのも可観測性での問題分析を行う上で役に立つかもしれません。

まとめ: 監視と可観測性の適切な使い分け

この記事を通じて、近未来の幼稚園での監視と可観測性について学んできました。物語を通じて、それぞれの概念、プラクティス、アンチパターンを理解し、それらを適切に使い分ける方法を学びました。ここでは、監視と可観測性の使い分けについて簡潔にまとめます。

監視

監視は、システムやサービスの状況を定期的にチェックし、問題が発生した際にアラートを発することを主な目的としています。主にメトリクス監視、イベント監視、ログ監視などの方法があります。

特徴

  • 予め設定された閾値やイベントに対して反応する
  • パフォーマンス指標やログデータを収集・分析する
  • 過去のデータを基にトレンドやパターンを把握することができる

向いている用途

  • できるできるできるできる
  • 予期される問題やパフォーマンス低下に対応する
  • 障害発生時に迅速な対応や復旧を行う

可観測性

可観測性は、システムやサービスの内部状況を理解しやすくすることを目的としており、メトリクス、トレース、ログの3つの要素から成り立っています。これらの要素を組み合わせることで、システムの内部状況をより詳細に把握し、複雑な問題や障害に対処できます。

特徴

  • システム内部の状態や挙動を可視化する
  • メトリクス、トレース、ログの3つの要素を組み合わせて分析する
  • 障害発生時に原因追跡やデバッグが容易になる

向いている用途

  • 複雑な問題や障害の原因を特定し、解決する
  • システムやサービスのパフォーマンス改善や最適化
  • 開発や運用チームが効率的にコラボレーションする

監視と可観測性の主な違い

項目 監視(メトくん) 可観測性(オブちゃん)
概要 パフォーマンス データの収集と分析 理解と診断のために内部状態を公開するシステムの能力
注力ポイント 事後対応型で、発生後に問題を特定します 問題が発生する前にシステムの動作を積極的に理解する
指標 定義済みの一連のパフォーマンス インジケーター システム状態を理解するためのカスタムのユーザー定義インジケーター
アラート 事前定義されたしきい値に違反したときにトリガーされます 事前定義されたしきい値に限定されず、さまざまな異常に使用できます
データ収集 受動的で、必要なときにのみデータを収集します アクティブで、より良い分析のためにデータを継続的に収集します
イベント監視 特定のイベントまたはシステムの動作パターンを監視します より深い理解のために、より大きなコンテキストの一部としてイベントを観察します
ログ監視 ログデータの収集と分析に重点を置いています ログは、より包括的なビューのためのデータ ソースの 1 つにすぎません
トレース ネイティブにはサポートされていません 本質的に、システム全体でリクエストを追跡して、理解を深めます
データ 粒度 粗く、重要なデータ ポイントのみ より細かく、より深い洞察を得るために、より広い範囲のデータ ポイントをキャプチャします
ツーリング Nagios、Zabbix,Prometheus などの従来の監視ツール Honeycomb、OpenTelemetry などの可観測性に重点を置いたツール
(Prometheus 等の監視ツールの機能として組み込まれているばあもある)
適応性 事前定義されたルールとメトリックに基づいて制限されます 柔軟で、進化するシステムとその要件に適応できます
トラブルシューティング 問題を特定できますが、根本原因は特定できません 根本原因とシステムの動作を特定するのに役立ちます
スケーラビリティ システムが複雑化するにつれて、スケーリングが困難になります システムの複雑さと成長に合わせて拡張できるように設計されています
メンテナンス 関連性を維持するには、定期的な更新が必要です システムの変更に対する回復力が高く、自己保守します
ユースケース インフラストラクチャのヘルス チェック、システムの稼働時間、リソースの使用状況 パフォーマンスの最適化、異常検出、システム動作分析

監視は、システムやサービスの安定性を維持し、問題が発生した際に迅速に対処するために適しています。一方、可観測性は、複雑な問題や複数の要素が関与する問題の根本原因を特定するために適しています。

適切な使い分けをすることで、システムやサービスの効率的な管理が可能となります。シンプルな問題や障害には監視を用い、複雑な問題や根本原因の特定が必要な場合には可観測性を活用することが望ましいです。

さいごに

次に学習すべきもの

監視・可観測性について参考になりそうな本を以下に挙げておきます（私も読んでる途中です）

1. 「入門Prometheus」

https://www.oreilly.co.jp/books/9784873118772/

  • 監視ツールのデファクトスタンダード（？）であるPrometheusの入門書です。導入や設定の基本などが書かれています。
  • 第2版の原著がこの前（2023年4月）出ました。しばらく待てば日本語訳本も出る可能性が高いです。

2. 「入門監視 ―モダンなモニタリングのためのデザインパターン―」

https://www.oreilly.co.jp/books/9784873118642/

  • 特定のツールに限らず、監視の基本的な考え方や手法について書かれています。

3. 「オブザーバビリティ・エンジニアリング」

https://www.oreilly.co.jp/books/9784814400126/

  • 可観測性本。可観測性とは何か、なぜ監視では原題のシステムに対応できなくなっているのかなど、分かりやすく学べます。

記事を作った感想(言い訳)

これまで「デザインパターン」「ソフトウェアアーキテクチャ」「チートシート」とChatGPTの支援でいろいろと作ってきましたが、今回が一番難しかったように思えます。以下に簡単に今回の苦労したポイントを書いておきます。

  1. キャラ設定を入れた
  • プロンプトを打つ際に、舞台設定・キャラ設定を含めたコンテクストを入れる必要がありますが、ChatGPTのキャッシュに載らず、当初の計画よりも設定を大幅に簡略化したり設定を適度に再入力する必要がありました。
  1. 見立ての設定が微妙にずれていた
  • 今回の見立ては「好き勝手遊んだり動いたりしている幼稚園児ってWebシステムのサービスに似てる」という発想から舞台を幼稚園に設定しましたが、可観測性が出てきた理由の1つでもある「クラウドサービスの普及に伴い、サービスが複雑化して障害の問題も複雑化した」等、いくつかのポイントをうまく物語に織り込むことができませんでした（スケーリングの話をする際に子供を複製するといった話になりかねません）。物語の設定選びの重要性を学びました。
  1. 知識が比較的体系化されていない、項目の境界があいまい
  • デザインパターンやソフトウェアアーキテクチャは1項目ごとにカバーする範囲が明確なため、ChatGPTに意図した内容を説明してもらいやすかったのですが、監視と可観測性は項目の境界があいまいなため、意図した内容を説明してもらうのが難しかったです。
  1. そもそも分野に疎い
  • このような難易度が高い条件下において、更に私の監視・可観測性に関する知識がそれほどななかったためChatGPTが返してきた内容に対して、適切なフィードバックをすることがあまりできませんでした。もっとこの分野に詳しい方であれば同じアプローチでもより充実した記事にできたと思います。

これらの点も含めて現在進行形でChatGPT相手に色んな試行錯誤をしています。ChatGPTに記事や書籍を作ってもらう際の勘所については別途どこかでまとめようとは思います。

せんでん

今回の記事と同様にChatGPTを使ってまとめた本の紹介です。こっちはそこそこいい感じにまとめられていると思います（私自身読み直しながら、気づいた点や疑問点を改善・補充しています）。
もちろんどちらも全文無料です。


「【図解】ストーリーでわかる！ソフトウェアアーキテクチャ13選」


「デザインパターンの絵本」

以上、お疲れさまでした。

Discussion