Vector: руководство по уходу за граблями
Не повторяйте дома — трюк выполнял профессиональный граблесборщик
Казалось бы простая задача — переместить логи из пункта А в пункт Б, что тут сложного. Но даже для такой пустяковой задачи придумали множество ПО: как более популярных Rsyslog, Logstash, fluentd, fluentbit, так и менее известных как file.d, недавно принудительно-опенсорснутая Пилорама (спасибо, Яндекс!) и множество других.
Сегодня хотелось бы поговорить про ещё один из сего семейства — Vector. Так получилось, что в последнее время я достаточно плотно имел с ним дело с разных сторон и собрал хорошую коллекцию «граблей» на любой вкус и цвет. «Перекладывалка» точно интересная, определённо достойная рассмотрения, но имеющая множество, кхм, особенностей. Вот про эти аккуратно разложенные особенности и как с ними жить я и хочу рассказать.
Моя цель
На написание статьи меня натолкнуло несколько вещей.
Я иногда вижу людей, которые берут Vector и тянут его в бой, потому что он же «safe blazing fast» — значит всё хорошо! Меня такие люди огорчают, потому что я же знаю — как только они вкусят проблем (а оно так и будет), то не разбираясь в проблемах выкинут Vector и возьмут что-то другое. По итогу только зря время потратят и потом будут рассказывать, какой Vector плохой, а-та-та.
В то же самое время некоторые люди осознанно Vector берут в бой по ряду причин. И для этих людей хотелось бы подсветить основные ловушки, которые их могут ожидать и как можно их разминировать (или по крайней мере чтобы болело не очень сильно).
Поэтому давайте я вам лучше сразу расскажу про тернии на пути к логам с векторным привкусом, а вы уже для себя сами решите — страшные это баги для вас или нет.
Важное уточнение. По ходу статьи я буду делать оценку тех или иных сторон Vector исходя не из сравнения с конкурентами («Vector то может мог быть и побыстрее, но вот Logstash…»), а по моим внутреннием ощущениям. Хорошее сравнение с другими перекладывалками я сделать не могу, потому что в них не разбираюсь — простите пожалуйста. Поэтому если я где-то говорю «плохо», то это вполне можно оказаться «приемлемо», а то и «хорошо» по сравнению с другими продуктами в данной нише — держите это в уме при чтении статьи.
О чём не пойдёт речь
Я не буду сравнивать Vector c другими перекладывалками логов по простой причине — я в других перекладывалках не разбираюсь на достаточном для качественного сравнения уровне. Что-то базовое (количество плагинов, сколько мейнтейнеров, примерная скорость работы) я может и знаю, а вот наиболее интересные моменты — нет. В таком «поверхностном» сравнении вижу довольно мало практического смысла — вы это отлично сможете сделать сами с учётом вашей локальной специфики. Это будет точно намного полезнее для вас.
Бенчмарков между проектами тоже не будет, потому что:
Бенчмарки это очень долго и сложно. У меня такой цели нет (по крайней мере пока что). Да и в актуальном состоянии их держать — отдельное искусство.
Чтобы делать качественные бенчмарки, нужно действительно хорошо разбираться во всех участниках бенчмарка, а не только в одном. А я так не умею на данный момент.
Я не ставлю своей целью показать, какие другие проекты плохие это и так очевидно.
Очень краткое (правда-правда) введение в 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, которые лучше не трогать без сильной на то причины:
Перезагрузка конфигов. Это просто феерия багов и падений. Пожалуйста, не используйте это без очень веской на то причны. Оценить масштаб можно например вот по такому фильтру.
Компоненты, которые появились относительно недавно и ещё не апробированы временем. Совет довольно капитанский, но нельзя не упомянуть. Для оценки степени доверия могу рекомендовать использовать статусы компонентов.
Просто баги. Тут особо системы нет — проверяйте, что вас конкретно интересует. Иногда конечно баги бывают особо феерические: логи просто перестают собираться.
Также обратите внимание, что Vector местами отламывает фичи между релизами. Это реальная жизнь, такое случается (и не единожды) — просто будьте к этому готовы (читайте release notes, читайте чат Discord). Тестируйте новые версии, раскатывайте новые версии постепенно. Vector в целом склонен к тому, чтобы поддерживать обратную совместимость, так что будет немного легче. Я вот подумываю в Vector чат в Telegram добавить бота с анонсом новых релизов — чтобы чуть проще было узнавать. К чести векторовцев — если в новой версии обнаруживаются серьёзные баги, то они обычно выкатывают достаточно быстро фикс-версию. Поэтому если новые фичи горят не очень сильно, возможно стоит подождать фикс-версий, чтобы обновляться.
Таков путь
Как начинать знакомство с функционалом, который вам интересен? Я для себя выработал следующий алгоритм:
Открываем документацию и читаем
Открываем Issues и ищем. Если нашли — пингуем и спрашиваем, когда пофиксят.
Открываем Discussions и ищем. Если нашли — пингуем и спрашиваем, до чего договорились.
Открываем Pull Requests и ищем. Если нашли — пингуем и спрашиваем, когда вмержат.
Если ещё что-то непонятно — спрашиваем в Discord в разделе Support. Там помогают. На практике такой алгоритм работает достаточно хорошо (хоть и отнимает время). Зато с вектором поближе познакомитесь :)
Недостающий функционал
Vector имеет довольно много плагинов. Но вместе с тем на практике случается, что конкретно нужного вам может и не быть. Хоть и кажется, что ваш случай вполне себе среднестатистический. Обычно это либо отсутствующий плагин (такие как SNMP, STOMP, RELP), либо просто какой-то функционал в уже существующем плагине.
По моему опыту, ждать завоза новых фичей можно очень долго. Поэтому если вы чем-то заблокированы из такого — скорее всего лучше переключитесь на другую перекладывалку логов или подбирайте другой интерфейс либо патчите Vector.
Например, когда мы исследовали для себя применимость Vector, собрали вот такой «букет»:
Отсутствие возможности сконфигурировать «drop_oldest» поведение для логов внутри буфера Vector: тык.
Потеря сообщений в Kafka при рестарте кластера: тыц.
Частично неработающий bulk mode при записи в ElasticSearch: туц.
Возможная out-of-order передача данных в Каfka: ссылка.
Возможное нарушение порядка передачи сообщений между инстансами Vector: и ещё.
Возможная утечка памяти из-за особенностей работы с метриками: вот.
Нет поддержки DLQ: иссус.
И это только что, нам бросилось на первый взгляд без особо глубокого погружения. У вас он будет свой :)
И это не считая таких мелочей, что 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.
Где вас могут ждать подвохи:
Если у вас хоть одна часть лог пайплайна работает медленно, то она будет замедлять весь пайплайн и блокировать операции. Про это достаточно подробно написано здесь, но я всё равно часто вижу вопросы про данное поведение.
Вы попали на плагин, где метрики отжирают всё. Проверить это легко — запустите Vector под flamegraph и посмотрите профиль (не забудьте только пересобрать с
debug = trueв Release mode. Если увидите в графе много вещей аляemit!— поздравляю, у вас метрики! Патчите Vector\нойте разработчикам, чтобы фиксили.У вас тупит какая-то внешняя система. Тут уже нужно смотреть. Либо реализация в Vector очень такая себе (профайлер и Discord в помощь), либо у вас конфигурация не совсем оптимальная (документация и бенчмарки в помощь. Особенно обратите внимание на батчинг — скорее всего поможет), либо внешняя система (там вы уже сами знаете, что делать).
Документация
Документация в Vector хорошая (это как моё мнение, так и мнение всех моих коллег). Тут тебе и описание плагинов, и референсные архитектуры развёртки, и описание около-векторных утилит. Однако это не мешает документации время от времени стучать вам в лоб черенком. Приведу несколько примеров:
Список метрик. Он в целом верный, но местами лжёт — будьте к этому готовы. У меня это стрельнуло, когда разрабатывал Grafana dashboard для Vector. В документации метрика есть, а на самом деле — её нет, или она с другими лейблами. Это же и касается документации метрик самих компонентов — могут врать. Что с этим делать? Репортить в апстрим, спрашивать в Discord, читать исходники (если умеете — они в плане метрик не самые тривиальные в Vector).
Незадокументированные возможности. Например, в Vector есть концепция буферов. Но мало кто знает, что на самом деле он более гибкий и позволяет делать иерархии буферов (что на практике полезно). Формально, оно ещё на GA, но что мешает задокументировать хоть как-то с пометкой «unstable» — непонятно. А вот если бы не спросил в Discord — так и не узнал бы о фиче.
Местами документация просто упускает достаточно важные (с точки зрения конечного пользователя) детали реализации. Например, то, что
kuberenetes_logsплагин читает логи из файловой системы (тыц). Не повезло человеку, повозился, пришёл в Discord, узнал, документацию доработали. Или например есть довольно удобный Vector API. Вещь может быть полезной для написания кастомных интеграций в ваш родной control plane. Но вот вся документация — это GraphQL playground, который нужно локально поднимать — онлайн варианта я не знаю. Очень неудобно — в моём случае мне было намного проще посмотреть в исходниках, что да как работает.А местами документация вообще непонятно, зачем есть. Например, страница Tuning. Полезной информации по тюнингу там конечно маловато. А ведь могли бы и про PGO упомянуть! (да знаю-знаю — чуть позже сделаю PR с соответствующей заметкой, если руки дойдут).
Иногда она просто неочевидна. Пользователь может ожидать по умолчанию, что логи будут передаваться в порядке поступления, то есть порядок логов будет сохраняться. Но в Vector это не так, так как он обрабатыает логи в N потоков. И для того, чтобы включить сохранение порядка, нужны специальные неочевидные настройки.
Векторовцы борятся с плохой документацией (за что им отдельное спасибо). Например, есть отдельный epic для внедрения авто-генерируемой документации, чтобы она меньше расходилась с кодом: тык, но работы ещё предстоит достаточно много.
Расширяемость
Vector не имеет возможности разрабатывать свои плагины. Поэтому если нужного вам input/output плагина нет в Vector (в терминах Vector они называются source/sink соответственно) — вам придётся патчить сам Vector и перекомпилировать его, очень неудобно. Когда плагины появятся — неизвестно. Где-то в Discord была информация, что планы по разработке RFC для плагинов были на 2023 год, а когда будет уже сама реализация — даже разработчики не знают. Грустно.
Что касается уровня трансформации логов, то здесь ситуация получше. Есть стандартный набор функций, есть собственный язык VRL, есть интеграция с Lua. Но у каждого способа есть свои нюансы:
Стандартный набор функций довольно ограничен. Свои функции туда без модификации Vector не добавить.
VRL — ещё один DSL, который придётся освоить. К тому же некоторые моменты могут быть неочевидны даже с документацией + всё же сыроват местами. Если хотите расширить VRL — снова же только через модификацию Vector. Для игрищ с VRL рекомендую онлайн VRL playground — поможет быстро разобраться, что к чему. Можно прямо из Vector поднять свой в закрытом контуре (это для особо «запущенных» случаев).
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:
Конечно же официальный сайт Vector: https://vector.dev/
Официальный англоязычный чат Vector в Discord (очень помогает в решении насущных проблем): https://chat.vector.dev/
Русскоязычный чат Vector в Telegram (чат не особо большой, но всё же): https://t.me/vectordev_ru. В этом чате обитаю я — можете спросить, если ещё что-то интересует :)
Русскоязычный чат про логи в Telegram (полезный и живой чат, рекомендую): https://t.me/ru_logs. Если есть вопросы про логи (как писать, чем снимать, где хранить, как смотреть) — скорее всем вам точно сюда.
На этом у меня всё! Удачи в приручении векторизированных граблей :)
P.S. Новый редактор Хабра — максимально отвратительный. Раньше было лучше (недовольное ворчание detected)!
