「入門監視」について

  • 大きく2部に別れており、前半の1章から4章は、監視の基本原則について、
    後半の5章から11章は監視の戦略について、それぞれ書かれている
  • この記事は、前半部分の「監視の基本原則」から学んだことについて書いています。
  • 書籍はこちら

学んだこと

本書を通して、以下のことを学びました。

  • ユーザ視点優先の監視を行う
  • 監視ツールの得意とするところを理解したうえで、複数のツールを組み合わせる
  • 監視は自動化する

それらについての詳細は以降で述べていきます。

私の監視ツールの遍歴

本題に入る前に、今まで私が経験してきた監視ツールを書き出してみました。
振り返ると、昔は動いているとどうかを監視するのが主目的だった気がします。
技術の進歩や時代背景もあるのかもしれないですが、最近は動いているのは当たり前で、
多くの場合そのサービスの品質を向上させるために監視をすることが目的となっている気がします。

  • Netseint(Nagios) / Bigbrother / MRTG
    • 約20年ほど前にインフラエンジニアとして働き出した頃はこういったツールが主流だったと記憶している
  • Nagios / monit / munin
    • それからしばらくは、Nagiosが主流で、メトリクス監視のツールがMRTGからMuninに置きかわったのは10年くらい前かな
  • Nagios / monit / Prometheus
    • 私の環境においては、未だNagiosがメインで、メトリクス監視のツールがここ3年くらいでPrometheusに置きかわった

ユーザ視点優先の監視を行う

この本を流し読みして一番印象に残ったのが、ユーザ視点優先で監視を行うことです。
ツールの遍歴のところで少し触れましたが、一昔前の監視は主にシステムがどういった状態にあるのか、
システムは自分たちが設計した範囲で正常に可動しているか等、システムを中心とした監視をしていた気がします。
少なからず、私においてはその認識で監視について考えていました。
また、アラートになる＝サービスに支障がでるなので、そうならないように、
如何に事前にアラートの兆候を検知するかに躍起になっていたのを思い出します。
そのため、Nagiosのwaringアラートを大量に出していた気がします。この本でいうところのアンチパターンに含まれる監視です。

今はどうかというと、時代の背景（いろんなポジションでユーザファーストの考え方が浸透している）のもあり、ここ5年くらいはユーザ視点で物事を考えることが私自身も増えて来た気がします。 そんな中でシステム構成を変更するタスクを行う機会があり、それに合わせて監視を見直そうと思い、本書を読みました。
「ユーザ視点優先で監視を行う」という一文に目がとまり、当たり前と思う半面、今の監視はユーザ視点でできているか？という疑問もありました。

私の業務上の責務はメール・DNSの安定稼働と信頼性向上なので、メール送信という観点で考えたことを記載します。

ユーザ視点でメール送信の監視を行う

まずは、ユーザがメールを送信する流れを考えました。

  1. メールソフトを起動する
  2. メールを書く
  3. 送信ボタンをクリックする

上記でサーバとの接続の部分はどこになるかというと、「送信ボタンをクリックする」の部分です。
送信ボタンをクリックすると、サーバ側では大きく以下の3つが行われます。

  1. smtp(基本はsmtpsでの接続)プロトコルでメールクライアントからの接続を受け付ける
  2. ユーザの認証を行う
  3. メールを配送する

この点から監視すべき項目は以下になると考えました。

  1. 送信メールサーバにsmtpで接続することができる
  2. ユーザ認証が成功する(監視する際には認証エラーがでないことを監視)
  3. メールの配送ログのステータスが正常

この時点で上記の内容のうち実施できていたのは1つだけでした。

  1. 送信メールサーバにsmtpで接続することができる

既存システムの監視はもちろんこれだけではなく、他にもいろんな監視項目があります

サーバの監視であれば、十分な気がしますが、ユーザ視点で見ると現状の監視では不十分だと認識することができました。

監視ツールの得意とするところを理解したうえで、複数のツールを組み合わせる

「専門化されたツールを複数使い、それらを疎に結合させて、監視プラットフォームを作ることで、
より柔軟性があり、問題の少ない監視スタックが作れることがわかった」と本書に記載がある。
時代の背景もあるのではと思うが、監視に限らず専門性に特化した人やモノを組み合わせて柔軟性を高くする傾向にあると感じている。
これは、変化のスピードが従来より早くなってきており、それに適応していく手段を考えた結果だと私は考えている。
そのため、監視においてもツールやその役割や監視方法が今後早いスピードで変化してく可能性を考慮すると、
専門化されたツールを複数使い、組み合わせて監視プラットフォームを作るという点に共感し、自身が監視しているシステムにも取り入れていきたいと思います。

監視は自動化する

確かに自動化は素晴らしいと思います。 監視対象のホストが起動したら勝手に監視が開始されるのが理想だと私も思います。 監視の自動化の必要性については、仮想化(主にコンテナ)が主流になってきたことが大きく影響していそうです。
都度IPが変わったり、死んだり、生まれたりを繰り返したりするシステムを想像すると、 手動で監視を追加することがそれだけで1つの職種になりそうな感じで、とても現実味がないです、
そういった環境下においては、監視の自動化の恩恵を大きく受けると思います。
私のが関わっているシステムは、物理サーバが多く頻繁に構成情報が変更されることはありません。
そのため、一度監視の設定を行うと大きな構成変更がない限りは監視設定を変更しないため、自動化の恩恵を受けにくい環境ではあると思います。
ただし、自動化自体はとても良いことだと私も思うので、可能な限り自動化を進めていきたいと考えています。

監視の自動化については、まだまだ技術的な知見が足りていないので、引き続き学習していく予定です。

Appendix

本書の第2章にあった監視サービスのコンポーネントの内容を簡単にまとめたものです。

監視サービスの構成要素

  • データ収集
    • プル
      • 監視サーバ上に監視対象の設定を記述して管理する
      • 監視サーバから監視対象に対して値を取得しにいく
    • プッシュ
      • 監視サーバ上に監視対象の設定を記述する必要はない
      • 監視対象から監視サーバに対して値を送る
    • どちらのタイプの監視ツールを採用するかについては、それぞれのメリット・デメリットを把握したうえで、システム構成や監視項目によって決める必要がある
    • メトリクス
      • メトリクスには、カウンタ、ゲージという2つの表現方法がある
      • カウンター
        • 増加していくメトリクス
      • ゲージ
        • ある時点の値を表すメトリクス
    • ログ
      • 基本的には連続した文字列のことで、いつイベントが発生したかを示すタイムスタンプが関連付けられているもの
      • 構造化ログ
        • 各フィールドに対して明確な意味のマッピングがある
        • 簡単に情報の抽出ができる
      • 非構造化ログ
        • 多くのログがこのタイプで、各フィールドに対して明確な意味のマッピングがない
        • 順序に意味を持つ場合が多い
      • ログの収集方法
        • 最も広く使われている方法は、システムでログを転送する方法
        • logstashやtd-agentといったプログラムを監視対象サーバにインストールすることで、非構造化ログをパースして構造化ログとしてログを転送するものもある
  • データストレージ
    • メトリクスデータ
      • メトリクスのような時系列データは、通常はTSDBに保存される
      • 時系列データベース(TSDB:Time Series DataBase)
        • RRD,MongoDB,InfluxDB
    • ログデータ
      • 一般的にはファイルに保存する形が多い
      • 検索エンジンに保存する
        • Elasticsearchなど
  • 可視化
    • 自身やチームの求めるものに沿った形で取得したデータを理解することが目的
    • 折れ線グラフ、棒グラフ、表形式、数字、テキスト等、用途にあったものを選択する
    • 価値あるダッシュボードには、異なる視点とスコープがある
      • 目的に沿った形で、データのスコープを決定し、データを可視化することで、1枚のダッシュボードに複数の異なる視点があつまり、1つのサービスもしくは1つのプロダクトのステータスを把握することができる
  • 分析とレポート
    • 監視データの種類によっては、単なる可視化を超えて、分析とレポートの分野に踏み込むと有益な場合がある
      • SLA(Service Level Agreement)等
  • アラート
    • メトリクスとアラートは1対1で対応している必要はない
    • 何か問題がおきたときにアラートを出すことが監視の目的ではない
    • 監視は質問を投げかけるためにある
      • この文章をどう解釈すればいいのかはよくわからない