Finesse エージェント/Supervisorキュー/SkillGroup 統計は問題をアップデートします

概要

この資料はキューの問題識別におけるトラブルシューティングの方法を記述したものでまたは Skillgroup 統計はとりわけ Computer-Telephony Integration （CTI）サーバと Finesse サーバ間のメッセージ遅延によって引き起こされる Finesse エージェントデスクトップ 環境で、観察される問題をアップデートします。 技術情報はログ分析を提供し、最適でない遅らせられたネットワークのこれらの統計アップデートメッセージの処理の Finesse サーバ機能を改善するために回避策と完了します。

前提条件

要件

次の項目に関する知識が推奨されます。

• Cisco Unified Contact Center Enterprise （UCCE） CTI サーバ（CTISVR）
• Cisco Finesse サーバ

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

• インストールされる CTISVR の Peripheral Gateway UCCE エージェント
• Finesse サーバ クラスタ

本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

CTI クライアントとして CTISVR を定期講読するサーバを、提供しますエージェント 機能をうまく解決して下さいなんとコンピュータ テレフォニー 統合 オブジェクト サーバ（CTIOS）かに類似したであるおよび Cisco Agent Desktop （CAD）は提供できます。 Finesse エージェント/スーパバイザはまたいくつかの CTIOS および CAD エージェントによって直面される問題に直面できます。

そのような問題の 1 つは Finesse エージェント/スーパバイザ デスクトップにアップデートしないキューまたは Skillgroup リアルタイム統計です。 CTIOS および CAD 環境では、エンジニアは通常デザイン ガイドラインをチェックし、エージェントごとの skillgroup、周辺装置ごとの総 skillgroups およびスーパバイザ等 1人あたりのチームのような設定 制限がオーバーサブスクライブされたかどうか確認します。  エンジニアはまたチェックします CTISVR の同時 CTI クライアント接続の数を、参照します Cisco Unified Contact Center Enterprise 設計 ガイドを、リリース 10.0(1)

関連情報はまたバージョン 10.5(x) およびバージョン 11 のための設計ガイドから参照することができます。

Finesse エージェント/スーパバイザのこの問題の種類のトラブルシューティングはまた述べられた設計制限確認から開始します。 ただし、Finesse エージェントは Finesse サーバに専らある追加制限によって影響を与えることができます。

問題の症状

問題をアップデートしないキューまたは Skillgroup 統計は一般的にこれらのシナリオではあります:

• 現在のエージェントの状態は Finesse エージェントデスクトップの個々のスキル/キュー小道具に反映されません。 ただしエージェントの状態が skillgroups と正しいことを、エージェントの状態をエージェントの Peripheral Gateway （PG） la コマンドで opctest の使用とチェックして、示します。
• エージェントの数は話す状態にしばらくありますが、Finesse エージェントかスーパバイザ デスクトップはまだ話す時間のスキル/キューで 0 を示します。
• Finesse サーバの再始動はシステムが一時的にはたらくようにしますが通常同じ問題はまたは時間数分以内に新しい表紙を付けます。

Finesse CTI メッセージングおよび Finesse キュー統計バッファ

Finesse エージェント キュー統計またはスキル統計は要求のこれらのペアおよび Finesse サーバの応答 CTI メッセージの交換によって更新遂行されます。

CTISVR 応答の結果 Finesse および QuerySkillGroupStatisticsConf メッセージによる getQueryQueueStatisticsReq() Message 要求。

デフォルトで、Finesse は指定 10 の第 2 stats リフレッシュ 間隔内の 751 人のスキル グループ 要求を処理できます。 処理されない要求は後で処理されるべきメッセージ キューでバッファリングされます。 Finesse はこのメッセージ バッファ キューとデフォルトで REQUEST メッセージを 5000 保持するために初期化されます。

ただし、バッファが充満し、圧倒されれば、いくつかのこれらのキュー stats REQUEST メッセージは時間を計られ、廃棄されます。

Finesse キュー統計バッファー オーバーランのための原因

1. 設計/設定加入超過。 スーパバイザ等 1人あたりの周辺装置ごとのエージェントごとの例えばスキル、総 skillgroups およびチームは推奨されるコンフィギュレーション制限のための Cisco Unified Contact Center Enterprise 設計 ガイドを示します。 加入超過は統計更新の余分な CTI メッセージングの原因となる場合がありそれ故に Finesse キュー統計要求 バッファをオーバーランします。

2. 最大値を超過することはすべてのイベント接続および監視モード接続を含む同時 CTI クライアント接続を可能にしました。 CTISVR リソース枯渇 CTI メッセージ処理速度の重要な低下に導く。

3. 例えば PG パフォーマンス CPU、メモリおよびディスク I/O etcs。

4. Finesse アプリケーションを十分なネットワーク帯域幅が CTI メッセージング遅延をサポートするために、すなわち 62ms 可能にしませんでした。

Finesse 帯域幅カルキュレータは現在の設計 specs をリンクで推奨されるネットワーク帯域幅を割り当てるためにここに提供しました。 http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html

CTI メッセージ遅延による Finess キュー統計バッファー オーバーラン

REQUEST メッセージ処理速度およびメッセージ バッファのこの Finesse 制限に基づいて、最大平均要求および応答遅延のデフォルト値は平均 Finesse 配置のための 62ms です。 平均遅延がかなり 62ms の基準を超過する場合、例えば 100ms のまわりの CTI メッセージ遅延。 それからバッファリングされた getQueryQueueStatisticsReq() CTI メッセージは CTISVR に決して送られ、その 10 第 2 リフレッシュ 間隔内の QuerySkillGroupStatisticsConf メッセージと十分に速く応答することができません。 そして残りの時間を計られた getQueryQueueStatisticsReq() メッセージはキュー統計バッファから廃棄されます。

関連した Finesse トレース

メッセージが webservices で見つけることができるキュー統計はログをうまく解決します。 それは Debug trace レベルを詳しいキュー統計メッセージを明らかにするために必要とします。

webservices のターンアップ Debug trace レベルへのステップに関しては、この docwiki リンクを参照して下さい。

http://docwiki.cisco.com/wiki/Logging:_Enable_debug_level_logging

ログ分析

キュー バッファがオーバーランするとき次 ログ 断片は Webservices ログから観察することができます

10 第 2 リフレッシュ 間隔の始めに 751 キュー統計要求 アップデートの円形の始まりを、探して下さい:

eg.
Sep 22 2014 14:34:59.878 -0700: %CCBU_pool-21-thread-1-6-QUEUE_STATISTICS_REQUEST: %[count=751]: Starting new round of querying active queue statistics

10 秒後に発生する 751 の要求のこれおよび次のラウンド間でそこに QuerySkillGroupStatisticsConf 751 のメッセージと一致する場合、例えばテキスト ツール Notepad++ によってフィルタリングし、確認して下さい:

eg
Sep 22 2014 14:34:59.888 -0700: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIQuerySkillGroupStatisticsConf[peripheralID=5000, skillGroupNumber=28353, routerCallsQNow=0, longestRouterCallQNow=0, agentsNotReady=0, agentsReady=0, agentsTalkingIn=0, agentsTalkingOut=0, agentsTalkingOther=0, agentsWorkNotReady=0, agentsWorkReady=0]CTIMessageBean [invokeID=112223, msgID=115, timeTracker={"id":"QuerySkillGroupStatisticsConf","CTI_MSG_NOTIFIED":1411536082977,"CTI_MSG_RECEIVED":1411536082976}, msgName=QuerySkillGroupStatisticsConf, deploymentType=CCE]][cti_response_time=1]: Decoded Message to Finesse from backend cti server

たとえば、この円形のための Finesse によって、別のワードで処理されるメッセージが QuerySkillGroupStatisticsConf 329 だけあればそこにバッファで並べられる 422 のメッセージがある必要があります。 明らかに、400 のメッセージのあたりで 10 秒毎に並べられることはありますそれからバッファが 3 分以内の 5000 のメッセージのしきい値に達することができる。

3 分以内に発生するポーリング エラーの最初の発生を、それですバッファー オーバーランのサイン捜して下さい:

Sep 22 2014 14:37:29.883 -0700: %CCBU_pool-21-thread-1-3-QUEUE STATISTICS POLLING ERROR: %[ERROR_DESCRIPTION= maximum pool and queue capacity reached so discarding execution][error_message=Thread pool saturated, discarding execution ]: Error during queue statistics polling

遅延を処理する CTISVR の実例

• Finesse は CTISVR に getQueryQueueStatisticsReq() 要求を- invokeId=112223 をトラッキングすること、queueId=28353 送信 します:

Sep 23 2014 22:21:22.875 -0700: %CCBU_pool-19-thread-4-7-CTIWriter.getQueryQueueStatisticsReq():  {Thrd=pool-19-thread-4} params : invokeId=112223, queueId=28353

• CTISVR は要求を受け取りました:

match InvokeID:0x1b65f with invoked=112223 in the Finesse request

and SkillGroupNumber:28353 with queueId in the Finesse request

22:21:22:921 cg1A-ctisvr SESSION 9: MsgType:QUERY_SKILL_GROUP_STATISTICS_REQ (InvokeID:0x1b65f PeripheralID:5000
22:21:22:921 cg1A-ctisvr SESSION 9:         SkillGroupNumber:28353 SkillGroupID:N/A )  

• CTISVR 応答:

22:21:22:999 cg1A-ctisvr SESSION 9: MsgType:QUERY_SKILL_GROUP_STATISTICS_CONF (InvokeID:0x1b65f PeripheralID:5000
22:21:22:999 cg1A-ctisvr SESSION 9:         SkillGroupNumber:28353 SkillGroupID:9431 AgentsLoggedOn:0 AgentsAvail:0 AgentsNotReady:0
22:21:22:999 cg1A-ctisvr SESSION 9:         AgentsReady:0 AgentsTalkingIn:0 AgentsTalkingOut:0 AgentsTalkingOther:0
22:21:22:999 cg1A-ctisvr SESSION 9:         AgentsWorkNotReady:0 AgentsWorkReady:0 AgentsBusyOther:0 AgentsReserved:0 AgentsHold:0
22:21:22:999 cg1A-ctisvr SESSION 9:         AgentsICMAvailable:0 AgentsApplicationAvailable:0 AgentsTalkingAutoOut:0
22:21:22:999 cg1A-ctisvr SESSION 9:         AgentsTalkingPreview:0 AgentsTalkingReservation:0 RouterCallsQNow:0

• Finesse は CTISVR 応答を受け取り、QuerySkillGroupStatisticsConf メッセージを形成しました:

Sep 23 2014 22:21:22.977 -0700: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIQuerySkillGroupStatisticsConf[peripheralID=5000, skillGroupNumber=28353, routerCallsQNow=0, longestRouterCallQNow=0, agentsNotReady=0, agentsReady=0, agentsTalkingIn=0, agentsTalkingOut=0, agentsTalkingOther=0, agentsWorkNotReady=0, agentsWorkReady=0]CTIMessageBean [invokeID=112223, msgID=115, timeTracker={"id":"QuerySkillGroupStatisticsConf","CTI_MSG_NOTIFIED":1411536082977,"CTI_MSG_RECEIVED":1411536082976}, msgName=QuerySkillGroupStatisticsConf, deploymentType=CCE]][cti_response_time=1]: Decoded Message to Finesse from backend cti server

これが平均応答時間である場合 QuerySkillGroupStatisticsConf 一致するメッセージを受け取るためにそれが Finesse のための 100ms 秒を引き継いだことに注意して下さい。 Finesse はバッファ キュー オーバーラン問題に動作できます。

回避策

Finesse サーバ側のリフレッシュ 間隔を設定 する aws.properties にプロパティがあります。 これは基本的に Finesse からの CTISVR へキュー統計要求（1 機の円形この配備の 751 のキュー統計要求であること）の 2 つのラウンド間の間隔です。 Finesse はデフォルトで 10 秒毎にそれを要求します。 このプロパティは意味する値で何かに Finesse はより多くの時間がややあることを可能性としてはより高く変更できます（例えば: 10sec の代りの 20sec）キュー統計要求の 1 つの円形を処理するため。 それはまた効果的に 62ms から 124ms に基準 CTI スキル統計要求および応答遅延を拡張します。

• Finesse OS プラットフォームへの得られたルートアクセス
• プロパティ ファイル /opt/cisco/desktop/conf/webservices/aws.properties への VI
• 10 から 20 まで Property 値これを修正しました

com.cisco.cc.webservices.reporting.core.queue_statistics_refresh_interval

注: 秒のキュー統計情報のためのリフレッシュ 間隔。

• 保存 aws.properties ファイル
• 再始動 Finesse Tomcat サービス
• 同じステップは Finesse クラスタ内のすべての Finesse ノードで遂行されるべきです