Казалось бы простая задача - переместить логи из пункта А в пункт Б, что тут сложного. Но даже для такой пустяковой задачи придумали множество ПО: как более популярных Rsyslog, Logstash, fluentd, fluentbit, так и менее известных как file.d, недавно принудительно-опенсорснутая Пилорама (спасибо, Яндекс!) и множество других.

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

Моя цель

На написание статьи меня натолкнуло несколько вещей.

Я иногда вижу людей, которые берут Vector и тянут его в бой, потому что он же "safe blazing fast" - значит всё хорошо! Меня такие люди огорчают, потому что я же знаю - как только они вкусят проблем (а оно так и будет), то не разбираясь в проблемах выкинут Vector и возьмут что-то другое. По итогу только зря время потратят и потом будут рассказывать, какой Vector плохой, а-та-та.

В то же самое время некоторые люди осознанно Vector берут в бой по ряду причин. И для этих людей хотелось бы подсветить основные ловушки, которые их могут ожидать и как можно их разминировать (или по крайней мере чтобы болело не очень сильно).

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

Важное уточнение. По ходу статьи я буду делать оценку тех или иных сторон Vector исходя не из сравнения с конкурентами ("Vector то может мог быть и побыстрее, но вот Logstash..."), а по моим внутреннием ощущениям. Хорошее сравнение с другими перекладывалками я сделать не могу, потому что в них не разбираюсь - простите пожалуйста. Поэтому если я где-то говорю "плохо", то это вполне можно оказаться "приемлемо", а то и "хорошо" по сравнению с другими продуктами в данной нише - держите это в уме при чтении статьи.

О чём не пойдёт речь

Я не буду сравнивать Vector c другими перекладывалками логов по простой причине - я в других перекладывалках не разбираюсь на достаточном для качественного сравнения уровне. Что-то базовое (количество плагинов, сколько мейнтейнеров, примерная скорость работы) я может и знаю, а вот наиболее интересные моменты - нет. В таком "поверхностном" сравнении вижу довольно мало практического смысла - вы это отлично сможете сделать сами с учётом вашей локальной специфики. Это будет точно намного полезнее для вас.

Бенчмарков между проектами тоже не будет, потому что:

1. Бенчмарки это очень долго и сложно. У меня такой цели нет (по крайней мере пока что). Да и в актуальном состоянии их держать - отдельное искусство.

2. Чтобы делать качественные бенчмарки, нужно действительно хорошо разбираться во всех участниках бенчмарка, а не только в одном. А я так не умею на данный момент.

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

Очень краткое (правда-правда) введение в Vector

Vector - очередная перекладывалка логов, только в этот раз написан на blazingly fast языке программирования Rust. Open source (GitHub), MPL-2.0 лицензия, разрабатывается за счёт Datadog (все разработчики Vector, которые на зарплате - из этой компании). Перекладывалка живая, быстрая, удобная, фичастая - всё как мы любим. Более подробно - на официальном сайте, не хочу лишний раз повторяться.

А вот что мы не любим, так это проблемы.

Стабильность

Vector хоть и написан на ржасте, но всё ещё падает (простите, panic'ует). Причём делает он это зачастую интересно. Внутри Vector обычно работает N потоков (подробнее тут). И вот если что-то сильно идёт не так, то один этот тред паникует, в лог у вас высыпается ошибка, а Vector продолжает работать дальше. Типичный паникующий Vector выглядит вот так - пример далеко не единственный. Сам лично поправил наверное 3-4 места, где оно "внезапно ложилось".

Если у вас есть на это мониторинг\алертинг (средства для этого есть) - повезло, вы придёте, посмотрите в логи, рестартанёте Vector. Не повезёт - не увидите, процесс то скорее всего останется работать. Тогда у вас может быть целый набор приключений: может просто пропускная способность снизится (воркеров то меньше стало) в части Vector. А может через некоторое время отвалятся все воркеры, и тогда ваш лог пайплайн встанет полностью - нехорошо!

Хорошая новость состоит в том, что паникует Vector всё же нечасто.

Что с этим делать? Настраивайте мониторинг с алертингом, следите за баг трекером с чатом дискорда за известными проблемами, настраивайте высокодоступные конфигурации Vector, применяйте рекомендуемый rollout.

Отдельно отмечу наиболее "багованные" по моему опыту части Vector, которые лучше не трогать без сильной на то причины:

1. Перезагрузка конфигов. Это просто феерия багов и падений. Пожалуйста, не используйте это без очень веской на то причны. Оценить масштаб можно например вот по такому фильтру.

2. Компоненты, которые появились относительно недавно и ещё не апробированы временем. Совет довольно капитанский, но нельзя не упомянуть. Для оценки степени доверия могу рекомендовать использовать статусы компонентов.

3. Просто баги. Тут особо системы нет - проверяйте, что вас конкретно интересует. Иногда конечно баги бывают особо феерические: логи просто перестают собираться.

Также обратите внимание, что Vector местами отламывает фичи между релизами. Это реальная жизнь, такое случается (и не единожды) - просто будьте к этому готовы (читайте release notes, читайте чат Discord). Тестируйте новые версии, раскатывайте новые версии постепенно. Vector в целом склонен к тому, чтобы поддерживать обратную совместимость, так что будет немного легче. Я вот подумываю в Vector чат в Telegram добавить бота с анонсом новых релизов - чтобы чуть проще было узнавать. К чести векторовцев - если в новой версии обнаруживаются серьёзные баги, то они обычно выкатывают достаточно быстро фикс-версию. Поэтому если новые фичи горят не очень сильно, возможно стоит подождать фикс-версий, чтобы обновляться.

Как начинать знакомство с функционалом, который вам интересен? Я для себя выработал следующий алгоритм:

1. Открываем документацию и читаем

2. Открываем Issues и ищем. Если нашли - пингуем и спрашиваем, когда пофиксят.

3. Открываем Discussions и ищем. Если нашли - пингуем и спрашиваем, до чего договорились.

4. Открываем Pull Requests и ищем. Если нашли - пингуем и спрашиваем, когда вмержат.

Если ещё что-то непонятно - спрашиваем в Discord в разделе Support. Там помогают. На практике такой алгоритм работает достаточно хорошо (хоть и отнимает время). Зато с вектором поближе познакомитесь :)

Недостающий функционал

Vector имеет довольно много плагинов. Но вместе с тем на практике случается, что конкретно нужного вам может и не быть. Хоть и кажется, что ваш случай вполне себе среднестатистический. Обычно это либо отсутствующий плагин (такие как SNMP, STOMP, RELP), либо просто какой-то функционал в уже существующем плагине.

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

Например, когда мы исследовали для себя применимость Vector, собрали вот такой "букет":

1. Отсутствие возможности сконфигурировать "drop_oldest" поведение для логов внутри буфера Vector: тык.

2. Потеря сообщений в Kafka при рестарте кластера: тыц.

3. Частично неработающий bulk mode при записи в ElasticSearch: туц.

4. Возможная out-of-order передача данных в Каfka: ссылка.

5. Возможное нарушение порядка передачи сообщений между инстансами Vector: и ещё.

6. Возможная утечка памяти из-за особенностей работы с метриками: вот.

7. Нет поддержки DLQ: иссус.

8. Потеря логов на ровном месте: парам-пам-пам.

И это только что, нам бросилось на первый взгляд без особо глубокого погружения. У вас он будет свой :)

И это не считая таких мелочей, что ElasticSearch sink стал работать более-менее нормально только относительно недавно, поддержка AMQP на source/sink появилась только осенью 2022, k8s логи иногда не читаются. И такого к сожалению очень много. А это означает, что роль "универсального" клея выполнять сложнее. Если кратко, то я сказал бы, что довольно много если не "детских болезней", то шероховатостей в текущей версии.

Производительность

Vector написан на blazingly fast Rust. Исходя из этого, можно в целом попробовать оценить производительность плюс-минус такой же, как и у fluentbit (который написан на C). Но все мы понимаем, что не языком единым.

С производительностью в Vector штука сложная. С одной стороны, разработчики Vector утверждают, что после переключения на Vector пользователи обычно получают повышение производительности. Правда по сравнению с чем - непонятно. Может быть по сравнению с Logstash? :) По моему личному опыту - в целом похоже на правду.

С другой стороны, производительность Vector очень сильно зависит от качества того плагина, который вы используете. Например, File и Kubernetes source плагины имеют очень большие проблемы с производительностью из-за своей крайне неэффективной реализации метрик. К сожалению, данная проблема не исправляется отключением метрик на уровне конфигурации Vector. Сколько ещё плагинов подвержено проблемам подобного рода из-за метрик - я не знаю (разработчики Vector тоже не знают). Более того, пока что данной проблемой разработчики Vector заниматься не собираются по каким-то внутренним причинам. Единственная работа, которая идёт в направлении этого ужасного недоразумения - этот PR с исправлением File плагина. Когда очередь дойдёт до остальных - неизвестно. Поэтому если для вас проблема критична - придётся самим патчить Vector каким-либо образом и, возможно, отправлять свои патчи в апстрим, если лень самим поддерживать на будущие версии (а вам будет лень, потому что Vector активно разрабатывается, и ваши патчи будут постоянно отламываться).

Ещё один пример - батчинг. Некоторые (тыц, тыц) плагины его просто не реализуют. Для некоторых плагинов PR на исправление уже есть, как будет для других - непонятно. Разработчикам Vector пока что не до этого, судя по всему.

Кстати! Для тех, кто любит перф со вкусом "пожёстче", то очень рекомендую попробовать собрать Vector c помощью PGO. Как это сделать - почитайте тут. Разработчики Vector данный подход пока что не интегрировали в свой пайплайн сборки, чтобы ускорить бинари у конечных пользователей. Но всё может поменяться в будущем (может быть наверное когда-нибудь я надеюсь если будет у них время и желание). Этот способ также можно попробовать применить к rsyslog и fluentbit - я не пробовал, но вдруг именно вам интересно будет.

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

Лично мой совет по оценке производительности Vector. Подготовьте свои собственные сценарии использования Vector, протестируйте их на последней версии Vector, посмотрите на результаты по скорости, потреблению ресурсов и так далее. Также для оценок метрик самого Vector может помочь vector top и internal_metrics плагин, который можно скрапить через тот же Prometheus exporter.

Где вас могут ждать подвохи:

1. Если у вас хоть одна часть лог пайплайна работает медленно, то она будет замедлять весь пайплайн и блокировать операции. Про это достаточно подробно написано здесь, но я всё равно часто вижу вопросы про данное поведение.

2. Вы попали на плагин, где метрики отжирают всё. Проверить это легко - запустите Vector под flamegraph и посмотрите профиль (не забудьте только пересобрать с debug = true в Release mode. Если увидите в графе много вещей аля emit! - поздравляю, у вас метрики! Патчите Vector\нойте разработчикам, чтобы фиксили.

3. У вас тупит какая-то внешняя система. Тут уже нужно смотреть. Либо реализация в Vector очень такая себе (профайлер и Discord в помощь), либо у вас конфигурация не совсем оптимальная (документация и бенчмарки в помощь. Особенно обратите внимание на батчинг - скорее всего поможет), либо внешняя система (там вы уже сами знаете, что делать).

Документация

Документация в Vector хорошая (это как моё мнение, так и мнение всех моих коллег). Тут тебе и описание плагинов, и референсные архитектуры развёртки, и описание около-векторных утилит. Однако это не мешает документации время от времени стучать вам в лоб черенком. Приведу несколько примеров:

1. Список метрик. Он в целом верный, но местами лжёт - будьте к этому готовы. У меня это стрельнуло, когда разрабатывал Grafana dashboard для Vector. В документации метрика есть, а на самом деле - её нет, или она с другими лейблами. Это же и касается документации метрик самих компонентов - могут врать. Что с этим делать? Репортить в апстрим, спрашивать в Discord, читать исходники (если умеете - они в плане метрик не самые тривиальные в Vector).

2. Незадокументированные возможности. Например, в Vector есть концепция буферов. Но мало кто знает, что на самом деле он более гибкий и позволяет делать иерархии буферов (что на практике полезно). Формально, оно ещё на GA, но что мешает задокументировать хоть как-то с пометкой "unstable" - непонятно. А вот если бы не спросил в Discord - так и не узнал бы о фиче.

3. Местами документация просто упускает достаточно важные (с точки зрения конечного пользователя) детали реализации. Например, то, что kuberenetes_logs плагин читает логи из файловой системы (тыц). Не повезло человеку, повозился, пришёл в Discord, узнал, документацию доработали. Или например есть довольно удобный Vector API. Вещь может быть полезной для написания кастомных интеграций в ваш родной control plane. Но вот вся документация - это GraphQL playground, который нужно локально поднимать - онлайн варианта я не знаю. Очень неудобно - в моём случае мне было намного проще посмотреть в исходниках, что да как работает.

4. А местами документация вообще непонятно, зачем есть. Например, страница Tuning. Полезной информации по тюнингу там конечно маловато. А ведь могли бы и про PGO упомянуть! (да знаю-знаю - чуть позже сделаю PR с соответствующей заметкой, если руки дойдут).

5. Иногда она просто неочевидна. Пользователь может ожидать по умолчанию, что логи будут передаваться в порядке поступления, то есть порядок логов будет сохраняться. Но в Vector это не так, так как он обрабатыает логи в N потоков. И для того, чтобы включить сохранение порядка, нужны специальные неочевидные настройки.

Векторовцы борятся с плохой документацией (за что им отдельное спасибо). Например, есть отдельный epic для внедрения авто-генерируемой документации, чтобы она меньше расходилась с кодом: тык, но работы ещё предстоит достаточно много.

Расширяемость

Vector не имеет возможности разрабатывать свои плагины. Поэтому если нужного вам input/output плагина нет в Vector (в терминах Vector они называются source/sink соответственно) - вам придётся патчить сам Vector и перекомпилировать его, очень неудобно. Когда плагины появятся - неизвестно. Где-то в Discord была информация, что планы по разработке RFC для плагинов были на 2023 год, а когда будет уже сама реализация - даже разработчики не знают. Грустно.

Что касается уровня трансформации логов, то здесь ситуация получше. Есть стандартный набор функций, есть собственный язык VRL, есть интеграция с Lua. Но у каждого способа есть свои нюансы:

1. Стандартный набор функций довольно ограничен. Свои функции туда без модификации Vector не добавить.

2. VRL - ещё один DSL, который придётся освоить. К тому же некоторые моменты могут быть неочевидны даже с документацией + всё же сыроват местами. Если хотите расширить VRL - снова же только через модификацию Vector. Для игрищ с VRL рекомендую онлайн VRL playground - поможет быстро разобраться, что к чему. Можно прямо из Vector поднять свой в закрытом контуре (это для особо "запущенных" случаев).

3. Lua - вроде вариант и хороший, но судя по отзывам отрициально сказывается на производительности. Лично не проверял, не могу прокомментировать.

Есть вариант "рабоче-крестьянский": всё что можно делаем на Vector, потом каким-либо образом сгружаем в свою программу, там гоняем свои чудо-юдо фильтры (например, встроить что-нибудь ML-based для обнаружения паролей), и потом уже отправляем дальше по вашему пайплайну (можно даже обратно в Vector, хех).

Какой конкретно способ выбрать вам? Рекомендую по умолчанию пробовать использовать VRL. Если совсем не получается - переключайтесь на Lua.

Экосистема

Под экосистемой я понимаю разного рода интеграции Vector с остальным тулингом, который может оказаться рядом с ним в инфраструктуре. Она у Vector местами подхрамывает.

Например, у Vector есть встроенный довольно неплохой с точки зрения количества метрик мониторинг. Хочу простую вещь - снять метрики в Prometheus, настроить по ним Grafana dashboard и какие-то алерты базовые поднять. Ан нет, Vector не предоставляет Grafana dashboard из-коробки. Более того, они не особо и заинтересованы в поддержке такого добра, так как внутри Datadog они не используют Grafana в этом случае. Что делать? Не знаю, мейнтейнить дашборд самим, а это нетривиальная задача, потому что метрики то тут, то там добавляются активно. И держать это в синхронизированном состоянии без централизованного контроля и заинтересованности от мейнтейнеров - сложно. А об имеющемся полу-гнилом дашборде вы никак не узнаете из документации - только поискав в репозитории по issues/discussions/PRs.

Другой пример - k8s operator. Один товарищ написал для куба. Насколько полезный на практике - не знаю, лично я не использовал. Наверное полезный. Написал анонс в Discord, его похвалили и... всё. Информация об этом операторе нигде не фигурирует в документации.

Возможно есть какие-то ещё примеры, о которых я не знаю. Что с этим делать? Не стесняйтесь задавать вопросы в чатах по Vector в Telegram и Discord (ссылки будут в конце статьи). Пишите нужные вам интеграции сами и пробуйте выкладывать в открытый доступ.

Развитие Vector и его команда

Эта тема будет немного более абстрактная, но почему бы и нет?

Vector развивается компанией Datadog, в нём относительно много контрибуторов. Но есть пару "но".

Хоть issues и открыты, но вот приоритеты между исправлениями\фичами, которые векторовцы прогают - скрыт где-то в недрах Datadog. Время от времени в тех или иных задачах проскакивает информация, что конкретно эта задача - не в роадмапе. То есть вы не можете оценить, когда нужный конкретно вам функционал попадёт в Vector. Единственный на данный момент способ узнать - спросить на GitHub/Discord у кого-то из команды разработки, иначе никак.

Когда-то были попытки публичного роадмапа, но они умерли и воскресать не собираются. Работа над тем, что действительно важно для сообщества тоже ведётся довольно вяло. Максимум, что используется - это голосование "пальцами вверх" под каждой issue. Причём насколько это влияет на приоритеты внутри команды разработки - неясно. Есть issue от 2020 года (по меркам проекта - очень старые) с довольно большим количеством лайков - воз и ныне там. Никакие опросы аудитории или нечто подобное не проводится, насколько мне известно.

Разработка/доработка самого Vector не то чтобы сложный процесс (если вы можете хоть как-то писать на Rust). Разработчики отзывчивые, помогают чем могут (как в Discord, так и прямо на GitHub). Только учтите, что они все работают в американских часовых поясах - учитывайте это при взаимодействии с ними. По "нашему" времени шанс получить ответ в рабочее время крайне низок. Также у них внутри команды есть on-duty дежурство, кто отвечает на вопросы\делает code-review. Поэтому пинговать определённых людей - не всегда лучшая стратегия. Проще в Discord в чате спросить - кто-то да откликнется на просьбу. Если нужен конкретный человек из команды - его обязательно позовут, не переживайте :)

Кстати, если вы вдруг будете собирать Vector локально - приготовьте комп помощнее. дебажные билды по пару минут, а релизные по 10 минут - это норма (нет). Совет - через features отключайте ненужные для вас вещи, должно помочь. Также можно попробовать mold - а вдруг!

Доработка простых фичей (например, добавление новой метрики, исправление мелкого бага, доработка документации) обычно очень простые. Добавление более сложного функционала (например, новый плагин) - достаточно сложный процесс с написанием RFC, множеством раундов code review, написания тестов, документации, полировки и прочее. Поэтому если захотите написать что-то большое - будьте готовы, это не так просто. Для примерной оценки своих сил вот несколько примеров: исправление документации, простая фича, сложная фича.

Также думаю будет полезным дать краткую характеристику членам команды (оценка субъективная, конечно же), для более продуктивного контрибута. Наиболее охотно идут контакт и проявляют "дружелюбие" это Jesse Szwedko (менеджер команды, если я правильно всё понимаю), Spencer Gilbert, Stephen Wakely, David Huie. Другие тоже конечно же отвечают, просто чуть реже (скорее всего, они просто-напросто заняты другой работой). Люди, которые отвечают на наиболее сложные технические вопросы по внутрянке Vector: Bruce Guenter, neuronull, Toby Lawrence. Также у команды есть распределени по доменам, где они больше всего разбираются. Например, Bruce Guenter разбиарется в метриках. Теперь вы и с командой знакомы немного, поздравляю!

Если вы вдруг тоже заходите разрабатывать Vector за денюжку (ну а вдруг?), то можно начать с простого контрибута как человек со стороны. Есть очень неплохие шансы (проверено на практике), что вам предложат вакансию в команде (у них как раз появятся новые места с конца июля 2023 - информация их первых рук), так что если кому-то интересно - дерзайте! Заодно и пользу сообществу принесёте.

Ещё есть интересный момент это параллельное развитие datadog-agent и Vector. Честно говоря, я плохо понимаю, зачем Datadog развивает параллельно два продукта. Есть предположение, что просто "так исторически сложилось", когда Datadog купил Timber (не путать с Tinder). И по накатанной развивают два продукта.

Полезные ссылки

Здесь собрал полезные на мой взгляд ссылки, которые вам могут помочь в приседаниях с Vector:

1. Конечно же официальный сайт Vector: https://vector.dev/

2. Официальный англоязычный чат Vector в Discord (очень помогает в решении насущных проблем): https://chat.vector.dev/

3. Русскоязычный чат Vector в Telegram (чат не особо большой, но всё же): https://t.me/vectordev_ru . В этом чате обитаю я - можете спросить, если ещё что-то интересует :)

4. Русскоязычный чат про логи в Telegram (полезный и живой чат, рекомендую): https://t.me/ru_logs . Если есть вопросы про логи (как писать, чем снимать, где хранить, как смотреть) - скорее всем вам точно сюда.

На этом у меня всё! Удачи в приручении векторизированных граблей :)

P.S. Новый редактор Хабра - максимально отвратительный. Раньше было лучше (недовольное ворчание detected)!