- 監視の定義：監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。（Monitorama 2016 - Greg Poirier）
- 1.1.1 監視とは複雑な問題をひとくくりにしたもの
- ツールは賢く注意深く選ぶべきで、かつツールが必要なら増やすことも怖がらない。
- 必要性に見合っていないツールを使うのではなく、問題を解決するツールを使う。
- ツールの乱立を避け、会社内でツールに関する規格を作りたい場合、たくさんの人と話し、どんな監視ツールがどんな目的で使われているかを知ること。
- 1.1.2 カーゴ・カルトなツールを避ける
- あるツールや手順だとなぜうまくいくのかを理解するための長年の試行錯誤は、そのツールを採用した人からは見えない、という難しさ。
- ツールとは、仕事のやり方、前提、文化的・社会的な規範が具現化したもの。
- 誰かが使っているからという理由で選ぶのではなく、評価し、試してみることが重要。
- あるツールや手順だとなぜうまくいくのかを理解するための長年の試行錯誤は、そのツールを採用した人からは見えない、という難しさ。
- 1.1.3 自分でツールを作らなければならない時もある
- 1.1.4 「一目で分かる」は迷信
- 理解もできないものを監視する仕組みを作ることは難しい。
- 監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべき。
- 監視は仕組みから孤立した仕組みではない。
- サービスを作って管理することになったら、監視を最優先項目の１つにするよう努力する。
「これを監視してます」と言うための「チェックボックス監視」となってしまうことを避ける。
- 1.3.1 「動いている」とはどういう意味か。「動いている」かどうかを監視しよう
- 自分が監視しているのは何なのかをまず理解する。サービスやアプリケーションのオーナーに聞いてみることから始める。
- 1.3.2 アラートに関しては、OSのメトリクスはあまり意味がない
- 「動いているか」を基準にアラートを送ることが有益であり、CPUやメモリといった低レベルなメトリクスに対してのアラートはあまり意味がない。
- パフォーマンスに影響を与える可能性のある負荷の急変化やトレンドを確認できることには、診断やパフォーマンス分析にとって重要。
- 「動いているか」を基準にアラートを送ることが有益であり、CPUやメモリといった低レベルなメトリクスに対してのアラートはあまり意味がない。
- 1.3.3 メトリクスをもっと高頻度で取得しよう
- 監視に寄りかからない。監視による通知を受け取った次にするべきことである、問題の修正を忘れてはいけない。監視を増やしても壊れたシステムが直るわけではない。
専門家されたツールを複数使い、それらを疎に結合させて「監視プラットフォーム」を作ること。利点として、1つのツールややり方に長期間にわたってコミットする必要がないことがある。
- 2.1.1 監視サービスのコンポーネント
- データ収集
- プル型とプッシュ型
- プル型はスケールしにくいというデメリットもある
- カウンタメトリクスとゲージメトリクス
- プル型とプッシュ型
- データストレージ
- 一週間前のCPU使用率を60秒ごとの粒度で気にする必要があるかというと大部分がそうではないはず。古いトレンドは大まかな動きがわかればよい。
- 可視化
- 過程やトレンドといった情報が含まれていない円グラフは使わない。全体との関連で表現する場合でも棒グラフの方が良い場合が多い。
- 最高のダッシュボードは、そのサービスを最もよく理解している人たちによって作られ、運用されているもの。
- 分析とレポート
- SLAとは、ほとんどの場合において願望や嘘である。SLAを満たさなかったことによるペナルティは、単なる返金である。
- たとえSLAが必要とされていなくても、SLAに当たる情報を監視しておくことはおすすめ。
- 可用性を考えたとき、サンプリングエラーという落とし穴がある。例えば、2分間のダウンタイムを計測するには、1分間隔でデータを収集する必要がある。
- 複雑なアーキテクチャでは、稼働時間と総運用時間を計算するのは大変。内部の冗長なコンポーネントの可用性は無視し、全体の可用性を計算してしまうことがおすすめ。
- 可用性100%は現実的ではない。
- SLAとは、ほとんどの場合において願望や嘘である。SLAを満たさなかったことによるペナルティは、単なる返金である。
- アラート
- 何か問題がおきた時にアラートを出すことが監視システムの目的ではない。監視は、質問を投げかけるためにあるもの。
- データ収集
- ユーザーとアプリケーションがやりとりをするところが、まず監視を追加すべきところ。何が問題なのかはわからなくても、何かが問題であることは教えてくれる。
- HTTPレスポンスコードを使った監視、レイテンシ。
- 2.3.1 安いから
- ツールの構築・運用をする常勤のメンバーのコスト
- 監視システム以外にこのメンバーが関わることで得られたはずの逸失利益
- ドキュメント作成のための時間
- 社内ツールの教育のための時間
- ミッションクリティカルなサービスを社内で運用することから発生する運用の複雑さによるコスト
- 2.3.2 あなたは（おそらく）監視ツールを設計する専門家ではないから
- 監視サービスの構築が最適な時間の使い道か？
- SaaSソリューションの広まりにより、メールサーバやDNSサーバを自前で運用している人はほとんどいなくなった。
- 2.3.3 SaaSを使うとプロダクトにフォーカスできるから
- 2.3.4 実際のところSaaSの方がよいから
- Airbnb, Pinterest, Yelp, Target といった企業でも、いまだに監視にSaaSを使っている。
Google, Facebook, Twitter, Netflix, Etsy といった進歩的な企業が高度な監視の仕組みを作り今日の状態に至るまでに何年もかかっていることを忘れない。世界レベルの仕組みは一週間でできるものではなく、数ヶ月、数年間にわたる継続した注意深さと改善から生まれるものである。
アラートには、「誰かを叩き起こすためのアラート」と「参考情報としてのアラート」があり、後者は事実上アラートではなく、単なるメッセージである。
- 3.1.1 アラートにメールを使うのをやめよう
- アラートのログを保持しておき、後でレポートを遅れるようにしておくことは重要。
- アラートのレポートを取ると、アプリケーションやサービスのどの部分でトラブルが多く、どこに改善の商店を合わせればよいかがわかる。
- 3.1.2 手順書を書こう
- 良い手順書に書かれていること
- これは何のサービスで、何をするものか。
- 誰が責任者か。
- どんな依存性を持っているか。
- インフラの構成はどのようなものか。
- どんなメトリクスやログを送っていて、それらはどういう意味なのか。
- どんなアラートが設定されていて、その理由は何なのか。
- 人間の判断と診断が必要ないものは自動化を検討する。
- 良い手順書に書かれていること
- 3.1.3 固定の閾値を決めることだけが方法ではない
- 変化量やグラフの傾きを使う
- 3.1.4 アラートを削除し、チューニングしよう
- アラートの量を減らすには
- そのアラートは誰かがアクションする必要がある状態か？
- 1ヶ月間のアラートの履歴を見る。どんなアクションを取ったか、そのアラートの影響はどうだったか。削除できるものはないか。
- アラートを削除するために、どんな自動化の仕組みが作れるか。
- アラートの量を減らすには
- 3.1.5 メンテナンス期間を使おう
- 3.1.6 まずは自動復旧を試そう
- 3.2.1 誤報を修正する
- 3.2.2 無用の場当たり的対応を減らす
- 監視自体は何も修復してはくれない。
- 3.2.3 上手にオンコールローテーションを組む
Follow-the-Sunローテーション- オンコール担当であるかどうかに関わらず全員がインシデント対応可能である状態を期待してしまうようになるのは避ける。
- ソフトウェアエンジニアリングにおける「丸投げ」を避けるため、ソフトウェアエンジニアもオンコールのローテーションに入れることがおすすめ。
- ツールを使ってオンコールの仕組みを補強する。
発生した問題を扱う、正式な手順。ITILのプロセスを採用しながら、シンプルにしたものは以下のようなもの。
- インシデントの認識
- インシデントの記録
- インシデントの診断、分類、解決、クローズ
- 必要に応じて、問題発生中にコミュニケーションを取る
- インシデント解決後、回復力を高めるための改善策を考える
数分以上かかるサービス停止を伴うインシデントの際には明確に定義された役割が重要になる。2つ以上の兼務は避けるべき。また、会社での通常の上下関係に従う必要はない。
- 現場指揮官
- 決断することが仕事
- スクライブ
- 書記
- コミュニケーション調整役
- 社内外問わず利害関係者に最新状況のコミュニケーションを取る。
- SME（Subject Matter Expert）
- 実際にインシデント対応をする人。
誰かを非難するようなことは絶対にしない。
システムは、予想しない（けれども問題があるとは言えない）動きをすることがある。
監視サービスが送ったメトリクスを捨てず、時系列データベースに保存しておき、それに対して算術関数や統計関数を実行することで、より正確に問題を検知できるようになる。過去に対する多くの情報を得ずに、未来を洞察したり推測することはできない。
平均。その集合がどのようなものかを表すのに便利。
平均値が対象を正確に表さない時に便利。
seasonality。データポイントがパターンを繰り返すこと。
データセットのある点を表す統計手法。第2四分位数＝中央値。よく使われる分位数はパーセンタイル。データセットを昇順に並び替え、上位nパーセントの値を取り除き、残った値で最大の値がnパーセンタイルの値となる。レイテンシの判断にパーセンタイル値を使う場合には、最悪ケースのことも考慮に入れる。
平均からどの程度離れているか、どの程度近いかを表現する方法。正規分布しているデータセットに対してしか期待するような結果は出ないことに注意する。
統計的手法を選択する際に考慮すべきいくつかのポイント。
- どちらか一方に大きな偏りがあるデータか？
- 極端な外れ値はよく発生するか？
- データポイントには上限もしくは下限があるか？
KPI : 全体としてビジネスがよい状態であるために会社が重要だと認識している計画を、どのように実行しているかを測るためのメトリクス。各メトリクスは、発生しているかもしれない問題の先行指標になっている。
対象のユーザーアクションのレイテンシと失敗をメトリクスとして取得する。ユーザーを個別に分析することはしない。
監視に必要な計測データを出力するように、アプリケーションやインフラを変更する。
そのためには、プロダクトマネージャやソフトウェアエンジニアチームのマネージャ、シニアソフトウェアエンジニアなどの人と話すこと。
- アプリケーションが動作しているかどうかを知るためにはどうすればいいか？
- アプリケーションのKPIは何か？なぜそのKPIなのか？そのKPIにより何がわかるのか？
リアルユーザ監視とシンセティック監視。
- リアルユーザ監視
- 監視のデータとして実際のユーザトラフィックを使うもの
- シンセティック監視
- 監視データを得るためのリクエストを生成するもの
- 6.3.1 フロントエンドパフォーマンスのメトリクス
- Navigation Timing API 仕様に基づいたAPIを通じてページパフォーマンスのメトリクスはブラウザにより公開されている
- 視覚的な観点でページがロードされ終わったのがいつかを判断できる Speed Index
- 秒間10フレームのビデオキャプチャを用いる
- 6.3.2 素晴らしい！ でもどうやったらいいの？
- WebpageTest.org
- WebpageTest のAPIをCIに組み込むことでパフォーマンスを継続的に計測しつづけられる
アプリケーション自体の監視は非常に効果的なのにも関わらず、見逃されがち。APMツールは便利であるが、アプリケーションやその背後にあるビジネスロジックに関する何のコンテキストも把握していないということについては理解しておく。
- 7.1.1 内部ではどのように動いているのか
- StatsDクライアントは UDP で StatsD サーバにメトリクスを送信している。ノンブロッキングなプロトコルを選択することで計測によるアプリケーションパフォーマンスへの大きな影響を避けている。
- 「ビルドが動いたか動かなかったか」ではなく、メタ情報（デプロイがいつ始まりいつ終わったか、どのビルドがデプロイされたか、誰がデプロイを実行したか、など）の監視。
- アプリケーションの健全性を伝えることのできるアプリケーション内のHTTPエンドポイントの監視。以下のような、メトリクスベースのやり方では得られない利点がある。
- ロードバランサーなどのヘルスチェックにも使える。
- エンドポイントでビルド情報を公開すると、環境内で何が動いているのかも簡単に判断できるようになる。
- アプリケーションが自分自身の健全性を把握できるようになる。
- 分散マイクロサービスアーキテクチャになると、最終的には自分自身が正常かどうかを各サービスが把握していることとなり、つまり環境全体を自動的にテストし続けているのと同じことになる。
- このエンドポイントはアプリケーション内にあるべき（全く別のアプリケーションであってはならない）。
- 7.4.1 メトリクスにすべきか、ログにすべきか
- 現在メトリクスとして計測しているものをログエントリとしていないのは、単なるツールの問題。
- 7.4.2 何のログを取るべきか
- ログレベルの設定は、すべて正常に動いている前提で重大度をつけてしまうという問題がある。
- 自分が完全に理解していないシステムのログ出力を設定するのは無理。あちこちにログ出力処理を追加するのではなく、「トラブルシューティングや仕組みの説明をするときにあったらとても便利な情報とは何か」から始める。
- 7.4.3 ディスクに書くべきか、ネットワーク越しに送るべきか
- まずはディスクに書き込み、定期的に外部にデータを送る機能があるサービスを組み合わせる。
- 直接ネットワーク越しにログを転送するログサービスも多いが、アプリケーションのトラフィックが増えるにつれて無視できないボトルネックになりがち。
- まずはディスクに書き込み、定期的に外部にデータを送る機能があるサービスを組み合わせる。
- サーバーレスアプリケーション（ファンクション）の監視に対して伝統的なポーリングモデルは、そのアプリケーションの総実行時間が1秒以下のような場合、ポーリング間隔をそこまで短くすることはできないので利用できない。
- ファンクションの中で何が起きているのかも知りたい場合はStatsDを使う。
- 分散トレーシングも検討する。
- マイクロサービス化することで、ユーザのリクエストに何が起きているのか理解するのが難しくなる。
- 分散トレーシング：マイクロサービスアーキテクチャに付き物の複雑なサービス間のやり取りを監視するための方法論とツールチェインのこと。
- 分散トレーシングは、正しく実装するのは非常に難しく時間がかかる監視の仕組みであり、業界内の一部でだけ役に立つもの。
OSの標準的なメトリクスから監視を始めるのは、アプリケーションが動いているかどうかという重要な事項との関連が弱いシグナルから監視を始めることになってしまう。そうではなく、これらを全システムで自動的に記録するようにしておきつつ、アラートは設定しないでおく。それを、診断やトラブルシューティングといった正しいコンテキストで使う。
- 8.1.1 CPU
- 8.1.2 メモリ
- freeなメモリが減り、スワップ使用量が増加したときのアラートは、アプリケーションがメモリに敏感な場合に、メモリ私使用が増加していることを示す指標となる。
- ログに出力される OOM Killer の呼び出しを監視する。
- 8.1.3 ネットワーク
- 最低でも、インターフェイスに対するinとoutのオクテット数、エラー数、ドロップ数を収集する。
- 8.1.4 ディスク
- iowaitが高い状態となることは避ける。
- await はディスクが処理をおこなうようリクエストを発行するのにかかった平均時間。キューで待った時間と実際にリクエストを処理した時間の両方が含まれる。
- IOPSは、データ転送能力を増強する必要があるかを判断したり、一般的なパフォーマンス問題を特定するのに便利。
- 8.1.5 ロードアベレージ
- この値はシステムパフォーマンスを表しているわけではないことに注意する。
- 代理指標（この値の高騰が他の問題の存在を示す）として役立つという例外がある。
- 一般的に、何に対してであってもロードアベレージに依存することは時間の無駄。
- SNMPをサーバ監視に使うことは避ける。
- 機能を拡張する＝エージェントの拡張。
- 実質的にセキュアでないプロトコルをネットワーク内で動かすことになる。
- ポーリングをおこなう集中型の仕組みであり、スケールや管理が難しくなる可能性がある。
- 簡単に設定できて拡張性の高い代替の仕組みが他にもある。
- 秒間リクエスト数により、パフォーマンスとトラフィックのレベルを測る。
- 全体の見通しの点では、HTTPステータスコードの監視も重要。
- コネクション数はリクエスト数ではないので混乱しないように注意する。
- リクエスト時間も便利なメトリクス。
- コネクション数（MySQLの場合はスレッド数）をまず監視する。
- 秒間クエリ数を見ることでデータベースがどのくらい忙しいのかを見る。
- スロークエリを見ることで、ユーザの体感が遅くなるという起こってほしくないことを知らせてくれる。
- レプリケーション遅延も監視する。
- データベースは大量の読み書きをするため、IOの速度により制約を受けるため、IOPSを記録しておくことも忘れない。
- Webサーバと同じような項目を追跡する。
- ロードバランサー自体の状態と、バックエンドのサーバの状態という別々の情報を知るために、フロントエンドとバックエンドの2つのメトリクスを両方取る。
- /health エンドポイントパターンをロードバランサーのヘルスチェックにも活用できる。
- キューの長さと消費率を監視する。
- キャッシュから追い出されたアイテム数とヒット・ミス比率が主なメトリクス
- ゾーン転送と秒間クエリ数に注視する。
- サーバークライアント間のドリフト（time drift）に注意する。
- 8.11.1 DHCP
- IPアドレスをリースしたDHCPサーバと、D_HCPプールが十分なリースの余裕を持っているかどうか。
- 8.11.2 SMTP
- 外向けのメールキューを見ることで、外部への送信待ちのメールがどのくらいあるかを表す。
- 送受信したメールの総数を監視することで、パターンや異常な動きを検知するのに良い。
- 受信箱のサイズを監視すると、どのくらいのキャパシティを用意すべきかの指標になる。
- データが存在していないことを検知する、といった場合の解決策は、デッドマン装置として知られている。
- 何らかの仕組みがアクションを止めるように指示するまではアクションを行う、という仕組み。
- 8.13.1 収集
- ログがsyslogデーモンで管理されている：ログを別のサーバに転送するようsyslogデーモンを設定可能。
- ログがsyslogデーモンで管理されていない
- ログをsyslogに送るようにする
- syslogの設定を変更し、ディスク上のファイルをsyslogに取り込むようにする
- いずれにしても、ログの取り込み方と送り方には一貫性があるべき。
- 8.13.2 保存
- 検索しにくい方法でログを保存すると、誰にログが見られず、活用されることがなくなってしまう。ログを活用して価値を得られるしっかりしたログ管理システムに送ること。
- 8.13.3 分析
- まずは以下のような項目のログを取る。
- HTTPレスポンス
- sudoの使用
- SSHログイン
- cron ジョブの結果
- MySQLやPostgraSQLのスロークエリ
- まずは以下のような項目のログを取る。
ネットワークの可用性を上げることは、ネットワークに依存するものを改善するための「てこ」であると言える。
- 9.1.1 SNMPとは
- デバイスを監視し管理することを目的に、1988年にRFC1067で提案されたプロトコル。
- 9.1.2 SNMPの仕組み
- ポート161（ポーリング・デバイスに対するインバウンドに使用）と162（トラップ・デバイスからのアウトバウンド）を使うUDPベースのプロトコル。
- SNMPトラップのデータはデバイスのsyslogにも記録されるので、トラップは無効にしてしまうことが多い。
- SNMPエージェントには、実装の標準は存在しない。
- 9.1.3 セキュリティについて
- SNMPは本質的にセキュアでないプロトコル。
- SNMPをセキュアにする最適な方法は、インフラにセキュリティの仕組みを組み込み、セキュアでないプロトコルをその上で使う予定であることを理解すること。守られていないネットワークでSNMPを使うことは推奨されない。
- 9.1.4 SNMPの使い方
- 9.1.5 インタフェイスのメトリクス
- ネットワークパフォーマンスは、以下のようないくつかの要素に分けることができる。
- 帯域幅
- スループット
- ネットワークリンクの実際のパフォーマンス。秒間ビットで表される。プロトコルと送信のオーバーヘッドにより、スループットはリンクの帯域幅より小さくなる。スループットを監視するのは、リンクの性能を最大限に活用しているかを確かめるのに重要。
- スループット性能が疑わしい場合は、パケットドロップ数やオーバーラン、コリジョン数などを確認する。
- レイテンシ
- エラー
- 送受信エラー、ドロップ、CRCエラー、オーバーラン、キャリアエラー、リセット、コリジョン。
- 物理的な問題も監視すべき。電気的鑑賞、送受信機やケーブルの欠陥�などの問題は、CRCエラーとキャリアエラーから監視可能。
- ジッタ
- あるメトリックの通常の測定値からの狂いのこと。レイテンシが 1ms / 150ms / 30ms と揺れ動く場合、ジッタが大きい例。
- ネットワークパフォーマンスは、以下のようないくつかの要素に分けることができる。
- 9.1.6 インタフェイスとログ
- デバイスのsyslogもインターフェイスの仕事内容についての情報を知る上で有用。
- トランクポートへの変更
- ポートの err-disabled への変化
- リンクアグリゲーションされたインターフェイスのバンドル化またはアンバンドル化
- デバイスのsyslogもインターフェイスの仕事内容についての情報を知る上で有用。
- 9.1.7 SNMPに関するまとめ
- アップリンクとサーバに使われているインターフェイスを監視してアラートを送るようにすべき。
ネットワークデバイスの設定変更の追跡は、インパクトが大きい取り組みの一つ。RANCIDのようなツールによるバージョン管理をおこなうことで、設定が変更されるたびにメールやslackなどへの通知をおこなうことができるようになる。
レイテンシ、ジッタ、パケットロスという3つの計測項目がすべて。使用しているコーデックも重要な監視項目。SNMPを通じてチェックできる。
ルートブリッジが変わったのはいつか・プロトコルのコンバージェンスがいつか。
- 9.6.1 CPUとメモリ
- グラフはあったほうがいいが、そのデータはうのみにせず、かつアラートを送るのはやめておく。
- 9.6.2 ハードウェア
- syslogにあるコールドスタートを示すメッセージは重要な項目の一つ。デバイスの再起動は注意を払うべきポイント。
フロー＝一定方向へのパケットのシーケンス。以下の7つすべてを共有している。
- 入力インターフェイス
- 送信元IPアドレス
- 宛先IPアドレス
- L3プロトコル
- UDPまたはTCPの送信元ポート
- UDPまたはTCPの宛先ポート
- IP ToS
フロー監視は、帯域幅を大きく使っている活動やノードを突き止めたり、IPごと、プロトコルごと、アプリケーションごと、サービスごとといった単位で帯域幅の使用率を分析するのに役立つ。
- 9.8.1 逆算する
- ビジネス上のあるゴールがあるとき、そのゴールにたどり着くために必要なリンクサイズなどを逆算する、など。監視データは使用されない。
- 9.8.2 予測する
- 監視システムに保存したデータを利用しトレンドラインを引くなどして予測する。
検知することを考えることは、保護を考えることにつながる。どのように基本的なセキュリティを実現するかということと、どのようにそれを監視するかということの両方を横断的に扱う必要がある。 セキュリティとは、脅威とリスクを見積もり、不正アクセス時に決断を下すこと。
コンプライアンスを実現することは、簡単なことから悪夢のようなことまでさまざま。多くの統制事項において、期待するとおりに確実に動くようにするには監視を実装するのが良い方法。
auditdは、Linuxカーネルへの直接のフックを使い、システムdえ発生するイベントやアクションを通知できるようにするコンポーネントである Linux Audit System の、ユーザスペースのインターフェイス。 Linux Audit System は他のシステムと別になっていることで、他のサブシステムが動いていないときでも動作し続けられるようになっている。
- 10.2.1 auditdのセットアップ
- 10.2.2 auditdとリモートログ
- まずは、SSHログインの成功と、sudoの成功/失敗についてアラートを設定する。
- auditdはその動作にsyslogサブシステムには依存していないので、rsyslogが無効化されていてもauditdは監査イベントを記録しリモートサーバにそれを転送し続けられる。ログの取り込みにrsyslogを使わない理由。
- ルートキットの検知にはいろいろな方法を利用する必要がある。
- ユーザ・プロセス振る舞い分類
- ログ分析
- ファイルシステムやプロセスの監査
- ファイルハッシュの比較
- など
- ネットワーク自体に対する脅威を検知するのに便利なしくみ。ネットワークタップをネットワーク内に配置して生のトラフィックを確認することで動作する。
- 監視は開発者自身が自主的におこなうべきもので、属人的な権威があってはいけない。
- 構築や設定が複雑なツールでは、ついつい専任者が属人性を作り込んでしまい、権威が発生しがち。
- C.3.1 監視SaaSビジネスそのものに対する信頼性
- C.3.2 事業の継続性について
- 事業の継続性リスクは、監視SaaSに限らず常に存在するもの。サービス継続期間やマーケットシェア、コミュニティの活発度などを判断材料として、注意深く選定するしかない。
- C.3.3 サービス品質について
- 監視SaaS自体の可用性や停止を伴うメンテナンスの実施頻度など。
- C.3.4 悪意はないか
- 監視エージェントなどの多くはソースコードが公開されていることが多いため、そこから調査することは可能。
- C.4.1 課題を見つける
- まずは自分たちのシステムにおいて、どのような監視が必要で、監視にどのような課題を抱えているかを洗い出す。
- その上で、その製品がどのような機能を備えているか調査し、自分たちの課題を解決できるかを吟味する。
- 課題がよくわからない、そもそも監視もできていない、という場合には、まずは何らかの監視SaaSを早めに導入する。
- C.4.2 機能要件を精査する
- 監視SaaSが自分たちの環境で使えるかどうかの観点は見落としがち。利用しているサーバにインストール可能か、などの観点で精査する。
- 利用規約を読み、どういったデータをSaaS側に送信し、預ける飛鳥があるのかもしっかり把握する。
- メトリクスデータだけか？ログも含めるのか？何らかの秘匿情報も預ける必要があるのか？など
- C.4.3 組み合わせて使う
- C.4.4 運用をサービスに合わせる
- サービスを自分たちの運用に合わせるのではなく、自分たちの運用をサービスに合わせる、ということは、監視に限らずSaaSを利用する上での鉄則。SaaSは運用におけるレールを示してくれるものでもある。
- C.4.5 ハッカビリティを備えているか
- C.4.6 外部の力を活用できるか
- テクニカルサポートのクオリティ、コミュニティの活発度、インターネットでのノウハウの共有状況など。
- C.5.1 監視エージェントのインストール
- C.5.2 監視エージェントが収集するメトリクス
- OSの標準的なメトリクスに監視を依存させすぎるのはよくないが、標準メトリクスの傾向を捉えておくことでシステムの大まかな兆候を掴むことはできる。
- OSのメトリクスの異常値は、実際にはなにかの結果でしかない。直接の原因であり、コントロール可能な数値を本来は監視すべき。
- チェック系の監視の多くはメトリクス監視で実現可能になったため、メトリクス監視が可能ならそちらに寄せるべき。
- C.5.3 シンセティック監視のすすめ
- 監視のノウハウがあまりない場合でもひとまずシンセティック監視を設定しておけば、大きな問題にすぐ気づくことができる。
- Webシステムの場合、ユーザが見る画面やAPIなどのシステムの一番外側さえちゃんとしていれば、内部に多少問題があってもビジネスにはただちに理教はない。
- それにより異常に気づいたら、内側にブレークダウンして原因究明をするのは大事なプラクティス。
- 監視のノウハウがあまりない場合でもひとまずシンセティック監視を設定しておけば、大きな問題にすぐ気づくことができる。
- C.6.1 テスト駆動開発と監視
- 「監視とは継続的なテストである」。監視とソフトウェアテストは本来似た性質を備えている。
- 開発者は運用されるシステムの監視に自覚的であるべき。システムを作るときは監視も一緒に考える。「ガソリン残量を計測できないような燃料タンク」を作らない。
- C.6.2 自分で監視を作る
- 自分が開発しているアプリケーションにある心配事、不安なところを監視すべき。何を監視すべきかを知っているのは開発者自身。
- C.6.3 監視を育てる
- 監視は1回作って終わりではない。観測方法や閾値の見直しを定期的におこない、アップデートしていく。
- /health エンドポイントパターンを積極的に活用する。ステートレスに作ることがポイント。エンドポイントは生の値を返し、値に対する加工はそれを取得した観測者以降で実施すべき。
- そのためのデータフォーマットとして、Health Check Response Format for HTTP APIs という JSON レスポンスの共通フォーマットが議論されている。
- OpenMetrics フォーマットも。
- C.6.4 自動復旧のためのアイデア
- どのような監視SaaSを使うにしても、自動復旧の実現にどのようなアイデアがあるかを調べる。
- C.7.1 監視パラダイムの変遷
- 新しい監視パラダイム・Observability（可観測性）
- 複雑化する・ライフサイクルが短命化するシステムの状態を捉えるために必要な要素を網羅するための概念。
- 新しい監視パラダイム・Observability（可観測性）
- C.7.2 機械学習と異常検知
- 単一メトリクスに対する静的な閾値設定にはいくつかの課題がある。
- 複雑な条件に対する閾値設定がやりづらい
- 設定者が想定している以上しか見つけられない
- 何らかの異常と標準メトリクスには相関があることが多く、機械学習を用いた異常検知はそのことを利用した監視SaaSならではの優位性のある仕組み。
- 単一メトリクスに対する静的な閾値設定にはいくつかの課題がある。