保守性、ログ記録、監視、メトリクス

ログの設定

Expressway は、トラブルシューティングと監査の目的で syslog 機能を提供します。 イベント ログは、通話、登録、送受信されたメッセージなどの情報を記録する、循環するローカル ログです。

Expressway のログ オプションを構成するには、 [メンテナンス] > [ログ] に移動しますログ記録 ページから、次のタスクを実行できます。

イベントログの詳細度を変更する

オプションで、 ローカル イベント ログの詳細度 を 1 ~ 4 の間で設定することにより、ローカル ログの詳細度を制御できます。すべてのイベントには 1 ~ 4 の範囲のレベルが関連付けられており、レベル 1 のイベントが最も重要とみなされます。


(注)  


レベル 3 またはレベル 4 でのログ記録は、通常の操作では推奨されません。このような詳細なログ記録により、2 GB のログが急速に回転する可能性があるためです。 ただし、トラブルシューティングのためにこのレベルの詳細を記録する必要がある場合があります。


リモートログが有効かどうかに関係なく、イベントは常にローカルのイベントログに記録されます。

次の表は、さまざまなイベントに割り当てられたレベルの概要を示しています。

レベル

割り当てられたイベント

1

登録リクエストや通話試行などの高レベルのイベント。 人間が簡単に読める形式です。 次に例を示します。

  • 通話試行/接続/切断

  • 登録試行が承認/拒否されました

2

すべてのレベル 1 イベントに加え、次も含まれます。

H.460.18 キープアライブや H.245 ビデオ高速更新などのノイズの多いメッセージを除いた、送受信されたプロトコル メッセージ (SIP、H.323、LDAP など) のログ

3

すべてのレベル 1 およびレベル 2 のイベントに加えて、次のイベントも含まれます:

  • プロトコルキープアライブ

  • 通話関連の SIP シグナリングメッセージ

4

最も詳細なレベル: レベル 1、レベル 2、レベル 3 のすべてのイベントに加えて、次の内容が含まれます。

  • ネットワークレベルの SIP メッセージ

ログ レベルを変更すると、Web インターフェイスを通じて表示するイベント ログと、リモート ログ サーバにコピーされる情報の両方に影響します。 変更は遡及的ではなく、変更後に記録された内容にのみ影響します。

Expressway は、ローカル ログに次の機能を使用します。 (ローカル) ファシリティにマップされているソフトウェア コンポーネント/ログが強調表示されます。

  • 0 (kern)

  • 3(デーモン)

  • 16 (local0) 管理者

  • 17 (local1) Config

  • 18 (local2) メディア統計

  • 19 (local3) Apache エラー

  • 20 (local4) etc/opt/apache2

  • 21 (local5) 開発者

  • 22 (local6) ネットワーク

イベントとレベル セクションには、Expressway によって記録されるすべてのイベントと、それらが記録されるレベルの完全なリストがあります。

証明書に準拠したログ記録

環境によっては、Expressway ログがセキュリティ認定の要件に準拠していることを確認する必要がある場合があります。 セキュリティと診断用ログの目的の間にはトレードオフがあり、認証準拠モードでは問題の呼び出しの正確な原因を特定できない可能性があります。

認証に準拠したログ記録を設定する方法

手順

ステップ 1

[メンテナンス(Maintenance)] > [ログ記録(Logging)]に移動します。

ステップ 2

ログオプション セクションで、認証ログ記録 モードを次のいずれかに設定します。

証明書ログ記録モード

説明

診断

このモードは認証に準拠していませんが、通話の問題を診断するのに最も役立ちます。

秘密

このモードは認証に準拠しています。

秘密と詳細

このモードも認証に準拠していますが、Syslog サーバへの安全な接続を使用して一部のログ情報を収集できます。 これらのログは診断という意味では特に役に立ちません。


リモート Syslog サーバーへのログの送信

Syslog は、複数のシステムからのログ メッセージを 1 つの場所に集約する便利な方法です。 これは、クラスター内のピアに特に推奨されます。

  • 最大 4 台のリモート Syslog サーバーにログ メッセージを送信するように Expressway を設定できます。

  • Syslog サーバは、次のいずれかの標準プロトコルをサポートする必要があります。

リモート Syslog サーバの設定


(注)  


  • キーワードでフィルタリング オプションは、重大度によってすでにフィルタリングされているメッセージに適用されます。

  • 最大 5 つのキーワードを使用できます。キーワードには、カンマで区切られた単語のグループ (例: "login successful") を含めることができます。

  • キーワード検索では最大 256 文字を使用できます。

  • システムのパフォーマンスに影響を与えないように、最初に最も関連性の高いキーワードを検索することをお勧めします。 これにより、システムは関連するログ メッセージをできるだけ早く syslog サーバにプッシュできるようになります。


手順

ステップ 1

[メンテナンス] > [ログ記録] に進み、このシステムがログ メッセージを送信する [リモート syslog サーバ] の IP アドレスまたは完全修飾ドメイン名 (FQDN) を入力します。

ステップ 2

各サーバの オプション ボタンをクリックします。

ステップ 3

使用する トランスポート プロトコルと ポート を指定します。 TLS の使用を選択した場合、syslog サーバの証明書失効リスト (CRL) チェックを有効にするオプションが表示されます。

ステップ 4

メッセージ形式 フィールドで、リモート syslog メッセージの書き込み形式を選択します。 デフォルトは レガシー BSD です

ステップ 5

[重大度でフィルター] オプションを使用して、送信する詳細のレベルを選択します。 Expressway は、選択した重大度のメッセージと、それよりも重大度の高いメッセージをすべて送信します。

ステップ 6

特定のキーワードを含むメッセージのみを送信する場合は、 [キーワードでフィルタリング] オプションを使用します。

ステップ 7

[保存(Save)] をクリックします。


使用される標準値

次の表は、ログサーバーとネットワーク設定に最適な形式を選択するのに役立ち、使用される標準値を示しています。

表 1. Syslog メッセージの形式

メッセージ形式

トランスポート プロトコル 

推奨ポート

RFC

レガシー BSD 形式

UDP

514

BSD 形式。 「RFC 3164」を参照してください。

IETF syslog 形式

UDP

514

IETF 形式。 RFC 5424 を参照 https://tools.ietf.org/html/rfc5424#section-6

TLS 接続を使用した IETF syslog

TLS

6514

IETF 形式。 RFC 5424 を参照 https://tools.ietf.org/html/rfc5424#section-6


(注)  


  • UDP プロトコルはステートレスです。 ご使用の環境で Syslog メッセージの信頼性が非常に重要な場合は、別のトランスポート プロトコルを使用する必要があります。

  • Expressway と syslog サーバの間にファイアウォールがある場合は、メッセージを通過させるために適切なポートを開く必要があります。

  • TLS トランスポートを選択した場合、Expressway は syslog サーバの証明書を信頼する必要があります。 必要に応じて、syslog サーバの CA 証明書をローカル信頼ストアにアップロードします。

  • TLS 使用時の CRL チェックはデフォルトで無効になっています。 CRL を有効にするには、 CRL チェックオン に設定し、関連する証明書失効リスト (CRL) がロードされていることを確認します。

    詳細については、 「セキュリティの基礎」 を参照してください。

  • リモート サーバを別の Expressway にすることはできません。

  • Expressway は他のシステムのリモート ログ サーバとして機能することはできません。

  • Expressway はリモートログに次のファシリティを使用します。 (ローカル) ファシリティにマップされているソフトウェア コンポーネント/ログが強調表示されます。

    • 0 (kern)

    • 3(デーモン)

    • 16 (local0) 管理者

    • 17 (local1) 構成

    • 18 (local2) メディア統計

    • 19 (local3) Apache エラー

    • 20 (local4) etc/opt/apache2

    • 21 (local5) 開発者

    • 22 (local6) ネットワーク


通話のメディア統計ログ

メディア統計を有効にする方法

オプションで Expressway でメディア統計の収集を有効にするには、 [メンテナンス] > [ログ記録] に移動し、 [メディア統計][オン] に設定します。 システムは、各通話のメディア統計をローカル ハード ディスクの /mnt/harddisk/log に記録し始めます。 10MB のファイルが最大 200 個保存され、200 個のファイルがいっぱいになると最も古いファイルが削除されます。

収集されるメディア統計には、転送されたパケット、失われたパケット、ジッター、メディア タイプ、コーデック、実際のビットレートが含まれます。

メディア統計も syslog メッセージとして公開されます。 メディア統計ログがオンの場合、Expressway はファシリティ 18 (local2) を使用して、設定されているすべてのリモート syslog サーバに統計を公開します。 メッセージの重大度は情報通知ですが、メディア統計メッセージは重大度フィルタの設定に関係なく公開されます。

通話詳細記録のキャプチャ

サービスを有効にすると (デフォルトではオフ)、Expressway はオプションで CDR をキャプチャできます。 CDR は 7 日間ローカルに保存され、リモート ログを使用する場合は syslog メッセージとして公開することもできます。

CDR の設定方法

Expressway で CDR を設定するには:

手順


ステップ 1

[メンテナンス(Maintenance)] > [ログ記録(Logging)]に移動します。

ステップ 2

ログ オプション セクションで、 通話詳細レコード フィールドを必要なオプションに設定します。

  • サービスとログ - CDR はローカルに 7 日間保存され、その後削除されます。 レコードはローカル イベント ログからアクセスでき、外部ログが有効になっている場合は INFO メッセージとして syslog ホストにも送信されます。

  • サービスのみ - CDR はローカルに 7 日間保存され、その後削除されます。 レコードには Web ユーザ インターフェイスからはアクセスできません。 CDR は REST API 経由でのみ読み取ることができます。

  • オフ - CDR はローカルに記録されません。 これがデフォルト設定です。


CDR プロパティ

この表は、CDR に表示されるプロパティを定義します。

フィールド

定義

uuid

CDR エントリの ID。

サービス UUID

レコードがプロキシ、Lync B2BUA、または暗号化 B2BUA からのものであるかどうかを識別するために使用される ID。

アクティブ

通話がライブ通話か履歴通話か。

初期呼び出し

複数コンポーネントの B2BUA 呼び出し (B2BUA ホップを含む) に内部的に接続するために使用されます。

ライセンス

通話にライセンスが使用されたかどうかを表示します。

licensed_as_traversal

呼び出しでトラバーサル ライセンスが使用されたかどうかを表示します。

ステータス

200 OK メッセージは、通話が成功したことを示します。 呼び出しが失敗した場合はエラー メッセージが含まれます。

タグ

通話 ID。

box_call_serial_number

複数の通話を結び付けるために追加された追加 ID (たとえば、B2BUA 経由)。

開始時間

通話の日時。 タイムゾーンは、[システム(System)] > [時刻(Times)] > [タイムゾーン(Time Zone)]で設定でき、日付の形式は YYYY-MM-DD です。

終了時間

通話の終了時刻。

ソースエイリアス

発信者のエイリアス。

宛先エイリアス

呼び出し先のエイリアス。

aside_destination_alias

発信者のエイリアス (Lync Interop の場合は MS Lync クライアント)。

bside_destination_alias

呼び出し先 (または非 Lync クライアント) のエイリアス。

aside_request_uri

発信者の uri (Lync Interop の場合は MS Lync クライアント) のリクエスト uri。

bside_request_uri

呼び出し先 (または Lync 以外のクライアント) の要求 URI。

プロトコル

通話が SIP <-> SIP、SIP <-> H323、H323 <-> SIP、または H323 <-> H323 であったかどうかを表示します。

プロトコル概要

上記と同じですが、通話がマルチコンポーネント、DVO などであった場合などの追加情報が含まれる場合があります。

media_routed

通話中にメディアが送信されたかどうかを表示します (例: NAT/IWF/B2BUA)。

音声

通話が音声のみだったかどうかを表示します。

トラバーサルライセンストークン

コールフォーク/ブランチがメディアを取得したかどうかを示します (オーディオは 1 トークン、ビデオは 2 トークンに相当します)。*

非トラバーサルライセンストークン

コールフォーク/ブランチがメディアを取得する必要がなかったかどうかを示します (オーディオは 1 トークン、ビデオは 2 トークンに相当します)。*

切断理由

通常の通話終了やその他のエラーなど、通話終了の理由を示します (つまり、最後のステータス)。

詳細

メディア統計を含む通話の詳細を提供します。

最終更新タイムスタンプ

上記のいずれかのフィールドが最後に更新された時刻。

* 通話がセットアップされると、これらのエントリのうち 1 つだけがゼロ以外の値を持ちます (つまり、応答されたフォークまたはブランチのみ)。

CDR にアクセスするための API

CDR を収集するには、次の安全な REST API を使用できます。

  • get_all_records (最大 7 日間のすべてのレコードを返します)。

  • get_records_for_interval (指定された期間内のレコードを返します)。

  • get_records_for_filter (任意の組み合わせを使用して結果をフィルタリングします)。

  • get_all_csv_records (最大 7 日間のすべてのレコードを csv 形式で返します)。


重要


通話履歴はローカルに 7 日間のみ保存され、自動的に削除されます。


目的の API にアクセスするには、次の URL を使用します。

https://%3CExpressway_IP%3E/api/external/callusage/%3CAPI%3E

API の例

入力パラメータ

パラメータ

説明

fromtime

必須。 CDR レコードが要求される開始時刻。

形式: YYYY-MM-DD HH:MI:SS

totime

必須。 CDR レコードが要求される終了時刻。

形式: YYYY-MM-DD HH:MI:SS

  • http://<Expressway_IP>/api/external/callusage/
    get_records_for_interval?fromtime=<fromtime>&totime=<to_time>

    https://203.0.113.17/api/external/callusage/
    get_records_for_interval?fromtime=2014-05-09 2000:00:00&totime=
    2014-05-10 2000:00:00
  • http://<Expressway_IP>/api/external/callusage/
    get_records_for_filter?uuid=<uuid>&src_alias=<src_alias>
    &dest_alias=<dest_alias>&protocol=<protocol>

    https://203.0.113.17/api/external/callusage/
    get_records_for_filter?uuid=6e3b5a8a-346c-421b-aa2e-f4409c43a81a
    &src_alias=TC149-057-h323@domain.com&dest_alias=
    TC149-065-h323@domain.com&protocol=H323 <-> H323

    入力パラメータ

    パラメータ

    説明

    uuid

    レコードの一意の識別子。

    src_alias

    通話の発信元。

    dest_ alias

    通話の宛先ポイント。

    プロトコル

    通話に使用されたプロトコル (SIP、H323 など)。

  • http://%3CExpressway_IP%3E/api/external/callusage/get_all_csv_records

CDR 例

サンプル CDR

このサンプル CDR は、csv を除くすべての API に適用されます。

[{"initial_call": "false", "protocol": "SIP <-> SIP", "protocol_summary": "", "disconnect_reason": "200 OK", "licensed": "false", "tag": "b8d52a60-16a1-4bdb-be93-f5a675408811", "aside_request_uri": "", "box_call_serial_number": "22cd0e7d-c498-4068-9239-624038fe5130", "source_alias": "sip:10000005@10.196.4.82", "uuid": "800fe013-83f4-4094-a5e6-e2f9489912e2", "last_updated_timestamp": 1444725389, "details": "{\"Call\":{\"SerialNumber\": \"800fe013-83f4-4094-a5e6-e2f9489912e2\",\"BoxSerialNumber\": \"22cd0e7d-c498-4068-9239-624038fe5130\",\"Tag\": \"b8d52a60-16a1-4bdb-be93-f5a675408811\",\"State\": \"Disconnected\",\"StartTime\": \"2015-10-13 01:36:26.485636\",\"InitialCall\": \"False\",\"Licensed\": \"False\",\"LicensedAsTraversal\": \"False\",\"SourceAlias\": \"sip:10000005@10.196.4.82\",\"DestinationAlias\": \"sip:10000010@cucm-82\",\"ToLocalB2BUA\": \"False\",\"Audio\": \"False\",\"License\":{\"Traversal\": \"0\",\"NonTraversal\": \"0\",\"DemotedTraversal\": \"0\",\"CollaborationEdge\": \"0\",\"Cloud\": \"0\"},\"Duration\": \"3\",\"Legs\":[{\"Leg\":{\"Protocol\": \"SIP\",\"SIP\":{\"Address\": \"10.196.4.61:5073\",\"Transport\": \"TLS\",\"Aliases\":[{\"Alias\":{\"Type\": \"Url\",\"Origin\": \"Unknown\",\"Value\": \"sip:10000005@10.196.4.82\"}}]},\"Targets\":[{\"Target\":{\"Type\": \"Url\",\"Origin\": \"Unknown\",\"Value\": \"sip:10000010@10.196.4.116\"}}],\"BandwidthNode\": \"DefaultZone\",\"EncryptionType\": \"AES\",\"Cause\": \"200\",\"Reason\": \"OK\"}},{\"Leg\":{\"Protocol\": \"SIP\",\"SIP\":{\"Address\": \"10.196.4.71:7001\",\"Transport\": \"TLS\",\"Aliases\":[{\"Alias\":{\"Type\": \"Url\",\"Origin\": \"Unknown\",\"Value\": \"sip:10000010@cucm-82\"}}]},\"Source\":{\"Aliases\":[{\"Alias\":{\"Type\": \"Url\",\"Origin\": \"Unknown\",\"Value\": \"10000005@10.196.4.82\"}}]},\"BandwidthNode\": \"Traversal-zone\",\"EncryptionType\": \"AES\",\"Cause\": \"200\",\"Reason\": \"OK\"}}],\"Sessions\":[{\"Session\":{\"Status\": \"Completed\",\"MediaRouted\": \"False\",\"CallRouted\": \"True\",\"Participants\":{\"Leg\": \"1\",\"Leg\": \"2\",\"Incoming\":{\"Leg\": \"1\"},\"Outgoing\":{\"Leg\": \"2\"}}}}],\"EndTime\": \"2015-10-13 01:36:29.745651\"}}", "status": "Disconnected", "destination_alias": "sip:10000010@cucm-82", "licensed_as_traversal": "false", "service_uuid": "e6723fd0-5ca2-11e1-b86c-0800200c9a66", "start_time": "2015-10-13 01:36:26.485636", "traversal_license_tokens": 0, "bside_destination_alias": "", "active": "false", "media_routed": "false", "aside_destination_alias": "", "non_traversal_license_tokens": 0, "bside_request_uri": "", "end_time": "2015-10-13 01:36:29.745651", "audio": "false”}]

サンプル csv CDR

uuid,service_uuid,active,initial_call,licensed,licensed_as_traversal,
status,tag,box_call_serial_number,start_time,end_time,source_alias,
destination_alias,aside_destination_alias,bside_destination_alias,
aside_request_uri,bside_request_uri,protocol_summary,protocol,
media_routed,audio,traversal_license_tokens,non_traversal_license_tokens,
disconnect_reason,details,last_updated_timestamp
800fe013-83f4-4094-a5e6-e2f9489912e2,e6723fd0-5ca2-11e1-
b86c-0800200c9a66,false,false,false,false,Disconnected,b8d52a60-16a1-
4bdb-be93-f5a675408811,22cd0e7d-c498-4068-9239-624038fe5130,2015-10-
13 01:36:26.485636,2015-10-13

01:36:26.485636,2015-10-13 01:36:29.745651,sip:10000005@10.196.4.82,sip:10000010@cucm-82,,,,,,SIP <-> SIP,false,false,0,0,200 OK,"{""Call"":{""SerialNumber"": ""800fe013-83f4-4094-a5e6-e2f9489912e2"",""BoxSerialNumber"": ""22cd0e7d-c498-4068-9239-624038fe5130"",""Tag"": ""b8d52a60-16a1-4bdb-be93-f5a675408811"",""State"": ""Disconnected"",""StartTime"": ""2015-10-13 01:36:26.485636"",""InitialCall"": ""False"",""Licensed"": ""False"",""LicensedAsTraversal"": ""False"",""SourceAlias"": ""sip:10000005@10.196.4.82"",""DestinationAlias"": ""sip:10000010@cucm-82"",""ToLocalB2BUA"": ""False"",""Audio"": ""False"",""License"":{""Traversal"": ""0"",""NonTraversal"": ""0"",""DemotedTraversal"": ""0"",""CollaborationEdge"": ""0"",""Cloud"": ""0""},""Duration"": ""3"",""Legs"":[{""Leg"":{""Protocol"": ""SIP"",""SIP"":{""Address"": ""10.196.4.61:5073"",""Transport"": ""TLS"",""Aliases"":[{""Alias"":{""Type"": ""Url"",""Origin"": ""Unknown"",""Value"": ""sip:10000005@10.196.4.82""}}]},""Targets"":[{""Target"":{""Type"": ""Url"",""Origin"": ""Unknown"",""Value"": ""sip:10000010@10.196.4.116""}}],""BandwidthNode"": ""DefaultZone"",""EncryptionType"": ""AES"",""Cause"": ""200"",""Reason"": ""OK""}},{""Leg"":{""Protocol"": ""SIP"",""SIP"":{""Address"": ""10.196.4.71:7001"",""Transport"": ""TLS"",""Aliases"":[{""Alias"":{""Type"": ""Url"",""Origin"": ""Unknown"",""Value"": ""sip:10000010@cucm-82""}}]},""Source"":{""Aliases"":[{""Alias"":{""Type"": ""Url"",""Origin"": ""Unknown"",""Value"": ""10000005@10.196.4.82""}}]},""BandwidthNode"": ""Traversal-zone"",""EncryptionType"": ""AES"",""Cause"": ""200"",""Reason"": ""OK""}}],""Sessions"":[{""Session"":{""Status"": ""Completed"",""MediaRouted"": ""False"",""CallRouted"": ""True"",""Participants"":{""Leg"": ""1"",""Leg"": ""2"",""Incoming"":{""Leg"": ""1""},""Outgoing"":{""Leg"": ""2""}}}}],""EndTime"": ""2015-10-13 01:36:29.745651""}}",1444725389

アラームベースの電子メール通知を構成する

Expressway は、アラームの重大度とオプションでアラーム ID に基づいて電子メールベースの通知をサポートします。 設定されている場合、システムでアラームが生成されると、設定された宛先アドレスに電子メール通知が送信されます。 アラームの重大度分類ごとに異なる電子メール ID を定義して、通知の緊急性を区別することができます。 同じ重大度のアラームに対して複数の電子メール ID を設定できます。

X12.6.2 からは、特定のアラーム ID の通知を特定の電子メール ID に送信したり、特定のアラーム ID の通知を無効にしたりすることもできます。


重要


電子メール ID の最大許容長は 256 文字です。


この機能は、カリ法を実装したい米国に拠点を置く顧客にも利用可能です。 Expressway 経由で直接 9-1-1 にダイヤルするための基準を満たす 9-1-1 通話が行われると、重大度緊急 のアラームが生成され、(設定されている場合) アラーム重大度緊急に対して設定されたメール ID に通知が送信されます 。


(注)  


暗黙的または明示的な接続用に、Simple Mail Transfer Protocol (SMTP) サーバを構成できます。 2 つの接続タイプの違いは次のとおりです。

  • 明示モード - クライアントは最初に SMTP サーバに接続します。 その後、サーバーは TLS/SSL 暗号化の有効化を明示的に要求します。 デフォルトのポートは 25 と 587 です。

  • 暗黙モード - クライアントは SMTP サーバに接続します。 チャネルを確立するとすぐに、サーバーは TLS/SSL 暗号化を 暗黙的に有効にします。 デフォルトの TCP ポートは 465 です。


事前準備

  • 電子メールを送信するための接続を確立するには、SMTP サーバの詳細を提供する必要があります。

  • Expressway は、SMTP サーバとの TLS 接続のみをサポートします。

  • SMTP サーバは、Expressway から直接または SMTP プロキシを使用してアクセスできる必要があります。 SMTP に HTTP プロキシを使用することはサポートされていません。

  • メールを送信する前に、送信元の電子メールとパスワードが SMTP サーバで検証されます。

  • X12.7 以降、Expressway では SMTP サービスが TLS 1.2 証明書ベースの検証を使用する必要があります。

    • クライアントが SMTP サーバ証明書を検証する際、その IP アドレスおよび/または完全修飾ドメイン名 (FQDN) が証明書の共通名 (CN)/サブジェクト別名 (SAN) に含まれている必要があります。

    • SMTP サーバ証明書の発行元を、Expressway の信頼できる証明機関 (CA) 証明書リスト (メンテナンス > セキュリティ > 信頼できる CA 証明書) にインポートする必要があります。

アラームベースの電子メール通知を構成するプロセス

手順


ステップ 1

[メンテナンス(Maintenance)] > [メール通知(Email Notifications)]に移動します。

ステップ 2

[電子メール通知] ドロップダウン リストで、 [オン]を選択します。

ステップ 3

ソース構成 セクションで、次の情報を入力します。

  • SMTP 認証を有効にする - SMTP サーバ認証はデフォルトで有効( オン 状態)になっています。 ドロップダウン リストを使用すると、 オンオフ の状態を切り替えることができます。 ユーザの SMTP サーバが認証を必要としない場合にのみ、これを オフ にする必要があります。 ほとんどのユーザはそれを必要とします。

  • 設定する宛先アドレスに通知を送信する送信元メールアドレス。

  • 通知の送信に使用する SMTP サーバの IP アドレスまたは FQDN。

  • [重大度ごとの宛先メール構成] セクションで、特定の重大度のアラームに関する通知を受信する電子メール アドレスを入力します。

  • [保存(Save)] をクリックします。

図 1. 電子メール通知の設定例

通知をカスタマイズする方法 - 無効にするかメールアドレスに送信する

オプションで、このプロセスを使用して、特定のアラーム ID の通知を特定の電子メール アドレスに送信したり、特定のアラーム ID の通知を完全に無効にしたりすることができます。 たとえば、しきい値警告アラームを指定された個人に送信したり、不要なアラームからの通知を停止したりします。

手順


ステップ 1

[メール通知(Email notifications)] ページの [カスタム通知(Custom notifications)] セクションに移動します。 ここでは、既存のカスタム通知を表示、編集、削除したり、新しい通知を追加したりできます。

ステップ 2

カスタマイズされた通知を作成するには:

  1. [Add(追加)] をクリックします。  

  2. 操作するアラーム ID を選択します。

  3. 通知 ドロップダウンで カスタム を選択して、選択したアラームの電子メールの送信先を定義します。このアラームに関して電子メールを送信しない場合は 無効 を選択します。

  4. 「カスタム」を選択した場合は、 「電子メール」 フィールドに、選択したアラーム通知を送信する宛先の電子メール アドレスを入力します。

  5. [保存(Save)] をクリックします。

  6. アラーム通知が意図したとおりに機能するかどうかをテストするには:

    1. [アラームの選択] ドロップダウンからテストするアラームを選択します。

    2. [今すぐテスト] ボタンをクリックします。

    3. テストから受信した電子メール通知が期待どおりであることを確認します。


メール通知の数を減らす

この改善の目的は、何らかの理由で複数のアラームが短期間に発生した場合に、管理者にメールをスパム送信しないようにすることです。

X14.2 以降、1 時間以内に同じアラームが 2 回以上発生した場合、電子メールは 1 回だけ送信されます。 同じアラームが解除されてから再度発生した場合、経過時間に関係なく、メールが送信されます。 当然、これは管理者がデバイスでメール通知を受信するように構成している場合にのみ適用されます。


(注)  


過去 1 時間以内に特定のアラームに関する電子メールがすでに送信されている場合、システムは電子メール通知を繰り返し送信してはなりません。


ここにいくつかの例を示します。

  1. 例 1

    1. ID 15000 のアラームが 14:00 に発生します。

    2. 電子メール通知が設定され、ID 15000 のアラームに対して電子メールが送信されます。

    3. 同じアラーム (ID 15000) が 14:55 に発生しましたが、1 時間経過していないため電子メール通知は送信されません。 ただし、15:01 に同じアラームが発生した場合は、電子メール通知が送信されます。

  2. 例 2

    1. ID 15000 のアラームが 14:00 に発生します。

    2. 電子メール通知が設定され、ID 15000 のアラームに対して電子メールが送信されます。

    3. 14:05 に同じ警報が解除されます。

    4. ID 15000 のアラームが 14:10 に再度発生します。

    5. ID 15000 のアラームの電子メール通知が再度送信されます。

システム メトリック コレクション

システム メトリック コレクションは、システム パフォーマンス統計を公開してパフォーマンスのリモート監視を可能にする Expressway の機能です。 Expressway は、ハードウェア、OS、アプリケーションのパフォーマンスに関する統計情報を収集し、その統計をデータを集約するリモート ホスト (通常はデータ分析サーバ) に公開します。 この機能は、Web インターフェイスまたはコマンド ラインを通じて Expressway で設定できます。


(注)  


1 つのピアからの構成はクラスター全体に適用されるため、クラスターを監視している場合は、プライマリ ピアでシステム メトリック収集を構成することをお勧めします。


リモート サーバでも構成が必要です。 Collectd デーモンはサーバ上で実行されている必要があり、collectd ネットワーク プラグインはクライアントが参照できるアドレスをリッスンするように設定されている必要があります。 構成の詳細は監視環境によって異なり、このガイドの範囲外となります。

収集したデータの使用方法

CirconusGraphite などのツールを使用して、Expressway から収集されたデータに基づいてグラフを生成し、統計を集計し、パフォーマンスを分析できます。 また、傾向を視覚化したり、潜在的な問題を予測したりするためにも使用できます。 視覚化できるメトリックは次のとおりです。

  • ゾーン別およびシステム別のアクティブコール数

  • 主要なプロセスメトリック: システム CPU、ユーザ CPU、および主要なプロセスのメモリ使用量

  • アラーム

システムメトリック収集を設定する方法(収集済み)

Expressway で設定する

この手順を使用して、Web ユーザ インターフェイスからオプションで Expressway を設定し、統計情報を収集して指定されたサーバに公開します。

(注)  


CLI から collectd をオンにするには、システムメトリックスサーバーの IP アドレスが必要です (ウェブ ユーザー インターフェイスの場合と同様の動作)。


手順

ステップ 1

Expressway にログオンし、 [メンテナンス] > [ログ記録] に移動します

ステップ 2

システム メトリック収集オンに切り替えます

ステップ 3

コレクション サーバのアドレスを入力します

リモート サーバを識別するには、IP アドレス、ホスト名、または FQDN を使用できます。

ステップ 4

収集サーバがデフォルト以外のポートでリッスンしている場合は、必要に応じてデフォルトの 収集サーバ ポート (リッスン ポート) を変更します。

ステップ 5

必要に応じて、デフォルトの 収集間隔 を変更します(ポリシーで、デフォルトの間隔である 60 秒よりも細かいメトリックが必要な場合は)。

ステップ 6

[保存(Save)] をクリックします。


Collectd を設定するための CLI コマンドの例

CLI を使用する場合は、関連するコマンドの例を以下に示します。

表 2. Collectd を設定するための CLI コマンド

コマンドの機能

コマンド例

メトリック収集のオン/オフを切り替える

xconfig ログ SystemMetrics モード: オン

サーバアドレスを指定する

xconfig ログ SystemMetrics ネットワークアドレス: アドレス

リスニングポートを指定する

xconfig ログ SystemMetrics ネットワークポート: 25826

収集間隔を指定する

xconfig ログ SystemMetrics 間隔: 60

システム メトリックス設定の読み取り

xstatus システムメトリック

リモートサーバを構成する

環境内でデータ分析に使用するサーバの選択と構成については、このドキュメントでは説明しません。 Circonus と Graphite は、collectd 情報を処理できるアプリケーションの例です。 分析ツールは collectd デーモンからのデータの受信をサポートしている必要があります。 このデーモンは Expressway 上で実行され、collectd ネットワーク プラグインを使用してメトリックを分析サーバにプッシュします。

ネットワーク プラグインは、データのカプセル化のために collectd バイナリ プロトコル を実装します。 分析サーバはこのデータを解析して表示できる必要があります。 分析サーバには、データの収集方法と表示方法を構成するための独自の UI が用意されている可能性があります。これは、collectd または代替ソフトウェアに基づいている可能性があります。

分析サーバーで collectd を使用している場合は、collectd.conf ファイルを変更して、サーバーが次のように動作するようにします。

  • Collectd クライアント (Expressway など) からのデータをリッスンします。 ネットワーク プラグインを有効にし、サーバの IP アドレスを使用して listen ブロックを構成する必要があります。 次に例を示します。

    <Plugin "network">
                   Listen "198.51.100.15"
            </Plugin>
  • 受信したデータを人間が読める形式 (CSV ファイルなど) で保存します。 ファイルを書き込む場所を指定するには、csv プラグインを有効にする必要があります。 次に例を示します。

    <Plugin "csv">
                    DataDir "/var/lib/collectd/csv"
                    StoreRates true
            </Plugin>
関連資料

トラブルシューティング

Expressway がデータを送信しているかどうかを確認するには、Expressway から TCP ダンプを設定し、データ分析サーバのアドレスに送信されたパケットを確認します。 [メンテナンス] > [診断] > [診断ログ] に移動し、 [ログ記録中に tcpdump を実行する] をオンにして、ログ記録を開始します。

Expressway から収集されたメトリクス

次のハードウェア統計が監視されます。

  • aggregation-cpu-sum

  • aggregation-cpu-average

  • システム内の各コアのコアあたりの CPU 使用率

  • df

  • ディスク

  • load

  • protocols-Tcp

  • protocols-Udp

  • スワップ

  • ユーザ(Users)

  • メモリ

  • アップタイム(Uptime)

  • プロセス

次のアプリケーション データは、collectd のカスタム exec-app プラグインによって監視されます。

  • gauge-active_alarms は、この Expressway 上のアクティブなアラームの数です。

  • gauge-active_calls は、この Expressway で処理されている通話の数です。

  • gauge-<service name> は各システムサービスのステータスです。

  • gauge-<zone name>_ActiveCalls は、指定されたゾーン内のアクティブな通話をカウントします。

  • ゲージ-<zone name>_BandwidthAllocated は、指定されたゾーンに割り当てられた合計帯域幅を測定します。

  • gauge-<zone name>_BandwidthLimit

これらの各メトリックは、自由形式のデータを許可する collectd GAUGE データ ソース タイプを使用します。 収集サーバーでは、完全な collectd 値の名前が表示されます、例: collectdHostnamecollectd.exec-app.gauge-active_calls


(注)  


ゾーン名はユーザーが設定できるため、collectd メトリックの命名スキーマと競合する可能性があります。 収集サーバがスキーマを適用している場合、一部のゾーンからのメトリックが受け入れられない可能性があります。


収集サーバに送信されるデータ

ネットワーク プラグインは、 collectd バイナリ プロトコル を使用して、監視対象のハードウェア リソースとソフトウェア プロセスを表す数値、文字列、および値のデータをカプセル化します。 プラグインは、デフォルトで UDP 25826 を使用して、間隔ごとに 1 回メトリック データ パケットを分析サーバにプッシュします。 分析サーバはデータを解析し、人間が読める形式で提示します。

分析サーバが collectd ネットワーク プラグインと csv プラグインを使用している場合、メトリックはメトリック名とタイムスタンプを使用してファイル名が作成され、小さな CSV ファイルとして保存されます。 例えば、 gauge-H323-2015-05-21

collectd プラグイン

これらの collectd プラグインは Expressway に実装されています。

プラグイン名

説明

集約

CPU 値をカウンター aggregation_cpu_sum と aggregation_cpu_averageに集計します。

CPU

プロセッサ情報。 生の情報は aggregation_cpu_average と aggregation_cpu_sumに集計されます。

DF

ファイルシステム情報については、 collectd Wiki の DF の説明を参照してください。

ディスク

ハードディスクのパフォーマンス。 collectd Wiki のディスクの説明を参照してください。

Exec-app

通話、アラーム、ゾーン、およびサービスに関する特定の Expressway 情報を返す exec のカスタマイズされたバージョン。

  • gauge-active_alarms

    → Expressway上のアクティブなアラームの数

  • gauge-active_calls

    → Expressway で処理されたアクティブな通話の数

  • gauge-B2BUA

    → B2BUA サービスのステータス

  • gauge-callusagemanager

    → CDR に使用されているサービスのステータス

  • gauge-<zone>_ActiveCalls

    → 指定されたゾーン内のアクティブな通話をカウントします

  • gauge-<zone>_BandwidthAllocated

    → 指定されたゾーンに割り当てられた合計帯域幅を測定します

  • gauge-c_mgmt

    → ManagementConnector サービス

  • gauge-collectd

    → Collectd サービスのステータス

  • gauge-edgeconfigprovisioning

    → MRA で利用されているプロビジョニングサービスのステータス

  • gauge-fail2ban

    → 自動保護機能で使用される fail2ban サービスのステータス

  • gauge-findmed

    → TMS プロビジョニングで使用される FindMe サービスのステータス

実行アプリ

  • gauge-H323

    → H.323 サービスハンドラのステータス

  • gauge-http

    → HTTP リクエストから HTTPS へのリダイレクトのステータス

  • ゲージ-https

    → Web インターフェースを有効化/無効化

  • ゲージインポートコントロール

    → TMS プロビジョニングで使用されるサービスのステータス

  • ゲージジャバード

    → XMPP で使用されているサービスのステータス

  • gauge-phonebookserver

    → Status of Phonebook service

  • gauge-portforwarding

    → Traffic Server(ATS)で使用しているサービスの状態

  • gauge-provisioningd

    → TMS プロビジョニングで使用されるサービスのステータス

  • gauge-provisioningserver

    → プロビジョニングサーバのサービス状態

  • gauge-proxy-registrationd

    → Exp-E 代理登録カウンター

  • gauge-restmanager

    → RESTAPI サービスのステータス

  • gauge-samlverifier

    → SAML SSO で使用されるサービスのステータス

  • gauge-SIP

    → SIP サービスハンドラーのステータス

  • gauge-snmpd

    → SNMP サービスのステータス

  • gauge-sshd

    → SSH サービスのステータス

Exec-app

  • gauge-sshdpfwd

    → MRA/WebRTC などで利用される SSH ポートフォワーディング サービスのステータス

  • gauge-sslh

    → WebRTC と TURN で利用されているサービスのステータス

  • gauge-trafficserver

    → MRA/WebRTC などで利用されている ATS サービスの状況

  • gauge-winbindd

    → Expressway 内部サービス、サービスのステータス

負荷

タスク キューに基づくシステム負荷。

メモリ

メモリ統計。

ネットワーク

リモート アドレスへの公開を有効にします。 プラグインは、データのカプセル化のために collectd バイナリ プロトコル を実装します。 リモート サーバには適切な解析ツールが必要です。

プロトコル(Protocols)

Expressway で使用されるプロトコルの構成可能なサブセット。

プロセス

システムプロセスをカウントし、状態 (実行中、スリープ中、ゾンビなど) ごとにグループ化します。 特定のプロセスに関する詳細な統計も収集します。 プラグインは次のプロセスを詳細に監視します。

  • アプリケーション

    → メイン APP プロセスのステータス

  • bramble

    → 非推奨。プレゼンス通知に使用

  • 資格情報マネージャーサーバメイン

    → 認証目的で使用されるプロセスのステータス

  • cvs_main

    → 証明書検証プロセスのステータス

  • erlang-beam

    → 内部 CDB プロセスステータス

  • erlang-epmd

    → 内部 CDB プロセスステータス

  • httpd

    → HTTP デーモンプロセスの状態

プロセス

  • httpserver

    → HTTP サーバのプロセスステータス

  • ivy

    → 内部 B2BUA プロセスステータス

  • licensemanagerservermain

    → ライセンス取得プロセスのステータス

  • managementconnectormain

    → 管理コネクタプロセスのステータス

  • 管理フレームワーク

    → 内部プロセスステータス

  • openssl2nss

    → SSL プロセスのステータス。

  • ポリシーサーバメイン

    → 通話ルーティングなどに使用されるポリシー サービスのステータス。

  • sshdpfwd

    → SSH ポート転送プロセスのステータス(MRA、WebRTC で使用)

  • syslog-ng

    → Syslog プロセスのステータス

  • traffic_server

    → MRA、WebRTC で使用される ATS プロセスのステータス

  • XCP

    → JabberD を使用している内部プロセスのステータス

Statsd

特定の Expressway 情報を返すカスタマイズされたバージョン。 たとえば、ICE の使用状況。

  • gauge-ICEPassthroughMetrics.b2buacalls

    → B2BUA コールが接続されました

  • gauge-ICEPassthroughMetrics.candidatesofferedmissingiceconfig

    → B2BUA コールは接続されていますが、ICE パススルーの入力/出力ゾーンが適切に構成されていません。 一方または両方のエンドポイントが ICE を提供している場合は、調査が必要な設定の問題がある可能性を示すためにメトリックを記録します。

  • ゲージ-ICEPassthroughMetrics.failedicenegotiationcalls

    → Expressway は ICE パススルー用に設定されており、エンドポイントは ICE のネゴシエートを試行する信号を送信しましたが、一方または両方がリモート候補を送信できず、パススルー ICE のネゴシエートに失敗しました。

  • ゲージ-ICEPassthroughMetrics.hosthostcalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。ホスト候補とホスト候補。

  • gauge-ICEPassthroughMetrics.hostrelaycalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。ホスト候補とリレー候補。

  • ゲージ-ICEPassthroughMetrics.hostsrvrflxcalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。ホスト候補とサーバーリフレクシブ候補。

  • ゲージ-ICEPassthroughMetrics.icecalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。

  • gauge-ICEPassthroughMetrics.icecandidatecalls

    → 一方または両方が ICE 候補を提供しました。

  • gauge-ICEPassthroughMetrics.iceconfiguredcalls

    → B2BUA コールが接続され、両側で ICE パススルーが適切に構成されました。

  • gauge-ICEPassthroughMetrics.noicecandidatesoffered

    → どちらの側も ICE 候補を提示しませんでした。

Statsd

  • gauge-ICEPassthroughMetrics.onepartyicecandidatecalls

    → 一方または両方が ICE 候補を提供しました。

  • ゲージ-ICEPassthroughMetrics.relayrelaycalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。リレー候補とリレー候補。

  • ゲージ-ICEPassthroughMetrics.srvrflxrelaycalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。サーバーリフレクシブ候補とリレー候補。

  • ゲージ-ICEPassthroughMetrics.srvrflxsrvrflxcalls

    → どちら側にもリモート候補がおり、どちら側にも選択されたローカル候補タイプがあります。 これは ICE パススルー呼び出しです。サーバーリフレクシブ候補とサーバーリフレクシブ候補。

スワップ

ディスクに書き込まれたシステム メモリの量。

アップタイム(Uptime)

システムの稼働時間を追跡し、特定の期間の平均実行時間や最大稼働時間などのカウンターを提供します。 collectd Wiki の稼働時間の説明を参照してください

ユーザ(Users)

現在ログインしているユーザの数。