Комментарии 16
Просмотрел статью, но не увидел самого интересного - сравнения Vector с другими решениями.
Специальный оператор берёт заданные пользователями данные и составляет configmap для Vector
А можно поподробнее, вы написали свой оператор? Или используете разработанный сообществом, насколько я помню vector не делали своего
У нас свой, это часть платформы https://deckhouse.io/
Про техническое решение почитать можно тут. А здесь есть примеры custom resources.
Отдельное спасибо за текстовый вариант доклада!
Зачем нужен вектор? Что он решает? Зачем он нужен? Чем он лучше promtail/fluentbit?
Решает проблемы доставки телеметрии в разные источники. Такого софта много. Сейчас на подходе, например OpenTelemetry collector.
Promtail - сразу мимо. Он не производительный, он узконаправленный. Даже свою маленькую проблему он решает плохо.
Если взять fluentbit v3, то это самое близкое, что сейчас есть на рынке, похожее на vector, но большинство необходимых фичей появились не так давно.
Вообще современному fluentbit я говорю "да". Это хороший проект. Есть инсайд, что его используют внутри AWS и GCP для процессинга данных.
У него есть несколько минусов, которые вижу сразу, но это уже отдельная стать! За вопрос большое спасибо.
Некропост, но все же. Я частично описывал тут https://habr.com/ru/articles/808313/
"Сравнили Vector.dev и FluentD ⭢ победил Vector"
смотрите сравнение с графиками тут https://medium.com/ibm-cloud/log-collectors-performance-benchmarking-8c5218a08fea (зеркало) там FluentD, Fluentbit. Vector
LPS - логов в секунду. LPS per CPU говорит о том, что Vector способен использовать доступные процессоры для масштабирования LPS, в то время как другие сборщики не могут этого сделать
Хорошая статья, спасибо.
Отдельное огромное спасибо за `use_apiserver_cache`. По-скольку Вы раньше столкнулись с проблемой, все, что нам нужно было для решение - это найти Ваше решение в чендж логах)))
Пару вопросов:
1. Зачем вообще нужен Reloader? Как я понимаю, он исполняет 2 функции Валидация и Релоад Vector Agent'ов. Первое еще понятно, но зачем "релоадить" агенты? Чем не устроил аргумент "--watch-config"? (https://vector.dev/docs/administration/management/#automatic-reloading-on-configuration-change)
2. Получается, если валидация происходет в Reloader'e, валидируется ВЕСЬ итоговый конфиг, который собирается из CR. Есть возможность узнать какой именно CR с ошибкой?
3. Сталкивались с проблемой генерации Огромного конфига для Vector'а, который не влезает в лимиты configMap'ы?
+ Можете пожалуйста дать ссылку, где именно описан (код) процесс валидации? Это сейчас немного острый момент для меня и я хотел бы подглядеть)
Watch config не устроил именно своей автоматикой, хотелось тут ручного управления. Плюс в той версии, когда мы смотрели первый раз (0.14), в нем были баги.
Да. Скрипт выводит diff между старым и новым конфигом и текст ошибки от vector. Чаще всего можно однозначно и легко
Пока не сталкивались, но планируем решать как в Prometheus operator - делить автоматом на чанки и хранить сразу в нескольких конфигмарах.
Код релоадера у нас теперь написан на Go. Лежит вот здесь.
Спасибо за статью! Подскажите, пожалуйста. Какие метрики используете для определение того, что есть проблемы со сбором метрик у vector? Например не собриются логи или есть еще какие-то проблемы/ошибки?
Интересно про prom метрики и какие алерты накрутили. Спасибо!
Алертов не так много. Все лежат здесь.
Есть ещё dashboard для Grafana.
Спасибо за статью! Начал использовать helm chart vector и стало интересно как лучше организовать код конфига для разных vector(vector-agent-eks, vector-ingester-eks, etc.). Имею ввиду, что добавлять в customConfig большую портянку неудобно/некрасиво. Не сталкивались ли с этой проблемой и как в целом организовали структуру кода для vector используя helm chart?
Сбор логов в Kubernetes с помощью Vector: преимущества, архитектура, реальные кейсы