勤務中は、NFSトラフィックを分析する必要があります。 Wiresharkは私のメインツールであり、彼のためにluaの
拡張機能を作成しました。 しかし、何かが欠けていました。 そして2週間前、私は新しい
Packetbeatツールに
出会いました。 残念ながら、paketbeat
は NFSを
サポートしておらず、 NFSを
サポートしていませんでしたが、この欠点を何とか修正できました。
パケットビート
Paketbeatは、elasticsearch、logstash、kibanaの作成者による
ビートツールの1つです。 これは、ネットワークトラフィックをリッスンし、jsonレコードに変換してelasticsearchに送信するelasticsearchのデータシッパーです。 Kibana4を使用する場合、収集されたトラフィックを視覚化するための標準パネル
があります。 現時点では、packetbeatはTCP、UDP、DNS、ICMP、HTTP、memcache、MongoDB、redis、PostgreSQL、MySQL、thrift、そしてNFSを認識します。 内部のどこかで、packetbeatはlibpcapを使用しています。
プロトコルを追加する方法
Packetbeatはgoで記述されています。 コードはgithubにあり、新しいプロトコルを追加する方法の手順が記載されたファイルが含まれています。 不足しているのは、作成されるjsonオブジェクトの「望ましい」形式です。
NFSトラフィック処理
NFS（およびおそらくその他すべて）トラフィックの処理は、次のスキームに従って発生します。
- メッセージが完全に受信されるまでtcpパケットを収集します
- rpcヘッダーの解析
- これがリクエストの場合、新しいレコードを作成して特別なキャッシュに入れます。
キャッシュ内のキーはxid（rpcトランザクションID）です - これが答えである場合、キャッシュから適切なエントリを取得し、追加します
応答からの情報、サーバーにかかった時間を追加します
要求を処理し、レコードをelasticsearchに送信します。
作成されたレコードは次のようになります。
{ "@timestamp": "2016-03-28T06:18:18.431Z", "beat": { "hostname": "localhost", "name": "localhost" }, "count": 1, "dst": "127.0.0.1", "dst_port": 2049, "nfs": { "minor_version": 1, "opcode": "GETATTR", "status": "NFSERR_NOENT", "tag": "", "version": 4 }, "rpc": { "auth_flavor": "unix", "call_size": 200, "cred": { "gid": 500, "gids": [ 491, 499, 500 ], "machinename": "localhost", "stamp": 4597002, "uid": 500 }, "reply_size": 96, "status": "success", "time": 25631000, "time_str": "25.631ms", "xid": "2cf0c876" }, "src": "127.0.0.1", "src_port": 975, "type": "nfs" }
このデータを取得すると、次の情報を取得できます。
- さまざまなリクエストの数
- エラーの数と種類
- 上位Nの顧客
- 上位Nのユーザーとグループ
- サーバーの応答時間
（オプション）
トラフィックを聞く
最も簡単なオプションは、NFSサーバーでpacketbeatを実行することです。 これが不可能な場合は、スイッチの
ポートミラーリングを使用できます。 詳細については、
こちらをご覧ください 。
Packetbeatには設定ファイルがあり、そこで何をすべきかを言う必要があります。
interfaces: device: any protocols: nfs: ports: [2049] logging: level: info output: elasticsearch: hosts: ["elasticsearch.node.name:9200"]
構成ファイルは「-c」オプションで指定されます。
結論の代わりに
この場所を読んで、何か新しいことを学んだことを願っています。