ТЛ;ДР : автор собрал сборщик NetFlow/sFlow из GoFlow , Кафка , Кликхаус , Графана и костыль для Го.
Здравствуйте, я эксплуататор и мне очень нравится знать, что происходит в инфраструктуре.
Еще я люблю вмешиваться в дела других людей, и на этот раз я зашел в Интернет. Предположим, у вас есть собственное сетевое оборудование и мешок монолитов, микросервисов и микросервисных монолитов, торчащих в Интернете со своими зависимостями в виде баз данных, кешей и FTP-серверов.
А иногда некоторые обитатели этого мешка начинают шалить в сети.
Вот лишь несколько примеров таких розыгрышей:
- резервное копирование за пределами предписанного окна в 40 потоков;
- ошибки конфигурации, которые отправляют приложение в одном DC в кеш другого DC;
- Вопросы приложения в соседней стойке к тому же кэшу «дайте мне этот полумегабайтный объект из кэша» двести раз в секунду.
Протоколы приходят на помощь Поток данных, передающихся по сети / ИПФИКС И sFlow , которые генерируют обширную информацию о трафике непосредственно с сетевого оборудования.
Остается только его куда-то положить и как-то обработать.
Из имеющихся сборщиков NetFlow были рассмотрены следующие:
- flow-tools — мне не понравилось хранение в файлах (долго делать выборки, особенно быстрые в процессе реагирования на инцидент) или MySQL (иметь там таблицу с миллиардами строк кажется довольно мрачная идея);
- Elasticsearch+Logstash+Kibana — очень ресурсоемкая комбинация, до 6 ядер старенького 2,2ГГц ЦП для получения 5000 потоков в секунду.
Однако Kibana позволяет вам запускать любые фильтры в браузере, что очень ценно;
- vflow — мне не понравился формат вывода (JSON, который без модификации невозможно сложить в Elasticsearch);
- коробочные решения – они мне не понравились ни из-за высокой цены, ни из-за небольшого отличия от выбранного.
Общая схема простого коллектора выглядит следующим образом: 
GoFlow анализирует пакеты NetFlow/sFlow и помещает их в локальную Kafka в формате protobuf. Самописная «лопата» goflow2ch принимает сообщения от Kafka и пакетно передает их в Clickhouse для большей производительности.
Схема вообще не решает вопрос высокой доступности, но для каждого компонента существуют либо стандартные, либо более-менее простые внешние способы ее обеспечения.
Тесты показали, что затраты ЦП на парсинг и сохранение тех же 5000 потоков в секунду составляют примерно четверть ядра ЦП, а потребляемое дисковое пространство в среднем составляет 11-14 байт на слегка усеченный поток.
Для отображения информации используйте веб-интерфейс ClickHouse под названием Табикс , или плагин для Графаны .
Плюсы схемы:
- возможность задавать произвольные вопросы о состоянии сети с помощью диалекта SQL;
- низкие требования к ресурсам и горизонтальная масштабируемость.
Подойдут старые/медленные процессоры и магнитные жесткие диски;
- при необходимости собирается полноценный конвейер данных для анализа сетевых событий, в том числе в реальном времени с использованием Kafka Streams, Flink или аналогов;
- возможность сменить хранилище на произвольное минимальными средствами.
- Чтобы задавать вопросы, необходимо хорошо знать SQL и его диалект ClickHouse; нет готовых отчетов и графиков;
- Множество новых движущихся частей в виде Kafka, Zookeeper и ClickHouse. Первые два написаны на Java, что может вызвать неприятие по религиозным соображениям.
Лично для меня это не было проблемой, так как все это уже так или иначе использовалось в организации;
- вам придется написать код. Либо «лопата», передающая данные из Kafka в ClickHouse, либо адаптер для записи напрямую из GoFlow.
- Обязательно стоит настроить ротацию по размеру данных в Kafka и ClickHouse, а потом проверить, действительно ли это работает. В Kafka есть ограничение на размер раздела журнала, а в ClickHouse есть разбиение на основе произвольного ключа.
Новый раздел каждый час и удаление ненужных разделов каждые 10 минут хорошо работают для оперативного мониторинга и выполняются скриптом буквально в несколько строк;
- «лопата» выигрывает от использования группы потребителей , позволяющий добавить больше «лопат» для масштабирования и отказоустойчивости;
- Kafka позволяет не потерять данные в случае сбоя «лопаты» или самого ClickHouse (например, от тяжелого запроса и/или неправильного ограничения ресурсов), но лучше, конечно, тщательно настроить базу данных;
- Если вы собираете sFlow, помните, что некоторые свичи по умолчанию меняют частоту выборки пакетов на лету, и она указана для каждого потока.
Несмотря на то, что система требует ношения на коленях, она уже помогла значительно сократить время, необходимое для разрешения нескольких инцидентов.
Теги: #Сетевые технологии #Системное администрирование #clickhouse #Netflow
