ネットワークパフォーマンス指標とは？問題の追跡と解決方法（2026年）

ネットワークパフォーマンス指標は、インフラストラクチャとユーザー間の診断レイヤーです。パケットの伝送速度や使用帯域幅、データのドロップや遅延の頻度など、あらゆる要素を捉えることで、通信速度の低下、パケットロス、アクセス不能といった問題の原因を明らかにします。 

ITチームにとって、それらは問題の正確な場所を把握できるか、何時間も推測に時間を費やすかの違いを生む。

この記事では、帯域幅、レイテンシ、スループット、パケット損失、ジッター、RTT、可用性など、すべてのITチームが追跡すべき主要な指標について解説します。それぞれの指標の仕組み、相互の影響、ユーザーレポートに基づいて最初に確認すべき指標、そしてそれらを基にした監視戦略の構築方法について学びます。

ネットワークパフォーマンス指標とは何ですか？

ネットワークパフォーマンス指標とは、コンピュータネットワークの全体的な健全性、速度、信頼性を測定、監視、評価するために使用される定量的および定性的な指標のことです。

これらのネットワークパフォーマンス指標は、以下の2種類に分類されます。

• メトリクスとは、ミリ秒単位の遅延、Mbps単位の帯域幅、パーセンテージで表されるパケット損失など、直接測定できる数値のことです。 
• 指標とは、「ネットワークの安定性」や「優れたユーザーエクスペリエンス」といった、より広範な概念のことです。これらは直接測定することはできません。そのため、複数の定量的な指標を総合的に分析することで算出されます。

例えば、あるネットワークが50msの遅延、0%のパケット損失、200Mbpsのスループットを報告したとしましょう。これらの3つの数値は、ネットワークが正常であることを示唆しています。しかし、同じネットワークでも15msのジッターが発生している可能性があり、これらの3つの指標ではそのジッターを検出することはできません。 

わずかなジッターだけでも、VoIP通話の音声が途切れ途切れになることがあります。そのため、監視ツールは単一の数値に頼るのではなく、複数の指標を同時に追跡するのです。

監視すべき主要なネットワークパフォーマンス指標

以下の指標を追跡してください。 

1。 帯域幅 

帯域幅 は、ネットワークまたは通信チャネルが一定時間内に処理できる最大データ量です。通常はメガビット/秒（Mbps）またはギガビット/秒（Gbps）で測定されます。

帯域幅とスループットは混同されがちですが、これらはネットワーク性能の異なる側面を測定するものです。

• 帯域幅 利用可能な最大容量です。 
• スループット これは、ネットワークの混雑、パケット損失、その他のオーバーヘッドを考慮した上で、実際の条件下でその容量を介して実際に転送されるデータ量です。 

ネットワークが混雑していたり​​、ハードウェアの処理能力が追いつかなかったりすると、接続の帯域幅が高くてもスループットが低くなることがあります。

例えば、帯域幅が100Mbpsの接続でも、ピーク時には実際のスループットは60Mbpsしか得られない場合があります。残りの40Mbpsは、ネットワークの混雑や再送信によって失われます。これが、両方の数値が重要な理由です。帯域幅は、最大で得られる可能性のある帯域幅を示し、スループットは、現在実際に得られている帯域幅を示します。

2. 遅延時間と往復時間（RTT）

レイテンシーとは、データが送信元から送信先まで一方向にのみ伝送されるのにかかる時間のことです。単位はミリ秒（ms）です。 

レイテンシが低いほど、より高速で応答性の高い接続が可能になります。レイテンシが高いと、特にビデオ通話、オンラインゲーム、金融取引などのリアルタイムアプリケーションにおいて、顕著な遅延が発生します。

往復時間（RTT）とは、データが送信先に到達してから送信元に戻ってくるまでの合計時間のことです。簡単に言うと、レイテンシは一方向の所要時間を測定するのに対し、RTTは往復全体の所要時間を測定します。

これは理解しておくべき重要な点です。なぜなら、ほとんどの監視ツールは実際には片方向の遅延ではなく、RTT（ラウンドトリップタイム）を報告するからです。 

pingのようなコマンドはパケットを送信し、応答が返ってくるまでの時間を計測します。つまり、設計上、RTT（ラウンドトリップタイム）を測定するのです。 

真の片方向遅延を測定するのは、接続の両端でクロックを正確に同期させる必要があるため、より困難です。そのため、ダッシュボードに「遅延」の数値が表示されている場合、それは多くの場合、RTT（ラウンドトリップタイム）を示しています。

例えば、双方向の遅延が75msのビデオ通話の場合、RTT（ラウンドトリップタイム）は約150msになります。広く使われている音声品質のベンチマークであるITU-T G.114規格では、許容できる音声通話品質を維持するために、片方向の遅延を150ms未満に抑えることを推奨しています。これを超えると、通話中に遅延が感じられたり、お互いの声が重なったりし始めます。

レイテンシが高くなる原因はいくつか考えられます。 

• デバイス間の物理的な距離
• ネットワークの輻輳
• BGPやOSPFなどのルーティングプロトコルの設定ミス。 

ネットワークのさまざまな部分における遅延とRTTを監視することで、遅延が発生している場所を正確に特定できます。

3.スループット

スループットとは、一定時間内にネットワークを介して実際に転送されるデータ量のことで、MbpsまたはGbpsで測定されます。これは、ネットワークが理論上どれだけの速度を出せるかではなく、現在どれだけの速度を出せているかを示すものです。 

スループットは常に帯域幅よりも低くなります。1Gbpsのリンクは1Gbpsの帯域幅を持ちますが、プロトコルのオーバーヘッド、再送信、輻輳などにより、通常は850～950Mbpsのスループットしか得られません。 

この2つの数値の差こそが、パフォーマンスに関する苦情の大半の原因となっている。

スループットが利用可能な帯域幅を下回る原因はいくつかあります。 

• ネットワークの輻輳
• データの再送信を余儀なくさせるパケット損失
• TCP独自の輻輳制御メカニズムは、パケット損失を検出すると意図的にデータ転送速度を低下させる。 

これは、同じ帯域幅を持つ2つのネットワークでも、パケット損失や輻輳の程度によって、スループットが大きく異なる可能性があることを意味します。

例えば、帯域幅が最大であれば10分で10GBのファイルを転送できるはずのファイルバックアップでも、パケットロスによって再送信回数が増えると25分かかる場合があります。帯域幅は同じでも、スループットは異なります。

測定できます NetFlowを使用したスループットSaaSを多用する環境で運用しているチームは、エッジルーターからだけでなく、ユーザーのエンドポイントからSaaSアプリケーションのエッジまでのスループットを測定してください。この経路こそが、ユーザー体験に直接影響を与えるからです。

4. パケット損失、エラー率、および再送信

これら3つの指標は互いに関連しており、それらの関連性を理解することで、問題をより迅速に診断できるようになります。  

a. エラー率 ネットワークインターフェースレベルで伝送エラーが発生する頻度を測定します。エラー率が高い場合は、ケーブルの不良、ハードウェアの故障、深刻なネットワーク混雑など、何らかの問題が発生していることを示す早期警告サインです。問題が発生していることは示されますが、具体的にどのような問題なのかはわかりません。

b. パケット損失 はより具体的です。これは、送信されたものの宛先に届かなかったデータパケットの割合を測定します。ほとんどのネットワークでは、1%未満のレートは一般的に許容範囲内と考えられ、パフォーマンスに目立った影響を与える可能性は低いとされています。高パケット損失は通常、次のようなものと定義されます。 5%を超えると、 そうなると、ユーザーは目立った遅延や中断を経験する可能性が高いでしょう。 

c. 再送信 TCPはパケット損失を検出すると自動的に再送を行います。これは、欠落または破損したパケットを再送することで、最終的にデータが完全に届くようにします。しかし、これにはコストがかかります。再送は元の転送に加えて追加の帯域幅を消費します。したがって、再送率が高いということは、同時に次の2つのことを意味します。 

• パケット損失が発生しています
• ネットワークは、その損失を回復するために追加の帯域幅コストを支払っている。 

パケット損失が連鎖的に発生する理由はここにあります。影響を受ける転送速度が低下するだけでなく、そのネットワーク経路を共有するすべての処理速度が低下するのです。

例えば、ファイル転送でパケットの3%が失われていると想像してみてください。TCPは失われたデータを再送信しますが、再送信のたびに既に混雑している回線のトラフィックが増加し、さらなる輻輳と損失を引き起こす可能性があります。この悪循環は、根本原因に対処しない限り断ち切るのが難しいものです。

パケット損失の根本原因には明確なパターンがあります。ランダムな損失は通常、一時的な輻輳を示し、継続的または体系的な損失は、ハードウェアの故障、ケーブルの不具合、または直接修正する必要のある永続的な設定ミスを示しています。

5。 ジッタ

ジッターとは、パケットが宛先に到着するまでの時間差のことです。正常なネットワークでは、パケットは安定した予測可能なペースで到着します。ジッターが大きい場合、一部のパケットは早く到着し、一部は遅れて到着するため、パケットの欠落や順不同が発生し、データの流れが阻害されます。

ジッターが目に見える問題となるのは、リアルタイムアプリケーションの場合のみです。ファイルダウンロードやメールの場合、アプリケーションがデータをすべて再構成してから表示するので、パケットの順序やタイミングはあまり重要ではありません。しかし、ライブ音声通話やビデオ会議では、パケットは正しい順序で正しいタイミングで到着する必要があります。そうでない場合、音声が途切れ途切れになったり、ロボットのような声になったり、ビデオがフリーズしたりといった問題が発生します。

業界全体で広く受け入れられている基準値は明確です。VoIPで許容されるジッターは、以下の値です。 30ミリ秒ジッターがこのしきい値を下回っている間は、通話品質は良好です。30msを超えると、音声が途切れたり、エコーが発生したり、音声伝送が遅延したりする可能性が高くなります。 

ジッターの最も一般的な原因は、ネットワークの混雑、ルーティングの不整合、ハードウェアの過負荷です。ネットワーク経路が混雑すると、パケットがキューに格納され、不均一な間隔で放出されるため、到着時間にばらつきが生じます。

例えば、チームでビデオ通話中に、同じネットワーク上の誰かが大きなファイルのダウンロードを開始すると、突然の混雑によってジッターが数秒以内に30msを超えることがあります。ダウンロード開始前は回線に余裕があったため通話は正常でしたが、ダウンロードによってその余裕が消費され、ジッターが急激に上昇したのです。

6. ネットワークの可用性

ネットワーク可用性とは、ネットワークとその重要なコンポーネントがユーザーにとってアクセス可能で正常に動作している時間の割合です。可用性が低下すると、スループットやレイテンシなどの他の指標がどれほど良好に見えても、ユーザーは依存しているアプリケーションやサービスに接続できなくなります。

可用性を計算するための標準的な式は次のとおりです。

稼働率（％）＝（総稼働時間－停止時間）／総稼働時間×100

ほとんどの企業SLAは、業界標準となっている少数の可用性目標に基づいて構築されています。

• 稼働率99.9%（99.9%）は、年間約8時間46分のダウンタイムを許容します。
• 稼働率99.99%（99.99%）により、年間ダウンタイムはわずか52分35秒に抑えられます。

理解しておくべき重要な点の1つは、ネットワークが技術的に「稼働している」ことと、ユーザーが機能的に利用できることの違いです。 

デバイスの状態チェックで稼働率が100%と表示されていても、レイテンシが許容レベルを超えて急上昇したり、パケット損失がアプリケーション接続を切断するほど高かったりすると、ネットワークは使用不能になる可能性があります。そのため、可用性は単独の数値としてではなく、常にレイテンシとパケット損失と併せて監視する必要があります。

例えば、VPNサービスは監視ツール上ではオンラインに見えるかもしれませんが、混雑したWANリンクの向こう側のユーザーは実際にはセッションを確立できません。ネットワークは技術的には稼働していますが、それを必要とする人々にとっては機能的に利用できない状態です。

7. アプリケーション応答時間

アプリケーションの応答時間とは、ユーザーがリクエストを送信してからアプリケーションが完全な応答を返すまでの合計時間です。ネットワーク遅延とサーバーがリクエストを処理する時間の両方が含まれるため、レイテンシとは異なります。 

レイテンシはネットワークの伝送時間のみを測定します。アプリケーションの応答時間には、それに加えて、データベースクエリの実行やアプリケーションロジックの読み込みといったサーバー処理時間も含まれます。

eコマースWebサイト、SaaSダッシュボード、モバイルアプリなどのインタラクティブなアプリケーションでは、応答時間が1秒未満であれば一般的に許容範囲です。パフォーマンスが1秒を超えると、 1秒の閾値ユーザーは遅延に気づく可能性があります。source) 

この指標は、重要な診断上の疑問、つまり速度低下の原因がネットワークにあるのかアプリケーションにあるのかを判断する上で貴重な情報を提供します。レイテンシは安定しているものの応答時間が上昇している場合は、サーバー側に問題がある可能性が高いです。両方が同時に上昇している場合は、ネットワークが原因である可能性が高いでしょう。

ネットワークパフォーマンス指標は互いにどのように関連しているか

各ネットワーク指標はそれぞれ異なるものを測定していますが、それらは独立して動作するわけではありません。ある指標の変化は、ほぼ必ず他の指標にも影響を与えます。 

知っておくべき重要な関係性は以下のとおりです。

帯域幅はスループットを保証するものではありません 

帯域幅とは、接続が処理できる最大データ量です。スループットとは、輻輳、パケット損失、プロトコルオーバーヘッドなどを差し引いた後に実際に伝送されるデータ量です。 

帯域幅が広ければスループットも高くなりますが、レイテンシやパケットロスが大きいと、実際のスループットは利用可能な帯域幅を大幅に下回ってしまう可能性があります。 

パケット損失率が3%の1Gbpsリンクでは、実際のスループットは常に1Gbpsをはるかに下回る。

パケット損失はスループットを圧縮し、同時にレイテンシを増加させる。

TCPはパケット損失を検出すると、それを輻輳信号と解釈し、送信レートを低下させます。失われたパケットは再送信する必要があり、送信側が損失を検出して再送信するまでの間、遅延が発生します。 

つまり、パケット損失は影響を受ける転送速度を低下させるだけでなく、その経路を共有する他のすべての接続が利用できるスループットを積極的に低下させるのです。

スループットが十分であっても、レイテンシが高いとユーザーエクスペリエンスが低下する。

ネットワークのスループットが500Mbpsであっても、レイテンシが高いと動作が遅く感じられることがあります。これは、Webアプリケーションやデータベースクエリのように、小さなリクエストを多数送信し、次のリクエストを送信する前に応答を待つアプリケーションで特に顕著です。 

往復するたびに遅延コストが発生し、そのコストはすぐに積み重なる。

ジッターはリアルタイムのトラフィックでのみ目に見えるようになる

ファイル転送や電子メールの場合、アプリケーションはすべてのデータを受信するまで待機してから表示するので、パケットの到着時間のばらつきは問題になりません。 

音声通話やビデオ会議の場合、パケットは順番通りに時間通りに到着する必要があります。 

ファイルのダウンロードでは気づかないような10ミリ秒のジッターでも、音声通話では途切れ途切れの音声になることがある。

RTTは、ユーザーが感じることを最もよく表す単一の指標です。

片方向遅延は、遅延が発生している場所を示します。RTTは、インタラクティブセッション中にユーザーが体験する状況を示します。 

RTT（ラウンドトリップタイム）が長いということは、送信側が確認応答を受信するまでに待つ時間が長くなることを意味し、実効スループットが低下し、転送の初期段階におけるTCP接続の成長が遅くなる。 

各指標が互いにどのように影響し合うかを簡単にまとめると以下のようになります。

最初に確認すべきネットワーク指標はどれですか？

ユーザーが問題を報告する際、彼らが説明する挙動は通常、特定の指標群を指し示している。 

苦情が寄せられた際の最初の参考資料として、この表を使用してください。

ネットワークパフォーマンスに影響を与える要因は何ですか？

ネットワークのパフォーマンス問題は、必ずしも同じ原因から発生するわけではありません。インフラストラクチャ内部の問題、設定上の決定の問題、アプリケーションの動作の問題、そしてネットワークとは全く関係のない要因など、様々な要因が考えられます。 

1. インフラの質

ネットワークが動作する物理的なハードウェアは、パフォーマンスに明確な制限を設けます。

• 古いルーターやスイッチでは、現代のトラフィック量に対応できません。 
• ケーブルの不具合は、インターフェースのエラー率の上昇、パケット損失、再送信といった形で現れる伝送エラーを引き起こす可能性があります。
• ハードウェアが旧式だと、ネットワークリンク自体に十分な容量があっても、スループットが制限される。

寿命が近づいているスイッチが、通常の負荷状態でパケットをドロップし始めたとします。症状は輻輳のように見えますが、スイッチを交換すればすぐに解決します。定期的なハードウェア点検と適切な時期の交換によって、このような問題は未然に防ぐことができます。

2. 設定オプション

ルーティング設定の誤り、不適切なQoSポリシー、設計不良のネットワークセグメントは、ハードウェア障害がなくてもパフォーマンスを低下させる原因となります。ルーティングミスによってトラフィックが必要以上に長い経路を通ってしまうと、その経路を利用するすべてのリクエストに遅延が発生します。

例えば、BGPの設定ミスにより、2つのオフィス間のトラフィックが直接WANリンクではなく外部ISPを経由してルーティングされてしまうことがあります。その結果、その経路上のすべてのユーザーのRTT（ラウンドトリップタイム）が2倍になります。ネットワーク自体は正常に動作していますが、設定が間違っているだけです。

3. トラフィックとアプリケーションのワークロード

アプリケーションによって、ネットワークにかかる要求は大きく異なる。 

• ファイルバックアップやビデオストリーミングは、継続的に大量の帯域幅を消費します。 
• VoIPやビデオ会議は、わずかな遅延、ジッター、パケット損失にも敏感である。 
• 月末になると、ERPシステムはトラフィックの急増を引き起こし、短時間のうちに利用率が安全なレベルを超えてしまう。

ワークロードの構成を把握していれば、適切なQoSポリシーを適用し、容量計画を正しく立てることができます。 

4．環境要因および外部要因

これらは、直接制御できない外部要因から発生するため、特定するのが最も難しい場合が多い。近くの機器からの電磁干渉（EMI）は、無線信号を劣化させ、ケーブルにエラーを引き起こす可能性がある。 

壁などの物理的な障害物は、Wi-Fi信号の強度を低下させる。 

同じチャンネルを使用している近隣の無線ネットワークは、あなたの無線信号に干渉し、インフラ障害のように見える問題を引き起こす可能性があります。 

ISPの問題も、よくある外部要因の一つです。帯域幅の制限、接続の混雑、ルーティングの問題、ISPネットワーク内部の未解決の問題などはすべて、社内で解決できない形でWANパフォーマンスに影響を与えます。 

5. セキュリティ上のオーバーヘッド

セキュリティツールは、通常の動作の一環としてネットワークリソースを使用します。ディープパケットインスペクションは通信速度を低下させる可能性があり、セキュリティとパフォーマンスの適切なバランスを見つけるには、慎重な調整が必要です。 

大量のトラフィックを処理するファイアウォールは、その負荷に対応できる規模で設計されていない場合、ボトルネックとなる可能性があります。また、侵害されたデバイス上のマルウェアは、ネットワークをスキャンする際に大量の帯域幅を消費し、明らかな原因のない輻輳を引き起こす可能性があります。 

例えば、SSL/TLS検査に対応していないファイアウォールでフルSSL/TLS検査を有効にすると、ネットワークリンク自体が全く変更されていなくても、スループットが30～50%低下し、レイテンシが著しく増加する可能性があります。

ネットワーク監視プロトコル：メトリクスの収集方法

ネットワークのパフォーマンス指標は特定のプロトコルによって収集され、各プロトコルはネットワーク動作の異なる層を捉えます。 

各プロトコルがどのような機能を提供し、どのような指標にデータを送信するのかを以下に示します。

SNMP（簡易ネットワーク管理プロトコル）

SNMPは、デバイス監視において最も広く使用されている標準ネットワークプロトコルです。CPU使用率、メモリ負荷、インターフェースの状態などの指標をネットワークデバイスからポーリングします。 

SNMPv3は暗号化と認証機能を追加することで、常時ポーリングなしでリアルタイムアラートが必要な環境において、より安全なものとなっています。 

SNMPは、デバイスが何をしているかを知りたい場合に最適なツールです。ただし、デバイスを通過するトラフィックの種類は表示されません。 

NetFlow、sFlow、およびjFlow

SNMPがデバイスの状態に焦点を当てるのに対し、NetFlowは動作に焦点を当てます。NetFlowは、送信元および宛先のIPアドレス、ポート、プロトコルなどのフローデータを取得し、ネットワーク内でトラフィックがどのように流れるかを把握するのに役立ちます。 

その可視性は、交通管理、容量計画、異常パターンの発見にとって極めて重要である。 

sFlowとjFlowはベンダー固有のバリエーションですが、動作原理は同じです。ただし、帯域幅を誰がどれだけ使用しているかを知りたい場合は、NetFlowを使用してください。

ICMP（インターネット制御メッセージプロトコル）

ICMPは、pingやtracerouteの基盤となるネットワークプロトコルです。デバイスに到達可能かどうか、また往復にかかる時間を確認する最も速い方法です。遅延、RTT（ラウンドトリップタイム）、および基本的なパケット損失を測定します。 

ICMPはトラフィックの詳細やデバイスの状態データを提供しませんが、接続の問題が報告された際に、ほとんどのチームが最初に頼るツールです。

Syslog

Syslogは、システムログの送信、保存、整理に使用される標準的なネットワークプロトコルです。ネットワーク機器からイベントメッセージを収集し、中央ログサーバーに送信します。設定変更、ログイン失敗、ハードウェアエラーなどを記録します。 

SNMPは定量的な指標を提供する一方、syslogは定性的なイベントデータを提供する。両者を組み合わせることで、ネットワークの状態をより包括的に把握できる。SNMPはパフォーマンス監視に適しており、syslogはイベント監査に適している。 

DPI（ディープパケットインスペクション）

DPIは、パケットのヘッダーだけでなく、パケットの実際の内容を検査します。これにより、アプリケーションごとにトラフィックを分類したり、異常を検出したり、アプリケーション層のパフォーマンスを測定したりすることが可能になります。 

SNMPやICMPよりもリソースを多く消費するため、ほとんどのチームはネットワーク全体の継続的な監視ではなく、特定のトラブルシューティングにこれを使用します。

APIエンドポイント

最新のクラウドサービスやSaaSアプリケーションは、APIを通じてパフォーマンスデータを公開します。APIエンドポイントを監視することで、SNMPなどの従来型プロトコルをサポートしていないサービスでも、アプリケーションの可用性や応答時間を追跡できます。 

これは、インフラストラクチャの一部がクラウド上で稼働し、一部がオンプレミスで稼働するハイブリッド環境において特に重要です。

AIを活用した監視

SNMP、NetFlow、ICMP、Syslog、DPI、およびAPIエンドポイントはすべて生データを収集します。AIおよび機械学習プラットフォームは、その生データを利用して、より迅速かつ賢明な意思決定を支援します。

従来の監視方法との主な違いは、閾値の仕組みにある。 

従来のツールでは、各メトリックに対してアラートのしきい値を手動で設定する必要がありました。一方、AI搭載プラットフォームは、ネットワークにおける正常な状態を学習し、メトリックが設定されたしきい値を超えていない場合でも、それに一致しないものがあれば警告を発します。 

AIによる監視がネットワークパフォーマンス指標に役立つ3つの具体的な理由：

• 自動ベースライン設定： レイテンシやスループットの「正常値」を手動で決定するのではなく、このプラットフォームは、時間帯、曜日、アプリケーションの種類など、さまざまな状況における実際のトラフィックパターンからベースラインを構築します。
• 異常スコアリング： 指標が異常な挙動を示した場合、プラットフォームはその変化の重大度をスコア化するため、チームはノイズではなく真の問題に集中できます。
• 予測に基づくキャパシティプランニング： AIツールは、帯域幅の使用状況とスループットの経時的な傾向を追跡することで、ユーザーが速度低下に気づく数週間前に、帯域幅が不足しているリンクやデバイスを特定できる。

ネットワーク監視戦略の構築

ビジネスにとって本当に重要なことを中心に据えたネットワーク監視戦略を構築する方法をご紹介します。 

各小見出しを直接的な指示として加えた改訂版のセクションは以下のとおりです。

SLAに基づいてしきい値を設定してください。

SLA（サービスレベル契約）を確認し、それに基づいて設定するすべてのしきい値を定義してください。各指標について、「ビジネスが実際に必要とするパフォーマンスレベルはどの程度か？」と自問自答してください。その数値がしきい値となります。

具体的に指示してください。「レイテンシを低く抑える」は適切な目標ではありません。「営業時間中のVoIPトラフィックの片方向レイテンシを100ms未満に抑える」であれば適切です。 

その数値が分かったら、アラートをその数値の80～90%に設定して、侵害が発生する前に通知を受け取れるようにしてください。SLAでパケット損失率が1%未満であることが求められている場合は、アラートは0.7%で発動します。

しきい値を設定する前に、2～4週間分のデータを収集してください。

初日からしきい値を設定しないでください。まずは監視ツールを少なくとも2～4週間稼働させ、時間帯や曜日を問わず実際のトラフィックデータを収集してください。そして、デフォルト値ではなく、実際に確認できたデータに基づいてしきい値を設定してください。

CPU使用率80%といったデフォルト値は、ほとんどの環境では感度が高すぎてノイズが発生します。基準値が決まったら、通常は90%または95%が適切な上限値となります。誤検知を防ぐのに十分な高さでありながら、ユーザーが問題に気づく前に実際の問題を検知できるほど低い値です。

QoSルールを適用して、最優先トラフィックを保護します。

VoIP、ビデオ会議、その他リアルタイム処理など、レイテンシに最も敏感なアプリケーションを特定し、それらに他のすべてのアプリケーションよりも優先される適切なQoSルールを割り当ててください。 

ファイルバックアップ、ソフトウェアアップデート、一括転送は待機させるべきです。リアルタイムのトラフィックは待機させるべきではありません。

問題が発生する前にこれを行ってください。 

業務時間中にジッターがすでに30msを超えている場合は、音声パケットを大量データ転送よりも優先するQoSルールを追加し、ジッターとパケット損失の数値を再確認してください。数値が減少すれば、ルールは有効です。減少しない場合は、問題の原因は別のところにあります。

毎週トレンドを追跡

毎週時間を取って、主要な指標の推移を確認しましょう。WANリンクの利用率が60%でアラートが発生していない状態は、現時点では問題ありませんが、利用率が毎月5%ずつ増加している場合、アプリケーションのパフォーマンスに影響が出たり、容量の増強が必要になったりするまでに8ヶ月の猶予があります。 

今この傾向を捉えることができれば、容量増強を計画できる。しかし、それを見逃してしまうと、何らかの事態が発生した際に慌てて対応しなければならなくなるだろう。

すべての環境を1つの監視ビューに統合する

オンプレミスのデバイスを1つのツールで監視し、クラウドのトラフィックを別のツールで監視し、SaaSのパフォーマンスをさらに別のツールで監視している場合、何らかの不具合が発生した際に、それらの間の関連性を見落としてしまう可能性があります。 

デバイスからのSNMPデータ、トラフィックからのNetFlowデータ、クラウドサービスからのAPIデータを相互に関連付ける単一のプラットフォームに統合します。 

複数のレイヤーにまたがる問題の根本原因分析は、すべてのレイヤーを一度に把握できる場合にのみ可能です。

Edwin AI を活用して、手動監視では対応しきれない作業を自動化しましょう。

戦略が確立されたら、 エドウィン AI 手動監視では対応できない部分、例えば以下のような部分を処理します。 

• 実際の交通パターンから基準値を作成する
• スコアリングの異常値を特定することで、チームは真に異常な点のみに集中できるようになります。
• ユーザーが気づく数週間前に容量の問題を警告する

すべての操作は、お客様が定義したポリシーと制限に従って行われるため、お客様の承認なしに自動的に実行されることはありません。その結果、チームはしきい値の管理に費やす時間を減らし、ネットワークの問題解決により多くの時間を費やすことができます。

LogicMonitorがネットワークメトリクスの監視にどのように役立つか

ネットワークパフォーマンス指標は、それに依存するサービスや、チームが取るべき行動と結びついて初めて価値を生み出します。 

それは、ほとんどの監視ツールが残している欠点です。しかし、LogicMonitorはその欠点を解消します。

LogicMonitorは、自律型ITのためのAIファーストプラットフォームであり、企業が事後対応型の運用から、問題が検知、理解、解決される統制された運用モデルへと移行できるよう支援するために構築されています。多くの場合、ユーザーが問題に気づく前に解決されます。 

このプラットフォームは、1つのシステムとして機能する3つのコンポーネントを接続します。

LMエンビジョン テレメトリ基盤を提供し、インフラストラクチャ、クラウド、エッジにわたる統合されたハイブリッド監視を実現します。この記事で取り上げたすべてのネットワークメトリックはLM Envisionを経由して処理されるため、オンプレミスデバイス、クラウド環境、ハイブリッドパス全体にわたって、チームは信頼できる唯一の情報源を得ることができます。

キャッチポイント Catchpointは、その可視性を社内システムだけでなく、ユーザーが実際に依存している配信環境全体（インターネット経路、外部依存関係、DNS、ISP、デジタルエクスペリエンスなど）にまで拡張します。ネットワークパフォーマンスの問題が自社インフラストラクチャの外部で発生した場合、Catchpointによってその原因を特定できます。

エドウィン AI Edwinは、専用のAIエージェントを活用し、共有されたシグナルを統制されたアクションへと変換します。プラットフォーム全体に組み込まれたEdwinは、お客様固有の環境における正常な状態を学習し、SLAのしきい値を超える前に逸脱を検知し、チームがデータから意思決定へとより迅速に移行できるよう支援します。Edwinは監視なしに動作することはありません。すべてのアクションは、承認、監査証跡、検証が組み込まれた、定義されたガードレール内で実行されます。

これら3つのコンポーネントが連携することで、閉ループが実現します。すなわち、環境全体にわたるシグナルを検出し、サービスへの影響を理解し、推論と優先順位付けを行い、次の行動を決定し、安全対策の範囲内で行動し、結果を検証します。

ネットワーク監視メトリクスへの対応関係は以下のとおりです。

Edwin AIは、ほとんどの監視手法で必要とされる手動によるしきい値設定を不要にします。お客様の環境における「正常」な状態を推測するのではなく、Edwinは時間帯、曜日、アプリケーションの種類を問わず、実際のトラフィックパターンからベースラインを構築し、異常がインシデントになる前に検知します。

よくあるご質問