Comments 8
По ходу статьи я буду делать оценку тех или иных сторон Vector исходя не из сравнения с конкурентами ("Vector то может мог быть и побыстрее, но вот Logstash..."), а по моим внутреннием ощущениям.
Без сравнения трудно убедить меня (и других) перейти с чего-то известного-популярного на vector.
Я ни в коем случае не ставил своей целью убедить кого-либо переходить на Vector. По проблемам, описанным в статье - это скорее уж анти-реклама, чего таить :)
Решение о том, нужен ли вам Vector в конкретно вашей ситуации - зависит исключительно от выбирающего, его контекста и множества других факторов. Я всего лишь подсвечиваю грабли, которые ждут вас, если вы таки подумаете в сторону вектора.
С другой стороны, Vector уже тоже достаточно известен-популярен - просто смотря с чем сравнивать.
А есть какое-то простое решение которое будет просто зеркалировать архивы логов с клиентов с папки "A" на сервер Фтп в папку "ClientName"?
Ну и чтобы все было классно и настраивалось через конфиги?
Именно для FTP сразу на ум не приходит ничего, кроме самописных скриптов по крону. Быстрый поиск дал вот такой плагин для fluentd: https://github.com/kzk/fluent-plugin-ftp . Но поциент-плагин скорее мёртв, чем жив.
DataDog развивает vector.dev потому что он сам его использует как фичу https://www.datadoghq.com/product/observability-pipelines/. Только она у них обмазана в красивый интерфейс.
Пока у них есть плашка "The opentelemetry source only supports log events at this time." (https://vector.dev/docs/reference/configuration/sources/opentelemetry/)
Ни о каком нормальном решении для обсервабилити речи быть не может)
Интересная статья. Про метрики согласен на все 199%. Очень удивился, когда при анализе просадки в производительности после включение метрик пожирание ресурсов увеличилось в 10 раз. Было весело)
Пришлось искать проблемы на ощупь)
Я точных ссылок и ошибок сейчас не вспомню, но есть еще одна большая проблема с производительностью, на которую наткнулся. Если в Vector'e много source'ов (Я заметил просадки, когда их стало >300) происходит магия. По умолчанию все source и последующая обработка логов (pipeline) делятся на "группы". Количество этих групп ограничено (хардкод). И если у вас source'ов, больше чем этих групп - все избыточные source попадут в одну группу (либо 0 либо 1, не помню точно).
Так вот, если у вас такой сценарий, скорее всего все логи, которые обрабатываются в группе 0 (или 1) - вы потеряете, т.к. вектор не затащит.
Мы пишем свой оператор для вектора (чтобы иметь функциональность, которую дает Logging operator, но без Logging Operator'а, потому что он и fluentd под капотом - говно). И из-за этой "ошибки" нам пришлось писать функционал, который сильно усложняет конфигурацию vector'а, но улучшает его производительность. То есть использование vector'а "в лоб" - практически невозможно в высоконагруженной реальности)
Vector: руководство по уходу за граблями