Отдельное огромное спасибо за `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'ы?
+ Можете пожалуйста дать ссылку, где именно описан (код) процесс валидации? Это сейчас немного острый момент для меня и я хотел бы подглядеть)
Интересная статья. Про метрики согласен на все 199%. Очень удивился, когда при анализе просадки в производительности после включение метрик пожирание ресурсов увеличилось в 10 раз. Было весело)
Пришлось искать проблемы на ощупь)
Я точных ссылок и ошибок сейчас не вспомню, но есть еще одна большая проблема с производительностью, на которую наткнулся. Если в Vector'e много source'ов (Я заметил просадки, когда их стало >300) происходит магия. По умолчанию все source и последующая обработка логов (pipeline) делятся на "группы". Количество этих групп ограничено (хардкод). И если у вас source'ов, больше чем этих групп - все избыточные source попадут в одну группу (либо 0 либо 1, не помню точно). Так вот, если у вас такой сценарий, скорее всего все логи, которые обрабатываются в группе 0 (или 1) - вы потеряете, т.к. вектор не затащит.
Мы пишем свой оператор для вектора (чтобы иметь функциональность, которую дает Logging operator, но без Logging Operator'а, потому что он и fluentd под капотом - говно). И из-за этой "ошибки" нам пришлось писать функционал, который сильно усложняет конфигурацию vector'а, но улучшает его производительность. То есть использование vector'а "в лоб" - практически невозможно в высоконагруженной реальности)
Мы хотели простой в реализации и будущей поддержке оператор. Использование архитектуры sample-controller подразумевает прямой использование функционала client-go. Получается слишком низкоуровнего и если кто-то захочет поучаствовать в разработке оператора (опенсорс же все) - будет сложней.
Нам понравилась реализация Controller Runtime, где все объекты соответствуют и интерфейсу client.Object и runtime.Object. (Минусы, конечно, есть. Из этой же статьи их видно)
+ нативное использование Controller Runtime в kubebuilder и OpenSDK стало немаловажным фактором.
Изначально мы архитектурно хотели сделать оператор схожим с оператором seaweedfs, но в процессе поняли, что настолько "в лоб" не получится и начали "поглядывать" на реализацию оператора у Виктории и того же Логгинг Оператора. (У логгинг мы точно знали все минусы, т.к. тесно с ним работали и даже отсылали им пулреквесты на всякие мелочи (да и не мелочи тоже), а у Виктории, на мой взгляд, очень хорошая и понятная архитектура кода)
Что-то мне подсказывает, что если DevOps(/SRE/инфраструктурный инженер) дошёл до кондиции, когда понимает, что ему нужен оператор для разворачивания какого-то ПО в кластере - он первым делом пойдёт искать уже готовый оператор с кучей звёзд.
Если же он не нашёл подходящий ему оператор, то, скорее всего, перед человеком стоит какая-то нетривиальная задача, и чаще всего минимальный опыт в программирований приведёт к очень плохому итоговому продукту.
Хорошая статья, спасибо.
Отдельное огромное спасибо за `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'ы?
+ Можете пожалуйста дать ссылку, где именно описан (код) процесс валидации? Это сейчас немного острый момент для меня и я хотел бы подглядеть)
Сорян за вопрос не в тему, но как вы делали такие прекрасные картинки?
Интересная статья. Про метрики согласен на все 199%. Очень удивился, когда при анализе просадки в производительности после включение метрик пожирание ресурсов увеличилось в 10 раз. Было весело)
Пришлось искать проблемы на ощупь)
Я точных ссылок и ошибок сейчас не вспомню, но есть еще одна большая проблема с производительностью, на которую наткнулся. Если в Vector'e много source'ов (Я заметил просадки, когда их стало >300) происходит магия. По умолчанию все source и последующая обработка логов (pipeline) делятся на "группы". Количество этих групп ограничено (хардкод). И если у вас source'ов, больше чем этих групп - все избыточные source попадут в одну группу (либо 0 либо 1, не помню точно).
Так вот, если у вас такой сценарий, скорее всего все логи, которые обрабатываются в группе 0 (или 1) - вы потеряете, т.к. вектор не затащит.
Мы пишем свой оператор для вектора (чтобы иметь функциональность, которую дает Logging operator, но без Logging Operator'а, потому что он и fluentd под капотом - говно). И из-за этой "ошибки" нам пришлось писать функционал, который сильно усложняет конфигурацию vector'а, но улучшает его производительность. То есть использование vector'а "в лоб" - практически невозможно в высоконагруженной реальности)
Пока у них есть плашка "The
opentelemetrysource only supports log events at this time." (https://vector.dev/docs/reference/configuration/sources/opentelemetry/)Ни о каком нормальном решении для обсервабилити речи быть не может)
Сорри - OperatorSDK, а не OpenSDK. Попутал
Мы хотели простой в реализации и будущей поддержке оператор. Использование архитектуры sample-controller подразумевает прямой использование функционала client-go. Получается слишком низкоуровнего и если кто-то захочет поучаствовать в разработке оператора (опенсорс же все) - будет сложней.
Нам понравилась реализация Controller Runtime, где все объекты соответствуют и интерфейсу client.Object и runtime.Object. (Минусы, конечно, есть. Из этой же статьи их видно)
+ нативное использование Controller Runtime в kubebuilder и OpenSDK стало немаловажным фактором.
Изначально мы архитектурно хотели сделать оператор схожим с оператором seaweedfs, но в процессе поняли, что настолько "в лоб" не получится и начали "поглядывать" на реализацию оператора у Виктории и того же Логгинг Оператора. (У логгинг мы точно знали все минусы, т.к. тесно с ним работали и даже отсылали им пулреквесты на всякие мелочи (да и не мелочи тоже), а у Виктории, на мой взгляд, очень хорошая и понятная архитектура кода)
А это и не ко мне вопрос был. Простите)
Тогда тут, скорее всего, обсуждается как это сделать, работая именно с Loki.
С Loki у меня опыт работы близок к 0, по этому вряд ли смогу подсказать
Нет. Все проходящие логи либо не трансформировались, либо json, либо полностью разрезались регуляркой.
Из issue я не очень понимаю, что человек имеет в виду под
Что значит «поля» в логах?
Звучит так, будто человеку нужна регулярка, но он “don’t want”
Что-то мне подсказывает, что если DevOps(/SRE/инфраструктурный инженер) дошёл до кондиции, когда понимает, что ему нужен оператор для разворачивания какого-то ПО в кластере - он первым делом пойдёт искать уже готовый оператор с кучей звёзд.
Если же он не нашёл подходящий ему оператор, то, скорее всего, перед человеком стоит какая-то нетривиальная задача, и чаще всего минимальный опыт в программирований приведёт к очень плохому итоговому продукту.
Pull requests уже есть. Там дорабатываются мелочи