IBM Sametime Unified Telephony 9: トラブルシューティング

問題をできるだけ早期に発見して解決します。

トラブルシューティングとサポート

このセッションには、IBM® Sametime® Unified Telephony の問題のトラブルシューティングに関する情報が記載されています。

このタスクについて

以下のリンクを使用すると、Sametime Unified Telephony のための他のトラブルシューティング情報リソースが見つかります。

Sametime Connect クライアントでのコール診断を有効にする

管理対象設定を使用して、IBM Sametime Connect クライアントでコール診断を有効にします。

このタスクについて

settingGroup の値 com.ibm.collaboration.realtime.telephony.sut.diagnostics と、以下のリストに示す設定名を使用します。
<settingGroup name="com.ibm.collaboration.realtime.telephony.sut.diagnostics" lastModDate="20090924T101030Z">
</settingGroup>
  • enabled: コール診断機能の有効と無効を切り替える場合は true、無効にする場合は false を指定します。
    <setting name="enabled" value="true"/>
  • supportEmail: メールアドレスまたはメーリングリストを値として指定します。ユーザーが Sametime Connect クライアントの [コール診断] セクションで [サポートにメール送信] ボタンをクリックすると、ログがそのメールアドレスまたはメーリングリストに自動的に送信されます。
    <setting name="supportEmail" value="name@example.com"/>
  • smtpServer: Sametime Connect クライアントが自動的にログを送信するために使用する SMTP サーバーの完全修飾ホスト名を値として指定します。
    <setting name="smtpServer" value="mail.example.com"/>
  • supportUrl: ユーザーが手動でコールの問題を報告できる Web ページの URL を値として指定します。ユーザーが Sametime Connect クライアントの [コール診断] セクションで [問題の報告] ボタンをクリックすると、そのページが開きます。
    <setting name="supportUrl" value="http://www.example.com/support.html"/>

管理対象設定の構成については、Sametime 9 Wiki の「Automatically updating client preferences with the managed-settings.xml file」を参照してください。

<settingGroup name="com.ibm.collaboration.realtime.telephony.sut.diagnostics" lastModDate="20090924T101030Z">
<setting name="enabled" value="true"/>
<setting name="supportEmail" value="sametime_support@renovations.com"/>
<setting name="smtpServer" value="mail.renovations.com"/>
<setting name="supportUrl" value="http://www.renovations.com/support.html"/>
</settingGroup>

Internet Explorer を使用した CMP からのダウンロードの有効化

Microsoft Windows Internet Explorer のセキュリティ設定を変更して、IBM Sametime Unified Telephony の CMP コンソールからのダウンロードに対応できるようにします。

このタスクについて

Internet Explorer で CMP からファイル (コール/トレースツールなど) を正常にダウンロードできるようにするために、以下の手順に従って、Internet Explorer のセキュリティ設定でダウンロード時の自動プロンプトを有効にします。

手順

  1. Internet Explorer を開きます。
  2. [ツール] > [インターネット オプション] をクリックします。
  3. [インターネット オプション] ダイアログボックスで、[セキュリティ] タブをクリックします。
  4. [セキュリティ] タブで、[このゾーンのセキュリティのレベル] セクションの [レベルのカスタマイズ] ボタンをクリックします。
  5. [セキュリティ設定 - インターネット ゾーン] ダイアログボックスで、リストの [ダウンロード] セクションまで下側にスクロールします。
    [セキュリティ設定 - インターネット ゾーン] ダイアログボックス
  6. [ファイルのダウンロード時に自動的にダイアログを表示] で [有効にする] をクリックします。
  7. [OK] をクリックし、確認プロンプトが出たら [はい] をクリックします。
  8. [インターネット オプション] ダイアログボックスに戻り、[適用] をクリックして変更を反映させます。
  9. [OK] をクリックしてダイアログボックスを閉じます。

テレフォニー制御サーバーの状況の判別

照会を実行して、テレフォニー制御サーバーの状況を検出できます。

このタスクについて

srxqry 照会を実行すると、テレフォニー制御サーバーの両方のノードについて、以下の情報を知ることができます。
  • クラスタ名とノード名
  • プラットフォームとモデル
  • 以下のような実際の RTP 実行レベル
    • 4: コール処理が実行されている
    • 3 以下: コール処理が実行されていない
  • 実行状態でないすべてのプロセス
  • すべてのシグナリング IP アドレス

手順

  1. SSH クライアントを開きます。
  2. テレフォニー制御サーバーのノードの 1 つに srx ユーザーとしてログインします。
  3. 以下のコマンドを入力します。
    ./startup/srxqry
  4. オプション: コール処理が実行されていない場合は、実行レベルを 4 に再設定することによって、それをオンにできます。 ./startup/srxctrl newRunlevelNode1 newRunlevelNode2 のフォーマットを使用します。 例えば、以下のようにします。
    ./startup/srxctrl 4 4

以下は、テレフォニー制御サーバーの両方のノードが最適な状態で実行されている場合の例です。
dubtcs02node1:/unisphere/srx3000/srx/startup (171> ./srxqry

-- --- srxqry started on Tue Sep  2 11:02:14 CEST 2008 ---

-- OS          : Linux
-- Platform    : x3650T
-- Cluster     : DUBTCS02

                   Node name             Status
                   ---------             ------
  Local  Node  :   dubtcs02node1         Online at state 4
  Remote Node  :   dubtcs02node2         Online at state 4


- Get running applications information on dubtcs02node1, please stand by...

- Checking for running applications on dubtcs02node1...
-- UCE and all signaling managers are up and running on dubtcs02node1

Found the following interfaces configured from RTP configuration!
For Node: dubtcs02node1

CCM 0.5      Vip:             9.163.98.192                          Up
CCM 1.0      Vip:             9.163.98.133                          Up
CCM TGCP     Vip:             9.163.98.199                          Up
CSTA         Vip:             9.163.98.246                          Up
SIP          Vip:             9.163.98.236                          Up
SIP TLS Auth Vip:             9.162.98.239                          Up

- Checking for running applications on dubtcs02node2...
-- UCE and all signaling managers are up and running on dubtcs02node2

Found the following interfaces configured from RTP configuration!
For Node: dubtcs02node2

CCM 0.5      Vip:             9.163.98.194                          Up
CCM 1.0      Vip:             9.163.98.159                          Up
CCM TGCP     Vip:             9.163.98.201                          Up
SIP          Vip:             9.163.98.238                          Up
SIP TLS Auth Vip:             9.163.98.245                          Up

-- --- srxqry ended on Tue Sep  2 11:02:26 CEST 2008 ---

ユーザー用自己診断テスト番号の構成

ユーザーが IBM Sametime Connect クライアントからコールできることを検査するために電話をかけることができる電話番号を構成できます。

このタスクについて

ユーザーがテレフォニー機能を検査するために電話をかける自己診断テスト番号を、番号計画で割り当てることができます。 これによってユーザーは、テレフォニー機能が正常な状態かどうかを知るために友人や同僚に問い合わせなくても、Sametime Connect クライアントで電話をかけられるかどうかを検査できます。 自己診断テスト番号が割り当てられて配布されると、ユーザーはそのテスト番号を Sametime Connect の [検索] フィールドに入力することによって、テストコールを開始できます。コールが正常に完了した場合、システムはボイスメッセージで応答して発信者の統一番号を知らせます。

ユーザーが自己診断テスト番号を使用するのは自分の Sametime Connect クライアントのコール機能を検査する場合がほとんどであると思われますが、以下のように他の機能のテストにも使用できます。
  • デバイスのテスト。 ユーザーは新しい優先使用番号を作成し、それをデフォルトにすることができます。ユーザーがテスト番号に電話をかけると、まずデバイスが鳴ります。そのコールに応じると、優先使用番号が確かに正しく構成されたことを伝えるアナウンスが聞こえます。 デバイスが鳴らない場合は、入力した番号に問題がある可能性があります。
  • 規則のテスト。ユーザーは、テスト番号と置き換える優先使用番号を作成して、規則を定義できます。 例えば、ユーザーが席を離れる 10 時から 11 時の間の着信コールは、携帯電話へ回すようにする規則を作成できます。 この規則をテストするには、ユーザーは携帯電話の実際の番号を、テスト番号に置き換えます。 その後ユーザーが 10 時から 11 時の間に自分に電話をかけると、アナウンスが聞こえます。 規則が正しく定義されていたことになるので、ユーザーはテスト番号ではなく携帯電話を示すよう規則を更新します。

テスト番号を構成するには、以下の手順に従います。

手順

  1. Common Management Portal にログインします。
  2. [Telephony Control Server] タブをクリックします。
  3. [ビジネスグループ] をクリックします。
  4. ナビゲータで [使用可能な私設網番号計画 (Available Private Numbering Plan)] をクリックし、自己診断テスト番号を追加する番号計画を選択します。
  5. ナビゲータで、[変換 (Translation)] > [接頭部アクセスコード (Prefix Access Code)] をクリックします。
  6. [追加...] をクリックします。
  7. [接頭部アクセスコード (Prefix Access Code)] フィールドに、自己診断テスト番号として使用する固有の電話番号を入力します。
  8. [最小長 (Minimum Length)][最大長 (Maximum Length)] フィールドに、接頭部アクセスコードの桁数を入力します。
  9. [接頭部タイプ (Prefix Type)] として [無効コード (Invalid Code)] を選択します。
  10. [アドレスの性質 (Nature of Address)] として [不明] を選択します。
  11. [宛先タイプ (Destination Type)] として [無効コード (Invalid Code)] を選択します。
  12. [アナウンス] フィールドの横の省略符号ボタンをクリックし、次に CVB_Dn_Voice_Bk をクリックします。
  13. [Save] をクリックします。

次のタスク

自己診断テスト番号をユーザーに配布します。これでユーザーは、自分のクライアントが正常に発呼できるかどうかを検査できるようになります。

ログとトレース

このセクションでは、IBM Sametime Unified Telephony によって生成された、ログファイルおよびトレースファイルの場所、構文、使用法を説明します。

ネットワークトラフィックの分析

Ethereal Network Analyzer でグラフィックユーザーインターフェースを使用する、またはコマンドラインを使用して、ネットワークトラフィックを分析できます。

Ethereal Network Analyzer を使用したネットワークトラフィックの分析

Ethereal Network Analyzer を使用して、IBM Sametime Unified Telephony 上のネットワークトラフィックデータを分析します。すべてのパケットが即時に表示され、また VoIP 分析を使用してメッセージフローが監視されるように Ethereal を構成できます。

始める前に
ご使用のマシンに X サーバーをインストールして開始する必要があります。 「Xming」は X サーバーの例です。
このタスクについて
以下の指示に従い、ネットワーク分析用に SSH を構成して Ethereal を実行します。 これを使用すると、パフォーマンスへの影響があります。
注: 使用できる多数の Ethereal ツールがあります。 Ethereal の使用についての詳しいヘルプが必要なときは、Web 上でご使用のツールに関する資料を検索してください。 例えば http://www.wireshark.org/docs のサイトには、資料が豊富にあります。
手順
  1. マシン上で X サーバーを開始します。
  2. X システム用に、SSH クライアントトンネリングオプションを構成します。 以下のオプションを使用可能に設定します。
    • X11 転送
    • X 表示位置は、ユーザーのローカルホストである必要があります。
    • リモート X11 認証プロトコルは MIT-Magic-Cookie-1 である必要があります。
  3. テレフォニー制御サーバーのノード 1 への root ユーザーとして SSH にログインします。
  4. プロンプトで次のように入力して Ethereal を開始します。
    ethereal
  5. Ethereal Network Analyzer が開いたら、[Capture] > [Options] をクリックします。
  6. [Capture] エリアの [Interface] ボックスで、 [Pseudo-device that captures on all interface: any] を選択します。
  7. [Capture Filter] をブランクに設定します。 これですべてのネットワークトラフィックデータがキャプチャーされます。
    注: SIP または MGCL に対するフィルタも役立ちます。
  8. 次の [Display Options] をクリックします。
    • [Update list of packets in real time]
    • [Hide capture info dialog]
    • [Enable network name resolution]
    • [開始] をクリックします。
    リアルタイムネットワークデータが表示されます。
コマンドラインを使用したネットワークトラフィックの分析

テレフォニー制御サーバーを通るコールのネットワークトレースを実行するには、以下の手順に従います。

このタスクについて
tethereal を使用して、テレフォニー制御サーバーを通るコールのライブパケットデータの収集と書き込みを行えます。
手順
  1. SSH シェルを開きます。
  2. テレフォニー制御サーバーに root ユーザーとしてログインします。
  3. トレースディレクトリに移動します。
    cd trace
  4. トレースデータを収集するには、次のコマンドを入力します。
    tethereal -i bond0 -q -w somefile.pcap 
    コールフローが実行されたら、CTRL-C キーを押します。
  5. 次のコマンドで、トレースデータを zip します。
    zip somefile.zip somefile.pcap
    zip された結果ファイルは、/root/trace に置かれます。
  6. WinSCP などのセキュア FTP クライアントを使用して、このファイルを収集します。

テレフォニー制御サーバー上でのログとトレース

リアルタイムトレースユーティリティ (RTT) を使用すると、テレフォニー制御サーバーのアクティビティをトレースできます。 収集されるトレースデータのタイプは、実行するスクリプトで決定されます。

このタスクについて
IBM Sametime Unified Telephony における問題の大半は、RTT トレースの実行と収集により判別できます。スクリプトはテレフォニー制御サーバー上の /unisphere/srx3000/srx/rtt_trace_scripts にあります。 通常は、以下のスクリプトのサブセットを 1 つだけ実行します。
  • csta_all* - テレフォニー制御サーバーとテレフォニーアプリケーションサーバーの間の通信をトレースするための、コンピュータによってサポートされる通信アプリケーションスクリプト。
  • hiq_all - プロセスの登録済みトレースポイントをすべてアクティブにするための、基本的な汎用スクリプト。
  • uce_all* - コールをトラッキングするための、ユニバーサルコールエンジンスクリプト。
  • mgcp_all* - メディアサーバーとゲートウェイ通信をトレースするための、メディアゲートウェイ制御プロトコルスクリプト。
  • sipsm_all* - CCM プロセスの開発トレースをアクティブ化またはクリアします。
  • soapServer_all - soapServer プロセスの開発トレースをアクティブ化またはクリアします。
手順
  1. SSH クライアントを開きます。
  2. テレフォニー制御サーバーのノード 1 に srx ユーザーとしてログインします。
  3. オプション: 選択可能なすべてのスクリプトをリストするには、このコマンドを入力します。 /unisphere/srx3000/srx/rtt_trace_scripts/ls 以下のリストが表示されます。
    acarscan_all*  mgcp_all*       rtm_omm_audit_minimal*  soapExport_all*      uce_dev*
    ccm_dev*       mgcpsm_dev*     rtm_prov*               soapMassProv_all*    xdm_prov*
    csta_all*      pdm_all*        sbrk_all*               soapServer_all*      xdm_reg*
    csta_dev*      prm_all*        sbrk_dev*               submgtSchedule_all*
    hiq_all*       rtm_all*        sipsm_all*              system.tfl
    hiq_msg*       rtm_callp*      sipsm_dev*              TFApply.pl*
    irm_all*       rtm_omm_audit*  sipsm_minimal*          uce_all*
  4. 適切なトレーススクリプトを開始します。 例:
     /unisphere/srx3000/srx/rtt_trace_scripts/csta_all
     /unisphere/srx3000/srx/rtt_trace_scripts/uce_all
     /unisphere/srx3000/srx/rtt_trace_scripts/hiq_msg
     /unisphere/srx3000/srx/rtt_trace_scripts/sipsm_all 
     /unisphere/srx3000/srx/rtt_trace_scripts/mgcp_all 
     /unisphere/srx3000/srx/rtt_trace_scripts/soapServer_all 
  5. トレースディレクトリに移動します。
    cd ../trace
  6. トレース情報を収集します。
    oprtt_read -R > somefile.rtt  
    コールフローが実行されたら、CTRL-C キーを押します。
  7. 次のコマンドで、ログファイルを zip します。
    zip somefile.zip somefile.rtt 
  8. WinSCP などのセキュア FTP クライアントを使用して、zip された somefile.zip ファイルを収集します。

テレフォニーアプリケーションサーバー上のログとトレース

テレフォニーアプリケーションサーバーの問題の解決に役立つように、ログとトレースプロパティを構成できます。

テレフォニーアプリケーションサーバー上での診断の収集

collect.sh コマンドを使用して自動的にダンプファイルを取得し、テレフォニーアプリケーションサーバーを再起動します。

手順
テレフォニーアプリケーションサーバーで、次のコマンドを実行します。
/enterprise/common/bin/collect.sh -DHCR
  • D は、要求されたファイルのダンプを作成します。
  • H は、heapdumps (Java™ アプリケーションが使用するアクセス可能なすべてのオブジェクトのダンプ) を組み込みます。
  • C は、coredumps (プロセスがクラッシュする直前のプロセスの作業メモリの状態を記録したもの) を組み込みます。
  • R は、テレフォニーアプリケーションサーバーを再起動します。

作成された heapdump は、/log/dumps/ ディレクトリに格納されます。

作成された残りのファイルは、/tmp/ ディレクトリに格納されます。以下に例を示します。
dumpfiles-ibmoem-tas5-2012-06-21-T145451-EEST.tar
logfiles-ibmoem-tas5-2012-06-21-T145451-EEST.tar
SIP ログとトレース

テレフォニーアプリケーションサーバーで SIP ログとトレースを使用して、IBM Sametime Unified Telephony における問題を診断できます。

このタスクについて
テレフォニーアプリケーションサーバー用の SIP ログファイルは、開始時に読み込まれ、トレースサービスを構成するために使用されます。 トレースサービスプロパティまたは設定の多くは、サーバープロセスの実行中に変更できます。 コンポーネントおよびコンポーネントグループのログの詳細レベルも指定できます。 詳しくは、WebSphere Application Server のインフォメーション・センターを参照してください。
手順
  1. WebSphere® Integrated Solutions Console にログインします。
  2. [トラブルシューティング] > [ログとトレース (Logs and Trace)] > [telephony_application_server_name] をクリックします。
  3. [全般] プロパティエリアで、[ログの詳細レベルの変更 (Change Log Detail Levels)] をクリックします。
  4. ボックス内に、次のレベル設定を入力します。
     *=info: com.ibm.sip.=all: com.ibm.ws.sip.=all 
  5. [適用][OK] をクリックします。
  6. 変更を保存してから WebSphere Application Server を再起動して、変更内容を有効にします。
次のタスク
/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/logs/server_name/trace.log で、トレースログを検索できます。
テレフォニーアプリケーションサーバーの詳細ログの有効化

OSGi と BCOM のログのプロパティをテレフォニーアプリケーションサーバー用に構成し、OSGi のログプロパティのデバッグバージョンを使用してサーバーを実行することができます。

このタスクについて
テレフォニーアプリケーションサーバーは、OSGi フレームワークが組み込まれた Eclipse Rich Client Platform 上に構築されます。 OSGi コンテナのログに記録された項目は、以下の場所に送信されます。
  • 開始ログは /log/osgi.log
  • ランタイムログは /log/osgi.err。ログレベルの変更は /enterprise/common/conf/logging.properties で行います

BCOM (基本通信) ログは /log/sut*.log で行われます。Common Management Portal を使用して、ログレベルを使用可能にします。

手順
  1. テレフォニーアプリケーションサーバーに root ユーザーとしてログインします。
  2. 次のコマンドを実行して、フレームワークを停止します。
    /etc/init.d/framework stop
  3. /enterprise/common/conf/logging.properties ファイルのバックアップコピーを作成します。
  4. /enterprise/common/conf/logging.properties ファイルを、デバッグバージョン /enterprise/common/conf/logging_debug.properties のコピーで置き換えます。その際、新しいファイルの名前を、元の名前 (logging.properties) に一致するように変更します。
  5. 次のコマンドを実行して、フレームワークを開始します。
    /etc/init.d/framework start

    これにより、デバッグバージョンの logging.properties ファイルを使用してシステムが実行されます。

  6. トラブルシューティングが完了したら、/etc/init.d/framework stop を使用して、もう一度フレームワークを停止します。
  7. 元の logging.properties ファイルを置き換えます。
  8. /etc/init.d/framework start でフレームワークを開始します
次のタスク
トレースしようとしている問題が再現した後、デフォルトの BCOM ログレベルを再アクティブ化する必要があります。
テレフォニーアプリケーションサーバーログの収集

テレフォニーアプリケーションサーバーによって生成された診断ログを収集するには、以下の手順で行います。

始める前に
テレフォニーアプリケーションサーバーのログに記録できるように、ログが有効になっていなければなりません。
手順
  1. SSH シェルを開きます。
  2. テレフォニーアプリケーションサーバーに root ユーザーとしてログインします。
  3. 以下のコマンドを入力します。
     cd /log; zip somefile.zip *.* 
    zip された結果ファイルは、/log/somefile.zip に置かれます。
  4. WinSCP などのセキュア FTP クライアントを使用して、このファイルを収集します。
テレフォニーアプリケーションサーバー上のネットワークトレースの実行

テレフォニーアプリケーションサーバーを通るコールのネットワークトレースを実行するには、以下の手順に従います。

このタスクについて
tcpdump を使用して、テレフォニーアプリケーションサーバーを通るコールのライブパケットデータの収集と書き込みを行えます。
手順
  1. SSH シェルを開きます。
  2. テレフォニーアプリケーションサーバーに root ユーザーとしてログインします。
  3. トレースディレクトリに移動します。
    cd trace
  4. トレースデータを収集するには、次のコマンドを入力します。
    tcpdump -s 0 -q -w somefile.pcap
    コールフローが実行されたら、CTRL-C キーを押します。
  5. 次のコマンドで、トレースデータを zip します。
    zip somefile.zip somefile.pcap
    zip された結果ファイルは、/root/trace に置かれます。
  6. WinSCP などのセキュア FTP クライアントを使用して、このファイルを収集します。

Sametime Connect 上のログとトレース

Sametime Unified Telephony を使用するようにプロビジョニングされた IBM Sametime Connect ユーザーは、そのクライアント上でトレースを使用可能に設定できます。

このタスクについて

詳細は、Sametime Standard のトピック「Sametime Connect でのログとトレース」を参照してください。

コールの問題のトラブルシューティング

このトピックを使用すると、ご使用の IBM Sametime Unified Telephony デプロイ済み環境における問題を解決する上で役立ちます。

Sametime Unified Telephony 全体が停止したときのトラブルシューティング

Sametime Unified Telephony のネットワーク全体でコールを完了できない場合、以下のトラブルシューティング手順に従います。

  1. テレフォニー制御サーバーが稼働していることを確認します。

    1. SSH クライアントを開きます。
    2. テレフォニー制御サーバーのノード 1 に srx ユーザーとしてログインします。
    3. 以下のコマンドを入力します。
      ./startup/srxqry
    4. テレフォニー制御サーバーが稼働していないときは、「テレフォニー制御サーバーのダウン時の回復」にある手順を実行します。
  2. テレフォニー制御サーバーと PBX との間の接続を検査します。
    1. 統一番号加入者としては構成されてはおらず、テレフォニー制御サーバーに直接登録されたテスト電話を使用して、テスト電話と PBX 装置に接続した電話との間で、両方向のコールをテストします。
    2. このテストで接続に問題があることが分かった場合は、 テレフォニー制御サーバーに直接登録された 2 つのテスト電話 (いずれも統一番号加入者としては構成されていない) 間でコールを試行します。 このコールに失敗した場合は、テレフォニー制御サーバーにおける CSTA 以外の問題として扱います。
    3. ステップ b のコールは成功したが、ステップ a のコールは失敗した場合は、 テレフォニー制御サーバーと PBX 装置の間の接続の問題として扱います。
    4. 前のステップで、テレフォニー制御サーバーが作動していることが分かった (ステップ a のコールが成功した) 場合、必要であれば、一時的な緊急サービスを加入者のデフォルト番号に提供できる可能性があります。 苦情がまた発生する可能性があるサービス時間帯まで、テレフォニーアプリケーションサーバーをシャットダウンしておきます。
  3. テレフォニーアプリケーションサーバーが稼働していること確認します。
    1. テレフォニー制御サーバーのノード 1 から srx ユーザーとしてログインし、cstasmdump コマンドを実行して、テレフォニーアプリケーションサーバーへの接続を検査します。 少なくとも何人かの加入者がモニタされるはずです。
    2. 加入者がモニタされない場合は、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの問題として扱います。
    3. 一部の加入者だけがモニタされない場合は、「モニタされていない状況」のステップに従います。
  4. テレフォニーアプリケーションサーバーが作動している場合は、問題が Sametime Connect 上の着信コールと発信コールに影響を与えているかどうかを判別します。問題が着信コールに影響を与えている場合は、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの問題として扱います。
  5. 問題が発信コールだけに影響を与えている場合は、BCOM と Sametime をこのシナリオから削除した上で、テレフォニーアプリケーションサーバーを使用して問題を再現できるかを判別します。
    1. テレフォニーアプリケーションサーバーの Web クライアントを使用して、シナリオを実行します。
    2. 問題を再現できる場合は、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの問題として扱います。
  6. 問題を再現できない場合、Sametime をシナリオから削除した上で、テレフォニーアプリケーションサーバーと BCOM を使用して問題を再現できるかを判別します。
    1. Sametime Connect クライアントを使用してシナリオを実行します。
    2. 問題を再現できる場合は、テレフォニーアプリケーションサーバーと BCOM の問題として扱います。
    3. 問題を再現できる場合は、Sametime クライアント/サーバーの問題として扱います。

隔離されたコール関連問題のトラブルシューティング

隔離された Sametime Unified Telephony ユーザーにコール関連の問題がある場合、以下の手順に従います。

  1. 問題となっている加入者が現在モニタされているかどうかを判別します。
    1. テレフォニー制御サーバーのノード 1 から srx ユーザーとしてログインし、cstasmdump コマンドを実行して、そのユーザーがモニタされているかを確認します。
    2. ユーザーがモニタされていない場合は、「モニタされていない状況」の指示に従います。
  2. シナリオからテレフォニー制御サーバーを削除し、問題を再現できるかを検査します。 再現できる場合は、PBX 装置の問題として扱います。
  3. テレフォニー制御サーバーがシナリオに含まれているときにのみ問題が発生する場合は、CSTA (テレフォニーアプリケーションサーバー) をシナリオから削除して、問題を再現できるかを判別します。
    1. 統一番号加入者としては構成されてはおらず、テレフォニー制御サーバー上に直接登録されたテスト電話を使用します。 テスト電話と PBX 装置に接続した電話との間で、両方向のコールをテストします。
    2. このテストで接続に問題があることが分かった場合は、テレフォニー制御サーバーに直接登録された 2 つのテスト電話 (いずれも統一番号加入者としては構成されていない) 間でコールを試行します。 このコールに失敗した場合は、テレフォニー制御サーバーにおける CSTA 以外の問題として扱います。
    3. ステップ b のコールは成功したが、ステップ a のコールは失敗した場合は、 テレフォニー制御サーバーと PBX 装置の間の接続の問題として扱います。
  4. 上記シナリオで問題を再現できない場合は、テレフォニーアプリケーションサーバーをシナリオから削除した上で、CSTA を使用して問題を再現できるかを判別します。
    1. CSTA ブラウザを使用してシナリオを実行し、テレフォニーアプリケーションサーバーのアクションをエミュレートします。
    2. 問題を再現できる場合は、テレフォニー制御サーバーの CSTA の問題として扱います。
  5. 問題が着信コールや発信コール (Sametime クライアント経由のもの) に影響を与えているかを判別します。 問題が着信コールに影響を与えている場合は、テレフォニーアプリケーションサーバーでモニタされる加入者の問題として扱います。
  6. 上記のシナリオでは問題を再現できない場合は、Sametime をシナリオから削除した上で、テレフォニーアプリケーションサーバーを使用して問題を再現できるかを判別します。
    1. テレフォニーアプリケーションサーバーの Web クライアントを使用して、シナリオを実行します。
    2. 問題を再現できる場合は、テレフォニーアプリケーションサーバーでモニタされる加入者の問題として扱います。
  7. 問題を再現できない場合、Sametime をシナリオから削除した上で、テレフォニーアプリケーションサーバーと BCOM を使用して問題を再現できるかを判別します。
    1. Sametime Connect クライアントを使用してシナリオを実行します。
    2. 問題を再現できる場合は、テレフォニーアプリケーションサーバーと BCOM の問題として扱います。
    3. 問題を再現できる場合は、Sametime クライアント/サーバーの問題として扱います。

テレフォニー制御サーバーのダウン時の回復

テレフォニー制御サーバーの 1 つノードが RTP レベル 3 以下である (コール処理が実行されていない) ときには、以下の指示に従います。

  1. 最低 1 つのノードが状態 4 である (コール処理が実行されている) 場合、テレフォニー制御サーバーのそのノードから、 問題の発生の数時間前からの RtpDumpLog の出力のコピーを取得します。
    1. srx ユーザーとしてログインし、以下のコマンドを実行します。
      RtpDumpLog –s <MMDDHHMM>
    2. 通常このコマンドでは両方のノードからの出力をマージしたものが提供されますが、このシナリオでは、ノード間の通信が途絶えた場合に備えて、各ノードで個別にこれを実行してください。
  2. 両方のノードから、問題の発生から現在に至るまでの /var/log/messages/var/log/messages-* のコピーを取得します。 これらのログから、詳細な調査のため何を行うべきかに関して、手掛かりが見つかるかもしれません。 はっきりしないときには、次の手順に進みます。
  3. いずれのノードもスワップメモリ使用率が過度に増大していないことを確認します。
    1. root ユーザーとしてログインし、両方のノードで片側ずつ top コマンドを実行します。
    2. 以下の行を確認します。
      Swap:  4192924k total,        0k used,  4192924k free,  1212524k cached
    3. used の値が total の値の 50% を超えていないことを確認します。
  4. いずれのノードも CPU 使用率が落ちていないことを確認します。
    1. root ユーザーとしてログインし、両方のノードで片側ずつ top コマンドを実行します。
    2. [1] キーを押します。
    3. 以下の行を確認します。
      Cpu0  :  0.3% us,  0.4% sy,  0.1% ni, 99.1% id,  0.2% wa,  0.0% hi,  0.0% si
      Cpu1  :  0.3% us,  0.4% sy,  0.1% ni, 99.1% id,  0.2% wa,  0.0% hi,  0.0% si
      Cpu2  :  0.2% us,  0.5% sy,  0.0% ni, 99.0% id,  0.2% wa,  0.0% hi,  0.0% si
      Cpu3  :  0.3% us,  0.5% sy,  0.0% ni, 98.2% id,  0.9% wa,  0.0% hi,  0.0% si
    4. 示された 4 つの CPU のいずれについても、id の値が常に 3% 未満になっていることはないことを確認します。
  5. RapidStat –c –b の出力を提供します。
  6. 回復させるため、以下の手順に従います。
    1. 1 つのノードだけが RTP レベル 3 であるときは、そのノードから以下のコマンドを実行して、それを状態 2 に下げます。
      ~srx/startup/srxctrl 2 0 
    2. それが状態 2 になったならば、そのノードでオペレーティングシステムをリブートします。
    3. リブート後、状態 4 にまで戻るかどうかを確認します。 戻らない場合、そのノードについて、RtpDumpLog –s Time of Reboot による追加出力を取得します。
    4. サービスがまだ復元していない場合、1 つのノードから次のコマンドを実行して、両方のノードを状態 2 に下げてみます。
      ~srx/startup/srxctrl 2 2 
    5. 各ノードが状態 2 に達したことを個別に確認します。
    6. 両方のノードを同時にリブートします。
    7. サービスが復元しない場合は、IBM にお問い合わせください。

テレフォニー制御サーバーにおける CSTA 以外の問題の解決

2 つの電話 (統一番号加入者ではない) 間でテストコールが作動しないときは、以下の手順に従います。

  1. 最低 1 つのノードが状態 4 である (コール処理が実行されている) 場合、テレフォニー制御サーバーのそのノードから、 問題の発生の数時間前からの RtpDumpLog の出力のコピーを取得します。 a. b.  
    1. srx ユーザーとしてログインし、以下のコマンドを実行します。
      RtpDumpLog –s <MMDDHHMM>
    2. 通常このコマンドでは両方のノードからの出力をマージしたものが提供されますが、このシナリオでは、ノード間の通信が途絶えた場合に備えて、各ノードで個別にこれを実行してください。
  2. 両方のノードから、問題の発生から現在に至るまでの /var/log/messages/var/log/messages-* のコピーを取得します。 これらのログから、詳細な調査のため何を行うべきかに関して、手掛かりが見つかるかもしれません。 はっきりしないときには、次の手順に進みます。
  3. いずれのノードもスワップメモリ使用率が過度に増大していないことを確認します。
    1. root ユーザーとしてログインし、両方のノードで片側ずつ top コマンドを実行します。
    2. 以下の行を確認します。
      Swap:  4192924k total,        0k used,  4192924k free,  1212524k cached
    3. used の値が total の値の 50% を超えていないことを確認します。
  4. いずれのノードも CPU 使用率が落ちていないことを確認します。
    1. root ユーザーとしてログインし、両方のノードで片側ずつ top コマンドを実行します。
    2. [1] キーを押します。
    3. 以下の行を確認します。
      Cpu0  :  0.3% us,  0.4% sy,  0.1% ni, 99.1% id,  0.2% wa,  0.0% hi,  0.0% si
      Cpu1  :  0.3% us,  0.4% sy,  0.1% ni, 99.1% id,  0.2% wa,  0.0% hi,  0.0% si
      Cpu2  :  0.2% us,  0.5% sy,  0.0% ni, 99.0% id,  0.2% wa,  0.0% hi,  0.0% si
      Cpu3  :  0.3% us,  0.5% sy,  0.0% ni, 98.2% id,  0.9% wa,  0.0% hi,  0.0% si
    4. 示された 4 つの CPU のいずれについても、id の値が常に 3% 未満になっていることはないことを確認します。
  5. RapidStat –c –b の出力を提供します。
  6. 以下の手順は、この状態からの回復を試行するためのものです。 以下の手順はサービスに影響を与えるので、サービス停止がもう進行していない場合は、サービス時間帯まで待ってからそれらの手順を実行してください。
    1. 1 つのノードから次のコマンドを実行して、両方のノードを状態 3 に下げてみます。
    2. ~srx/startup/srxctrl 3 3 
    3. 各ノードが状態 3 に達したことを個別に確認します。
    4. 両方のノードを状態 4 に戻します。
    5. サービスが復元しない場合は、IBM にお問い合わせください。

テレフォニー制御サーバーとテレフォニーアプリケーションサーバーの間の接続問題の解決

テレフォニーアプリケーションサーバーで構成された統一番号加入者が、どれもテレフォニー制御サーバーによってモニタされていないときには、以下の手順に従います。

  1. テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの間の LAN 接続を検査します。
    1. テレフォニーアプリケーションサーバーで以下のコマンドを実行します。
      netstat –eanp | grep 1040
    2. 以下の例のような出力を見つけます。
      tcp        0      0 10.233.6.37:43871       10.233.2.115:1040       ESTABLISHED 103        227198     3964/jsvc.exec
    3. この TCP 接続が ESTABLISHED と表示されていないときには、テレフォニー制御サーバーのノード 1 で同じコマンドを入力することにより、テレフォニー制御サーバーがポート 1040 上で listen していることを検査します。 以下のような出力を見つけます。
      tcp        0      0 10.233.2.115:1040       0.0.0.0:*               LISTEN      1522       40384      10752/ttudProc1 
    4. テレフォニー制御サーバーが CSTA の適正な IP アドレスのポート 1040 上で listen していないときには、テレフォニー制御サーバーが CSTA ポートで listen していない問題として扱います。
    5. ステップ c でテレフォニー制御サーバーがポート 1040 上で listen していても、ステップ a では ESTABLISHED 接続が示されなかったときには、テレフォニーアプリケーションサーバー上で以下のコマンドを使用して、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの間の LAN 接続を検査します。
      telnet <CSTA IP Address of telephony control server> 1040 
    6. 以下の例のような出力を見つけます。
      Trying 10.233.2.115... Connected to 10.233.2.115. Escape character is ‘^]'. µ0005<?xml version=”1.0” encoding=”UTF-8”?><SystemStatus xmlns=”http://www.ecma-international.org/standards/ecma-323/csta/ed4”><systemStatus>enabled</systemStatus></SystemStatus>
    7. 前のステップの出力が表示された場合は、<CTRL> ] を使用してこの接続をエスケープします。すると telnet プロンプトが表示されます。 これに q <CR> と応答して、シェルに戻ります。 出力が表示された場合には、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの間の LAN 接続は使用可能ではあるものの、テレフォニーアプリケーションサーバーが接続を作成しなかったことを意味します。 テレフォニーアプリケーションサーバーの /log ディレクトリからログを収集し、サーバーを再起動してみます。
    8. ステップ f で出力が表示されなかった場合には、テレフォニーアプリケーションサーバーが CSTA ポート上でテレフォニー制御サーバーと通信できないことを意味します。 テレフォニー制御サーバーの CSTA ポート上で CSTA ブラウザがテレフォニー制御サーバーと通信できることは、以前のステップで既に判明している可能性があります。 したがって問題は、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの間の LAN 接続に関連していると考えられます。 これを LAN 問題として扱います。
  2. 上記ステップ 1b で ESTABLISHED メッセージが表示された場合には、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの間の CSTA LAN 接続は適正であるものの、テレフォニー制御サーバーがテレフォニーアプリケーションサーバーからのモニタ要求への応答に失敗しているか、またはテレフォニーアプリケーションサーバーがモニタ要求を送信していないかのいずれかであることを意味します。 この場合、以下のようにして、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの両方からトレースを収集します。
    1. テレフォニーアプリケーションサーバーとテレフォニー制御サーバーのシステム時刻が同期していることを確認します。
    2. テレフォニーアプリケーションサーバー上にディレクトリ /tmp/logs を作成することにより、ログファイルのコピーの一時保管場所を作成します。 それが既に作成されている場合は、新規ログ用にここでそれを空にします。
    3. テレフォニーアプリケーションサーバーまたはテレフォニー制御サーバーのいずれかから、この手順の開始時のタイムスタンプを取得します。
    4. csta-user および cstasm フラグを使用可能にして、テレフォニー制御サーバー上で RTT トレースを開始します。
    5. テレフォニーアプリケーションサーバーを再起動します。
    6. テレフォニー制御サーバー上で RTT トレースを停止します。
    7. cstasmdump を実行して、加入者がモニタされているかどうかを再度確認します。
    8. 加入者がまだモニタされていない場合は、上記ステップ c で取得したタイムスタンプ後に変更された、テレフォニーアプリケーションサーバーの /log ディレクトリにあるファイルすべてを、ステップ b で作成した一時保管場所にコピーします。ls –ralt /log を使用して、最近変更されたファイルをリスト下部に表示させます。
    9. ステップ h でコピーしたファイルすべて、およびステップ f で停止した RTT トレースを提供します。

テレフォニー制御サーバーと PBX の間の接続問題の解決

デバッグの結果、テレフォニー制御サーバーに直接登録された、統一番号加入者としては定義されていない電話が、PBX 上の電話との間のコールの送受信で問題があることが判明した場合、以下の指示に従います。

  1. テレフォニー制御サーバーに直接登録された、統一番号加入者でない 2 つの電話間で直接コールできることを確認します。 これらのコールが失敗する場合、「テレフォニー制御サーバーにおける CSTA 以外の問題」の指示に従います。
  2. テレフォニー制御サーバーから以下のコマンドを使用することにより、テレフォニー制御サーバーと PBX SIP インターフェースの間の SIP メッセージフローを検査します。
    tethereal –i any | grep <SIP Signalling IP of PBX Equipment>.  
  3. テレフォニー制御サーバーに直接登録された電話と PBX 電話の間で、各方向にコールしてみます。 SIP トラフィックが両方向に見られる場合は、テレフォニー制御サーバー/SIP PBX ダイヤル計画の問題として扱います。
  4. SIP トラフィックが見られなかった場合は、2 つのソフトスイッチの相互登録を確認します。 Common Management Portal で、テレフォニー制御サーバーアシスタントを使用して、PBX 装置を示す SIP エンドポイントが登録済みであることを確認します。 PBX で、テレフォニー制御サーバーを示すエンドポイントが登録済みであることを確認します。
  5. 少なくとも一方の側で未登録の場合、以下の手順を使用して、テレフォニー制御サーバーと PBX 装置の間の LAN 接続を検査します。
    注: このテストでは、テレフォニー制御サーバーをファイアウォールなしの状態にして、システムを RTP 状態 3 3 まで下げて状態 4 4 に戻す必要があります。ファイアウォール規則を復元するとサービスに影響します。 この時点で、システムが既にサービス停止状態になっていると想定しています。
    1. 以下のコマンドを使用して、テレフォニー制御サーバーの両方のノードで、ファイアウォール規則を一時的に使用不可にします。
       iptables –flush
      .
    2. それぞれの側から他方の側の SIP トランキングアドレスに ping してみます。 ping に成功した場合は、これで登録が行われ、両端間でコールが可能になる可能性があるので、様子を見てみます。 このようになった場合は、パケットフィルタ規則の問題として扱います。
  6. ping に成功したものの、登録がまだ行われず、コールが引き続き不可能である場合は、以下のステップに従います。
    1. テレフォニー制御サーバーと PBX の間のインターフェース上で、Ethereal の詳細トレースを収集します。
    2. また、テレフォニー制御サーバー上で sipsm の RTT トレースを使用可能に設定します。
    3. トレースを実行しながら、まずテレフォニー制御サーバーのノードの 1 つからタイムスタンプを取得した後、テレフォニー制御サーバーを状態 3 3 に下げて状態 4 4 に戻します。このステップで、使用不可になった通常のファイアウォール規則が再度使用可能になります。
    4. テレフォニー制御サーバーとカスタマー PBX 装置が相互に登録されて、それらの間のコールが可能になるかを確認します。
    5. トレースを停止します。
    6. コールがやはり不可能である場合には、これらのトレースを添付して、IBM にお問い合わせください。
    7. 次のコマンドの出力も添付してください。 テレフォニー制御サーバーのいずれかのノードで srx ユーザーとしてログインします。
      RtpDumpLog –s <time>
      ここで time は、システムが状態 3 に下がったときの時刻です (HHMM 形式)。

加入者がモニタされていない問題の解決

全部ではなく、一部の加入者が、テレフォニー制御サーバーによってモニタされていないときには、以下の手順に従います。

  1. 加入者統一番号の構成を確認します。
    1. Common Management Portal を開きます。
    2. [テレフォニー制御サーバー] > [ビジネスグループ (Business Group)] > [BG および PNP の選択 (Choose BG and PNP)] > [メンバー] > [加入者 (Subscribers)] > [加入者統一番号 (Subscriber Unified Number)] > [サービス (Services)] をクリックします。
    3. 以下の設定を確認します。[CSTA] が ON で タイプ 1 (Type 1) に設定されている必要があります。[統一番号] が ON で InboundAndOutbound に設定されている必要があります。
  2. テレフォニーアプリケーションサーバーで加入者の構成が適正であることを確認します。
    1. Common Management Portal で、[ユーザーとリソース (Users & Resources)] > [ユーザー] > [ユーザー管理 (User Administration)] > [ユーザー] > [調査対象のユーザー ID (UserID being investigated)] > [リソース (Resources)] をクリックします。
    2. 加入者の [オフィス/プライベート番号 (Office/Private Code)][内線 (Extension)] が統一番号加入者 (DID) 番号に一致し、[統一番号] に緑のチェックマークがあることを確認します。
  3. すべての構成が正しい場合は、以下の手順を実行します。
    1. テレフォニーアプリケーションサーバーとテレフォニー制御サーバーのシステム時刻が同期していることを確認します。
    2. テレフォニーアプリケーションサーバー上にディレクトリ /tmp/logs を作成することにより、ログファイルのコピーの一時保管場所を作成します。 それが既に作成されている場合は、新規ログ用にここでそれを空にします。
    3. テレフォニーアプリケーションサーバーまたはテレフォニー制御サーバーのいずれかから、この手順の開始時のタイムスタンプを取得します。
    4. csta-user および cstasm フラグを使用可能にして、テレフォニー制御サーバー上で RTT トレースを開始します。
    5. テレフォニーアプリケーションサーバーで加入者を削除して再作成し、上記の緑のチェックマークのあるリソースとして、統一番号を再度割り当てます。
    6. テレフォニー制御サーバー上で RTT トレースを停止します。
    7. cstasmdump を実行して、加入者がモニタされているかどうかを再度確認します。
    8. 加入者がまだモニタされていない場合は、上記ステップ c で取得したタイムスタンプ後に変更された、テレフォニーアプリケーションサーバーの /log ディレクトリにあるファイルすべてを、ステップ b で作成した一時保管場所にコピーします。ls –ralt /log を使用して、最近変更されたファイルをリスト下部に表示させます。
    9. ステップ h でコピーしたファイルすべて、およびステップ f で停止した RTT トレースを提供します。

テレフォニーアプリケーションサーバーと BCOM の問題の解決

テレフォニーアプリケーションサーバー Web クライアントからの発呼は可能でも、Sametime Connect からは不可能であると判別した場合は、以下の手順に従います。

  1. Sametime Connect が、テレフォニーアプリケーションサーバー上の BCOM への接続を、セキュア接続 (TCP ポート 4709) と非セキュア接続 (TCP ポート 4708) のどちらで試行しているかを確認します。これは Sametime サーバー上で Ethereal または netstat を使用して行います。
  2. 接続が成功しない場合は、以下の手順に従います。
    1. テレフォニーアプリケーションサーバーの BCOM ポートへの LAN 接続を検査します。
    2. コマンドプロンプトに以下のコマンドを入力します。
      telnet <telephony application server IP Address> 4708 
      または
      telnet <telephony application server IP Address> 4709
      上記のステップ 1 で検出された、Sametime で使用されるポートを使用します。
    3. 画面がブランクになれば、接続が成功したことを意味します。 <CTRL> ] に続いて q <CR> を押すことにより、この接続をエスケープします。
    4. 接続が成功しなかった場合、以下のコマンドをテレフォニーアプリケーションサーバーで入力することにより、テレフォニーアプリケーションサーバーが関連ポート上で listen していることを確認します。
      netstat –eanp | grep 4708 or netstat –eanp | grep 4709
      .
    5. 以下のような出力が表示されるはずです。
      tcp        0      0 10.233.6.37:4708        :::*                    LISTEN      103        13917      3964/jsvc.exec 
    6. 上記のような出力が表示されない場合は、テレフォニーアプリケーションサーバーがダウンしている問題として扱います。
    7. ステップ e で出力が表示される場合は、LAN の問題としてトラブルシューティングします。
  3. ステップ c で接続に成功した場合は、テレフォニーアプリケーションサーバーが BCOM ポートの TCP 接続は受け入れていても、BCOM がログオンを許可していないことを意味します。 この場合は、テレフォニーアプリケーションサーバーの BCOM 認証の問題として扱います。

テレフォニー制御サーバーの CSTA の問題の解決

テレフォニー制御サーバーが TCP ポート 1040 上で listen してはいるが、テレフォニーアプリケーションサーバーや CSTA ブラウザからの CSTA メッセージの一部またはすべてに応答していないと判別した場合、以下の手順に従います。

  1. CSTA ユーザー、CSTASM、TTUD の RTT トレースを開始します。
  2. CSTA ブラウザを使用して、コールシナリオを試行します。
  3. RTT トレースを停止します。
  4. チケットを介してこれらのトレースを提供します。

テレフォニーアプリケーションサーバーでモニタされる加入者の問題の解決

特定の統一番号加入者に、CSTA ブラウザでは再現できないが、テレフォニーアプリケーションサーバー Web クライアントでは再現できる問題があると判断した場合には、以下の手順に従います。

  1. テレフォニーアプリケーションサーバーとテレフォニー制御サーバーのシステム時刻が同期していることを確認します。
  2. テレフォニーアプリケーションサーバー上にログファイルのコピーの一時保管場所を作成します。 例えば、/tmp/logs ディレクトリを作成します。既にある場合は、新規ログ用にここでそれを空にします。
  3. テレフォニーアプリケーションサーバーまたはテレフォニー制御サーバーのいずれかから、この手順の開始時のタイムスタンプを取得します。
  4. csta-usercstasm フラグを使用可能にして、テレフォニー制御サーバー上で RTT トレースを開始します。
  5. テレフォニーアプリケーションサーバー Web クライアントを使用して、シナリオを再現します。
  6. テレフォニー制御サーバー上で RTT トレースを停止します。
  7. cstasmdump の出力を取得します。
  8. 上記ステップで取得したタイムスタンプ後に変更された、テレフォニーアプリケーションサーバーの /log ディレクトリにあるファイルすべてを、上のステップで作成した一時保管場所にコピーします。ls –ralt /log を使用して、最近変更されたファイルをリスト下部に表示させます。

パケットフィルタ規則の問題の解決

テレフォニー制御サーバーへの接続が、テレフォニー制御サーバーの内部ファイアウォール規則によってブロックされていると判断した場合には、以下の手順に従います。 通常、これはコマンド iptables --flush を使用してファイアウォール規則をフラッシュすることにより確認できます。 このコマンドを実行した後に問題がなくなる場合、パケットフィルタ規則を変更する必要があるかもしれません。

  1. 必要な接続のソース IP、トランスポート、宛先 IP、宛先ポートを判別します。 テレフォニー制御サーバーから netstat –eanp | grep Source IP を使用してこれを表示できる場合があります。
  2. Common Management Portal 上でテレフォニー制御サーバーアシスタントを使用して、新しい規則を追加する、または既存の規則を変更します。
  3. 変更内容が不正確であると問題が発生する可能性があるため、続行する前に新たなデータベースバックアップを取ります。
  4. iptables --flush コマンドを使用した場合は、パケットフィルタ規則を再度使用可能にする必要があります。 テレフォニー制御サーバーを状態 3 3 に下げた後、状態 4 4 に戻します。

テレフォニー制御サーバーが CSTA ポートで listen していないときの問題の解決

テスト電話と PBX 装置との間で送受信するコールをテレフォニー制御サーバーが処理できると判別した場合は、以下の手順に従います。netstat コマンドの実行後、テレフォニー制御サーバーは CSTA ポート 1040 上で listen していないので、テレフォニーアプリケーションサーバーは接続できません。

  1. テレフォニー制御サーバーから、問題の発生の数時間前からの RtpDumpLog の出力のコピーを取得します。
    1. テレフォニー制御サーバーのいずれかのノードに srx ユーザーとしてログインします。
    2. 以下のコマンドを実行します。
      RtpDumpLog –s MMDDHHMM 
  2. 両方のノードから、問題の発生から現在に至るまでの /var/log/messages/var/log/messages-* のコピーを取得します。 これらのログから、詳細な調査のため何を行うべきかに関して、手掛かりが見つかるかもしれません。 はっきりしないときには、以下のようにします。
    1. df –h コマンドを実行することにより、テレフォニー制御サーバーの両方のノードで、パーティションにディスクスペース不足がないことを確認します。
    2. ディスクスペース使用率の問題は、先に進む前に解決しておく必要があります。
  3. 両方のノード間の LAN 接続について、管理 IP (それぞれのノードから他方のノードに ping する) および CIP IP (それぞれのノードから他方のノードに ping する) の両方を検査します。 LAN 接続の問題は、先に進む前に解決しておく必要があります。 LAN 問題が見つかって修正されても、サービスが復元しない場合は、回復を行います。
  4. root として両方のノードで片側ずつ top コマンドを使用することにより、いずれのノードもスワップメモリ使用率が過度に増大していないことを確認します。 h.
  5. 以下の行を確認します。
    Swap:  4192924k total,        0k used,  4192924k free,  1212524k cached
    i.
  6. 「used」の値が「total」の値の 50% を超えていないことを確認します。 6.
  7. いずれのノードも CPU 使用率が落ちていないことを確認します。
    1. root として両方のノードで片側ずつ top コマンドを使用します。
    2. [1] キーを押します。
    3. 以下の行を確認します。
      Cpu0  :  0.3% us,  0.4% sy,  0.1% ni, 99.1% id,  0.2% wa,  0.0% hi,  0.0% si Cpu1  :  0.3% us,  0.4% sy,  0.1% ni, 99.1% id,  0.2% wa,  0.0% hi,  0.0% si Cpu2  :  0.2% us,  0.5% sy,  0.0% ni, 99.0% id,  0.2% wa,  0.0% hi,  0.0% si Cpu3  :  0.3% us,  0.5% sy,  0.0% ni, 98.2% id,  0.9% wa,  0.0% hi,  0.0% si  m.     
    4. 示された 4 つの CPU のいずれについても、「id」の値が常に 3% 未満になっていることがないことを確認します。
  8. 以下の手順に従い、回復を試みます。 以下の手順はサービスに影響を与えるので、サービス停止がもう進行していない場合は、サービス時間帯まで待ってからそれらの手順を実行してください。
    1. csta-usercstasm フラグを使用して、RTT トレースを開始します。
    2. 1 つのノードから ~srx/startup/srxctrl 3 3 を実行して、両方のノードを状態 3 に下げてみます。その後、状態 3 に達したことを各ノードから個別に確認します。
    3. 両方のノードを状態 4 に戻します。
    4. RTT トレースを停止します。

テレフォニーアプリケーションサーバーがダウンしている問題の解決

テレフォニーアプリケーションサーバーが TCP ポート 4708 と 4709 のいずれでも listen していないと判断したときは、以下の手順に従います。

  1. テレフォニーアプリケーションサーバーの /log ディレクトリから、問題の発生以降、変更のあったファイルを収集します。
  2. テレフォニーアプリケーションサーバーを再起動してみます。 問題が継続する場合は、再起動以降に変更のあった追加のログファイルを収集します。

テレフォニーアプリケーションサーバーの BCOM 認証の問題の解決

Sametime サーバーとクライアントについて、テレフォニーアプリケーションサーバーの適切なポート (4708 と 4709) を使用して通信できるのにログインできない、と判断したときは、以下の手順に従います。

  1. TAS で定義したユーザー ID、ドメイン、パスワードが一致することを確認します。
  2. TAS の /log ディレクトリから、ログイン試行の失敗以降、変更のあったログファイルを収集します。

テレフォニーアプリケーションサーバーのエラーメッセージ

このセクションでは、テレフォニーアプリケーションサーバーのエラーの名前、その説明、そのエラーを修正および解決するために必要な修正アクションをリストしています。

invalidDefaultExpiration
エラー: デフォルトの有効期限の値は 300 秒より大きくなければなりません。

ユーザーの処置

デフォルトの有効期限の値は 300 秒より大きくなければなりません。
invalidHostname
エラー: 入力したホスト名が間違っています。

ユーザーの処置

入力されたホスト名の値が、有効なホスト名ではありません。
invalidMinimumExpiration
エラー: 最小の有効期限の値は 1 秒以上でなければなりません。

ユーザーの処置

最小の有効期限の値は 1 秒以上でなければなりません。
invalidPortNumber
エラー: 入力したポート番号が間違っています。

ユーザーの処置

入力されたポート番号が、有効なポート番号ではありません。
invalidTimerRate
エラー: 削除の頻度の値は 1 秒以上でなければなりません。

ユーザーの処置

削除の頻度の値は 1 秒以上でなければなりません。
jsp.errorBox.pager.notDigits
ページ番号 {0} には数字しか含めることができません。

ユーザーの処置

入力されるページ番号には数字しか含めることができません。{0} は送信された番号です。
jsp.errorBox.pager.overPage
ページ番号 {0} は有効範囲である 1 から {1} を超えています。以下に最後のページを表示します。

ユーザーの処置

入力されたページ番号は有効範囲を超えています。結果として、使用可能な最後のページが表示されます。 {0} は入力された数字で、{1} は使用可能な合計ページ数です。
jsp.errorBox.pager.zero
ページ番号 {0} は有効範囲である 1 から {1} を超えています。以下に最初のページを表示します。

ユーザーの処置

入力されたページ番号は有効範囲を超えています。結果として、使用可能な最初のページが表示されます。 {0} は入力された数字で、{1} は使用可能な合計ページ数です。
jsp.userinfo.error.noResults.login
このログインユーザー名が割り当てられているユーザーが見つかりません。

ユーザーの処置

入力されたログインユーザー名が、有効な/登録済みユーザー名ではありません。ユーザー SIP レジストリ下の、現在の登録リストを検査してください。
jsp.userinfo.error.noResults.unifiedNumber
この番号が割り当てられているユーザーが見つかりません。

ユーザーの処置

入力された統一番号が、有効な/登録された番号ではありません。ユーザー SIP レジストリ下の、現在の登録リストを検査してください。
proxy_findMBeanConnectionError
ProxyConfigMBean に対する接続を取得できません。詳細は、エラーログを確認します。この接続の設定も確認してください。ProxyConfigMBean が稼働していない可能性があります。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。この接続の設定も確認してください。ProxyConfigMBean が稼働していない可能性があります。
proxy_getConnectionError
AdminClient に接続できません。詳細は、エラーログを確認してください。この接続の設定も確認してください。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。この接続の設定も確認してください。
proxy_readFromMBeanError
ProxyConfigMBean から SIP プロキシデータを読み取れません。詳細は、エラーログを確認します。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。
proxy_writeToMBeanError
ProxyConfigMBean に SIP プロキシデータを書き込めません。詳細は、エラーログを確認します。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。
registrar_findMBeanConnectionError
RegistrarConfigMBean に接続できません。詳細は、エラーログを確認してください。この接続の設定も確認してください。RegistrarConfigMBean が稼働していない可能性があります。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。 この接続の設定も確認してください。RegistrarConfigMBean が稼働していない可能性があります。
registrar_getConnectionError
AdminClient に接続できません。詳細は、エラーログを確認してください。この接続の設定も確認してください。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。 この接続の設定も確認してください。
registrar_readFromMBeanError
RegistrarConfigMBean から SIP レジストラデータを読み取ることができません。詳細は、エラーログを確認してください。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。
registrar_writeToMBeanError
RegistrarConfigMBean に SIP レジストラデータを書き込むことができません。詳細は、エラーログを確認してください。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。
registrarUserBean_findMBeanConnectionError
RegistrarAdminMBean に接続できません。詳細は、エラーログを確認してください。この接続の設定も確認してください。RegistrarAdminMBean が稼働していない可能性があります。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。 この接続の設定も確認してください。RegistrarAdminMBean が稼働していない可能性があります。
registrarUserBean_getConnectionError
AdminClient に接続できません。詳細は、エラーログを確認してください。この接続の設定も確認してください。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。 この接続の設定も確認してください。
registrarUserBean_readFromMBeanError
RegistrarAdminMBean から SIP レジストラデータを読み取ることができません。詳細は、エラーログを確認してください。

ユーザーの処置

詳細は、エラーログを確認します [SystemOut.log と SystemErr.log は /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/ にあります]。
reply.result.commanddefined.adminUser.notAuthorized
要求されたアクションを実行する権限がありません。

説明

ユーザーが実行する権限のないアクションを実行しようとした場合、常に発生します。

ユーザーの処置

現在の許可が、要求されたアクションと互換性があるかどうかを検査してください。 許可を設定するには、ユーザーに割り当てられたユーザープロファイルに変更を加えるか ([ユーザーとリソース (Users & Resources)] > [ユーザー] > [プロファイル管理 (Profile Administration)] > [ユーザープロファイル (User Profiles)])、またはユーザーにさらにプロファイルを割り当てます ([ユーザーとリソース (Users & Resources)] > [ユーザー] > [ユーザー管理 (User Administration)] > [ユーザー] > [ユーザーの編集 (Edit User)] > [プロファイル] タブ)。
reply.result.commanddefined.alarmaction.alarmNotFound
アラームが見つかりません: {0}

ユーザーの処置

アラームが見つかりません。
reply.result.commanddefined.alarmaction.illegalAlarmId
正しくないアラーム ID: {0}。

説明

[操作およびメンテナンス (Operation & Maintenance)] > [診断 (Diagnostics)] > [アラームおよび障害 (Alarms and Faults)] > [アラームのアクティブ化 (Active Alarms)] > [アラームをマスクする (Mask an Alarm)] でメッセージが表示されます。

ユーザーの処置

アラームをマスクする際に、アラーム ID または管理対象リソースが欠落しています。
reply.result.commanddefined.alarmdestination.ping.failed
Ping!... ホストが見つかりませんでした。

ユーザーの処置

宛先ホストが到達可能かどうかを検査してください。
reply.result.commanddefined.alarmdestination.ping.invalid
Ping!... ホストが無効です。

ユーザーの処置

宛先ホスト名が正しいかどうかを検査してください。
reply.result.commanddefined.alarmdestination.ping.success
Ping!... ホストが見つかりました。

ユーザーの処置

提供すべき解決策はありません。宛先ホストが見つかりました。
reply.result.commanddefined.alarmdestination.wrongip
入力された IP は、アラーム宛先として受け入れられませんでした。

説明

[操作およびメンテナンス (Operation & Maintenance)] > [診断 (Diagnostics)] > [アラームおよび障害 (Alarms and Faults)] > [アラーム宛先 (Alarm Destination)] でメッセージが表示されます。

ユーザーの処置

対応するフィールドに、有効な IP アドレスを指定してください (X.X.X.X、X は 0...255)。
reply.result.commanddefined.centerBG.noBg
使用可能なビジネスグループがありません。まず、ビジネスグループを構成してください。

説明

このメッセージは、[テレフォニー制御サーバー] > [ビジネスグループ (Business Group)] において、[ビジネスグループのリスト (List Business Groups)] 画面と [クイック追加 (Quick Adds)] からのナビゲーション例外のもとで常に表示されます。

ユーザーの処置

テレフォニー制御サーバーの管理者は、サポートする会社ごとに、1 つのビジネスグループを作成する必要があります。
reply.result.commanddefined.centerBG.noBgAssigned
ビジネスグループがユーザーに割り当てられていません。

説明

[テレフォニー制御サーバー] > [ビジネスグループ (Business Group)] メニューで、メッセージが表示されます。

ユーザーの処置

ユーザー (管理者は)、少なくとも 1 つのビジネスグループを管理する権限を持っている必要があります。 ビジネスグループへのユーザーのアクセス権限は、[テレフォニー制御サーバー] > [ビジネスグループ (Business Group)] > [ビジネスグループリスト (Business Group List)] > [ビジネスグループ (Business Groups)] > [ビジネスグループの編集 (Edit Business Group)] > [ユーザーアクセス (User Access)] によって設定できます。
reply.result.commanddefined.configurationFiles.actionOk
構成ファイルに実行されたアクションは、正常に終了しました。

ユーザーの処置

アクションが正常に実行されました。

テレフォニー制御サーバーのアラームのリスト

このセクションでは、テレフォニー制御サーバーのアラームの名前、その説明、アラームを修正および解決するために必要な修正アクションをリストしています。

SIPCounterAboveHighThldTrap
カウンタ値が定義済みのしきい値制限を超えたことを示しています。

ユーザーの処置

このアラームは、SIPCounterBelowThld によってクリアされます。
SIPCounterAboveLowThldTrap
カウンタ値が定義済みのしきい値制限を超えたことを示しています。

ユーザーの処置

このアラームは、SIPCounterBelowThld によってクリアされます。
SIPCounterBelowThldTrap
カウンタ値が定義済みのしきい値制限内であることを示しています。

ユーザーの処置

これは消去アラームです。
hiqAccountDeletedTrap
指定されたアカウントが非アクティブになっており、それ以降使用不可になっていたことを示すアラームが以前に報告されました。アカウントはそのまま使用されなかったため、削除されました。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQAccountDisabledTrap
指定されたログインアカウントは、最近使用されておらず、将来削除される可能性があります。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQAccountInactiveTrap
指定されたログインアカウントは、最近使用されておらず、将来使用不可になる可能性があります。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQAucUscFileSeqNumberErrorTrap
CDR ファイルシーケンス番号が正しくない可能性があります。これは、データベースの読み取りまたは書き込みエラーが原因で発生します。

ユーザーの処置

課金ファイルのシーケンス番号、特にアラームが発生した直後に生成されたファイルのシーケンス番号が正しいかどうか確認してください。 データベースの状況を確認してください。 シーケンス番号エラーが発生するのは多くの場合、フェイルオーバーがデータベースの読み取り/書き込みエラーの後に発生した場合です。あるいは、一時的なデータベースエラーが原因でアラームが発生する場合があります。
hiQAucUscLocalSecStorageOkTrap
このノードでは、CDR 課金データの 2 次ストレージを使用できます。

ユーザーの処置

これは消去アラームです。
hiQAucUscPriStorNotPossibleTrap
このノードでは、CDR 課金データの 1 次ストレージを使用できません。

ユーザーの処置

CDR ディスクパーティション (/cdr) が srx ユーザーによって書き込み可能かどうか確認してください。 データに使用できる十分なスペースがパーティション上にありますか?
hiQAucUscPriStorOkTrap
このノードでは、CDR 課金データの 1 次ストレージを使用できます。

ユーザーの処置

これは消去アラームです。
hiQAucUscSecStorNotPossibleTrap
このノードでは、CDR 課金データの 2 次ストレージを使用できません。これは、ディスクスペースが不足しているか、あるいは CDR ディスクパーティションが書き込みできない場合に発生する可能性があります。

ユーザーの処置

CDR ディスクパーティション (/cdr) が srx ユーザーによって書き込み可能かどうか確認してください。 データに使用できる十分なスペースがパーティション上にありますか?
hiQAucUscServerBackupDownTrap
使用量収集サーバーからバックアップ FTP サイトへのリンクがダウンしています。

ユーザーの処置

以下を調べて問題を訂正してください。指定されたネットワークエレメントはオンライン状態か、あるいはオフライン状態か。ネットワーク問題あるいは間違った構成 (例、IPSec) が原因で Sametime Unified Telephony との通信ができないのではないか。潜在的に障害のあるエレメントまたは構成が間違っているエレメントには、LAN スイッチ、ルーター、ファイアウォール、DNS が含まれる場合があります。 アクティブな CDR ハンドラノードと課金サーバーとの間の FTP 構成を調べます。障害は、一過性の条件によって引き起こされた可能性があります。 システムを妥当な期間モニタして、アラームが再発するかどうかを調べます。 再発する場合、このアラームは、支援を求めて次に高位の障害クリア権限に連絡を取らない限り、解決されません。
hiQAucUscServerBackupUpTrap
使用量収集サーバーからバックアップ FTP サイトへのリンクは稼働しています。

ユーザーの処置

これは消去アラームです。
hiQAucUscServerFtpDownTrap
使用量収集サーバーから 1 次 FTP サイトへのリンクがダウンしています。

ユーザーの処置

このアラームは、hiQAucUscServerFtpUpTrap によってクリアされます。以下に関する問題を調べて訂正してください。指定されたネットワークエレメントがオンライン状態か、あるいはオフライン状態か Sametime Unified Telephony と通信できない原因は、ネットワーク問題あるいは間違った構成 (例、IPSec) か。潜在的に障害のあるエレメントまたは構成が間違っているエレメントには、LAN スイッチ、ルーター、ファイアウォール、DNS が含まれる場合があります。 アクティブな CDR ハンドラノードと課金サーバーとの間の FTP 構成を調べます。外部サーバーが正常に作動しており、通信リンクがアクティブでトラフィックを伝送している場合、問題は Sametime Unified Telephony アプリケーション内に存在する可能性があります。
hiQAucUscServerFtpUpTrap
使用量収集サーバーから 1 次 FTP サイトへのリンクは稼働しています。

ユーザーの処置

このアラームにより、FTP サイト用のリンクダウントラップがクリアされます。
hiQAucUscServerTxCdrTrap
使用量収集サーバーは CDR ファイルを FTP サイトに送信できませんでした。

ユーザーの処置

--
hiQAucUscStbBackupFTPLinkDownTrap
使用量収集サーバーからバックアップ FTP サイトへのリンクがダウンしています。

ユーザーの処置

Sametime Unified Telephony が通信を失った、障害のあるネットワークエレメントまたはアプリケーションは、Alarm Details Dialog Box Description フィールドを調べて判別できます。ネットワーク問題あるいは間違った構成 (例、IPSec) によって Sametime Unified Telephony と通信できなくなっていないかどうか確認してください。潜在的に障害のあるエレメントまたは構成が間違っているエレメントには、LAN スイッチ、ルーター、ファイアウォール、DNS が含まれる場合があります。該当する修正アクションを取ってください。 スタンバイ CDR ハンドラノードと課金サーバーとの間の FTP 構成は正しいですか? 正しい場合、このアラームは、支援を求めて次に高位の障害クリア権限に連絡を取らない限り、解決されません。
hiQAucUscStbBackupFTPLinkUpTrap
使用量収集サーバーからバックアップ FTP サイトへのリンクは稼働しています。

ユーザーの処置

これは消去アラームです。
hiQAucUscStbPriFTPLinkDownTrap
使用量収集サーバーから 1 次 FTP サイトへのリンクがダウンしています。

ユーザーの処置

Sametime Unified Telephony が通信を失った、障害のあるネットワークエレメントまたはアプリケーションは、Alarm Details Dialog Box Description フィールドを調べて判別できます。ネットワーク問題あるいは間違った構成 (例、IPSec) によって Sametime Unified Telephony と通信できなくなっていないかどうか確認してください。潜在的に障害のあるエレメントまたは構成が間違っているエレメントには、LAN スイッチ、ルーター、ファイアウォール、DNS が含まれる場合があります。 該当する修正アクションを取ってください。スタンバイ CDR ハンドラノードと課金サーバーとの間の FTP 構成は正しいですか? 正しい場合、このアラームは、支援を求めて次に高位の障害クリア権限に連絡を取らない限り、解決されません。
hiQAucUscStbPriFTPLinkUpTrap
使用量収集サーバーから 1 次 FTP サイトへのリンクは稼働しています。

ユーザーの処置

これは消去アラームです。
hiQAudAvailDiskSpBelowCritThldTrap
ファイルシステムで使用可能なスペースは、スーパーユーザー以外のユーザーが使用できるスペースです。残りのスペースは、スーパーユーザーによって使用または予約されています。マニュアルページ df(1) を参照してください。データベースで使用可能なスペースは、データベースのタイプによって異なります。

ユーザーの処置

ファイルシステム内の不要なファイルまたはデータベース内の不要なテーブルを削除することによって、より多くのスペースを取得することが可能かどうかを調べてください。一部のデータベースでは、実行時およびテーブルの再分配時にサイズを増やすことができる場合があります。
hiQAudAvailDiskSpBelowMajorThldTrap
ファイルシステムで使用可能なスペースは、スーパーユーザー以外のユーザーが使用できるスペースです。残りのスペースは、スーパーユーザーによって使用または予約されています。マニュアルページ df(1) を参照してください。データベースで使用可能なスペースは、データベースのタイプによって異なります。

ユーザーの処置

ファイルシステム内の不要なファイルまたはデータベース内の不要なテーブルを削除することによって、より多くのスペースを取得することが可能かどうかを調べてください。一部のデータベースでは、実行時およびテーブルの再分配時にサイズを増やすことができる場合があります。
hiQAudAvailDiskSpBelowMinorThldTrap
ファイルシステムで使用可能なスペースは、スーパーユーザー以外のユーザーが使用できるスペースです。残りのスペースは、スーパーユーザーによって使用または予約されています。マニュアルページ df(1) を参照してください。データベースで使用可能なスペースは、データベースのタイプによって異なります。

ユーザーの処置

ファイルシステム内の不要なファイルまたはデータベース内の不要なテーブルを削除することによって、より多くのスペースを取得することが可能かどうかを調べてください。一部のデータベースでは、実行時およびテーブルの再分配時にサイズを増やすことができる場合があります。
hiQAudCpuUtilAboveCritThldTrap
現在の CPU 使用量が非常に高くなっています。CPU 使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。sar コマンドを使用して、次の監査チェックまでの CPU 使用量を調べることができます (例、"sar -u 10 15")。この状態が長引く場合、システムに備わっている CPU がユーザーの目的を達成するには少なすぎる、ユーザーの必要に比べて構成されている監査しきい値が低くすぎる、ループプロセスなど非常に多くの CPU 時間を消費するプロセスが存在している、などの原因が考えられます。ps コマンドを繰り返し使用することによって、これらのプロセスを識別します。例えば、ps -e -o "pid=" -o "time=" -o "comm" " sort -t" " -k1 を使用して、結果を比較します。"time" 値が変更されたプロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、処理が継続的にループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。プロセスをさらに分析する場合、コマンドトレースが役立つことがあります。プロセスがループしている場合には、再起動が役立つことがあります。多くの CPU 時間が消費されていても、ループが発生しておらず、プロセスが正常に作動しているように見える場合は、通常の動作である可能性が高いといえます。
hiQAudCpuUtilAboveMajorThldTrap
現在の CPU 使用量が非常に高くなっています。CPU 使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。sar コマンドを使用して、次の監査チェックまでの CPU 使用量を調べることができます (例、"sar -u 10 15")。この状態が長引く場合、システムに備わっている CPU がユーザーの目的を達成するには少なすぎる、ユーザーの必要に比べて構成されている監査しきい値が低くすぎる、ループプロセスなど非常に多くの CPU 時間を消費するプロセスが存在している、などの原因が考えられます。ps コマンドを繰り返し使用することによって、これらのプロセスを識別します。例えば、ps -e -o "pid=" -o "time=" -o "comm" " sort -t" " -k1 を使用して、結果を比較します。"time" 値が変更されたプロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、処理が継続的にループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。プロセスをさらに分析する場合、コマンドトレースが役立つことがあります。プロセスがループしている場合には、再起動が役立つことがあります。多くの CPU 時間が消費されていても、ループが発生しておらず、プロセスが正常に作動しているように見える場合は、通常の動作である可能性が高いといえます。
hiQAudCpuUtilAboveMinorThldTrap
現在の CPU 使用量が非常に高くなっています。CPU 使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。sar コマンドを使用して、次の監査チェックまでの CPU 使用量を調べることができます (例、"sar -u 10 15")。この状態が長引く場合、システムに備わっている CPU がユーザーの目的を達成するには少なすぎる、ユーザーの必要に比べて構成されている監査しきい値が低くすぎる、ループプロセスなど非常に多くの CPU 時間を消費するプロセスが存在している、などの原因が考えられます。ps コマンドを繰り返し使用することによって、これらのプロセスを識別します。例えば、ps -e -o "pid=" -o "time=" -o "comm" " sort -t" " -k1 を使用して、結果を比較します。"time" 値が変更されたプロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、処理が継続的にループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。プロセスをさらに分析する場合、コマンドトレースが役立つことがあります。プロセスがループしている場合には、再起動が役立つことがあります。多くの CPU 時間が消費されていても、ループが発生しておらず、プロセスが正常に作動しているように見える場合は、通常の動作である可能性が高いといえます。
hiQAudCpuUtilBelowThreshTrap
現在の CPU 使用量は、すべての構成済みしきい値よりも低くなっています。

ユーザーの処置

これは消去アラームです。
hiQAudCpuUtilChangedTrap
現在の CPU 使用量が変更されましたが、依然として構成済みしきい値の 1 つより上にあります。

ユーザーの処置

これは消去アラームです。
hiQAudCpuUtilTrap
現在の CPU 使用量に関する情報を取得できます。

ユーザーの処置

これは消去アラームです。
hiQAudDetectorWithinLimitTrap
以前に、指定された検出機能は構成済みの最大実行間隔よりも長い時間がかかっていました。現在は、再びこの制限内で稼働しています。

ユーザーの処置

これは消去アラームです。
hiQAudFileGroupSizeChanged1Trap
このアラームは、指定されたファイルグループのサイズが変更されたものの、まだ大きすぎることを示しています。

ユーザーの処置

これらは消去アラームです。
hiQAudFileGroupSizeChanged2Trap
指定されたファイルグループのサイズを監査プロセスがモニタしましたが、構成されたサイズ制限を超えています。

ユーザーの処置

そのグループからファイルを削除するようにしてください。このファイルグループにリカバリアクションが構成されている場合、この処置が既に試みられている可能性があります。
hiQAudFileGroupSizeChanged3Trap
このアラームは、指定されたファイルグループのサイズが変更されたものの、まだ大きすぎることを示しています。

ユーザーの処置

これらは消去アラームです。
hiQAudFileGroupSizeChanged4Trap
このアラームは、指定されたファイルグループのサイズが変更されたものの、まだ大きすぎることを示しています。

ユーザーの処置

これらは消去アラームです。
hiQAudFileGrpAboveCritThldTrap
指定されたファイルグループのサイズを監査プロセスがモニタしましたが、構成されたサイズ制限を超えています。

ユーザーの処置

そのグループからファイルを削除するようにしてください。このファイルグループにリカバリアクションが構成されている場合、この処置が既に試みられている可能性があります。
hiQAudFileGrpAboveMajorThldTrap
指定されたファイルグループのサイズを監査プロセスがモニタしましたが、構成されたサイズ制限を超えています。

ユーザーの処置

そのグループからファイルを削除するようにしてください。このファイルグループにリカバリアクションが構成されている場合、この処置が既に試みられている可能性があります。
hiQAudFileGrpBelowThreshTrap
指定されたファイルグループのサイズが大きすぎるという報告が以前に行われました。ただし、現在ではすべての構成済みしきい値よりも小さくされています。

ユーザーの処置

これは消去アラームです。
hiQAudFileSystemAboveMinTrap
このアラームは、使用可能なファイルシステムまたはデータベーススペースが、構成済み最小しきい値レベルより大きくなったことを示します。

ユーザーの処置

これは消去アラームです
hiQAudFileSystemBelowMin1Trap
このアラームは、使用可能なファイルシステムまたはデータベーススペースが変更されたものの、依然として構成済み最小しきい値レベルより小さいことを示します。この削減操作によって、指定されたデータスペースに関するファイルシステムまたはデータベーススペースの、重大度レベルが「重大」よりも低いエラーメッセージが自動的に消去されるため、新規の重大アラームのみがオープンのままとなります。

ユーザーの処置

これは消去アラームです。
hiQAudFileSystemBelowMin2Trap
このアラームは、使用可能なファイルシステムまたはデータベーススペースが変更されたものの、依然として構成済み最小しきい値レベルより小さいことを示します。この削減操作によって、指定されたデータスペースに関するファイルシステムまたはデータベーススペースの、重大度レベルが「重大」よりも低いエラーメッセージが自動的に消去されるため、新規の重大アラームのみがオープンのままとなります。

ユーザーの処置

これは消去アラームです。
hiQAudFileSystemBelowMin3Trap
このアラームは、使用可能なファイルシステムまたはデータベーススペースが変更されたものの、依然として構成済み最小しきい値レベルより小さいことを示します。この削減操作によって、指定されたデータスペースに関するファイルシステムまたはデータベーススペースの、重大度レベルが「重大」よりも低いエラーメッセージが自動的に消去されるため、新規の重大アラームのみがオープンのままとなります。

ユーザーの処置

これは消去アラームです。
hiQAudFileSystemBelowMin4Trap
このアラームは、使用可能なファイルシステムまたはデータベーススペースが変更されたものの、依然として構成済み最小しきい値レベルより小さいことを示します。この削減操作によって、指定されたデータスペースに関するファイルシステムまたはデータベーススペースの、重大度レベルが「重大」よりも低いエラーメッセージが自動的に消去されるため、新規の重大アラームのみがオープンのままとなります。

ユーザーの処置

これは消去アラームです。
hiQAudFreeSpaceOKTrap
指定されたファイルシステム上の空き領域を判別中に問題が発生しました。その問題は、もはや存在していません。

ユーザーの処置

これは消去アラームです。
hiQAuditStartingTrap
Audit Manager プロセスが開始中です。

ユーザーの処置

これは消去アラームです。
hiQAudMemUtilAboveCriticalThldTrap
現在のメモリ使用量が高くなっています。メモリ使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。その状態が継続する場合、システムのメインメモリがユーザーの目的を達成するほど十分にない、監査しきい値を低く構成し過ぎた、メモリリークのあるプロセスなど不必要にメモリを消費するプロセスが存在している、などの原因が考えられます。通常操作の際のプロセスサイズに関する情報が役立ちます。大量のメモリを使用するプロセスを、ps コマンドで識別します。例えば、ps -e -o "pid="-o "vsz=" -o "comm" " sort -t" " - k2 -n などとします。"vsz" 値が大きいかまたは変更された (またはその両方) プロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、プロセスがループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。これらのプロセスのスタックまたはブレークサイズに関して、監査プロセスからイベントを検索してください。分析を進める場合はトレースを使用します。プロセスにメモリリークがある場合、再起動が役立つ場合があります。明らかなループが見られず、プロセスが正常に作動しているように見えるのに、メモリが足りなくなる場合は、通常の動作である可能性が高いといえます。
hiQAudMemUtilAboveMajorThldTrap
現在のメモリ使用量が高くなっています。メモリ使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。その状態が継続する場合、システムのメインメモリがユーザーの目的を達成するほど十分にない、監査しきい値を低く構成し過ぎた、メモリリークのあるプロセスなど不必要にメモリを消費するプロセスが存在している、などの原因が考えられます。通常操作の際のプロセスサイズに関する情報が役立ちます。大量のメモリを使用するプロセスを、ps コマンドで識別します。例えば、ps -e -o "pid="-o "vsz=" -o "comm" " sort -t" " - k2 -n などとします。"vsz" 値が大きいかまたは変更された (またはその両方) プロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、プロセスがループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。これらのプロセスのスタックまたはブレークサイズに関して、監査プロセスからイベントを検索してください。分析を進める場合はトレースを使用します。プロセスにメモリリークがある場合、再起動が役立つ場合があります。明らかなループが見られず、プロセスが正常に作動しているように見えるのに、メモリが足りなくなる場合は、通常の動作である可能性が高いといえます。
hiQAudMemUtilAboveThldTrap
現在のメモリ使用量が高くなっています。メモリ使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。その状態が継続する場合、システムのメインメモリがユーザーの目的を達成するほど十分にない、監査しきい値を低く構成し過ぎた、メモリリークのあるプロセスなど不必要にメモリを消費するプロセスが存在している、などの原因が考えられます。通常操作の際のプロセスサイズに関する情報が役立ちます。大量のメモリを使用するプロセスを、ps コマンドで識別します。例えば、ps -e -o "pid="-o "vsz=" -o "comm" " sort -t" " - k2 -n などとします。"vsz" 値が大きいかまたは変更された (またはその両方) プロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、プロセスがループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。これらのプロセスのスタックまたはブレークサイズに関して、監査プロセスからイベントを検索してください。分析を進める場合はトレースを使用します。プロセスにメモリリークがある場合、再起動が役立つ場合があります。明らかなループが見られず、プロセスが正常に作動しているように見えるのに、メモリが足りなくなる場合は、通常の動作である可能性が高いといえます。
hiQAudMemUtilBelowThreshTrap
現在のメモリ使用量が、すべての構成済みしきい値よりも低くなっています。

ユーザーの処置

これは消去アラームです。
hiQAudMemUtilChangedTrap
現在のメモリ使用量が変更されましたが、依然として構成済みしきい値の 1 つより高い状態です。

ユーザーの処置

これは消去アラームです。
hiQAudMemUtilTrap
現在のメモリ使用量に関する情報を取得できます。

ユーザーの処置

これは消去アラームです。
hiQAudNamedDetectorStartingTrap
指定された検出機能は、開始中または再起動中です。

ユーザーの処置

これは消去アラームです。
hiQAudOSProcInstanceNotRunningTrap
指定されたプロセス (または指定されたプロセスのインスタンス) は、現在は実行されていません。

ユーザーの処置

--
HiQAudOSProcNotRunningTrap
指定されたプロセス (または指定されたプロセスのインスタンス) は、現在は実行されていません。

ユーザーの処置

--
hiQAudProcessInfoAvailTrap
指定されたプロセスのプロセス情報を、再び取得できるようになりました。

ユーザーの処置

これは消去アラームです。
hiQAudProcessNotRunningMajorTrap
指定されたプロセスは、現在は実行されていません。

ユーザーの処置

サブシステムによって、プロセスは自動的に再実行されるか、手動、またはリカバリアクションを介して開始する必要があります。
hiQAudProcessNotRunningMinorTrap
指定されたプロセスは、現在は実行されていません。

ユーザーの処置

サブシステムによって、プロセスは自動的に再実行されるか、手動、またはリカバリアクションを介して開始する必要があります。
hiQAudProcessRunningTrap
指定されたプロセスは、現在実行中です。

ユーザーの処置

これは消去アラームです。
hiQAudProcHeapAboveCritThldTrap
指定されたプロセスのプログラム中断セグメント (静的データ) が高くなっています。つまり、プログラムは動的に多くのメモリを割り振っていますが、その一部分しか解放しないか、まったく解放しません。 これは、プログラムエラー (メモリリーク)、プロセス外部からの大量の入力データ、指定されたプロセスの中断サイズ制限を監査構成で低く設定しすぎた結果の構成エラーによって引き起こされる場合があります。

ユーザーの処置

メインメモリ不足を避けてプログラムを再初期設定するために、プロセスを停止して再実行することが必要になる場合があります。この操作を、RTP リカバリマネージャのリカバリアクションとして構成することができます。この問題が頻繁に起きる場合、指定されたプロセスと対応するイベントのトレースを行ってください。
hiQAudProcHeapAboveMajorThldTrap
指定されたプロセスのプログラム中断セグメント (静的データ) が高くなっています。つまり、プログラムは動的に多くのメモリを割り振っていますが、その一部分しか解放しないか、まったく解放しません。 これは、プログラムエラー (メモリリーク)、プロセス外部からの大量の入力データ、指定されたプロセスの中断サイズ制限を監査構成で低く設定しすぎた結果の構成エラーによって引き起こされる場合があります。

ユーザーの処置

メインメモリ不足を避けてプログラムを再初期設定するために、プロセスを停止して再実行することが必要になる場合があります。この操作を、RTP リカバリマネージャのリカバリアクションとして構成することができます。この問題が頻繁に起きる場合、指定されたプロセスと対応するイベントのトレースを行ってください。
hiQAudProcHeapAboveMinorThldTrap
指定されたプロセスのプログラム中断セグメント (静的データ) が高くなっています。つまり、プログラムは動的に多くのメモリを割り振っていますが、その一部分しか解放しないか、まったく解放しません。 これは、プログラムエラー (メモリリーク)、プロセス外部からの大量の入力データ、指定されたプロセスの中断サイズ制限を監査構成で低く設定しすぎた結果の構成エラーによって引き起こされる場合があります。

ユーザーの処置

メインメモリ不足を避けてプログラムを再初期設定するために、プロセスを停止して再実行することが必要になる場合があります。この操作を、RTP リカバリマネージャのリカバリアクションとして構成することができます。この問題が頻繁に起きる場合、指定されたプロセスと対応するイベントのトレースを行ってください。
hiQAudProcHeapSizeChanged1Trap
指定されたプロセスのヒープサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcHeapSizeChanged2Trap
指定されたプロセスのヒープサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcHeapSizeChanged3Trap
指定されたプロセスのヒープサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcHeapSizeChanged4Trap
指定されたプロセスのヒープサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcHeapSizeOkTrap
プロセスのヒープサイズが、すべての構成済みしきい値より低くなりました。

ユーザーの処置

これは消去アラームです。
hiQAudProcNotRunningCriticalTrap
指定されたプロセスは、現在は実行されていません。

ユーザーの処置

サブシステムによって、プロセスは自動的に再実行されるか、手動、またはリカバリアクションを介して開始する必要があります。
hiQAudProcStackAboveCritThldTrap
指定されたプロセスのプログラムスタックサイズが、構成済みしきい値より高くなっています。これは、再帰関数呼び出し内のプログラムエラー、再帰的に定義された入力データ、指定されたプロセスのスタックサイズ制限を監査構成で低く設定し過ぎた構成エラーによって引き起こされる場合があります。

ユーザーの処置

メインメモリ不足を避けてプログラムを再初期設定するために、プロセスを停止して再実行することが必要になる場合があります。この操作を、RTP リカバリマネージャのリカバリアクションとして構成することができます。この問題が頻繁に起きる場合、指定されたプロセスと対応するイベントのトレースを行ってください。
HiQAudProcStackAboveMajorThldTrap
指定されたプロセスのプログラムスタックサイズが、構成済みしきい値より高くなっています。これは、再帰関数呼び出し内のプログラムエラー、再帰的に定義された入力データ、指定されたプロセスのスタックサイズ制限を監査構成で低く設定し過ぎた構成エラーによって引き起こされる場合があります。

ユーザーの処置

メインメモリ不足を避けてプログラムを再初期設定するために、プロセスを停止して再実行することが必要になる場合があります。この操作を、RTP リカバリマネージャのリカバリアクションとして構成することができます。この問題が頻繁に起きる場合、指定されたプロセスと対応するイベントのトレースを行ってください。
HiQAudProcStackAboveMinorThldTrap
指定されたプロセスのプログラムスタックサイズが、構成済みしきい値より高くなっています。これは、再帰関数呼び出し内のプログラムエラー、再帰的に定義された入力データ、指定されたプロセスのスタックサイズ制限を監査構成で低く設定し過ぎた構成エラーによって引き起こされる場合があります。

ユーザーの処置

メインメモリ不足を避けてプログラムを再初期設定するために、プロセスを停止して再実行することが必要になる場合があります。この操作を、RTP リカバリマネージャのリカバリアクションとして構成することができます。この問題が頻繁に起きる場合、指定されたプロセスと対応するイベントのトレースを行ってください。
hiQAudProcStackSizeChanged1Trap
指定されたプロセスのスタックサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcStackSizeChanged2Trap
指定されたプロセスのスタックサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcStackSizeChanged3Trap
指定されたプロセスのスタックサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcStackSizeChanged4Trap
指定されたプロセスのスタックサイズが変更されましたが、依然として構成済みしきい値の 1 つより高いままです。

ユーザーの処置

これは消去アラームです。
hiQAudProcStackSizeOkTrap
プロセスのスタックサイズが、すべての構成済みしきい値より低くなりました。

ユーザーの処置

これは消去アラームです。
hiQAudSemUtilAboveCritThldTrap
現在使用されているセマフォの数が相対的に高くなっています。セマフォ使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。次の周期的なチェックを待つか、ipcs コマンドを使用して 2 つの監査チェック間の一定の期間にわたってセマフォ使用量をチェックできます。例えば、"root" ユーザーとして "ipcs -s" を呼び出すと、どのユーザー (ipcs 出力のフィールド所有者) がいくつの (nsems フィールド) セマフォを作成したかに関する情報が得られます。その状態が継続する場合、ユーザーの目的を達成するだけの必要な数のセマフォがシステムに構成されていない、監査しきい値が低く構成されすぎていてシステム統合担当者がユーザーのシステムの特別な必要に適合させる必要がある、不必要にセマフォを使用するプロセスが存在している、などの原因が考えられます。セマフォを不必要に使用するプロセスを識別するのは簡単な作業ではなく、プロセスに関する特別な知識を必要とします。比較するために、通常操作時のセマフォ使用量に関する情報があれば、役立ちます。各コンポーネントのリソース使用量については、「RTP Installation and Configuration Guide」を参照してください。
hiQAudSemUtilAboveMajorThldTrap
現在使用されているセマフォの数が相対的に高くなっています。セマフォ使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。次の周期的なチェックを待つか、ipcs コマンドを使用して 2 つの監査チェック間の一定の期間にわたってセマフォ使用量をチェックできます。例えば、"root" ユーザーとして "ipcs -s" を呼び出すと、どのユーザー (ipcs 出力のフィールド所有者) がいくつの (nsems フィールド) セマフォを作成したかに関する情報が得られます。その状態が継続する場合、ユーザーの目的を達成するだけの必要な数のセマフォがシステムに構成されていない、監査しきい値が低く構成されすぎていてシステム統合担当者がユーザーのシステムの特別な必要に適合させる必要がある、不必要にセマフォを使用するプロセスが存在している、などの原因が考えられます。セマフォを不必要に使用するプロセスを識別するのは簡単な作業ではなく、プロセスに関する特別な知識を必要とします。比較するために、通常操作時のセマフォ使用量に関する情報があれば、役立ちます。各コンポーネントのリソース使用量については、「RTP Installation and Configuration Guide」を参照してください。
hiQAudSemUtilAboveMinorThldTrap
現在使用されているセマフォの数が相対的に高くなっています。セマフォ使用量のチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。次の周期的なチェックを待つか、ipcs コマンドを使用して 2 つの監査チェック間の一定の期間にわたってセマフォ使用量をチェックできます。例えば、"root" ユーザーとして "ipcs -s" を呼び出すと、どのユーザー (ipcs 出力のフィールド所有者) がいくつの (nsems フィールド) セマフォを作成したかに関する情報が得られます。その状態が継続する場合、ユーザーの目的を達成するだけの必要な数のセマフォがシステムに構成されていない、監査しきい値が低く構成されすぎていてシステム統合担当者がユーザーのシステムの特別な必要に適合させる必要がある、不必要にセマフォを使用するプロセスが存在している、などの原因が考えられます。セマフォを不必要に使用するプロセスを識別するのは簡単な作業ではなく、プロセスに関する特別な知識を必要とします。比較するために、通常操作時のセマフォ使用量に関する情報があれば、役立ちます。各コンポーネントのリソース使用量については、「RTP Installation and Configuration Guide」を参照してください。
hiQAudSemUtilBelowThreshTrap
現在のメモリ使用量が、すべての構成済みしきい値よりも低くなっています。

ユーザーの処置

これは消去アラームです。
hiQAudSemUtilChangedTrap
現在のメモリ使用量が変更されましたが、依然として構成済みしきい値の 1 つより高い状態です。

ユーザーの処置

これは消去アラームです。
hiQAudSemUtilTrap
現在のメモリ使用量に関する情報を取得できます。

ユーザーの処置

これは消去アラームです。
hiQAudShMemUtilBelowThreshTrap
現在使用されている共有メモリ ID の数が、すべての構成済みしきい値よりも低くなっています。

ユーザーの処置

これは消去アラームです。
hiQAudShMemUtilChangedTrap
現在使用されている共有メモリ ID の数が変更されましたが、依然として構成済みしきい値の 1 つより高い状態です。

ユーザーの処置

これは消去アラームです。
hiQAudShMemUtilTooAboveCritThldTrap
現在使用されている共有メモリセグメントの数が相対的に高くなっています。共有メモリセグメントのチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。ipcs コマンドを使用してください。例えば "root" ユーザーとして "ipcs -mp" を使うと、どの共有メモリセグメントをどのプロセスが作成し (cpid フィールド)、使用しているかに関する情報が得られます。その状態が継続する場合、ユーザーの目的を達成するのに必要な数のセグメントがシステムに構成されていない、監査しきい値を低く構成し過ぎた、共有メモリセグメントを不必要に使用するプロセスが存在している、などの原因が考えられます。通常操作時のプロセス固有の共有メモリセグメント使用量に関する情報が役立ちます。上記のコマンドを使用して、多数のセグメントを作成するプロセスを識別します。セグメントの総数と、同一プロセスによって作成されたセグメントの数 (cpid) を比較します。それを「通常の」値と比べてください。これらのプロセスが正常に作動しているか確認します。RTP ノードマネージャが制御しているプロセスの場合、プロセスが継続的にループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。分析を進める場合はトレースを使用します。ループしているプロセスを再実行することが役立つ場合もあります。
hiQAudShMemUtilTooAboveMajorThldTrap
現在使用されている共有メモリセグメントの数が相対的に高くなっています。共有メモリセグメントのチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。ipcs コマンドを使用してください。例えば "root" ユーザーとして "ipcs -mp" を使うと、どの共有メモリセグメントをどのプロセスが作成し (cpid フィールド)、使用しているかに関する情報が得られます。その状態が継続する場合、ユーザーの目的を達成するのに必要な数のセグメントがシステムに構成されていない、監査しきい値を低く構成し過ぎた、共有メモリセグメントを不必要に使用するプロセスが存在している、などの原因が考えられます。通常操作時のプロセス固有の共有メモリセグメント使用量に関する情報が役立ちます。上記のコマンドを使用して、多数のセグメントを作成するプロセスを識別します。セグメントの総数と、同一プロセスによって作成されたセグメントの数 (cpid) を比較します。それを「通常の」値と比べてください。これらのプロセスが正常に作動しているか確認します。RTP ノードマネージャが制御しているプロセスの場合、プロセスが継続的にループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。分析を進める場合はトレースを使用します。ループしているプロセスを再実行することが役立つ場合もあります。
hiQAudShMemUtilTooAboveMinorThldTrap
現在使用されている共有メモリセグメントの数が相対的に高くなっています。共有メモリセグメントのチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。ipcs コマンドを使用してください。例えば "root" ユーザーとして "ipcs -mp" を使うと、どの共有メモリセグメントをどのプロセスが作成し (cpid フィールド)、使用しているかに関する情報が得られます。その状態が継続する場合、ユーザーの目的を達成するのに必要な数のセグメントがシステムに構成されていない、監査しきい値を低く構成し過ぎた、共有メモリセグメントを不必要に使用するプロセスが存在している、などの原因が考えられます。通常操作時のプロセス固有の共有メモリセグメント使用量に関する情報が役立ちます。上記のコマンドを使用して、多数のセグメントを作成するプロセスを識別します。セグメントの総数と、同一プロセスによって作成されたセグメントの数 (cpid) を比較します。それを「通常の」値と比べてください。これらのプロセスが正常に作動しているか確認します。RTP ノードマネージャが制御しているプロセスの場合、プロセスが継続的にループしているコードブロックを識別するのに、イベントやトレースが役立つ場合があります。分析を進める場合はトレースを使用します。ループしているプロセスを再実行することが役立つ場合もあります。
hiQAudShMemUtilTrap
現在の共有メモリ ID 使用に関する情報を取得できます。

ユーザーの処置

これは消去アラームです。
hiQAudSubsystemRunningTrap
指定されたサブシステムは、現在実行中です。

ユーザーの処置

これは消去アラームです。
hiQAudSwapSpaceAboveCritThldTrap
システムはスワップスペースを使い果たしています。スワップスペースのチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。sar コマンドを使用できます。例えば、"sar -r 10 1" とします。"%swpused" という列に使用量が表示されます。その状態が長引く場合、構成されたスワップスペースがユーザーの目的を達成するには小さ過ぎる、ユーザーの特別の必要に対して監査しきい値を低く構成しすぎた、メモリリークのあるプロセスなど不必要にスワップスペースを消費するプロセスが存在している、などの原因が考えられます。通常操作の際のプロセスサイズに関する情報が役立つことでしょう。ps コマンドを繰り返し使用することによって、大量のメモリを使用するプロセスを識別します。例えば、ps -e -o "pid=" -o "vsz=" -o "comm" " sort -t" " -k2 -n などとします。"vsz" 値が大きいかまたは変更された (またはその両方) プロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、繰り返し呼び出されるコードブロックを識別するのに、イベントやトレースが役立つ場合があります。これらのプロセスのスタックまたはブレークサイズに関して、監査プロセスからイベントを検索してください。分析を進める場合はトレースを使用します。プロセスにメモリリークがある場合、再起動が役立つ場合があります。
hiQAudSwapSpaceAboveMajorThldTrap
システムはスワップスペースを使い果たしています。スワップスペースのチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。sar コマンドを使用できます。例えば、"sar -r 10 1" とします。"%swpused" という列に使用量が表示されます。その状態が長引く場合、構成されたスワップスペースがユーザーの目的を達成するには小さ過ぎる、ユーザーの特別の必要に対して監査しきい値を低く構成しすぎた、メモリリークのあるプロセスなど不必要にスワップスペースを消費するプロセスが存在している、などの原因が考えられます。通常操作の際のプロセスサイズに関する情報が役立つことでしょう。ps コマンドを繰り返し使用することによって、大量のメモリを使用するプロセスを識別します。例えば、ps -e -o "pid=" -o "vsz=" -o "comm" " sort -t" " -k2 -n などとします。"vsz" 値が大きいかまたは変更された (またはその両方) プロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、繰り返し呼び出されるコードブロックを識別するのに、イベントやトレースが役立つ場合があります。これらのプロセスのスタックまたはブレークサイズに関して、監査プロセスからイベントを検索してください。分析を進める場合はトレースを使用します。プロセスにメモリリークがある場合、再起動が役立つ場合があります。
hiQAudSwapSpaceAboveMinorThldTrap
システムはスワップスペースを使い果たしています。スワップスペースのチェックは、監査によって周期的に行われており、これが一時的な状態で、次のチェックまでに解消するならば、クリアイベントが発行されます。

ユーザーの処置

これが一時的なピーク状態なのか、永続的なものなのかを確認します。sar コマンドを使用できます。例えば、"sar -r 10 1" とします。"%swpused" という列に使用量が表示されます。その状態が長引く場合、構成されたスワップスペースがユーザーの目的を達成するには小さ過ぎる、ユーザーの特別の必要に対して監査しきい値を低く構成しすぎた、メモリリークのあるプロセスなど不必要にスワップスペースを消費するプロセスが存在している、などの原因が考えられます。通常操作の際のプロセスサイズに関する情報が役立つことでしょう。ps コマンドを繰り返し使用することによって、大量のメモリを使用するプロセスを識別します。例えば、ps -e -o "pid=" -o "vsz=" -o "comm" " sort -t" " -k2 -n などとします。"vsz" 値が大きいかまたは変更された (またはその両方) プロセスが、正しく作動していることを確認してください。RTP ノードマネージャが制御しているプロセスの場合、繰り返し呼び出されるコードブロックを識別するのに、イベントやトレースが役立つ場合があります。これらのプロセスのスタックまたはブレークサイズに関して、監査プロセスからイベントを検索してください。分析を進める場合はトレースを使用します。プロセスにメモリリークがある場合、再起動が役立つ場合があります。
hiQAudSwapUtilBelowThreshTrap
現在のスワップスペース使用量が、すべての構成済みしきい値よりも低くなっています。

ユーザーの処置

これは消去アラームです。
hiQAudSwapUtilChangedTrap
スワップスペース使用量が変更されましたが、依然として構成済みしきい値の 1 つより高い状態です。

ユーザーの処置

これは消去アラームです。
hiQAudSwapUtilTrap
現在のスワップスペース使用量に関する情報を取得できます。

ユーザーの処置

これは消去アラームです。
hiQGlobalCommsEstablishedTrap
このアラームは、通信が再確立されたことを報告するために使用されます。

ユーザーの処置

これは消去アラームです。
hiQGlobalCommsOperationalTrap
指定された通信リンクは完全に作動可能です。

ユーザーの処置

これは消去アラームです。
hiQGlobalCriticalLossOfCommsTrap
このトラップは、通信アラームの欠落を報告するために使用されます。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQGlobalDegradedCommsTrap
このイベントは、指定された通信リンクが混雑しているか品質が低下した状態であることを報告するために使用されます。

ユーザーの処置

hiQGlobalFuncAvailTrap
hiQGlobalFuncUnavailTrap
このアラームは、特定の機能が利用できないことを報告します。レベル 1 = それほど重要でない; レベル 2 = かなり重要; レベル 3 = 非常に重要

ユーザーの処置

このアラームは、hiQGlobalProcessAliasGrpAvailTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalMajorLossOfCommsTrap
このトラップは、通信アラームの欠落を報告するために使用されます。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQGlobalMinorLossOfCommsTrap
このトラップは、通信アラームの欠落を報告するために使用されます。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQGlobalMsgQueueAboveHighThldTrap
このアラームは、指定されたキュー内のエレメント数が定義済みしきい値制限を超えたことを報告するために使用されます。

ユーザーの処置

アラームが続くようであれば、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalMsgQueueAboveLowThldTrap
このアラームは、指定されたキュー内のエレメント数が定義済みしきい値制限を超えたことを報告するために使用されます。

ユーザーの処置

アラームが続くようであれば、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalMsgQueueAboveMedThldTrap
このアラームは、指定されたキュー内のエレメント数が定義済みしきい値制限を超えたことを報告するために使用されます。

ユーザーの処置

アラームが続くようであれば、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalMsgQueueBelowThldTrap
指定されたキュー内のエレメント数が、定義済みしきい値制限より低くなっています。

ユーザーの処置

これは消去アラームです。
hiQGlobalProcAbnormalTermTrap
この指定されたプロセスは異常終了しました。

ユーザーの処置

このアラームは hiQGlobalProcessInitActiveTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalProcessAliasGrpAvailTrap
冗長プロセスの集合である、プロセスの別名グループが使用可能です。

ユーザーの処置

これは消去アラームです。メモ: 対応するアラームが存在する場合にのみ送信されます。起動時の 1 つのグローバルクリア。
hiQGlobalProcessAliasGrpUnavailTrap
冗長プロセスの集合である、プロセスの別名グループが使用不可です。このことは、これらのプロセスが提供する機能がいずれも使用不可であることを意味します。

ユーザーの処置

メモ: Sametime Unfied Telephony システムは、このようなアラームが送信されたことを記録します。このアラームは、hiQGlobalProcessAliasGrpAvailTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalProcessInitActiveTrap
プロセスは正常に開始しました。

ユーザーの処置

これは消去アラームです。
hiQGlobalProcPartialInitFailTrap
指定されたプロセスは、部分的 (または重大な) 初期化障害を検出しました。重大な場合、続行できません。

ユーザーの処置

これらのアラームは hiQGlobalProcessInitActiveTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalProcSevereInitFailTrap
指定されたプロセスは、部分的 (または重大な) 初期化障害を検出しました。重大な場合、続行できません。

ユーザーの処置

これらのアラームは hiQGlobalProcessInitActiveTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalResourceExceedLimitTrap
指定されたリソースが、定義済み制限を超えました。

ユーザーの処置

このアラームは、hiQGlobalResourceWithinLimitTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQGlobalResourceWithinLimitTrap
指定されたリソースが、定義済み制限内にあります。

ユーザーの処置

これは通知アラームです。
hiQGlobalSevereDegradedCommsTrap
このイベントは、指定された通信リンクが混雑しているか品質が低下した状態であることを報告するために使用されます。

ユーザーの処置

--
hiQGlobalVerySevereDegradedCommsTrap
指定された通信リンクが混雑しているか品質が低下した状態で作動しています。

ユーザーの処置

指定された通信リンクが適切に構成されていること、および通信パスが使用可能であることを確認してください。
hiQHardwareFailureTrap
このアラームは、ハードウェアに関連したアラームが発生したことを示します。

ユーザーの処置

これらのアラームは hiQHardwareInServiceTrap でクリアできます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQHardwareInServiceTrap
このイベントは、ハードウェアに関連したアラームをクリアするのに使用されます。

ユーザーの処置

これは消去アラームです。
hiQImportantFuncUnavailTrap
このアラームは、特定の機能が利用できないことを報告します。レベル 1 = それほど重要でない; レベル 2 = かなり重要; レベル 3 = 非常に重要

ユーザーの処置

このアラームは、hiQGlobalProcessAliasGrpAvailTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQLicenseCountMismatchTrap
クラスタの 2 つのノード間で、faultyObject によって識別されたタイプのライセンス数が異なっています。

ユーザーの処置

その状態が自動的に解決されなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQLicenseCountOkTrap
割り当てられたライセンスの数が、faultyObject によって識別されたタイプの、アクティブ化されたライセンス数によって許可される制限以内になっています。

ユーザーの処置

これは消去アラームです。
hiQLicenseCountSyncTrap
Sametime Unfied Telephony クラスタの 2 つのノード間で、faultyObject によって識別されたタイプのライセンス数が、同じです。

ユーザーの処置

これは消去アラームです。
hiQLicenseRestoreOkTrap
復元の後に、ライセンス交付がシステムで適正に作動しています。

ユーザーの処置

これは消去アラームです。
hiQLicenseRestoreTrap
最新のリリースよりも 72 時間以上古いリリースにシステムを復元した結果、強制ライセンス交付が起きてライセンス交付違反となりました。

ユーザーの処置

その状態が自動的に解決されなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQLicenseSessionCountOKTrap
faultyObject によって識別されたタイプのライセンスセッションの数が、警告しきい値より低くなっています。

ユーザーの処置

これは消去アラームです。
hiQLicenseSessionsTrap
faultyObject によって識別されたタイプのライセンスセッションの数が、警告しきい値を超えています。

ユーザーの処置

追加のライセンスをインストールする、または製品内で現在割り当てられている数を削減してください。アラームは、RTP ライセンス交付パラメータの周期的な監査の際に、手動でクリアされます。
hiQLicensesExceededTrap
割り当てられたライセンスの数が、faultyObject によって識別されたタイプの、アクティブ化されたライセンスの数を超えました。

ユーザーの処置

追加のライセンスをインストールする、または製品内で現在割り当てられている数を削減してください。
hiQNmAliasMembersExceededTrap
重大なアラーム。RTP パラメータの Rtp/Nm/ProcsPerAlias は、すべての別名のメンバーの最大数を指定します。このパラメータは、tcn ファイルまたは CLI/GUI によって構成されるすべての別名メンバーに対して十分なものでなければなりません。

ユーザーの処置

パラメータ Rtp/Nm/ProcsPerAlias を大きくしてください。
hiQNmAliasTableLenExceededTrap
重大なアラーム。RTP パラメータの Rtp/Nm/MaxAliases は、tcn ファイルまたは GUI/CLI によって構成される別名の数以上とする必要があります。

ユーザーの処置

パラメータ Rtp/Nm/MaxAliases を大きくしてください。
hiQNmDbMaxProcGrpExceededTrap
データベースには、ノードマネージャが処理できるより多くの項目が含まれています。ノードマネージャは、それらの項目を無視します。

ユーザーの処置

データベースが正常にインストールされていることを確認してください。
hiQNmDbTableNotClosedTrap
ノードマネージャは、データベース表を閉じることができませんでした。

ユーザーの処置

データベースが正常にインストールされていること、および表が存在していることを確認してください。
hiQNmDbTableNotOpenedTrap
ノードマネージャは、データベース表を開くことができませんでした。

ユーザーの処置

--
hiQNmDbUnreachable1Trap
ノードマネージャは、データベースに達することができませんでした。

ユーザーの処置

データベースが正常にインストールされ、実行中であることを確認してください。以下の診断ファイルは、問題を分析するための情報を提供します: - SnmLogFile* に加え $HOME/$PLID/log からの最新の 5 つのデータベースログファイル。もし存在している場合は、Oracle の場合 RtpOracle*、Clustra の場合 RtpClustra*、RtpCluUserDB*。- さらに、以下のファイルが必要となる場合があります。Oracle の場合: ~oracle/admin/T001/bdump/alertT001.log、Clustra の場合: すべてのノードの現在の Clustra 履歴ファイル。
hiQNmDbUnreachable2Trap
ノードマネージャは、データベースに達することができませんでした。

ユーザーの処置

データベースが正常にインストールされ、実行中であることを確認してください。以下の診断ファイルは、問題を分析するための情報を提供します: - SnmLogFile* に加え $HOME/$PLID/log からの最新の 5 つのデータベースログファイル。もし存在している場合は、Oracle の場合 RtpOracle*、Clustra の場合 RtpClustra*、RtpCluUserDB*。- さらに、以下のファイルが必要となる場合があります。Oracle の場合: ~oracle/admin/T001/bdump/alertT001.log、Clustra の場合: すべてのノードの現在の Clustra 履歴ファイル。
hiQNmDiagnosticErrorTrap
このイベントの発生は必ずしも問題ではありませんが、関連した問題の診断に役立つ場合があります。

ユーザーの処置

RTP プラットフォームを監視してください。
hiQNmNodeDownMsgErrorTrap
NODEDOWN メッセージを指定されたノードに送信しようとしたときにエラーが発生しました。NODEDOWN メッセージは、シャットダウンが正しい順序で終了するために非常に重要です。

ユーザーの処置

「プログラマの手引き」で、関数 RtpComSendMessage() の戻りコードの説明を調べてください。
hiQNmNodeMgrSignalRestartTrap
SIGTERM、SIGINT、SIGQUIT というタイプの信号がノードマネージャに送信されました。

ユーザーの処置

その信号がなぜ送信されたかを確認してください。コマンドによって送信された場合、エラーとは限りません。
HiQNmNodeMgrStartingTrap
RTP ローカルノードマネージャが開始中です。

ユーザーの処置

これは消去アラームです。
hiQNmNodeShutdownTrap
指定されたプロセスの代わりに、ノードは停止されます。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQNmProcessCoreCreatedTrap
コアが RtpWriteCore() によって書き込まれた場合、コアは $HOME/$PLID/core ディレクトリにあります。

ユーザーの処置

RtpWriteCore() は、呼び出しプロセスに対して SIGABRT を送信することに注意してください。
hiQNmProcessExecvErrorTrap
execv が errno を戻したので、バイナリを開始できませんでした。RTP プロセスに対して再起動が設定されている場合、RTP はそれを再び開始しようと試みます。

ユーザーの処置

errno の意味を、execv の man ページで検索してください。
hiQNmProcessExitedTrap
この警告は、ノードマネージャからの明示的なシャットダウン要求なしに、プロセスが停止したときに出されます。

ユーザーの処置

このイベントは、実際のクリーンアップ処理を実行する前に、終了した子プロセスに対して RTP が wait() の呼び出しを行うときに、イベント 47 または 48 の代わりに報告されます。この場合、終了が処理されると、RTP はプロセス出口状況を持たなくなります。通常、システムは失敗したプロセスを再度開始することによって自動的に回復します。ただし、そのイベントがさらに頻繁に起きる場合、Sametime Unified Telephony カスタマーサービスにご連絡ください。可能な場合、そのイベントの前後 1 時間に書き込まれた RTP ログファイルおよびすべての Pstack ファイルを保存してください。
hiQNmProcessExitedwithCodeTrap
この警告は、ノードマネージャの子プロセスが、イベント中に表示されているコードで終了したときに出されます。

ユーザーの処置

通常、システムは失敗したプロセスを再度開始することによって自動的に回復します。ただし、そのイベントがさらに頻繁に起きる場合、Sametime Unified Telephony カスタマーサービスにご連絡ください。可能な場合、そのイベントの前後 1 時間に書き込まれた RTP ログファイルおよびすべての Pstack ファイルを保存してください。
hiQNmProcessHealthChkTimeoutTrap
このメジャーアラームは、プロセスが時間内にヘルスチェックに応答しない結果として生じます。

ユーザーの処置

RTP ヘルスチェックは応答のないプロセス (すなわち、デッドロックまたは無限ループ) を停止して、RTP がそれらを再度開始できるようにします。
hiQNmProcessInitCompleteTrap
RTP ミドルウェアと呼ばれるそのプロセスは、初期化フェーズを正常に終了しました。

ユーザーの処置

これは消去アラームです。
hiQNmProcessReadyTimeoutTrap
このメジャーアラームは、プロセスが指定された時間内に RtpNmReady() を呼び出さなかった結果として生じます。

ユーザーの処置

timeUntilReady および restartTimeUntilReady が、そのプロセスに対して正しく構成されていることを確認してください。
hiQNmProcessRestartShortTimeTrap
プロセスの再実行が早すぎます。頻繁な再実行を避けるために、ノードマネージャはプロセスの立ち上げを再試行する前に待機するようにします。

ユーザーの処置

プロセスが正常に構成されていることを確認してください。
hiQNmProcessTerminatedBySignalTrap
この警告は、ノードマネージャの子プロセスが、信号を受信したために終了したときに出されます。

ユーザーの処置

通常、システムは失敗したプロセスを再度開始することによって自動的に回復します。ただし、そのイベントがさらに頻繁に起きる場合、Sametime Unified Telephony カスタマーサービスにご連絡ください。可能な場合、そのイベントの前後 1 時間に書き込まれた RTP ログファイルおよびすべての Pstack ファイルを保存してください。
hiQNmQueueAllocErrorTrap
共有メモリの問題のために、プロセスキューを割り振ることができませんでした。

ユーザーの処置

shmget()、shmat() の man ページで errno の説明を調べてください。
hiQNmQueueCorruptedTrap
プロセスのキューは整合状態にありません。さらなる問題を避けるために、プロセスを停止させて新しいキューから始めることができます。

ユーザーの処置

プロセスが再び開始されることを確認してください。開始される場合は、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQNmResizeGlobalProcTblTrap
ノードの再起動により、別のノード上のプロセス数が変更されました。

ユーザーの処置

メモリ飽和のためと思われる共有メモリの問題。結果として、そのノードのプロセス表のサイズを変更する必要があります。
hiQPartnerNodeLeftClusterTrap
通信テストをリクエストするために、またはノードがパートナと通信できないときに Survival Authority に送信されます。Survival Authority が応答するように SNMP の set コマンドでリクエストします。

ユーザーの処置

この場合、Sametime Unified Telephony が、Sametime Unified Telephony クラスタの 2 つのノード間の通信問題が解決するまで、2 つのノードのどちらに呼び出し処理アクティビティを引き継がせ、どちらをシャットダウンさせるかを決定します。アクティビティログで SurvivalAuthority をフィルタすれば、Survival Authority Reporting セクションで存続処理をモニタできます。 (Survival Authority は、CMP と連結することも分離することも可能です)。
hiQPrimeClusterInstalledSnmTrap
スーパーノードマネージャは、PRIMECLUSTER/CF クラスタソフトウェアがインストールされていることを検出しました。スーパーノードマネージャは、クラスタ構成情報を CF (Cluster Foundation) から取り出します。

ユーザーの処置

これは通知アラームです。
hiQProcessExitedTrap
この警告は、プロセスの作業の続行を妨げるような重大な問題のために、プロセスが終了した場合に出されます。

ユーザーの処置

通常、この終了は構成問題やリソース問題が原因で、プロセスの開始中にのみ起こります。そのプロセスは RTP に登録できない場合があります。プロセスの終了を引き起こす原因はいくつか考えられます。RtpErrno を確認してください。
hiQSecurityFirewallTrigClearTrap
ファイアウォールのトリガを引き起こした条件が、クリアされました。これ以上の IP パケットが廃棄されることはありません。

ユーザーの処置

これは消去アラームです。
hiQSecurityFirewallTrigTrap
ファイアウォールは IP パケットの廃棄を開始しました。少なくとも 1 人のユーザーからの、ユーザーごとの 1 秒当たりの IP パケット数が、構成されたしきい値を超えました。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSevereHardwareTrap
このアラームは、ハードウェアに関連したアラームが発生したことを示します。

ユーザーの処置

これらのアラームは hiQHardwareInServiceTrap でクリアできます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQSnmCfNodeStatusTrap
スーパーノードマネージャが起動するとき、またはノードの状況が変化したときに、指定された CF (Cluster Foundation) ノードの状況が報告されます。

ユーザーの処置

これは消去アラームです。
hiQSnmClusterChangeInfoSentTrap
スーバーノードマネージャは、クラスタ構成の変更について、ローカル RTP ノードマネージャに連絡しました。

ユーザーの処置

これは消去アラームです。
hiQSnmClusterChangeTrap
スーパーノードマネージャは、クラスタソフトウェアへのインターフェースを介してクラスタの変更を検出します。

ユーザーの処置

これは消去アラームです。
hiQSnmNodeInfoMismatchTrap
スーパーノードマネージャは、RtpClustertab にリストされているその自身のノード情報 (名前および ID) と、クラスタソフトウェアから提供されたノード情報に不一致があることを検出しました。

ユーザーの処置

RtpClustertab ファイルを確認して修復してください。
hiQSnmRebootForSubsystemTrap
ヘルス検出機能スクリプトは、システムのリブートを必要とします。詳細は、$HOME/$PLID/log にあるヘルス検出機能スクリプトのログファイルを参照してください。

ユーザーの処置

大がかりなアクションが実行可能であれば、システムはリブートされます。それ以外の場合、システムをリブートすることが推奨されています。他に問題を起こさずに RTP が実行されるかどうかを監視してください。
hiQSnmRmsClusterSwInstalledTrap
スーパーノードマネージャは、RMS クラスタソフトウェアがインストールされていることを検出しました。スーパーノードマネージャは、クラスタ構成情報を RMS から取り出します。Reliant Monitor System は、クラスタ間の接続および現在のクラスタ構成 (すなわち、そのクラスタに現時点でどのノードが所属していて、どのノードが所属していないか) のモニタを担当します。

ユーザーの処置

これは消去アラームです。
hiQSnmRmsWorkingAgainTrap
スーパーノードマネージャは、以前に障害が検出された RMS が再び作動していることを検出しました。Reliant Monitor System は、クラスタ間の接続および現在のクラスタ構成 (すなわち、そのクラスタに現時点でどのノードが所属していて、どのノードが所属していないか) のモニタを担当します。

ユーザーの処置

これは消去アラームです。
hiQSnmRtpNodeDownTrap
この重大アラームは、スーパーノードマネージャがノードのダウンを報告していることを示します。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSnmRtpNodeDownWasUpTrap
この重大アラームは、スーパーノードマネージャが、以前稼働していたノードが現在はダウンしていると報告していることを示します。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSnmRtpNodeUpTrap
スーパーノードマネージャは、そのノードが稼働していることを報告します。

ユーザーの処置

これは消去アラームです。
hiQSnmRtpNodeUpWasDownTrap
スーパーノードマネージャは、ダウンしていたノードが現在は稼働していることを報告します。

ユーザーの処置

これは消去アラームです。
hiQSnmRtpPlatformPlidReportTrap
スーパーノードマネージャは、RTP プラットフォームが開始された ID を報告します。

ユーザーの処置

これは消去アラームです。
hiQSnmRtpRestartForSubsystemTrap
言及されたサブシステムのヘルス検出機能スクリプトは、RTP 全体の再起動を要求しています。その理由については、$HOME/$PLID/log にあるヘルス検出機能スクリプトのログファイルを参照してください。

ユーザーの処置

RTP が停止され、再起動されます。他に問題を起こさずに RTP が実行されるかどうかを監視してください。
hiQSnmSpecialActScrSuccessTrap
言及されたサブシステムの特別アクションスクリプトは、正常に返されました。

ユーザーの処置

これは消去アラームです。
hiQSnmSpsClusterSwInstalledTrap
スーパーノードマネージャは、SPS (Sametime Unified Telephony Parallel Server) クラスタソフトウェアがインストールされていることを検出しました。スーパーノードマネージャは、クラスタ構成情報を SPS から取り出します。

ユーザーの処置

これは消去アラームです。
hiQSnmStartupFailedTrap
スーパーノードマネージャは RTP 全体の開始の際に、単一のサブシステムを開始できませんでした。このため RTP の開始を続行できません。これまでに開始されたサブシステムはすべて停止されます。

ユーザーの処置

言及されたサブシステムがなぜ開始できなかったかを確認してください。
hiQSnmStartupSuccessTrap
スーパーノードマネージャプロセスは、正常に開始しました。

ユーザーの処置

これは消去アラームです。
hiQSnmSubsysAdmInterventionTrap
言及されたサブシステムのヘルス検出機能スクリプトは、管理者の介入を必要としています。

ユーザーの処置

詳細は、ヘルス検出機能スクリプトの終了コードを確認し、$HOME/$PLID/log にあるヘルス検出機能スクリプトのログファイルを参照してください。
hiQSnmSubsysAlreadyRunningTrap
スーパーノードマネージャは、既に稼働中のサブシステムを開始しようとしました。

ユーザーの処置

これは消去アラームです。
hiQSnmSubsysFailedTrap
スーパーノードマネージャは、指定されたサブシステムに対して検出機能を実行し、失敗しました。

ユーザーの処置

このアラームは、支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSnmSubsysRestartSuccDepTrap
スーパーノードマネージャは、以前にそのサブシステムの再起動を試みましたが失敗しました。しかし現在では、そのサブシステムが再び稼働中であることが検出されています。スーパーノードマネージャは、従属するサブシステムも再起動させます。

ユーザーの処置

これは消去アラームです。
hiQSnmSubsysRestartSuccessTrap
スーパーノードマネージャは、以前にそのサブシステムの再起動を試みましたが失敗しました。しかし現在では、そのサブシステムが再び稼働中であることが検出されています。

ユーザーの処置

これは消去アラームです。
hiQSnmSubsystemStartErrorTrap
スーパーノードマネージャは、言及されたサブシステムを開始できません。関連付けられた開始スクリプトがエラーを返します。

ユーザーの処置

詳細は、開始スクリプトの終了コードを確認し、$HOME/$PLID/log にある開始スクリプトのログファイルを参照してください。
hiQSnmSubsystemStartSuccessTrap
スーパーノードマネージャは、言及されたサブシステムを正常に開始しました。

ユーザーの処置

これは消去アラームです。
hiQSnmSubsystemStopSuccessTrap
スーパーノードマネージャは、言及されたサブシステムを正常に停止しました。

ユーザーの処置

これは消去アラームです。
hiQSnmSystemSwitchOffTrap
ヘルス検出機能スクリプトは、システムのスイッチオフを要求しています。詳細は、$HOME/$PLID/log にあるヘルス検出機能スクリプトのログファイルを参照してください。

ユーザーの処置

大がかりなアクションが実行可能であれば、システムはスイッチオフされます。そうでない場合、システムをスイッチオフすることが推奨されます。クラスタ内の残りのノード上の RTP が、他に問題を起こさずに実行されるかどうかを監視してください。
hiQSolidBackupFailedTrap
ソリッドバックアップは失敗しました。失敗したバックアップは、Alarm Details Dialog Box Description フィールドを調べて判別できます。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidBackupSuccessTrap
ソリッドデータベースバックアップが正常に完了しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidBothHSBDbPrimaryTrap
両方のソリッドホットスタンバイデータベースが、プライマリとしてマークを付けられています。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidCreateNewDbFailedTrap
新規のソリッドデータベースを作成する際に障害が発生しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDatabaseStarted2Trap
ソリッドデータベースが再起動されました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDatabaseStartedTrap
ソリッドデータベースが再起動されました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbBrokenCopyTrap
ソリッドデータベースは破損したホットスタンバイデータベースまたは netcopy データベースです。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbConvertedTrap
ソリッドデータベースは正常に変換されました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbDoesNotExistsTrap
ソリッドデータベースが存在していません。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbIndexErrorTrap
指定されたソリッドデータベースの索引が OK ではありません。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbIndexTestSuccessTrap
ソリッドデータベース索引がテストされ、OK です。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbOpenFailureTrap
ソリッドデータベースを開くことに失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbOpeningProblemTrap
ソリッドデータベースを開く際に問題を検出しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbServerCorruptTrap
単一のデータベースサーバーが破損しています。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbTstConnectFailureTrap
致命的エラーのために、テスト用にソリッドデータベースを接続することに失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidDbTstOpenFailureTrap
致命的エラーのため、テスト用にソリッドデータベースを開くことに失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidFatalErrSrvNotStartTrap
ソリッドデータベースサーバーは、致命的エラーのために開始できませんでした。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidFatalErrSrvShutdownTrap
致命的エラーのために、ソリッドデータベースサーバーの緊急シャットダウンが発生しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidFlowEngineIntErrorTrap
ソリッド FlowEngine プロセスが内部エラーを検出したため、正常に続行することができません。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidFlowEngineStartedTrap
ソリッドデータベースサーバーが開始されました。

ユーザーの処置

--
hiQSolidHSBSwitchPrimErrTrap
示されたエラーによって、ホットスタンバイロールからプライマリへの切り替えが失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidHSBSwitchSecErrTrap
示されたエラーによって、ホットスタンバイロールからセカンダリへの切り替えが失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidLocalDbServerCorruptTrap
ローカルデータベースサーバーが破損しています。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidNewConnsAllowedTrap
新規データベース接続が許可されています。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidNewDbNotCreatedTrap
新規ソリッドデータベースは作成されませんでした。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidNoNewConnsAllowedTrap
ソリッドデータベースサーバーは致命的な状態にあります。新規接続は許可されません。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidOldDbVersionTrap
ソリッドデータベースは、ソリッドの古いバージョンからのものです。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidServerStartFailedTrap
ソリッドデータベースを開始することに失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidStartedHSBPrimaryTrap
ホットスタンバイプライマリとして開始しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidStartedHSBSecondaryTrap
ホットスタンバイセカンダリとして開始しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidTableConvertedTrap
指定されたソリッドデータベース表が変換されました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSolidTooManyClientsTrap
接続しているクライアントが多過ぎて、示されたユーザーが接続に失敗しました。

ユーザーの処置

支援を求めて次に上位の障害クリア権限に連絡を取らない限り、解決されません。
hiQSubMgmtRemoveResourceErrorTrap
このマイナーアラームは、加入者の管理リソースを削除するためのジョブが失敗したことを示します。

ユーザーの処置

手動でリソースを削除してください。
hiQSubMgmtRemoveResourceSuccessTrap
加入者の管理リソースを削除するためのジョブが正常に完了しました。

ユーザーの処置

これは消去アラームです。
hiQSystemSurvivalModeTrap
この重大アラームは、システムがサバイバルモードで作動していることを示します。

ユーザーの処置

パートナノードの障害の原因を訂正してください。
hiQTcaClearedTrap
指定されたログカテゴリのログに記録された項目の数が、特定の期間にわたって、以前にアラームを引き起こしたしきい値を超えませんでした。

ユーザーの処置

これは消去アラームです。
hiQTcaL1CommunicationTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

すべての Tca アラームは手動でクリアできます。または、構成された時間間隔の後に自動的にクリアされます。
hiQTcaL1DatabaseTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

アラームは手動でクリアできます。または、構成された時間間隔の後に自動的にクリアされます。
hiQTcaL1EnvironmentTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL1EquipmentTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL1IndicationTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL1MibTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL1ProcessingTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL1SecurityTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL1ServiceTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2CommunicationTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

すべての Tca アラームは手動でクリアできます。または、構成された時間間隔の後に自動的にクリアされます。
hiQTcaL2DatabaseTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

アラームは手動でクリアできます。または、構成された時間間隔の後に自動的にクリアされます。
hiQTcaL2EnvironmentTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2EquipmentTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2IndicationTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2MibTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2ProcessingTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2SecurityTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL2ServiceTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3CommunicationTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

すべての Tca アラームは手動でクリアできます。または、構成された時間間隔の後に自動的にクリアされます。
hiQTcaL3DatabaseTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

アラームは手動でクリアできます。または、構成された時間間隔の後に自動的にクリアされます。
hiQTcaL3EnvironmentTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3EquipmentTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3IndicationTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3MibTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3ProcessingTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3SecurityTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTcaL3ServiceTrap
指定されたログカテゴリのカウンタは、定義されたしきい値を超えました。

ユーザーの処置

--
hiQTicCopyToTicketPoolFailedTrap
チケットファイルを中央チケットプールからまたはそこに移動させるために copy コマンドを使用する必要がありますが、ここでは失敗しました。

ユーザーの処置

RTP の状態 (特に、適切なチケットタイプの使用可能なチケットファイルについて) を確認してください。問題が見つからなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQTicDiskFullTicketPoolFailedTrap
チケットプールの構成済みディスクパーティションがいっぱいです。

ユーザーの処置

--
hiQTicPoolDiskDevNotAccessibleTrap
チケット初期設定の際にエラーが発生しました。中央チケットプール用の構成済みディスク装置にアクセスできませんでした。

ユーザーの処置

RTP 環境を確認してください。
hiQUCEServicesRegisteringTrap
そのイベントは、サービスが UCE に登録される前、初期設定の最初に各 UCE プロセスによって報告されます。

ユーザーの処置

これは消去アラームです。
hiQUCEServicesRegistrationFailedTrap
呼び出し処理の際に使用する登録が失敗しました。

ユーザーの処置

このアラームは、ノードと UCE プロセスが一致している限り、hiQUCEServicesRegisteringTrap によってクリアされます。
hiQVeryImportantFuncUnavailTrap
このアラームは、特定の機能が利用できないことを報告します。レベル 1 = それほど重要でない; レベル 2 = かなり重要; レベル 3 = 非常に重要

ユーザーの処置

このアラームは、hiQGlobalProcessAliasGrpAvailTrap によってクリアされます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。
hiQVerySevereHardwareFailureTrap
このアラームは、ハードウェアに関連したアラームが発生したことを示します。

ユーザーの処置

これらのアラームは hiQHardwareInServiceTrap でクリアできます。クリアできなければ、支援を求めて次に上位の障害クリア権限に連絡を取ってください。