Vector.dev: затащили в PoC

Как оно там, внутри

На данный момент у нас двухуровневая иерархия векторов:

• —  агентский Vector.dev, который собирает логи с FreeIPA и OpenNebula серверов, а также наших Prometheus экспортеров;

• — центральный Vector.dev, который агрегирует данные от агентских векторов.

В планах добавить третий уровень – прокси для различных локаций или контуров, но пока без этого.

Центральный Vector.dev запущен в Kubernetes и отправляет данные в кластер ClickHouse, агентские ставятся просто из deb-пакетов.

File source или работа с файлами

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

Многострочные логи

У File source есть такая конфигурация как multiline. Из названия понятно, что объединяет несколько строчек логов в одну запись. Интересно то, что даже если на первый взгляд кажется, что в логах нет многострочных записей, то это может быть заблуждение.

Вот пример вывода части файла, ничего не указывает на многострочные логи:

Но если покопаться в файле, то замечаем, что запись лога является многострочной. Если это не обрабатывать отдельно, то каждая новая строчка такой многострочной записи будет новой записью в ClickHouse и никак не связана с предыдущей строкой лога.




Поэтому для обеспечения логической связности сообщения логов некоторые записи приходится обрабатывать как многострочные. Но с вектором это достаточно просто, мы использовали следующую конфигурацию на основе регулярных выражений (здесь нам помогает то, что каждая отдельно взятая запись начинается с временной метки):

Вектор уже сам склеивает многострочные сообщения и отправляет их в ClickHouse объединенными.

Fingerprint

Другой пример – это настройка правила определения «уникальности» лог-файла. Параметр fingerprint определяет, как файл идентифицируется. Это актуально для систем с включенной ротацией логов.

По умолчанию – это checksum (берутся строчки с начала файла и по ним считается контрольная сумма, даже интереснее по умолчанию берется одна первая строка). С одной стороны, какие могут быть проблемы? Действительно, большинство логов содержат в каждой записи уникальное значение – временную метку. Тогда все просто. Оказывается, что есть системы и лог-файлы, у которых шапка в начале каждого лог-файла одинаковая. В итоге получаем, что вектор не может различить файлы.

К сожалению, настройки, позволяющие игнорировать какое-то количество строк при вычислении контрольной суммы в векторе, нет (т.е., по сути, игнорировать статический заголовок), есть настройка (fingerprint.ignored_header_bytes), позволяющая пропускать определенное количество байт, но по выводы ниже видно, что рассчитать в нашем случае количество байт не получится. Но есть другая настройка – она определяет, какое количество строк учитывается для подсчета контрольной суммы. Ей мы и воспользовались.

Продолжение статьи читайте на Хабре.