モニタリングについて

モニタリング入門 永ちゃん 作 成 日 ： 2 0 2 2 / 0 7/ 2 0 ※本資料は個人的主観で書いているので人により考えが違うこともあるかと 思いますが、その点はご了承下さい。

目次 1. ITシステムのモニタリングとは 2. ITシステムのモニタリング目的 3. モニタリングのメリット・デメリット 4. モニタリングの観測場所 5. モニタリングデータの収集方法 6. アラートルール設定 7. モニタリングからオブザーバリティへ ※全て個人的主観の元で記載しています 2

１．ITシステムのモニタリングとは 3

そもそもモニタリングとは • 日本語で訳すと監視 • どんなシステムでも障害発生したら迅速対応して問題解決をする必要がある • 監視を行っていないと迅速な対応が難しくなり、障害原因特定に時間がかかる • 人で例えるのであれば診察と同じ 発熱、腹痛、頭痛といった病気の症状がでたら人は医者にかかる 放置してひどくなるケースや重い病気になっているケースも💦 ＝＞そのために日頃から人は健康を意識する 4

２．ITシステムのモニタリング目的 5

モニタリングの目的 ・インフラやサービスの障害を素早く見つけること ・障害を見つけるためのモニタリングのポイント ①サービスの正常性を確認 ②障害の予防と原因特定 6

障害を見つけるためのポイント① ①サービスの正常性を確認 ・ITシステムの役割：エンドユーザーにサービスを正常に提供すること ・ここで言う正常とは WEBサイトがストレスなく快適に閲覧できる 商品を選択して買い物かごに入れて、注文することができる 預金状況を確認して必要なお金だけを引き出すことができる ・正常な状態が担保されていることが大事でどこかの処理で異常がある場合は復旧させる ＝＞正常な状態を監視するにはどうしたらいいか？ 7

障害を見つけるためのポイント① サービスの正常性を確認をするためには。。。 例：WEBサイトシステムの場合 ・WEBサイトが閲覧できること ・WEBサイトで閲覧してカードに入れて購入までの一連の動作が実行できること（シナリオ監視） が担保されていることが必要になる =>シナリオ監視でITシステムで動作しているサービスをユーザー視点でモニタリングが可能 ※次ページにイメージ図あり 8

障害を見つけるためのポイント② ②障害の予防と原因特定 ・以下構成のような場合に片側が障害となったことを検知する＝予防 ・原因特定をするために必要な項目をモニタリング=>HW/SWなど モニタリング ツール レスポンス/データ読書 URL監視 死活監視 プロセス監視 リソース監視 9

３．モニタリングのメリットデメリット 10

モニタリングのメリット ・ビジネス損失の減少 ITシステムが停止することはビジネス停止し機会損失を生んでしまうのを減少させる ・管理工数削減 モニタリング項目の状況を確認可能で素早く特定できるようになる ・障害期間の短縮/予防 モニタリング定常的に実施することで障害発生を早く把握できる ・システム/サービス安定 システムをモニタリングすることで影響が広がる前に対処できるようになる 11

モニタリングのデメリット ・モニタリングを行うために人員が必要 モニタリングならではの専門用語の理解 ツール導入のためのツール理解 システムトラブル対応時にはスキルを持つ人が必要 ・モニタリングするための工数、コストが増加 現状のシステム構成の把握やシステム構成の関連ドキュメントの管理を継続的に行う 人件費やツール導入費 12

モニタリングのデメリットの解消のために ・無料/有料のモニタリングツールを導入する ツール導入は簡単かもしれないが、その後のモニタリング設計や運用までが大変！！ ・MSP（Managed Service Providor）を利用する 24/365でモニタリングを行ってくれアラート通知までしてくれる 運用オプションをつけると一括で任せることができるが予算とよく相談！！ またベンダーによってできることが違うので比較することが大事 =>自社で実施するよりベンダーへ一括で任せた方が運用管理コストも含めて考えると安い場合も 13

４．モニタリングの観測場所 14

モニタリングの観測場所 ・サーバ：Inteligence Performance Monitoring Interface ・ネットワーク：データ送受信量、パケットエラー率、パケットドロップ率 ・OS：CPU使用率、メモリ使用率、ディスク使用率 ・ミドルウェア：Apache、Tomcat、Nginx、PostgreSQL、MySQL ・アプリケーション：エラーログの出力先 ・チェックモニタリング： PING（ICMPパケットを利用したチェック）、WEBシステムの動作チェック =>様々なモニタリング対象があるがモニタリングする項目が何なのかが知っておくことが重要 15

５．モニタリングデータ収集方法 16

PushとPull ・Push方式とPull方式がある ・Push方式 監視対象となるホストにエージェントをインストールし、 各ホストのエージェントが監視サーバに対してデータを送信する形 ・Pull方式 監視サーバ上へ監視対象についての設定を行い、監視対象からデータを集めてくる形 17

Push方式のメリット・デメリット ・スケーラビリティを確保しやすく大規模監視システムに対応しやすい ・エージェントを導入するだけでモニタリングを開始することができる ・モニタリング対象が増えたときにモニタリングサーバに負荷が集中する 18

Pull方式のメリット・デメリット ・監視対象の一覧を知っておくことができる ・データ取得できなかった際に異常に気付くことができる ・エージェントが動作させられないモニタリング対象にも対応しやすい 19

Push vs Pull どっちがよいなどはない ・モニタリング対象が動的になりPush型が目立つようにはなってきている ・入門監視はモニタリングツールの運用を辞める為にSaaSを使うことを推奨 ※モニタリングに時間を割くことなく、他のことに時間を割くことができる為 ・OSSではCNCFプロジェクトからPrometheusが先導して始めている ・ZabbixもPrometheusで取得できる項目と同じようにできるために日々VersionUp PushもPullも方式が違うだけで、良し悪しは利用したいシステムに合わせればよい ※情報を追っていくことも大事 ※個人的には。。。 Zabbixは学習ハードル低い、Prometheus学習ハードル高い でもAgentが作れるPrometheusは面白い https://www.oreilly.co.jp/books/9784873118642/ 20

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

６．アラートルール 21

取得したデータをアラート化する ・取得したデータ全てをアラート化する必要なし ・解決までの時間短縮するためにアラートを設定するのが目的 ① アラートを管理ツールで管理し、アラートの優先度を決定 ② モニタリングの内容、アラートによるビジネス影響についてドキュメントに残す ③ アラートのチューニング ④ 自動復旧を試みる ※よくない例：分からないけどエラーというキーワードでモニタリングしとけば良いか！ =>保存しないといけないデータ量も膨大になり、アラート量も大量になる。。。 22

① アラート管理ツールで管理し、アラートの優先度を決定 ・アラートによっては至急対応、翌営業日確認で良い2パターン存在するはず ・優先度が高で全て電話連絡ありだとアラート疲れが発生 ・アラートの内容から事前にアラート管理ツール側で条件分岐をし、電話あり/なしを判断させる ・電話あり/なしを分離するためにもアラートの優先度を決定する クリティカル/サービス影響があるアラート：電話あり 参考情報としてのアラート：電話なし 23

②ドキュメントに残す ・モニタリングの内容を理解していなければ、アラートを受けても対応ができない =>なんでモニタリングをしているのかドキュメントに残すことが大事 ・アラートの内容によってはサービス影響も発生する =>どのアラートがでたら、どういったサービス影響があるかドキュメントに残すことが大事 ※可能であればアラートに対する対処までドキュメント化できると尚良い ドキュメント化することでシステムのことを知らなくても、 ドキュメントからシステムに対する知識を得ることができ、自動化への1歩にも繋がる 24

③アラートチューニング ・毎日同じアラートでていて影響ないと思ったら無視してしまうのが人 ・初期設定したことが全てではなくシステムは生き物なので見直しが必要 アラートに対して本当にアクションが必要？ サービス影響がないアラートの優先度下げれない？影響があるものは優先度上げない？ 過去のアラート状況から閾値の見直しはできない？ 過去対応してきたものが統一した対応であれば自動化を試みてもいいかも？ 25

④自動復旧を試みる ・過去の対応から既知事象で手順書通りの対応であれば自動化は可能 ・なんで自動化を試みるか？ 日本国内の少子化がどんどん進んでいて人の確保が難しくなる 人を増やす、採用/育成にはお金がかかる =>コストは勿論だが、本来人がやるべき仕事に集中できるなら越したことはない 26

※ここまでの振返り 27

モニタリングについて振返り ・モニタリングはエンジニアリングのための道具 ・その道具を使って 継続して観測して異常を検知し復旧させる 継続して観測してシステムの価値の維持/向上させる 予め定義した原理原則に基づいてトラブル対応を実施するが時には原則を無視することも =>No Silver Bulletを胸に刻んで Let’s Engineering 28

６．モニタリングから オブザーバリティ(o11y)へ 29

オブザーバリティとは ・Observe（観察する）+Ability（能力）の単語の組み合わせ =>システム運用する上で必要な情報を外部から取得できる状態にして観測できること ・オブザーバリティが生まれた背景 =>インフラからアプリへの視点へ コンピュータ性能の向上したことにより診るべき箇所のレイヤが上がってきた システムが複雑化になり、コンポーネント間の通信を視覚化する重要性が高まった クラウドベンダーがIaaSを提供したことにより、動くアプリに注目されるようになった 30

監視とオブザーバリティの違い 監視とは ・アラート通知を受けてからの受動的対処 ※人が病気の症状がはっきり出ている状態で医者にかかる オブザーバリティとは ・通常の状態からシステムの内部を正確に把握し変化時にアラートになる前に能動的に対処 ※人にセンサーをつけて生活しデータは分析され、異常値が出たら生活に注意する 31

監視とオブザーバリティの違い ・従来の監視方法 死活監視、リソース監視、ログ監視 =>障害となった原因は分からないがサービス復旧を優先して再起動を実施 ※何が起きているかを診ること ・オブザーバリティでの観測方法 従来の監視+より多くの情報を収集して根本原因を掴む≠なんでも取得するわけではない ＝＞障害をトリガーにするのではなく、通常と違うをトリガーに対処する ※予期せぬことが起きたときに何故それが起きたかを把握すること 32

オブザーバリティの3本柱 ・メトリクス：何が起きているのか =>サービス稼働状況（REDメソッド） サーバやコンテナなどのリソース状況（USEメソッド）のモニタリング ・トレース：どこで問題が起きているのか =>SynteticsやAPMの領域から診ることが求められてきている ・ログ：なぜ問題が発生したのか =>ログが出力されるようにする 33

オブザーバリティの3本柱（メトリクス） ・REDメソッド：Rate、Error Rate、Durationの略 Rate ＝ 毎秒リクエスト数 ErrorRate ＝ エラー率 Duration ＝ レイテンシ、レスポンスタイム =>どのくらいアクセスがきて、どれくらい正常にレスポンスを返答しているかモニタリング ・USEメソッド：Utilization、Saturation、Errorsの略 Utilization ＝使用率（処理中でのBusyだった時間） Saturation ＝飽和状態（余裕がない状態で処理できないキューの量） Errors ＝エラーイベント数 =>REDメソッドと併せて診ることでボトルネック箇所や根本原因の特定に利用（モニタリング観点含む） 34

オブザーバリティの3本柱（トレース） ・複数コンポーネントにまたがるリクエスト全体の流れを呼び出して依存環境を考慮して可視化 Syntetics Monitoring： 稼働時間を観測して、可用性の問題を解決する Application Perfomance Management： WEBシステムで動いているアプリケーションの処理をモニタリング 35

オブザーバリティの3本柱（トレース） Syntetics：稼働時間を観測して、可用性の問題を解決する ・RUM(RealUserMonitoring) エンドユーザーのタイミング、エラー、ディメンション情報をリアルタイムで受動的に収集して分析 ・DOM(Document Object Model) ウェブ上の文書のコンテンツと構造からなるオブジェクトのデータを表現したもの ※WindowsDeveloperBlogより：https://onl.tw/1ZGrLXX ・HAR(HTTP Archive) Web ブラウザとサイトの間のすべてのやり取りのログ ・APIエンドポイント APIにアクセスするためのURI 36

オブザーバリティの3本柱（トレース） ・RUM(RealUserMonitoring)： 37

オブザーバリティの3本柱（トレース） ・RUM(RealUserMonitoring)： 38

オブザーバリティの3本柱（トレース） ・RUM(RealUserMonitoring)： 39

オブザーバリティの3本柱（トレース） ・DOM(Document Object Model) 40

オブザーバリティの3本柱（トレース） ・HAR(HTTP Archive) 41

オブザーバリティの3本柱（トレース） APM：WEBシステムで動いているアプリケーションの処理をモニタリング ・モニタリングしてない時にエンドユーザーからの応答が遅いことへのクレーム発生 ・インフラのモニタリング結果を確認しても異常なし ・問題の原因調査したらアプリ側での処理でDBへアクセスループが発生 =>アプリケーションをモニタリングしないとアプリの動作は把握できない 42

オブザーバリティの3本柱（ログ） ・システムログ：OS内部のイベントのログ ・インフラストラクチャログ：物理的および論理的な機器のログ ・アプリケーションログ：アプリケーションでイベントが発生した時に生成されるログ ・監査ログ：イベントと変更のログ ・セキュリティログ：システム内で発生したセキュリティイベントに応答して生成されるログ =>これらのログをラベル付けしてフィルタリングしやすいようにする またログの中身はフォーマットを統一化しないとそれぞれでパース処理することになるので大変 43

オブザーバリティの考え方を実現するために ・正常な状態をモニタリング項目毎に定義する 何をもって正常というか定義がないとことには運用も始まらない ・正常な状態でなくなった際の対応方法をモニタリング項目毎に定義する モニタリングの時もそうだが対処方法についてドキュメント化することが大事 ・正常な状態であることを継続的に確認する モニタリングにはなかった項目で障害を起因とせずに継続的に確認 =>確認を簡単にするためにダッシュボードの作り込みなどもする ・正常な状態でなくなった場合は正常な状態に復旧させ、必要に応じて再発防止策を実施 モニタリングの時と同様 44

END 45