IBM Guardium Data Protection 12.x — トラブルシュート¶
IBM Guardium Data Protection 12.x — トラブルシュート（既知の問題と対処）
| 症状 | 原因 | 対処手順 | 関連ログ・コマンド | 出典 |
|---|---|---|---|---|
| S-TAP 接続不可（Status = Down） | ネットワーク／ファイアウォール／証明書／load balancing 設定不整合、または Collector 過負荷 | 1) DB サーバ上で ps -ef | grep -i tap で guard_stap / guard_discovery プロセスを確認 2) /usr/local/guardium 配下の guard_tap.ini の sqlguardip / failover_sqlguardip と Collector の到達性を確認 3) Collector 側 Buffer Free ％ をチェック（Inspection Engines UI 末尾）し過負荷を確認 4) Internal Load Balancer (ILB) が有効ならセッション分散を確認、必要に応じ failover_sqlguardip を設定 5) Windows S-TAP かつ全 Collector ダウンの場合、VERDICT_RESUME_DELAY を設定して DB セッションを進行可能に 6) GIM 経由で S-TAP を再起動（Manage > Module Installation） |
ps / guard_tap.ini / Inspection Engines UI / VERDICT_RESUME_DELAY / GIM | S35, S84, S2, S45, S73, S74, S27 |
| Sniffer 過負荷／落ち（Buffer Free 急減・パケット欠損） | 不要トラフィックの混入（統計サービス／監視製品）、Inspect Returned Data や Records Affected が広範囲で有効、port 範囲指定が広すぎる | 1) Inspection Engine の Ignored Ports List に非 DB ポートを追加（例: 80） 2) Session-level policy で IGNORE SESSION ルールを追加 例 Zabbix: IF SOURCE_PROGRAM = 'ZABBIX' { SOFT_DISCARD_SESSION } 例 SAP HANA 統計: IF DB_TYPE='SAP HANA' SOURCE_PROGRAM='STATISTICSSERVICE' { IGNORE_SESSION } 3) PACKETS_LIMIT = 30 で初期 30 パケット内にセッション特定できないものを IGNORE 4) Records Affected を厳しい port のみに限定、または store max_results_set_size / max_result_set_packet_size / max_tds_response_packets で閾値調整 5) ポート範囲指定を狭め、Engine 数を最適化（最大 50/appliance） |
Session-level policy / SR_POLICIES / store max_results_set_size / Buffer Free | S76, S84, S87, S94, S39, S45 |
| Aggregator 容量不足（disk 90% 超）／GUI 停止 | /var パーティションまたは内部 DB が 90% 超に達し、nanny プロセスが auto_stop_services_when_full でサービス停止 | 1) CLI で support show db-status used % により内部 DB 使用率を確認 2) 90% 超なら stop inspection-core で流入を止め、support show db-processlist running で長時間クエリを確認 3) restart gui で GUI を一時的に起動 → "Run Once Now" purge を Archive / Export 無効で実行 4) 必要時のみ store auto_stop_services_when_full off で 5 分停止を回避（緊急時専用、resolve 後 on に戻す） 5) 完了後 store auto_stop_services_when_full on / restart stopped_services 6) /var 側が原因なら show filesystem usage / support show large_files 10 0 で大きいファイル特定 → support clean log_files で削除（IBM Support 推奨） 7) 根本原因（policy 過剰 / S-TAP 流入過多）を見直し |
show auto_stop_services_when_full / support show db-status used % / support must_gather system_db_info / restart gui / support show large_files / support clean log_files | S79, S75, S68, S69, S66, S67, S45, S73 |
| Collector → Aggregator のデータエクスポート設定変更失敗 | Collector / Aggregator 間の shared secret key 不一致 | Collector と Aggregator の shared secret key を再確認し一致させる | Aggregation troubleshooting / Data Export | S75 |
| Aggregator で Collector 変換不可 | Collector を後付けで Aggregator/CM へ変換することは不可 | Aggregator を再インストール（インストール時に Aggregator を選択） | Installing your Guardium system | S75 |
| Aggregator restore 後 HY000 エラー | DB の整合性／参照整合の取り直しが未実施 | ダミーインポート（dummy import）を実行する | Aggregation troubleshooting | S75 |
| Audit process と Report で結果の差異 | Appliance 間の timezone 不一致 | 全 appliance を同一 timezone に揃える（CLI store timezone / GUI System Configuration） | store timezone | S75 |
| UI Banner: Data not exported or archived / Old partitions found | Daily archive がスケジュール通り動作していない、または partition が古い | Schedule UI で archive job の実行履歴を確認、必要なら手動 export → archive を実行。partition は表示順に古いもの優先で archive 対象とする | Schedule / Audit Process Log | S75, S81 |
| fix が必要だが ServiceNow / SOX チケットと監査ログの整合確認に時間がかかる | 手動チケット照合工数の問題 | 12.2 から SOX ticket reconciliation（生成 AI 連携）で ServiceNow 等の change ticket と user activity log を自動突合 | Configuring generative AI | S2 |
| patch / fix の入手方法が不明 | — | Fix Central（https://www.ibm.com/support/fixcentral）で製品 = Guardium、バージョン = 12.x を選択して bundle を取得。CM の Patch Management から Managed Unit へ配布 | IBM Fix Central / Patch Management | S78, S31 |