Хочу сразу извиниться, что не дал ранее развёрнутый ответ. Дело в том, что Zalando даже в своей документации советует использовать свою сборку Spilo, в дефолте чего-то может не быть, версии могут быть не те. Именно поэтому в операторе возможно настроить все используемые образа. Соответственно вы можете использовать вместо pgbouncer odyssey, просто сделайте образ, который бы имел сходный интерфейс и настраивался через переменные окружения. Я тоже смотрел в эту сторону и даже начинал писать скрипт конфигурации, просто пока никто из клиентов такое не попросил.
Возможность кастомизации — это еще одна из причин, по которой нас и подкупил этот оператор
На самом деле яйца не в одной корзине: виртуалки зукипера на разных серверах, в кубах — pod anti-affinity. Но проблема с MTU, которую не отловили сразу, привела к полной недоступности ZK. В статье еще забыт момент о том, что в конфигах netplan был указан нужный MTU, однако он не применялся.
Никто не спорит, что loki хорошее решение, однако нам видится у него ряд минусов:
он не разворачивает json, поэтому часто он не удобен для аналитики
наши клиенты и инженеры знают SQL и им удобно пользоваться такими инструментами как balerter
С появившемся внешним clickhouse можно обеспечить любую скорость работы с логами. Да, loki умеет использовать внешнее хранилище, но оно не добавит скорости.
Дело в том, что на рынке cейчас много разных решений и все они имеют право на жизнь. При этом промышленный стандарт, типо helm, еще не появился
У нас используются дневные партиции. Почасовые партиции мы тестировали, но в итоге отказались. Они есть в одном из коммитов. Спасибо, что заметили ошибку в статье.
Сложно угадать сколько у вас в среднем падает логов ежедневно, но можно допустить что несколько сотен лямов в день, а с таким кол-вом можно спокойной жить и с партициями по месяцу.
Дело в том, что мы искали вариант, который позволит бить данные на относительно не большие куски, которые, в случае чего, можно было бы легко удалить. Да и логи мы не храним месяцами. Так что разбиение по дням нас устраивает. Однако никто не мешает использовать свою кастомную схему.
ORDER BY (timestamp, nsec, namespace, container_name)
Очень часто мы ищем логи во временном промежутке в каком-то namespace. Переход на другую сортировку значительно замедлял просмотрщик логов.
Еще не видно никаких Codecs
Да, мы знаем про кодеки, однако сильная переработка схемы данных не была целью этого релиза.
Если у вас есть еще какие-то предложения — вы можете всегда их оформить issue на github.
Подразумевается производительность?
Обязательно попробуем его и дополним статью.
Возможность кастомизации — это еще одна из причин, по которой нас и подкупил этот оператор
Дело в том, что на рынке cейчас много разных решений и все они имеют право на жизнь. При этом промышленный стандарт, типо helm, еще не появился
У нас используются дневные партиции. Почасовые партиции мы тестировали, но в итоге отказались. Они есть в одном из коммитов. Спасибо, что заметили ошибку в статье.
Дело в том, что мы искали вариант, который позволит бить данные на относительно не большие куски, которые, в случае чего, можно было бы легко удалить. Да и логи мы не храним месяцами. Так что разбиение по дням нас устраивает. Однако никто не мешает использовать свою кастомную схему.
Очень часто мы ищем логи во временном промежутке в каком-то namespace. Переход на другую сортировку значительно замедлял просмотрщик логов.
Да, мы знаем про кодеки, однако сильная переработка схемы данных не была целью этого релиза.
Если у вас есть еще какие-то предложения — вы можете всегда их оформить issue на github.