オペレータ コンソールのトラブルシューティング

2
2
UIM 20.3.3 では、ネイティブ OC 画面(ホーム ページ、グループ ビュー ページ、デバイス表示ページ、モニタリング テクノロジ(プローブ)ビュー ページ)を表示する CA Business Intelligence (CABI)の依存関係が削除されました。カスタムおよび標準装備のダッシュボードとレポートは、引き続き CABI を使用して表示されます。つまり、CABI と依存関係があります。ただし、ネイティブ OC 画面は CABI (Jaspersoft)に依存しなくなったので、HTML5 を使用して表示されます。HTML5 を使用したネイティブ OC 画面の詳細については、UIM 20.3.3 記事の「モニタリング データの設定および表示」の記事または「CABI 依存関係の削除(ネイティブ オペレータ コンソール)」を参照してください。
オペレータ コンソール(OC)が UMP サーバではなくプライマリ ハブ上にインストールされる
現象:
8.51、9.02、9.2、または 20.1 環境を 20.3 にアップグレードすると、オペレータ コンソール(OC)インストーラが UMP サーバではなくプライマリ ハブに OC をインストールしようとします。この問題はどのように解決できますか。
解決策:
オペレータ コンソールは wasp プローブを検索してからファイルを検索します。プライマリ ハブ上にファイルが見つかった場合、OC はプライマリ ハブにインストールされます。また、インストール先を UMP サーバに変更することはできません。
OC インストーラがプライマリ ハブに OC を展開しようとする場合は、アップグレードをキャンセルし、以下の手順に従います。
このプロセスは、プライマリ ハブに OC がすでにインストールされている場合でも有効です。
  1. プライマリ ハブ上で利用可能な wasp.cfg ファイルのバックアップを作成します。
  2. wasp アンインストーラを実行します。
  3. コントローラのインストール済みパッケージ リストで、UMP/OC 関連のパッケージが存在するかどうかを確認します。(削除する必要があるパッケージのリストについては、手順 4 を参照してください)。
    1. パッケージが存在する場合は、手順 4 に進み、プローブ ユーティリティを使用してパッケージをアンインストールします。
    2. それ以外の場合は、手順 11 に移動して wasp フォルダを削除します。
  4. IM から、プライマリ ロボット コントローラ プローブをクリックして強調表示します(UI を開かないでください)。
    primary robot controller probe
  5. Ctrl + P キーを押して、プローブ ユーティリティを開きます。
  6. コントローラ プローブの inst_pkg_remove コールバックを使用して、UMP/OC パッケージを削除します。つまり、inst_pkg_remove wasp と指定します。ドロップダウン リストから inst_pkg_remove パッケージを検索します。
  7. [パッケージ]セクションに、削除するパッケージを入力します。
    primary robot controller probe
  8. プローブ ユーティリティを使用して以下のプローブを削除します。
    • wasp_service_wrapper
    • nisapi_wasp
    • ump
    • ump_operatorconsole
    • wasp_alarmviewer_api
    • policy-management-ws
    • mcs-ui-app-portlet
    • ump_cabi
    • ump_accountadmin
    • ump_dashboard
    • adminconsoleapp
    • uimhome
    • uimesdplatelemetry
    • mps
    • wasp
  9. [実行]ボタン(再生アイコン)をクリックするとエラーが発生する場合、プライマリ ハブ上で再度プローブを展開し、次に inst_pkg_remove パッケージを実行します。
  10. コントローラ UI を開き、[ステータス]タブの[インストール パッケージ]にアクセスして、アプリが削除されていることを確認します。
    primary robot controller probe
  11. ファイルシステムから wasp フォルダを削除します。
  12. プライマリ ハブ上に wasp、adminconsoleapp、uimhome、および uimesdraylemetray パッケージを再度展開します。
  13. 以前の wasp.cfg ファイルを再利用する必要がある場合は、.cfg ファイルの webapps セクションから UMP/OC Web アプリをクリアして置き換える必要があります。
  14. wasp プローブをアクティブにします。
  15. OC インストーラを再度実行します。UMP サーバが見つかるはずです。以下のスクリーンショットでは、セットアップに 2 つの UMP サーバが含まれており、インストーラはセカンダリ UMP サーバを選択しています。その状態で、インストーラの実行を許可します。
    primary robot controller probe
  16. セカンダリ UMP への OC のインストールが完了した後、現在のセカンダリ OC 上のロボットを非アクティブ化します。
  17. OC インストーラを再度実行して、プライマリ UMP をアップグレードします。
    primary robot controller probe
  18. セカンダリ OC ロボットをアクティブ化します。
  19. 両方のサーバで展開が動作していることを確認します。
CABI ダッシュボードが OC に表示されない
現象:
CABI ダッシュボードが、すべてのブラウザ タイプですべてのユーザの OC に表示されません。「
システム コンポーネントが見つかりません
」というエラー メッセージが OC の UI に表示されます。OC の wasp.log は以下のとおりです。
DEBUG [https-jsse-nio-443-exec-7, com.firehunter.ump.utils.ProbeAddress] Unable to get port_list for robot : null ERROR [https-jsse-nio-443-exec-7, com.ca.cabi4uim.controllers.CABIController] Unable to initialize cabi probe client: Unable to communicate with any of the possible cabi probes: cabi,cabi_external
以下のような環境です。
  • UIM 20.3 および ump_operatorconsole v2.06 と CABI v4.30 は別々のロボット上にあります。
  • OC と CABI の両方で HTTPS が有効です。
  • CABIJS に直接ログオンすると、UIM CABI ダッシュボードは正常に機能します。
解決策:
以下の手順で、問題を解決できる場合があります。
  • CA Unified Infrastructure Management Hotfix Index から robot_update_9.32.zip をダウンロードし、UIM アーカイブにインポートします。
  • CABI ロボット上で、robot_update_9.32 を展開します。
  • OC ロボット上で、以下の手順に従います。
    • wasp プローブを非アクティブにします。
    • ..\Nimsoft\probes\service\wasp\webapps\cabi の名前を変更します。
    • ..\Nimsoft\probes\service\wasp\work の名前を変更します。
    • robot_update_9.32 を展開します。
    • ump_cabi 4.22 を展開し、...\Nimsoft\probes\service\wasp\webapps\cabi.war の更新日が変更されていることを確認します。
    • wasp プローブをアクティブにします。
OC のホーム ページがロードされない
現象:
OC 20.3 にログインしても、OC のホーム ページがロードされません。
解決策:
ページを閉じたり、他のオプションをクリックしたりしないでください。OC のホーム ページが完全にロードされるまで待機します。しばらくするとロードされます。
OC から CABI ログイン ページにリダイレクトされる
現象:
OC 20.3 にログインしても OC のホーム ページがロードされません。さらに、左側のペインで[レポート]オプションをクリックすると、CABI ログイン ページにリダイレクトされます。
解決策:
OC のホーム ページが完全にロードされた後に、他のオプションを選択してください。OC と CABI は別個の Web アプリケーションです。JasperServer で CABI のセッションを作成する場合、その処理はホーム ページをロードするプロセスによって許可されます。OC ホーム ページがロードされる前に[レポート]オプションを選択すると、CABI ログイン ページに
予期せず
リダイレクトされます。ホーム ページがロードされると、セッションはキャッシュされ、CABI ログイン ページへのリダイレクトは発生しなくなります。OC セッションが 15 ~ 20 分間アイドル状態になっていると、CABI セッションはタイムアウトする場合があります。その場合は、ホーム ページを選択して再度ロードします。
OC のインストール先が CABI サーバになる
現象:
使用している環境で、20.3.1 へのアップグレード中に、OC のインストールで CABI サーバへのインストールが試行されます。UMP へのインストールは試行されません(上のセクションで説明されているようなプライマリ ハブへのインストールも試行されません)。インストール中、ドロップダウン リストに OC をインストールできるサーバが表示されません。そのため、UMP サーバへのインストールなど、インストール先を選択できません。CABI サーバへのインストールのみが試行されます。
解決策:
回避策として、以下の手順に従います。
  • OC のインストールを開始する前に、CABI ロボットをシャットダウンします。
  • OC のインストールを開始します。ドロップダウン リストから、OC をインストールできる UMP サーバを選択できるようになります。
OC に SLM グループ、アカウント、SLA が表示されない
現象:
20.3.x にアップグレード後、OC に SLM グループ、アカウント、または SLA が表示されません。複数の SLA と複数のアカウントがあり、これらはデータベースにあります。
解決策:
SLA アラームが warning_severity = null の場合、この問題が発生する可能性があります。これにより、ブラウザがアカウントとグループを含む SLM リスト(OC 内)を取得できないエラーが発生します。回避策として、以下の手順に従います。
  1. データベースで以下のクエリを実行します。
    select sla_id from S_SLA_ALARM where warning_severity is null
  2. sla_id をコピーし、以下の更新クエリを実行します。
    update S_SLA_ALARM set warning_severity =0 where sla_id =<from the first query>
    null 値を持つすべての warning_severity に操作を繰り返し、0 に置換します。
  3. ログオフして再度ログインします。
    問題は解決しているはずです。
オペレータ コンソールでデータ アクセス エラーが発生する
現象:
UIM 20.3.2 でオペレータ コンソールにアクセスすると、データ アクセス エラーが表示されます。UIM 20.3.2 および CABI は正しく設定されています。また、ホーム ページをロードするときに、CABI コンテンツ(データ アクセス エラー)が表示されず、ネットワーク タブに 404 エラーが表示されます。
解決策:
これはコンテンツの問題です。CABi にダッシュボードがないため、データ アクセス エラーが発生しています。CABI ロボット上で以下のパッケージを展開または再展開します。
  • uim_core_dashboard
  • uim_unified_reporter
オペレータ コンソール ログインの監査
現象:
UIM 20.3.2 にアップグレードしました。ポータルへの外部ユーザのサインインをモニタリングしたいです。オペレータ コンソールから監査ログを収集して、アカウント ユーザとバス ユーザのタイムスタンプ付きサインインを表示する方法はありますか? また、アカウント ユーザの最終ログオン日を簡単に確認する方法はありますか?
解決策:
20.3.x で、User_ table は CM_User_ table になりました。動作は同じです。このテーブルのエントリは、ユーザ(nimbus ユーザまたはアカウント ユーザ)が初めて OC にログインするたびに作成されます。ただし、loginDate および lastLoginDate フィールドは、新しいテーブルの属性ではありません。別の方法は、KB 記事で説明されているように、OC ログインの logmon を使用して wasp.log をモニタリングすることができます。KB は引き続き UMP を参照しますが、wasp.log はログインの試行をログに記録します。
例:
  • 管理者が OC にログイン
    wasp.log
    Dec 23 12:36:13:261 DEBUG [http-nio-80-exec-17, com.fr.ump.auth.NmsAuth] Login from request user {userId=10159, screenName=
    administrator
    , [email protected], locale=en_US, firstName=administrator, middleName=null, lastName=} Dec 23 12:36:13:403 DEBUG [http-nio-80-exec-17, com.fr.ump.auth.NmsAuth] User prin [email protected]cf24917(administrator) found for 10159
  • アカウント ユーザがログイン: (
    ipxxxxx
    wasp.log
    Dec 23 12:45:47:211 DEBUG [http-nio-80-exec-12, com.nimsoft.nimbus.probe.service.wasp.db.DbPreparedStatement] Query pNJt took: 0.001s Dec 23 12:45:47:211 DEBUG [http-nio-80-exec-12, com.nimsoft.nimbus.probe.service.wasp.auth.LoginModule] ippma03 logged in. Dec 23 12:45:47:211 DEBUG [http-nio-80-exec-12, com.firehunter.ump.auth.NmsAuth] User:
    ipxxxxx
    , NimBUS login milliseconds: 129 Dec 23 12:45:47:215 DEBUG [http-nio-80-exec-12, com.firehunter.ump.auth.NmsAuth] Login from request user {userId=10161, screenName=ipxxxxx, [email protected], locale=en_US, firstName=dicjiod, middleName=null, lastName=dsmopc}