TL;DR: автор собрал коллектор NetFlow/sFlow из GoFlow, Kafka, ClickHouse, Grafana и костыля на Go.

Здравствуйте, я эксплуататор и очень люблю знать, что происходит в инфраструктуре. А ещё я люблю лезть в чужие дела, и в этот раз залез в сеть.

Предположим, у вас есть своё сетевое оборудование и мешок торчащих в интернет монолитов, микросервисов и монолитов микросервисов с их зависимостями в виде баз данных, кэшей и FTP-серверов. И иногда некоторые обитатели этого мешка начинают в сети шалить.

Вот лишь некоторые примеры таких шалостей:

• резервное копирование вне предписанного окна в 40 потоков;
• ошибки конфигурации, посылающие приложение в одном ДЦ в кэш другого ДЦ;
• вопросы приложения в соседней стойке к тому же кэшу “дай мне вот этот полумегабайтный объект из кэша" двести раз в секунду.

SNMP счётчики с портов коммутаторов или ВМ дадут только приблизительно понять, что происходит, а хочется точности и быстроты анализа проблем. На помощь приходят протоколы NetFlow/IPFIX и sFlow, которые генерируют богатую информацию о трафике прямо с сетевого оборудования. Осталось её куда-то сложить и как-то обработать.

Из имеющихся NetFlow коллекторов были рассмотрены следующие:

• flow-tools — не понравился хранением в файлах (долго делать выборки, особенно оперативные в процессе реакции на инцидент) или MySQL (иметь там таблицу в миллиарды строк кажется довольно безрадостной затеей);
• Elasticsearch + Logstash + Kibana — очень ресурсоёмкая связка, до 6 ядер пожилого 2.2 ГГц CPU на приём 5000 потоков (flows) в секунду. Однако, Kibana позволяет натыкать какие угодно фильтры в браузере, что ценно;
• vflow — не понравился выходным форматом (JSON, который без модификации невозможно сложить в тот же Elasticsearch);
• коробочные решения — не понравились либо высокой ценой, либо малым отличием от выбранного.

А выбрано было описанное в презентации Louis Poinsignon на RIPE 75. Общая схема простого коллектора получилась такая:

GoFlow разбирает NetFlow/sFlow пакеты и складывает их в локальную Kafka в формате protobuf. Самописная “лопата” goflow2ch вынимает сообщения из Kafka и перекладывает их в Clickhouse пачками для большей производительности. В схеме совершенно не рассматривается вопрос высокой доступности, но для каждого компонента есть или штатные, или более-менее простые внешние способы её обеспечения.

Испытания показали, что затраты CPU на разбор и сохранение тех же 5000 потоков в секунду составляют примерно четверть ядра CPU, а занимаемое дисковое пространство в среднем 11-14 байт на слегка усечённый поток.

Для отображения информации используется либо Web UI для ClickHouse под названием Tabix, либо плагин для Grafana.

Плюсы схемы:

• возможность задать произвольные вопросы о состоянии сети при помощи диалекта SQL;
• нетребовательность к ресурсам и горизонтальная масштабируемость. Подойдут старые/медленные процессоры и магнитные жёсткие диски;
• при необходимости собирается полноценный data pipeline для анализа сетевых событий, в том числе в реальном времени при помощи Kafka Streams, Flink или аналогов;
• возможность смены хранилища на произвольное минимальными средствами.

Минусов тоже порядочно:

• чтобы задавать вопросы, нужно неплохо знать SQL и его ClickHouse-диалект, готовых отчётов и графиков нет;
• множество новых движущихся частей в виде Kafka, Zookeeper и ClickHouse. Два первых на Java, что может вызывать отторжение по религиозным мотивам. Лично для меня сие проблемой не было, так как всё это уже так или иначе использовалось в организации;
• придётся писать код. Либо “лопату”, перекладывающую данные из Kafka в ClickHouse, либо адаптер для записи прямо из GoFlow.

Встреченные особенности:

• следует обязательно настраивать ротацию по размеру данных в Kafka и ClickHouse, а потом проверять, что она действительно работает. В Kafka есть лимит на размер партиции лога, а в ClickHouse — партицирование по произвольному ключу. Новая партиция каждый час и удаление лишних партиций каждые 10 минут неплохо работают для оперативного мониторинга и делаются скриптом буквально из нескольких строк;
• “лопата” выигрывает от использования consumer groups, позволяющих добавлять больше “лопат” в целях масштабирования и отказоустойчивости;
• Kafka позволяет не терять данные при падении “лопаты” или самого ClickHouse (например, от тяжёлого запроса и/или некорректно ограниченных ресурсов), но лучше, конечно, внимательно настроить БД;
• если будете собирать sFlow, помните, что некоторые коммутаторы по умолчанию меняют частоту выборки пакетов на ходу, и она указывается для каждого потока.

В итоге из компонентов с открытым исходным кодом и синей изоленты получен инструмент наблюдения за обстановкой в сети как в плюс-минус реальном времени, так и в исторической перспективе. Несмотря на свою наколеночность, он уже помог уменьшить время решения нескольких инцидентов в разы.