監視の世界 ようこそ監視の世界へ 2019/06/22 Yuhki Hanada

本スライドの目的 ● 特定の製品について書いているわけではなく、「監視ではこんな事をしている」というものです。 そのためここで記載されている機能的なものを全てカバーする事は、よほどの規模でなければ現実的な選択肢で はないと思います。 ● また、基本的にオンプレでの監視システムの構築と運用をベースに記載しています。逆に言うと SaaS のソリ ューションを使う事で、このスライドに書かれている監視システム自信の「運用」を省略する事ができます。 「他の人はこんな監視をしているんだ」という発想の一助になれば幸いです。

監視の世界アジェンダ 監視の種類 / 監視の手段 / 通報手段 リソース監視 ログ監視 外形監視 運用状況の監視 HW監視･設備監視 イベント監視 監視と運用 1 2 5 4 3 6 7 8

監視の種類 いろいろな監視や監視方法のメソロドロジー、監視システムについて 1

監視の種類 業界の標準のような決まった分類はありません。、カテゴリ分けしてみました。 • リソース監視 (OSのリソース監視。CPU/Memory/Disk etc) • アプリケーション監視 (Web Server / Application / Database。SAPやMQなどの基盤サービス） • ログ監視 • 外形監視 (URL監視、トランザクション監視 (サービスなどに実際にアクセスして操作を実行する)) • 運用状況の監視 (バッチ処理、定期タスク、SLA etc) • HW監視 (Server、Network、Storage)、設備監視 (電源やUPSなどの物理インフラ) • イベント監視

データソースからデータを取得し、その値と閾値を比較する。方法はある意味無限。 データを取る I/F として、いろいろな仕組みや規格の名前が出てくる 監視の手段 物理I/Fをもった Linuxデバイス • テキストファイル (syslog 含む) • コマンドの標準出力 / 標準エラー出力 (vmstat を定期的に実行 etc) • WMI (Windows のインターフェイス。標準規格の WBEMにそった実装） • Perfmon (Windows) • CIM (Common Information Model) • SMI-S (ストレージの規格) • SNMP (Polling) • SNMP Trap • JDBC • JMX (Java Management Extension) • HTTP • SOAP /JSON • DI/DO (電気接点信号） • テレビカメラ監視 定期的に画像の差分を確認し異常があった場合にイベントを発生させる (監視デバイス自体が一つのサーバー） UDPなので到達保証が無いものの 未だに広く使われている 監視製品は、通常複数のI/Fに対応している

通報手段 • ライト･アラーム ･Linux が入っていてネットワーク接続できる独立型（REST, rsh や SNMPでライトを外部から制御） ･PC等につないでPC経由でコマンドを発行してライトを制御するタイプ 「パトライト」https://www.patlite.co.jp/ 「警子チャン」http://www.isa-j.co.jp/keiko-10th/products/4gx/feature.html • email • 電話による音声通報 TELStaff https://www.hitachi-solutions.co.jp/telstaff/sp/inform/

監視システムのコンポーネント例 リソース履歴用DB イベント保管DB 監視Agent / Log Agent 監視サーバー本体 (イベントの収集、Agent の設定、管理) 性能履歴保管用サーバ HA Load balancing Application/DB Web Application /DB イベント 履歴データ 概念的なもので特定の製品を表しているものではありません オンプレでスケールする監視システムを構築する場合は、意外と大量のコンポーネントが必用になります（小規模だと1 serverに収まる） HA Application/DB ハートビート 監視サーバー プレゼンテーション層 (監視データのユーザーへのビジュアライズ) 落ちても監視が停止するわけではないので、 可用性は高くなくても良い(と言う考え方も ある） 監視が止まらないように可用性を確保 する。 HA 監視Agent / Log Agent 監視中継サーバー (Agentの負荷分散) キャパシティ予測 障害予測 分析

リソース監視 リソースの使用率の監視 2

リソース監視 (1) • OS情報の監視 正確な理解と、しきい値設定には、OSや環境に関する基本的な知識が必用 例）Windows と Linux の CPU使用率の意味の違い Windows に Load Average に相当するものはあるか → 同じ値は無いが、Queue長を示す別の指標がある。 物理メモリの使用率 → OSによって物理メモリを常に100%使おうとするものがありリソース不足とは言えない。 仮想化環境では、CPU監視はどう意味があるのか。 → 仮想マシン上のCPU使用率は物理マシン上のCPU使用率のように絶対値でない etc...

リソース監視(2) 監視間隔 • 0秒間隔で監視する監視 Agent を作ると100%のCPUを使用する監視 Agent ができる • 「1秒間隔で監視したいのですが」と言われる事もある → リソース監視自体が監視対象のリソースに影響を与えるのでバランスが必用 • 通常の監視Agent は Sampling 値（その時の瞬時値）を使用している → OSが提供する値も突き詰めるとサンプリングに過ぎない。どの程度の粒度を許容するか。 • 1秒程度のCPUピークを見逃す事は、リソース監視でさほど問題は無い →つきつめるとあるプロセスはその瞬間で100%のCPU (1コア）を使っている

リソース監視 (3) • リソース監視もログ監視で行われるケースもある (ログにリソース使用率を吐きだしている場合も） UIでリソースの使用率がわかるレベルを求めてないケースもある。 • リソース監視の情報をどこから持ってくるべきか 仮想化環境など使用しているアーキテクチャーの知識が必用 仮想マシンの使用しているIOPSをどこから持ってくるべきか。 Windows と Linux が混在している環境ならOSに依存しないvCenter から取った方が安心できる etc. 履歴データの収集 • リソース使用量の情報は、保管すると膨大になる • 古いデータを、1日平均や、1日の最大値、最小値等に加工して保存するような仕組みが必用

ログ監視 一番シンプルなものの、奥が深い監視です 3

ログ監視 (1) • もっとも良くある？監視方法 • OS/アプリケーションが吐くログの中に含まれるキーワード（Error、Warning、Exception...等）を監 視する • Windows だと Event Log, Linux 系だと syslog(ng) にアプリのログを書き込める • サーバー間でログを転送して、最終的に特定のサーバーに集めるシステムを作る事がある → ログ収集 (syslog, fluentd等のソフトを使う) • OSが管理するログに統合するよりもアプリケーション毎に独自のディレクトリに独自のログを吐いて いるのが多い（気がする） → 例えば syslog に統合した時点で syslog の format に統一しないといけないので本来のアプリのログの見やすさだったり情報の 粒度が失われるから。だと思います。

ログ監視 (2) • 監視製品で監視する以外にもログを取得して保管するという要件が同時にあるのが通常 → 監視していたキーワードの前後の部分が障害原因の特定に必用である事が多い。 → 監視製品側からログが見えます。という製品は、ログの全てが見えているわけではないケースがある。その 場合は、ログの保管とサーチ用のソリューションは通常別途必用なケースがある → 全ログの保管とサーチの機能は、それだけで専門ベンダーがある領域 (Sumo Loigic, Splunk etc) → コストがかかる部分なのでログの保管を諦めているユーザーもいます。 • ログ毎にフォーマットが違うので、そのログのどの部分を、Severity として解釈するか、Message として解釈をするのか。というフォーマット解釈の定義が取り込み時に必用になる → 監視製品には、このフォーマットファイルがある事を持って、”100製品に対応”みたいなマーケットメッセ ージを出す事がある。

ログ監視(3) FORMAT NT_Base %t %s %s %s %s %s %s %s* hostname DEFAULT origin DEFAULT category $3 eventType $4 sid $5 sub_source $6 id $7 msg $8 -date1 $1 -date2 $2 date PRINTF("%s %s", date1, date2) END IBM Tivoli Enterprise Console のログフォーマットファイル（ログのフォーマットを解釈するためのファイル） http://publib.boulder.ibm.com/tividd/td/tec/GC32-0668-01/ja_JA/HTML/tec4mst25.htm ログラインを分解して 監視製品の持っているカラムに割り当てる • ログのフォーマットはいろいろあるので、「特定の製品と連携できる」というマーケティン グメッセージより、ユーザーが自分で簡単にいろいろなログに対応できる機能を解放してい るかが重要。 以下のような情報が公開されているかが ポイント • フォーマットファイルの書き方 • ファイルのパスの指定方法 監視間隔の指定方法 • 監視イベントを送信できなかった時 のキャッシュの有無。 • キャッシュファイルの位置 • 再送のタイミング(接続の回復を定期 的にチェックする, 新しいイベントが 発生した時点で過去のイベントも順 番を守って送出する等)

外形監視 サービス全体を監視します 4

外形監視 • システムを実際に外部からアクセスして正常に使用できるかを監視 →Web、アプリケーションサーバー、DBを監視してもサービスとして動いているかは監視できていない。 Web URLにアクセスして 200が返ってきたらＯＫ → 一番簡単な方法 Webページの Page A → Page B → Page C →購入ボタンをクリック。という遷移を見る → トランザクションを記録するためのツールを使ってスクリプトを作る ブラウザでは無い、クライアントソフト(SAP GUI 等）に対する監視 → 専用の端末を用意して実際に”ロボット“を動かしてアクセスする。 • 何台アクセススクリプトの再生ポイントを用意するか → コストの問題。再生Agent用のサーバーが必用 • どこからアクセスするか（イントラネット/インターネット） → DC内からの監視では、ＤＣ外からアクセスできているのか確認できない。

運用状況監視 日々の運用の情報も監視システムに集められます 5

運用状況監視 • システム運用の中にはいろいろな定期タスクがある • ジョブ･スケジューリング (日本だと JP1 が圧倒的) → 深夜0:00になったらメンテナンスページに切り替え • Web / Application サーバーをシャットダウン • DBサーバーをバックアップ • Web / Application サーバーを起動 通常ページに差し替え • 日次、週次のバックアップ • その他システムの運用で生まれた様々なスクリプト (cron、手動で実行) • 多くはログを経由して監視する → IBMの JobScheduling 製品、バックアップ製品なら、IBM のモニタリング製品に Event を直接送る。日立製 品なら JP1製品に Event を直接送る。という連携が運用製品レベルで実装されている。 「JP1にイベントを送れますか？」などの質問がよくある。 → jevsend コマンドで送れます。 http://itdoc.hitachi.co.jp/manuals/3020/30203K0660/BASE0295.HTM

HW監視・設備監視 HW毎に独自の監視の世界があります 6

HW監視 • Server / Network 機器 / Storage 機器 / UPS 例） • 電源故障(UPS:Unit Power Supply),Fan故障、その他コンポーネント故障 • Storage装置：LUNオフライン、バッテリー寿命、データコピーの失敗 • UPS :停電信号、インバーター運転信号、バイパス運転 • Hardware は、基本SNMPをサポートしていると思って間違い無い。 → 加えて HW独自の方法をサポートしている • Network機器は SNMP に加え syslog 文化もある → Network機器がsyslog を外部の syslog サーバーに転送できるようになっている • Server / Storage 機器は、独自の監視ツールを持っている。 → Server /Storage の H/Wは機能が製品毎に独特 → 独特の機能を管理するための管理ツールがある → 管理ツールと監視機能が一体化している 実際の障害時に問題解決には、Hardware独自の管理･監視ツールに頼る必用がある。 「統合」監視ツールの仕事は、何かが起きた事をいち早く察知する事

イベント監視 全ての情報は最終的にイベントとして集まってきます 7

イベント監視 • イベント監視 = 普通の人がイメージする監視 • 情報をパッケージにしたもの = イベント → しきい値に達した、ジョブが失敗した、FANが障害を起こした etc • 監視規模が大きくなればなるほど、イベントが山のように来る → 同じイベントが短時間に大量に来る事があり、さばけないとシステム停止につながる → イベント処理を自動化する機構が備わっている（特種な言語でルールを作れる） → 同じ内容のイベントを全て一つとして取り扱う → 回復イベント（しきい位置を下回った）が来た時に、以前のイベントと対消滅させる • イベントを保存するのに DBを持っている製品がほとんど → DBの運用を考える必用がある（バックアップは？保管期間は？） • イベントをトリガーにしたアクション イベントの内容を見て自動的に資産情報を検索する → IPアドレス 192.168.10.3の持ち主の連絡先を資産DBから検索してイベントに付加する → ライトアラームを点灯させる。 → Aさんに電話をかけ受信が確認できなかった場合、Bさんに電話、確認が取れてもとれなくても最期はメール。

監視と運用 監視は運用の一部です 8

監視と運用 • 監視は運用の一部 • 運用には複数のツールが存在しており、これらがスムーズに連携できているととても便利 • 監視製品のイベントコンソール上いつまでも古いイベントが存在したり、問題は継続しているのにイベ ントをクローズしてしまうケースが発生しやすい。 異常検知 チケット作成 チケットクロ ーズ 修正依頼 オープン インシデント管理 変更管理 ナレッジ管理 • キャパシティの拡張 バグの修正 コンソール上に イベント サービスデスクに チケットを生成 障害から新しいナ レッジが登録 修正依頼 クローズ 構成管理 • アプリケーションのバー ジョン変更 • サーバーの追加 監視製品 サービスデスク製品 バグ管理製品 資産管理製品 ナレッジ管理製品 ※理想はこれらの情報がリンクだけで芋づる式に辿れる事。