この記事では、Response Time Viewer for Wireshark(以降RTVと記載)のインストール方法をガイドします。

 

RTVは、Wiresharkにて取得したキャプチャデータを読み込み、分析するツールとなります。Wiresharkを事前に

インストールの上、下記手順に進んでください。

 

1. ソーラーウインズの提供する無償ツールResponse Time Viewer for Wiresharkを下記よりダウンロード

 無料のSolarWinds Response Time Viewer for Wireshark®をダウンロード

 

2. ダウンロードした実行ファイルを管理者として実行

スクリーンショット 2017-06-28 22.26.08.png

3. .NET Framework 3.5 SP1と4.0の両方を自動的に設定

スクリーンショット 2017-06-28 22.25.52.png

4. インストーラが起動

RTV_Install_01.png

5. メールアドレスを入力し、続けるをクリック

RTV_Install_02.png

6. インストールウィザードが実行されるので、確認の上、Nextをクリック

RTV_Install_03.png

6. License Agreementを確認の上、I accept the terms of the License Agreementにチェックをつけ、Nextをクリック

RTV_Install_04.png

7.

RTV_Install_05.png

8. Finishをクリックし、セットアップを終了

RTV_Install_06.png

9. RTVを起動

スクリーンショット 2017-06-28 22.40.49.png

10. Browseボタンをクリックし、分析対象のパケットキャプチャファイルを指定し、Analyzeをクリック

RTV_Install_07.png

11. 分析結果がDashboardに表示

 データ量やPCのスペックに応じて、処理時間に差異があります。

RTV01.png

12. アプリケーション応答時間とネットワーク応答時間を確認したい項目を選択肢し、結果を表示

RTV01b.png

 

その他

 パケットキャプチャファイルを開くことができない場合やWiresharkのインストールフォルダを個別設定している場合は、

 Settingsからeditcap.exeのパスを確認し、再設定してください。

スクリーンショット 2017-05-04 22.53.46 2.png

この記事では、業務ネットワーク上の「アプリケーションがなんだか遅い」という問い合わせに対する無償ツールを使った原因分析方法を案内します。

 

ネットワークエンジニアにとって、なんだか遅いという問い合わせは、簡単に回答できない、難しい問い合わせです。

ネットワークが全く通じない、という場合は、影響は甚大ですが、対応方法は、シンプル、かつ実施すべきことがはっきりしています。

しかしながら、「遅い」という問い合わせは、「何が起きているのか、問題の原因と考えられる箇所を探す」という作業から始まります。

当該アプリケーションの通信経路を確認し、経路上のネットワーク機器の状態を確認するという流れで、問題を切り分けてることが一般的でしょう。

 

様々な情報を確認した結果、通信経路上の機器に問題がなく、ネットワークが原因である可能性が低い、という結論になった場合、次のステップは、

サーバやアプリケーションを管轄しているチームにエスカレーションすることになります。

さて、どのような値を提供すれば、原因はネットワークじゃない、と説得力のある報告ができるのでしょうか?

 

そこで、ソーラーウインズが無償提供しているツール、Response Time Viewer for Wireshark(以降RTVと記載)というツールが役立ちます。

RTVは、Wiresharkでパケットキャプチャしたデータを分析するツールです。1200種類のアプリケーションを分類し、ネットワーク応答時間と

アプリケーション応答時間に分けて表示します。

すなわち「アプリケーションがなんだか遅い」という原因を、ネットワーク側が疑わしいのか、サーバ・アプリケーション側を詳しく

確認すべきなのか、ということがわかるようになります。

 

 www.yahoo.co.jpへの通信を分析した例

RTB02.png

 ネットワーク応答時間(Network Response Time)の平均(Average)は、9.3msということがわかります。

 同様に、アプリケーション応答時間(Application Response Time)の平均は、24.9msです。

 上記例の場合、いずれも十分短い時間で反応しているため、問題はないと考えられます。

 両方の値が長ければ、ネットワークの問題と考えられます。ネットワーク機器やトラフィックの状態を確認する必要がありそうです。

 アプリケーション応答時間のみが長いということであれば、サーバもしくはアプリケーション側の問題と考えられます。適切なチームに

 上記結果とあわせてエスカレーションしてみてください。

 

RTVのインストール方法や使い方については、こちらにガイドがございます。

 

Response Time Viewer for Wiresharkの紹介ページダウンロードはこちらからどうぞ)

 

この機能の有償版は、OrionプラットフォームのQoE機能として提供されています。

QoEは、常にデータの取得と分析を実施します。よって、問題が発生した際には、分析結果も取得されている、ということなります。

詳しくは、こちらの「アプリケーションがなんだか遅い」を解明するをご参照ください。

この記事では「アプリケーションがなんだか遅い」というトラブルに対する原因分析方法についてガイドします。

 

そもそも、情報システム部門の皆様が同じ質問を利用者様から受けた場合、どのように対応されてますか?

アプリケーションが遅い原因は様々な要素が考えられます。

  1. パソコン上のウイルス対策ソフトがスキャン中
  2. パソコン上で何かの処理を同時に行っており、CPU、メモリ、HDDなどの負荷が高い状態
  3. 通信経路に障害が発生しており、利用可能な帯域に制限がある状態
  4. サーバー側の不具合が発生している

 

ネットワーク管理者の立場からすると3以外の選択肢を直接証明することは難しいことです。

1と2については、問い合わせ元の利用者とのコミュニケーションによって、切り分け可能です。

また、Pingなどによりネットワークの疎通を確認したり、SNMP監視ツールなどにより、

ネットワーク機器のインターフェイス利用状況を確認できれば、3ではなさそうだ、ということも推測できます。

 

ソーラーウインズの提供するOrionプラットフォームに含まれるQoE機能を活用すると、通信遅延の理由が、

ネットワークにあるのかサーバー側にあるのか、容易に判別ができます。

 

QoE機能のポイントは、ネットワークの応答時間とアプリケーションの応答時間を識別し、それぞれの

遅延状況を分析表示する点にあります。1,200種類以上のアプリケーションを自動的に分類して表示します。

 

図1. データ取得リクエストに対する最初のデータのレスポンスまでにかかる時間をアプリケーションごとに表示図2. TCP 3ウェイハンドシェイク(Syn、Syn-Ack、Ack)にかかる時間をアプリケーションごとに表示
QoE_101.pngQoE_102.png

実際の例で確認してみましょう。

図1と図2のMS SQLを比較すると、データ取得リクエストに対するレスポンスは、平均3.34秒です。

他方、TCP 3ウェイハンドシェイクにかかる時間は、平均279ミリ秒です。

200ミリ秒を超えるTCP 3ウェイハンドシェクは非常に長い、と言えますが、データ取得リクエストに対する

レスポンスにかかる時間の方がはるかに長いと言えます。

このことより、サーバーを調査すればよいということがわかります。

あとはサーバーチームに任せるもよし、SAMのアプリケーションとハードウェアの依存関係を表示する機能

AppStackを用いて詳細に分析することも可能です。

 

スクリーンショット 2017-04-13 10.08.38.png

QoE機能は、Orionプラットフォームの機能ですが、ネットワークパフォーマンス・モニター(NPM)、

もしくはサーバー&アプリケーション・モニター(SAM)のいずれかのライセンスで有効となります。

 

参考資料

トラフィクをネットワークミラーポートから取得し分析

サーバーにインストールしたエージェントを用いてトラフィックを分析

無償ツールで実現する、アプリケーション遅延の原因分析

アラートの管理で「新しいアラートの追加」

(下記画面はアラート作成後画面のため、「アラートの編集」で内容を表示します)

 

 

 

 

 

 

 

 

 

 

 

 

 

オフライン機器(IP疎通がなくNPM,NCMで管理していないNW機器)のconfigNCMimportして

configの間違い等をPolicy, Rule等でcheckするために外部ノードとして登録する方法。

 

1. MY DASHBOARDS>NPMサマリー>ノードを管理

 

  複数の外部ノードを一括で追加する方法は現在ございません

 

2. ノードを追加

 

3. ホスト名またはIPアドレスを入力して外部のノードを選択し、右下の次をCLICKし、OK, 
  
次の画面でManage node(s) with NCM Yes に変更し(この項目はNCMのみ使用時は表示されない)
  
「ノードを追加」をCLICK

 

 

 

4. 追加した外部ノードを選びノードの詳細でCONFIG>Import Config

 

5. 参照でImportするconfig fileを選択し送信

 

5. Importしたconfigclickすれば内容表示可能

 

    importしたconfigは他のconfigとの比較、Policy-Report, Rulecheckも可能

 

  NCMPolicy-Report, Policy, Ruleの関連性とScriptでのConfig修正例

    https://thwack.solarwinds.com/docs/DOC-189567

 

   

6. ノード間の比較例

   下記はノード間(別ノード)のconfigとの比較例ですが、ノード内(例えばstartupとrunning)の比較も可能

MY DASHBOARDS>設定>jobs 内で用意されているJobs Listのうち 'Example Daily Config Report' の

設定(Edit)で 'ENTER NOTIFICATION DETAILS' の'Email Results'を選択し必要箇所に入力する事で

NCM内にdownloadされたconfigの差分についてメール送信が可能となります。

Toに宛先メールアドレス   Email Server AddressにServer情報  ADD JOB SPECIFIC DETAILSのところの

Please select a config file type ...... を'Running' でtestした内容を紹介します。

 

テストはNPM12.0  NCM7.5 で実施しました。

 

1. Job設定

  MY DASHBOARDS>設定>jobs で

  用意されている'Example Daily Config Change Report' のcopyで作成しました。

 

 

2. 動作テスト

compare typeをRunning指定でテスト実施。 メール通知のBEFOREがrunningになります。

(typeがstartupの場合、メール通知のBEFOREがstartupになります)

 

13:45 LAB-3 ルーターのみtelnetでconfig 変更実施 (exec-timeout を6分から7分に変更)

13:50 別job(config backup job)を使用し、LAB-3,router-1, router-2, router-3のrunning configのみ download

13:55 config change report jobを13:55にセット(対象はLAB-3,router-1, router-2, router-3)

 

これで、LAB-3の11:45にdownloadしておいたrunning configと13:45に変更し13:50にjobでdounloadした

running configが比較されて、差分があるのでメール通知となる。

メールでは変更しなかったrouter-1,2,3は no change となっています。

 

 

 

 

3.追加情報

変更(差分)があった場合のみメール通知する事も可能

(差分がない場合はメール自体が送信されません)

 

NCM 'real time change detection' 機能について

詳細は NCM Administrator Guideの121ページから128ページのstep6まで

概略は以下url をご参照ください。

https://support.solarwinds.com/Success_Center/Network_Configuration_Manager_(NCM)/Configure_Real-time_Configuration_Change_Detection

 

よりシンプルな手順は

Settings>All settings>NCM設定>Configure Real-Time Change Detection

にも記載されています。

 

この機能を使って、Ciscoの場合とYamaha RTX1100の場合の設定例を紹介します。

テストはNPM12.0  NCM7.5で実施。

 

1. Ciscoの場合のCisco側設定

  logging 192.168.12.167  <-Syslogビューア(NCM) のIP address

 

2. Yamaha の場合のYamaha RTX1100側設定

  syslog host 192.168.12.167

 

3. RCM側 'Syslogビューア' の設定

  デスクトップ アプリで'Syslogビューア'を起動

  

View>Alerts/Filter Rules

 

すでにあるNCM rules Cisco IOS Realtime Change Notificationを選んでCopyしSample 画面(例)のように必要箇所を入力しOK

 

  General 画面で該当ノードの指定 下記例では(Yamaha RTX1100のIP address 192.168.12.168を指定)

 

  Message画面でsyslog に出力される典型的なパターンを記述する。

     Yamaha RTX1100の例として'administrator' succeeded を指定

  Ciscoの例としては、Configured from console by vty0 を指定

 

4. RCM側アラート設定

   

  アラート:Real-Time config change detection のメール通知設定

  Real-Time config change detection をcopyし設定した例:

 

‘アクションを追加’で’電子メール/ページを送信’を選んで宛先メールアドレスとメールサーバー情報を入力

5. Real-Time Change Detection をEnableにする

  Settings>All settings>NCM設定>Configure Real-Time Change Detection

     Step 6 でEnableにし送信をクリック

 

6. テスト

    Yamaha RTX1100にtelnet, administrator にloginし抜けてsyslog->alert の詳細を表示し、メールで通知も確認

    Ciscoの場合はconfigure terminal で設定モードに入って、実際に設定変更するしないに関わらず、

  Configured from console by vty0 がsyslogに出力され->アラート->メール通知となります。

   

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.