Netcool OMNIbus V8.1 — 典型ユースケース¶
Netcool/OMNIbus V8.1 — 典型ユースケース（運用手順）
| ユースケース名 | 想定状況 | 手順サマリ | 使用コマンド | 注意点 | 出典 |
|---|---|---|---|---|---|
| 基本構成のセットアップ | Syslog Probe + 単一 ObjectServer + Web GUI を 2 ホストで稼働 | 1) IBM Installation Manager (IM) で OMNIbus をインストール (interim fix / fix pack 適用も IM 経由) 2) ObjectServer ホストで nco_dbinit により ObjectServer (例: NCOMS) を作成 3) omni.dat に NCOMS と Probe ホストを記述 → nco_xigen で interfaces 生成 4) ObjectServer 起動 (nco_objserv -name NCOMS) と nco_pad 起動 5) Probe ホストで Syslog Probe (nco_p_syslog) を起動し ObjectServer に接続 6) Jazz for Service Management に Web GUI を導入し DASH 上に AEL 表示 |
nco_dbinit, nco_xigen, nco_objserv, nco_pad, nco_p_syslog | Probe / Gateway は別ダウンロードの追加コンポーネント。各 Probe の install.txt に従う | S4, S1 |
| イベント取り込み (Probe) | Syslog 出力アプリのアラート取り込み | 1) アプリ稼働ホストに Syslog Probe (nco_p_syslog) を配置 2) Probe rules file を編集し @Identifier / @Severity / @AlertGroup / @Node を組成 3) Probe を起動して ObjectServer NCOMS:4100 に接続 4) AEL でイベントが alerts.status に到着するのを確認 |
nco_p_syslog, nco_pa_start, nco_sql | Identifier の組成は deduplication の振る舞いを決める。重複させたいフィールド (Node + AlertKey + AlertGroup 等) を慎重に選ぶ | S1, S4 |
| 重複排除 (deduplication) | 同一現象の繰り返し発生をまとめる | 1) ObjectServer に同一 Identifier のイベントが届くと自動的に既存行の LastOccurrence と Tally を更新（deduplication） 2) Probe rules で Identifier を一意に組成すれば既定で動作（追加トリガ不要） 3) X in Y solution（短時間に複数回発生したら escalate）を SuppressEscl + xiny_aggregation.sql の insert/reinsert トリガで実装 |
alter trigger group, alerts.status update | X in Y は名前と値ペア (NVP) を使う実装で、ObjectServer のメモリ消費に注意。custom escalation は xiny_aggregation.sql の両トリガに同条件で追加 | S1 |
| Auto Resolution（自動解消） | 解消イベント (Severity = Clear) を対応する障害イベントとマッチさせて自動消し込み | 1) Probe で解消イベントを Severity=0 (Clear) としてマーク 2) generic_clear トリガが対応する Identifier の障害行を Severity=0 に更新 3) delete_clears トリガが Severity=0 の行を一括削除 4) カスタム相関は generic_clear をベースに作成（EVALUATE 句は使わない） |
automation.sql, alter trigger generic_clear | generic_clear は $NCHOME/omnibus/etc/automation.sql に定義。標準 trigger_group は本番投入前に挙動を必ず確認 | S1 |
| ハウスキーピング (Expire / De-escalate) | 古いイベントの自動削除と severity 緩和 | 1) hk_set_expiretime トリガが ExpireTime 未設定行に既定値（master.properties から）を設定 2) hk_de_escalate_events が時間経過で Severity を段階的に下げる 3) コアテーブルが膨大化しないよう housekeeping 系 trigger_group を有効維持 |
alter trigger group housekeeping enabled | master.properties の値変更で挙動制御可能。トリガを長時間止めると alerts.status の肥大化リスク | S1 |
| AEN（高優先イベントの即時通知） | クリティカル障害をオペレータ画面に最優先で表示 | 1) Probe rules file で acceleration 用フラグカラムを 1 にセット 2) ObjectServer 側でフラグセット時に AEN プロセス nco_aen 経由で配信 3) Web GUI / AEL クライアントが Granularity を待たずに通知を受信 |
nco_aen, alter trigger | Probe 側で複雑な acceleration 条件を記述できる。alerts.status に専用列を追加することがある | S1 |
| 多段構成 (Collection/Aggregation/Display) | 大規模環境で ObjectServer を役割分離 | 1) Probe を Collection ObjectServer 群に接続 2) bidirectional ObjectServer Gateway で Collection → Aggregation 層へ転送 3) Aggregation 層に Backup ObjectServer を立て、bidirectional gateway で双方向同期 → fail-over 可能化 4) ユーザは Display ObjectServer に向けて AEL を起動 |
nco_g_objserv, nco_pad | Aggregation 層の severity 取り扱いと命名規約はベストプラクティスに従う。bidirectional gateway は cache を持つ | S1 |
| Failover（基本フェイルオーバ構成） | プライマリ ObjectServer 障害で待機系へ切替 | 1) Primary と Backup ObjectServer を同一 host または別 host に構築 2) bidirectional ObjectServer Gateway で alerts.status を相互複製 3) Probe 側 Server プロパティに Primary, Backup の順に記述 4) 切替時 Probe は Backup ObjectServer に再接続して継続 |
Probe -server, nco_g_objserv | Backup の ObjectServer Gateway が動作していないと resync 漏れ発生。両系の trigger 内容は同期させる | S1 |
| EIF 経由のイベント受信 | IBM Tivoli Monitoring 等から EIF イベントを取り込む | 1) Probe for Tivoli EIF (nco_p_tivoli_eif) を導入 2) eif_default.rules / tivoli_eif.rules で EIF クラス → alerts.status カラムへマッピング 3) Predictive Event 用には predictive_event.rules を include 文の comment-out を解除して有効化 4) IBM Tivoli Monitoring 側では EIF 送信先として OMNIbus Probe を指定 |
nco_p_tivoli_eif, eif_default.rules, tivoli_eif.rules | GSKit ($NCHOME/bin) で SSL 接続。LIBPATH/LD_LIBRARY_PATH を C-based EIF アプリ側で設定 | S2, S3 |
| Predictive Event 連携 (ITM Agent) | ITM の予兆イベントを OMNIbus へ集約し AEL で可視化 | 1) ITM Agent for OMNIbus を導入し health/performance を Tivoli Enterprise Monitoring Server に送出 2) ITM 側の Predictive Situation を EIF 経由で Probe for Tivoli EIF へ転送 3) ObjectServer に専用列追加 + predictive_event.rules で alerts.status へ反映 4) Web GUI で predictive_event.elf フィルタと predictive_event.elv ビューを Event List に Load |
nco_p_tivoli_eif, Event List Configuration | Predictive Event の操作（acknowledge 等）は IBM Tivoli Monitoring 側で行う | S3 |
| WAAPI による Web GUI 設定の自動化 | ユーザ・フィルタ・ビューを大量投入 | 1) WAAPI コマンドファイル (XML) を作成 2) UNIX: $WEBGUI_HOME/waapi/bin/runwaapi options -file cmd.xml / Windows: $WEBGUI_HOME\waapi\bin\runwaapi.cmd で実行 3) 標準出力／指定ファイルで応答 XML を受信 4) DASH 上で反映を確認 |
runwaapi, runwaapi.cmd | Web GUI 側のキャッシュタイミングに依存。失敗時は Web GUI ログを確認 | S5 |
| scope-based event grouping | 同一発生源（同じ scope）のイベントを自動グルーピング | 1) Probe rules file または Netcool/Impact 連携で alerts.status の Scope 列に値を投入 2) ObjectServer 側で同一 scope 同時発生のイベントを自動的にグループ化（containment 形成） 3) IBM Netcool Operations Insight Event Analytics と組み合わせて further reduction |
Probe rules, Impact policy | Scope の粒度設計は運用ナレッジに依存。サーバルーム単位のような共通属性で一貫性を保つ | S1 |
| FIPS 140-2 モード運用 | 暗号要件のある現場で OMNIbus を稼働 | 1) ObjectServer / Process Agent / Proxy Server / Gateway を FIPS 140-2 モードで起動するようプロパティ設定 2) GSKit ($NCHOME/bin) を経由した SSL/TLS 接続で証明書配置 3) 監査ログを併用してアクセス追跡 |
GSKit, nc_gskcmd | FIPS モードでは利用可能な暗号アルゴリズムが制限される。既存サードパーティ製接続が動作するか事前検証 | S1 |