予測VoIPトランジットモニタリング

注釈

システムでVoIPを使用していない場合、またはこれが主な焦点ではない場合でも、予測を使用して監視する方法に関心がある場合があります。 このタスクはその使用例の鮮明な例であるため、監視方法は中継VoIPのアプリケーションの例と見なされます。 標準的な方法では、問題は解決されず、予測方法を使用した監視は比較的簡単です。 以下に書かれていることは理論的な研究ではなく、現在数か月間実際に使用されています。

はじめに

ITインフラストラクチャの最新のアクティブ監視システムのほとんどは、同じ原則を使用しています。 監視システムは何らかの方法で機器またはソフトウェアに問い合わせ、結果を取得し、テンプレートまたは所定の最大許容値と比較します。



たとえば、SMTPサーバーの可用性を判断するには、監視システムはTCPポート25でサーバーに接続し、文字列「helo my.monitoring.com」を送信して応答として文字列を受信し、SMTPサーバーから切断する必要があります。 次に、先頭のサーバー応答行に数字2で始まる3桁のコードが含まれているかどうかを確認します。含まれている場合、サーバーは稼働しています。稼働していない場合、システムはアラートを出します。 これは実際にはパターンマッチング方法です。

別の例は、プロセッサの負荷を確認することです。 監視システムは、多くの場合SNMPによってサーバーをポーリングし、現在のプロセッサ負荷の値を受け取り、それを最大許容最大値（80など）と比較します。プロセッサの負荷が80％を超える場合、監視システムは警告を発する必要があります。 これは、問い合わせられた値の最大許容値をチェックする方法です。

いずれにせよ、監視システムを構成するプロセスでは、機器またはソフトウェアの正常な動作と見なされるもの、誤動作、または近い将来誤動作を引き起こす可能性がある状況について明確な基準を設定する必要があります。

この監視原理は、ほとんどの場合に機能します。 ただし、誤動作と見なされるものと正常な動作であるものの基準を設定することは、困難すぎるか、まったく不可能です。

標準的な方法では解決できない監視タスクの1つは、中継VoIPの定量的および定性的パラメータの監視です。 予測に基づく監視システムの仕組みを説明する前に、中継VoIPプロバイダーの仕組みを説明する必要があります。

VoIPトランジットの仕組み

他のビジネスと同様に、中継VoIPには多くのニュアンスがありますが、それらは説明するには長すぎて利用できません。 したがって、説明は、指で言うように、原始レベルになります。

この問題は、エンドユーザーレベル（電話をかけている人ではなく、VoIPサービスを提供する企業のレベル）で考慮する必要はありません。 この観点から、2社がサービスの提供に関与しています。 最初の企業AはVoIPトラフィックの消費者であり、クライアントは通話を開始し、2番目の企業Bは通話を終了するサプライヤです。

通常、サプライヤは1つ以上の宛先を提供します。 宛先は、特定の価格で販売される電話コードのグループです。 目的地の例：ロシアモバイルビーライン、スペインマドリード、カザフスタンアルマトイ。 現在、世界には約1300の目的地があります。

通常、消費者企業はすべての方向を顧客に提供します-これはA-to-Zと呼ばれます。 したがって、消費者は、さまざまな方向の多くのサプライヤと契約を結び、その後、方向をさまざまなサプライヤにルーティングする必要があります。 これは非常に困難です。

一方、サプライヤーは可能な限り多くのトラフィックを集めることに関心があります。 ただし、これには多数の契約と潜在的な財務リスクが伴います。たとえば、多くの企業の1つ以上が消費したトラフィックに対して料金を支払わない場合があります。

したがって、サプライヤーと消費者の両方にとって、中継会社である中継会社と協力することは有益です。中継会社は、厳密にはVoIPトラフィック自体を生成および提供せず、それらを接続します。

実際、サプライヤーと消費者の間の相互作用の多くのつながりのある構造の代わりに、私たちはスター構造を取得します。その中心は一時的なものです。











ほとんどの場合、一時的なプロキシはそれ自体でアラームと音声の両方をプロキシします。

説明した監視システムが展開されている会社には、約250のサプライヤと250の消費者がいます。 同社はAからZ方向を提供しており、合計約1500の方向名が請求書に登録されています。

トランジット会社にとって、消費者、サプライヤー、目的地の仕組みを監視することは非常に重要です。 そして、これを各消費者、サプライヤー、方向性の文脈で行うこと。 短期的には、障害が発生した場合、トランジェントはマージンを失います。 長期的には、誰もが高レベルのサービスに関心を持っています。

さて、トランジェントの動作の概要を概説した後、監視システムのタスクを定式化します。

監視システムの目的

VoIPの監視に関しては、通常、ジッタ、遅延、パケット損失、MOSなどのパラメータを監視することを意味します。 シスコには強力な技術があり、4年前にすでにそれについて書いています。

ただし、中継VoIPオペレーターの場合、同様のテクノロジーの使用と同様のメトリックの分析は適切ではありません。 当然、トランジェントはパケット損失の割合と、パートナーに対するジッターと遅延の両方を分析しますが、これは障害が検出された後にのみ行います。 障害自体は、次のような他のパラメーターを分析することで検出されます。

•合計分数。

•コールの総数。

•ASR（Answer Seizure Ratio）は、コールの総数に対する非ゼロ期間の成功したコールの比率として定義されます。

•ACD（平均通話時間）は、平均通話時間です。

最初の2つのパラメーターは定量的であり、最後の2つは定性的です。 これらのパラメーターが分析される理由は長い間説明できますが、これは記事の範囲を超えています。

また、通常、監視システムは何らかの方法でリモートデバイスに問い合わせます。説明した監視システムはCDR（通話詳細レコード）をデータソースとして使用します。 CDRファイルはテキストであり、各行には1回の呼び出しまたは呼び出しの試行に関する情報が含まれています。 特定のコールの詳細レベルは異なる場合があり、すべての機器がCDRを書き込むかどうかに依存します。 高品質のCDRには約100個のパラメーターを含めることができます。これには、誰が電話をかけたか、どこで電話をかけたか、通話時間、通話完了コードだけでなく、VoIPに関しては、ジッター、コーデック、パケット損失などのパラメーターも含まれます、MOSなど。

監視システムが潜在的な障害をチェックする必要がある合計値の数を計算してみましょう。 250のサプライヤー、250の消費者、1,500の方向のパラメーターを分析する必要があります。 サプライヤ、コンシューマ、および方向ごとに4つの数量を確認する必要があるため、次のようになります。



250 * 4 + 250 * 4 + 1500 * 4 = 8000



ただし、ここでのポイントは、チェックする必要がある数量が比較的多いことではありません。 実際には、各パートナーと各方向は独自の方法で一意であり、さらに、各パートナーと方向の作業パラメーターは時刻に大きく依存します。

根拠がないようにするために、実際の交通データに基づいて構築されたいくつかの例を考えてみましょう。







グラフは、同じ地理的領域にある2つのパートナーのトラフィックの分布を分単位で示しています。 グラフの値は、パートナーが15分間隔で消費した分数です。 8〜22時間後の最初のパートナーの消費量が15分で約2500分である場合、2番目のパートナーの消費量は500以下です。最初のパートナーが8〜18時間で1500分未満または4000分以上消費し始めた場合、障害が発生したため、原因を分析する必要があります。 2番目のパートナーの場合、これはそうではありません;彼にとっては、潜在的な障害に対する他の基準があります。

別の例。







グラフは、コールのトラフィックの分布を示しています。 グラフの値は、トラフィック量が同程度の3つの異なる方向で行われた15分間のコール数です。 最初の2つの方向は地理的に近い地域にあり、3番目の方向は地理的に離れています。つまり、この国のタイムゾーンは異なります。

トラフィックを監視するための基準を設定するのが非常に難しいことは明らかです。 標準的な方法による実際のタスクは解決されていません。

予測方法なぜ機能するのか

各方向とパートナーは独自の方法でユニークであるという事実にもかかわらず、仕事の定量的および定性的パラメーターを予測することができます。 たとえば、3日間連続する方向の1つのスケジュールを検討します。わかりやすくするために、同じチャートに毎日異なる色を描画します。







同じ方法で、4日目に宛先に通話が配信されると想定するのは論理的です。 実際、方向がどのように振る舞うべきかを予測することができ、方向が予測どおりに振る舞わない場合は、潜在的な障害についてアラートを出します。

したがって、予測可能なソフトウェアを作成することで問題を解決できます。 現在、多くの予測方法が開発されています。 ただし、予測方法の1つをプログラムで実装するのはかなり難しく、完成品を使用する方が収益性が高くなります。

予測機能は非常に有名で人気のある製品であるrrdtoolに組み込まれており、これはGPLの下で配布されています。

rrdtoolに実装された予測方法

私は10年以上にわたってrrdtoolを積極的に使用してきましたが、最近まで、予測機能が組み込まれているとは考えていませんでした。 VoIPモニタリングに予測を使用するというアイデアは、 Jake D. Brutlagの「ネットワークモニタリングの時系列における異常な動作の検出」を読んだ後に思いつきました。著者に感謝の意を表します。

予測方法は、 クリケット監視システムで使用されます。 ただし、このソフトウェア製品は長い間開発されていません。さらに、クリケットはSNMPを介してデバイスをポーリングし、前述のようにVoIPトラフィックを監視するには、CDRを処理する必要があります。 rrdtoolに実装された予測を使用する監視システムはいくつかありますが、どれも適切ではなかったため、監視システムをゼロから作成する必要がありました。

率直に言って、当初はこれが機能するかどうかは確実ではありませんでした。 そのため、最初はIPトラフィックで監視方法をテストしました。 最も単純なスクリプトは、インターフェイスカウンタの問い合わせであり、受信した値はrrdデータベースを形成する特別な方法で埋められました。 予測方法がいくつかのグローバルな失敗を明らかにした後、方法が正しく機能することが最終的に明らかになりました。

Jake D. Brutlagの記事には、予測に使用される公式と多くの有用な情報がありますが、詳細や技術的な詳細には触れずに、これがどのように機能するかについて少し説明します。

rrdtoolが予測を開始するには、特定の方法でrrdデータベースを作成する必要があります。 データベースを作成するとき、シーズンの期間など、予測に影響を与えるさまざまな要因などのパラメーターが予測に設定されます。 次に、rrdデータベースに測定値を入力するだけで、rrdtoolは潜在的な障害の予測と特定を行います。

rrdtoolでは、Holt-Winters予測方法が実装され、さらに、予測値に対する測定量の異常を検出するメカニズムが実装されています。

ウィキペディアによると、異常は標準からの逸脱です。 ミス、違反、エラー（緯度の「回避、除去、注意散漫」、緯度のaberrareから（緯度のab-「from」+ lat。errare「さまよう、間違える」）-「去る、逸脱する」）。

写真を見れば、収差とは何かを理解できます。







Holt-Winters予測では、季節の概念が使用されます。 IPおよびVoIPトラフィックの場合、シーズンは通常1日です。 ただし、任意の期間のシーズンを指定できます。

Holt-Wintersメソッドは、2つの値を使用して予測をすぐに計算します。最初の値は測定値自体の予測であり、2番目の値は測定値の予測値からの許容偏差の予測（偏差）です。 実際、2番目の値は、実際の値からの予測の許容偏差のコリドーの幅に影響します。

もう1つの重要な事実として、Holt-Winters法は短期予測法です。つまり、予測はシーズン全体ではすぐに作成されません（この場合、1日ではなくすぐに作成されません）。 実際、数量の新しい測定ごとに、次の値の予測が行われ、その計算のために、以前の測定の履歴と最後の測定値が使用されます。 変化する可能性のある係数があります。これは、前の履歴と最後の測定が予測に影響を与える程度に依存します。

収差は、フローティングウィンドウを使用して、いくつかの測定に基づいて検出されます。 つまり、測定値が許容値の範囲を超えてノックアウトされた場合、これが常に収差の出現につながるとは限りません。 デフォルトでは、最後の9つの測定値のうち7つが許容値の予測範囲から外れると、異常が発生します。 ただし、パラメーターを変更して、たとえば、ウィンドウの長さを3に、ウィンドウのミス数を2に設定すると、最後の3つの次元のうち2つがコリドーからノックアウトされたときに異常が発生します。

rrdtoolを使用したことがある場合、このチャート作成ツールがどれほど強力であるかを知っています。 グラフの最後の3つの段落について説明します。 このようなグラフは、説明されている監視システムに組み込まれています。







2番目の太さの青い線は、パートナーが消費した分数の実際の測定値です。 灰色の領域-ちょうど1日前の実際の値。 ピンクの線は予報です。 赤と緑の線は、許容値のコリドーの上下の境界線を示しています。 負の値の領域の黒い線は、予測値からの許容偏差の予測（偏差）です。 実際、黒い線は廊下の幅を設定します。 デフォルトでは、廊下の下限と上限（赤と緑の線で表示）は、予測値と偏差の予測値の下限の上限と減算を加算して得られます。収差は金色で示されています。

収差を詳しく検討してください。







値がコリドーからノックアウトされた後しばらくして異常が発生したことがわかります。この場合、rrdデータベースはデフォルトでウィンドウの長さが9に設定され、非ウィンドウヒットの数は7に設定されています。

収差をグラフに表示するのは簡単ですが、監視システム自体は、これを通知するために、収差の発生の瞬間をプログラムで検出する必要があります。 プログラムによる異常の発生の検出も、rrdtoolを使用して簡単に実装できます。

Rrdtoolは図面の形でグラフを作成します。図のグラフ表示領域には一定の座標があります。そのため、マウスボタンをクリックするだけで時間軸に沿ってグラフをスケーリングする手順やクラスを書くことは難しくありません。 実際にrrdtoolのWEB GUIであるcactiを使用すると、javaスクリプトによってどのように実装されるかを確認できます。

説明されている監視システムでは、システムの中核はrrdtoolです。 ただし、潜在的な障害の予測と特定だけでは十分ではありません。 システムが障害アラートを発行したときは、データにすばやくアクセスして状況を分析することが重要です。 したがって、VoIPトラフィックの分析のための追加機能を実装します。 監視システムの追加機能を簡単に説明するために、一般的な用語で監視システムの配置方法を検討しましょう。

監視システムの仕組み

監視システムを次の図に示します。



15分ごとに新しいCDRファイルが処理されます。 ファイルには、最大150,000のエントリを含めることができます。 データは解析され、postgresqlデータベースに入力されます。このデータベースには生のCDRが28日間保存されます。 CDRデータベースには1日に最大1,000万件のレコードが蓄積され、合計で約2億5000万件になります。 当然、パートナーおよび指示のコンテキストで任意の期間の情報取得の要求のパフォーマンスを向上させるために、レポートを生成するのに十分な要約情報を含む追加のテーブルも記入されます。 1日に約20万件のレコードがピボットテーブルに分類され、そのようなボリュームでは、データベースはサンプリングのためのクエリを処理します。数週間であっても、非常に高速です。

さらに、CDRのデータベースを照会することにより、ASR、ACD、分数、サプライヤー、消費者、および宛先による通話に関する情報を格納するrrdデータベースの値を満たすデータが選択されます。 合計で、約8000個のrrdデータベースが更新されます。 rrdtool操作の特性により、パートナーまたは方向へのトラフィックがなかった場合、0に等しい値をデータベースに書き込む必要があります。rrdデータベースの更新後、アラートモジュールによって新しい異常がないかどうかがチェックされます。 異常がある場合、アラートモジュールはメールで手紙を送信できます。さらに、新しいアラートが表示されると、監視システムクライアントを実行しているユーザーは、トレイにあるクライアントアプリケーションのアイコンの色を変更して通知を受け取ります。

単一のCDRファイルの処理とアラートの送信には、最悪の場合2分半かかります。 サーバーアプリケーションはpythonで記述され、FreeBSDで実行されます。

著者の個人的な好みにより、監視システムのクライアントはWEBアプリケーションではありません。 クライアントアプリケーションはPyQTで記述されています 。 サーバーとのクライアント通信には、xmlrpcプロトコルが使用されます。これは、SSLに加えてセキュリティのために機能します。 クライアント認証では、HTTP基本認証が使用されます。 クライアント要求を処理するサーバーアプリケーションはマルチスレッドです。

この記事でクライアントアプリケーションインターフェイスを詳細に説明する価値はありません。80ページを超えるドキュメントはユーザードキュメントだけだからです。 ユーザーが得るものを一般的な用語でのみ説明します。

監視システムの使用方法

製品を作成または説明するときは、まず、製品を正しく配置する必要があります。 当初、潜在的な障害を通知するシステムの実装が計画されていましたが、初期操作中に障害検出機能だけでは不十分であることが判明しました。障害の原因を効果的に分析するツールが必要です。 したがって、最終的にはすべてが監視およびトラフィック分析システムに変わりました。 現在、この製品はVoIPトラフィックを監視および分析するためのシステムとして位置付けられています。

前述のように、監視には、rrdtoolに実装された予測機能が使用されます。 アラートのリストを表形式で表示し、アラート行をクリックして、アラートが発生した規模のグラフを作成することができます。

トラフィック分析には、rrdtoolを使用して作成されたチャートが使用されます。 ユーザーは、アラートが発生した値に基づいてチャートを作成および分析できます。また、ドロップダウンリストで関心のあるチャートを簡単に見つけることができます。 グラフ（厳密には、その作成元のrrdデータベース）は、過去28日間の情報を保存し、マウスを使用して時間内に便利にスケーリングされます。 たとえば、次の図のように、マウスの左ボタンで関心のある領域を選択すると、10分の1秒で関心のある時間間隔のグラフを取得できます。







グラフで選択された時間のVoIPパラメーターをより詳細に分析する必要がある場合、ユーザーは、ASR、ACD、分、および消費者、サプライヤー、方向ごとに分類されたコールごとに、表形式でグラフに表示されたデータを1回クリックするだけで統合レポートを作成できます。







要約レポートには、選択した時間間隔のパラメーターが反映されます。さらに、選択した時間間隔よりも正確に1日早いパラメーターを表示できます。







これにより、トラフィックの変化を迅速に把握して、障害の原因をさらに分析できます。

より詳細な分析を行うには、ジッタコーデック、パケット損失、MOSなど、特定のコールのレベルで詳細な情報を表示するテーブルを作成できます。

監視システムには他にも多くの便利な機能が実装されており、その説明には多くの時間がかかります。

このため、監視システムはルーティング制御部門であるすべてのレベルのサポートで使用されます。 監視システムは価格とマージンに関するデータを提供しないという事実にもかかわらず、パートナーの仕事の質と方向にしばしば関心があるため、販売部門でも使用されます。

次に、予測方法を使用して監視することの欠点と利点を検討します。

メソッドの欠点

欠点は次のとおりです。

•監視システムの比較的高い反応性。 はい、メソッドは機能しますが、障害は検出されますが、迅速ではありません。 ウィンドウ3の長さとウィンドウ2のミスの数があったとしても、システムが障害に関する警告を出すまでにかなり長い時間が経過します。

•比較的多数の誤検知。 ただし、この特定の監視システムを検討する場合、トラフィック分析の機能により誤った応答を非常に簡単に判断できるという事実によって、これを補います。

•システムは、統計データの分析に基づいています。 統計は、大量のデータに対してうまく機能します。 たとえば、トラフィックがどの方向にもほとんど行かない場合、予測するものは何もありません。

メソッドの利点

利点は次のとおりです。

•システムは完全に自律的に動作します。 障害を識別するための基準を設定する必要はありません。システム自体が障害を公開します。 トラフィックプロファイルが変更されると、システムはアラートを出します。 プロファイル全体が変更された場合、しばらくするとシステムは新しいプロファイルに合わせて調整されます。

•rrdtoolによる実装は非常に視覚的です。 従業員は、仕事の経験がほとんどなくても、すぐに学習します。

•IMHO、現時点では、中継VoIPを監視する唯一の可能な方法であり、重要な財政的および人的資源を必要としません。

おわりに

かなりの量にもかかわらず、これはレビュー記事です。 rrdtoolに実装されている予測方法について、すべてを整理するいくつかの記事を書く予定です。 VoIPに加えて、インターネットチャネルトラフィックを監視し、Ciscoルーターのプロセッサをロードするために使用します。



PS

ちなみに、人気のある監視システムの作成者であるMuninは、予測を使用した監視も実装する予定です。 ここには、「rrdを使用した異常検出」というフレーズがあります。 願わくば、この機能がすぐに表示されることを願っています。いずれにせよ、あなたはすでにそれが何であるか知っています...