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, помните, что некоторые коммутаторы по умолчанию меняют частоту выборки пакетов на ходу, и она указывается для каждого потока.

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

Комментарии (8)


  1. oldbay
    25.09.2018 12:09
    +1

    «Я тебя слепила из того что было.»


  1. rt3879439
    25.09.2018 14:29

    Потыкайте палочкой ntopng.


  1. Sleuthhound
    25.09.2018 18:41

    Ntopng Community версия урезана по функционалу, в свое время испытывал ее.


  1. sohmstyle
    25.09.2018 22:58

    А пробовали SiLK от CERT?
    У меня не было большого опыта сравнения производительности с другими коллекторами, но если делать запросы к записям с суммарным объёмом под 100 GB, то rwfilter думает иногда долго. Но этот анализатор больше под консоль заточен, поэтому не всем подойдёт.


    1. rzerda Автор
      26.09.2018 12:26

      Нет, не пробовал. Запросы и в моей схеме работают не очень быстро, особенно если спросить что-нибудь нетривиальное (да и процессора на ClickHouse я несколько пожалел). Но меня подкупили интерфейсы (бинарный формат для потоков и SQL для запросов), а также возможность менять хранилище или даже использовать несколько одновременно. В ЛС мне подсказали про pmacct, который тоже умеет писать в Kafka и AMQP, но и его я не смотрел ещё.

      В этой истории меня сейчас больше беспокоит представление информации. Например, в Prometheus/Grafana вызывающе легко набросать ad-hoc график и посмотреть нужное без опоры на заранее созданные дашборды. Писать SQL даже по одной простой таблице посложнее, особенно если делаешь это нечасто.


  1. rzerda Автор
    26.09.2018 12:21

    del


  1. Vetal130
    27.09.2018 18:43

    Ссылка на github с кодом будет?
    Спасибо


    1. rzerda Автор
      27.09.2018 18:50

      Нет; код страшный, под комтайной, а единственная реакция на ошибки — «падай, systemd переподнимет».

      Автор GoFlow разместил пример использования, его при необходимости вполне можно творчески переосмыслить: github.com/cloudflare/flow-pipeline.