Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

APIとともにMist SLEとインサイトを使用する

RESTful APIを使用して、ネットワークパフォーマンスに関するインサイトを取得します。

ジュニパー Mistポータルを使用してネットワークの運用を監視すると、問題になる前に何が起こっているのかを把握することができます。ネットワークを無線、有線、WAN など、複数の視点から見ることができます。さらに、ジュニパーMist™が提供するツールを使用して、潜在的な問題のトラブルシューティングと修正を行うことができます。

サービスレベルの監視>の主要なMistダッシュボードには、予測分析と相関エンジン(PACE)の結果がサービスレベル期待値(SLE)メトリックの形式で表示されます。SLEは、機械学習とジュニパー Mist クラウドのMist PACEを活用します。これらのリソースを使用して、SLEはアクセスポイント(AP)からのストリーミングテレメトリを、エンドユーザーのネットワークエクスペリエンスをほぼリアルタイムで可視化に変換します。SLEの詳細については、ジュニパーのMist AIネイティブ運用ガイドをご覧ください。

Mist GUIに表示されるすべての機能と同様に、SLEとインサイト情報もAPIから入手できます。

SLE

特定のSLEに関する情報を収集して、履歴レポートに使用したり、他の自動化をトリガーしたりすると便利な場合があります。他のAPI呼び出しと同様に、最初にデータを収集するエンドポイントを決定します。以下に、 getOrgsSitesSle エンドポイントのAPI GETリクエストの例を示します。

注:{org_id}を組織IDに置き換えます。

詳細については、「 SLEの概要」を参照してください。

インサイト

インサイトは、サイト、アクセスポイント、または無線クライアント全体のネットワークエクスペリエンスの概要を提供します。サイトを確認するときに始めるのに最適な場所です。

以下のInsightsエンドポイントのいずれかにGETリクエストを行うことで、Insight情報を見つけることができます。

  • GetSiteInsightMetrics
  • GetSiteInsightMetricsForDevice
  • GetSiteInsightMetricsForClient

詳細については、「 インサイトの概要」を参照してください。

メトリックと分類子

ジュニパー Mist SLEとInsightsのエンドポイントは、メトリックと分類子をサポートしています。メトリックは、サービスレベルが設定されたしきい値を満たしているかどうかを追跡します。メトリックがしきい値を満たしていない場合、この障害は、障害が発生した場所をさらに詳しく把握するために、分類子の1つに起因する可能性があります。

SLEとInsightsのエンドポイントでは、多くの場合、 metric 引数が必要になります。これは、生の統計情報や設定に加えて、Mistが内部データ分析の結果の計算値を公開するためです。新しいデータ分析機能が追加されるたびに一意のAPI関数を作成するのではなく、Mist少数の関数のみを公開しますが、 metric 引数を使用して取得する派生データ値を指定します。

注意:

以下のAPIエンドポイントは、2026年のリリースで非推奨になります。

  • :site_id/sle/:scope/:scope_id/metric/:metric/summary

  • :site_id/sle/:scope/:scope_id/metric/:metric/classifier/:classifier/summary

これらは、以下の新しいエンドポイントに置き換えられます。

  • :site_id/sle/:scope/:scope_id/metric/:metric/summary-trend

  • :site_id/sle/:scope/:scope_id/metric/:metric/classifier/:classifier/summary-trend

インサイト メトリックの一覧を取得するには、次の GET 呼び出しを発行できます。

応答は次のようになります。

利用可能なInsightメトリックの例を表示する別の方法は、Mistポータルにログインし、同じブラウザーから次のリンクを新しいタブで開くことです。

https://api.mist.com/api/v1/const/insight_metrics

前の GET 呼び出しの例 GET /api/v1/const/insight_metricsを使用して、呼び出しの最後に目的のメトリックを追加します。現在サポートされているメトリックとその分類子の一部については、以下の GET 呼び出しの例を参照してください。

AP稼働時間: AP可用性

GETコール:
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • APの再起動: ap-reboot
  • AP到達不能: ap-unreachable
  • サイトダウン: サイトダウン

容量: 容量

GETコール:
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • AP負荷 :AP負荷
  • 非WiFi干渉: 非WiFi干渉
  • WiFi干渉: wifi干渉

カバレッジ: カバレッジ

GETコール:
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • 非対称ダウンリンク:asymmetry-downlink
  • 非対称アップリンク:asymmetry-uplink
  • 弱信号: 弱信号

ローミング: ローミング

GETコール:
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • 高速ローミングに失敗しました: 高速ローミングなし
  • 遅い11Rローミング:Suboptimal-11r-roam
  • 遅いOKCローミング: 最適ではないokcローミング
  • 低速標準ローミング:スローローミング

接続の成功 :successful-connect

GETコール:
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • アソシエーション: アソシエーション
  • 認可: 認可
  • DHCP: DHCP

スループット: スループット

GETコール:
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • 容量: 容量
  • カバレッジ: カバレッジ
  • デバイス機能: device-capability
  • ネットワークの問題: network-issues

接続時間: 接続時間

GETコール::
注:{site_id} をサイト ID に置き換えます。
リクエスト例: 応答例:
  • アソシエーション: アソシエーション
  • 認可: 認可
  • DHCP: DHCP
  • インターネットサービス: IPサービス\u000C

SLEパーセンテージの計算

SLEメトリックの成功率は、選択した時間枠中にしきい値に到達した頻度の割合として計算されます。分類子はパーセンテージとしても計算されますが、これらの値は親障害への影響を示します。

たとえば、次のスクリーンショットでは、Time to Connect が 96% の確率で成功していることが示されています。午後3:00から4:00の間に接続に成功したすべてのクライアントは、4秒以内に接続プロセスを完了しました。

Success Rate on the Time to Connect Root Cause Analysis Page

このメトリックの成功率(%)は、「メトリック概要」APIエンドポイントから導き出されます。

注:site_idを実際のサイトIDに置き換えます。

メトリックの失敗率は、失敗(sle.samples.degraded)を合計(sle.samples.total)で割ることによって計算されます。これが成功率のパーセンテージに変換されます。上記のAPI応答ペイロードを使用すると、計算は次のようになります。

このスクリーンショットは、メトリックの失敗に寄与した分類子(DHCP、承認、アソシエーション、インターネットサービス)を示しています。

Example: Classifier Percentages

分類子の影響(%)は、同じ「メトリックサマリー」APIエンドポイントから導き出されます。

注:site_idを実際のサイトIDに置き換えます。

分類器の影響は、分類子の障害 (classifiers[n].samples.degraded) をすべての障害の合計 (classifiers[].samples.degraded) で割ることによって計算されます。これはパーセンテージに変換されます。上記のAPI応答ペイロードを使用すると、DHCPの計算は次のようになります。

SLEの監視

SLEデータは10分ごとに更新されます。ただし、この粒度で監視するとSLEが変動しやすくなります。そのため、明示的な開始時刻と終了時刻を使用して 1 時間間隔でクエリを実行し、ポーリングは 1 時間に 1 回のみ行うことをお勧めします。