По долгу службы, мне часто приходится анализировать NFS-трафик. Wireshark является моим основным инструментом и для него я даже создавал расширение на lua. Но чего-то не хватало. И вот две недели назад я наткнулся на новый для меня инструмент Packetbeat. К сожалению, paketbeat
Packetbeat
Paketbeat — это один из инструментов из комплекта beats от создателей elasticsearch, logstash и kibana. Это отправитель (shipper) данных в elasticsearch, который слушает сетевой трафик, конвертирует его в json-записи и посылает в elasticsearch. Если вы используете Kibana4, то есть стандартные панели для визуализации собранного трафика. На данный момент, packetbeat распознаёт TCP, UDP, DNS, ICMP, HTTP, memcache, MongoDB, redis, PostgreSQL, MySQL, thrift и, теперь уже, NFS. Где-то внутри, packetbeat использует libpcap.
Как добавить свой протокол
Packetbeat написан на go. Код находится на гитхаб и содержит файл с инструкцией как добавить новый протокол. Что отсутствует, так это 'желаемый' формат создаваемого json объекта.
Обработка NFS трафика
Обработка NFS (как и наверно всего остального) трафика происходит по следующей схеме:
- собираем tcp-пакеты, пока сообщение не полностью получено
- разбираем rpc-заголовок
- если это запрос, создаём новую запись и кладём её в специальный кеш.
ключом в кеш-е используется xid (идентификатор rpc-транзакции) - если это ответ, берём соответствующую запись из кеш-а, добавляем
информацию из ответа, добавляем время, которое потребовалось серверу
на обработку запроса и отправляет запись в 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 юзеров и групп
- время отклика сервера
(ваши варианты)
Прослушивание трафика
Самым простым вариантом будет запустить packetbeat на NFS сервере. Если такая возможность отсутствует, то можно использовать port mirroring на свиче. Подробно об этом можно прочитать тут.
Packetbeat имеет конфигурационный файл, где нам нужно сказать, что он должен делать:
interfaces:
device: any
protocols:
nfs:
ports: [2049]
logging:
level: info
output:
elasticsearch:
hosts: ["elasticsearch.node.name:9200"]
Указывается конфигурационный файл ключом '-c'.
Вместо заключения
Надеюсь дочитав до этого места вы узнали что-то новое.
Комментарии (6)
antage
03.04.2016 15:53А какая-то аггрегация, фильтрация и предобработка пакетов есть? Или весь трафик прямиком идет в ES?
tmk826
03.04.2016 16:30JSON-записи прямо отправляются в ES. Агрегация и фильтрация происходят после в кибане.
blind_oracle
04.04.2016 01:58Там таки не весь траффик идет, насколько я понимаю, а аггрегированный в события, специфичные для протокола. Эдакий аналог netflow, но более высокоуровневый.
tmk826
04.04.2016 10:00Да, первая фильтрация происходит на уровне libpcap. Выбираются пакеты, которые как порт отравителя или порт получателя имеют указанный в конфигурационном файле порт. Следующий уровень фильтрации происходит на уровне протокола — обрабатываются пакеты соответствующие спецификации протокола. В ES отправляются только json-варианты пакетов, Но агрегация, типа сума переданных байтов, происходит на стороне ES.
DuD
Вот смотрю я на эти графики от packet beat, красиво все информативно, но какова цена? Какой overhead от этого "сниффера" и подходит ли он для серьезных нагрузок?
tmk826
packetbeat съедает порядка 10% CPU. Какое количество пакетов остаётся пропущенными, сказать пока не могу. Но так-как в основе лежит libpcap, то потери будут одинаковые с аналогичными инструментами, как tcpdump или wireshark. В отличии от wireshark, не создаётся временный файл и, соответственно, packetbeat не зависит от свободного места на диске. Мы смотрим NFS-трафик всего лишь неделю. Проблем пока не замечено, но всё возможно ещё впереди.