Команда А пилит фичу, которая меняет API в условном сервисе заказов. Чтобы ее протестировать, нужно еще обновить условный сервис уведомлений, который этот API дергает.
Оптимальным решением будет применить версионирование API совместно с feature-флагами: Команда А выпускает новую версию API (v2) параллельно со старой, а сервис уведомлений обновляется без спешки и переключается на новый эндпоинт в рантайме с помощью флага, что гарантирует нулевой даунтайм и независимый деплой обеих команд.
Да, можно сделать один Gateway и два listener, но я сделал сознательно для разделения Gateway в разных YAML (gateway-redis1.yaml и gateway-redis2.yaml). Потому что их скорее всего будет много, а разные файлы читать легче чем один большой.
Спасибо за комментарий. Скриншотов нет, потому что все делается из консоли. Но я везде добавил консольный вывод чтобы можно было проверить и сравнить вывод
Добавьте пожалуйста в статью нужно ли устанавливать свой сервер или приложение подключается к вашим серверам.
можно на rutracker выложить)
Оптимальным решением будет применить версионирование API совместно с feature-флагами: Команда А выпускает новую версию API (v2) параллельно со старой, а сервис уведомлений обновляется без спешки и переключается на новый эндпоинт в рантайме с помощью флага, что гарантирует нулевой даунтайм и независимый деплой обеих команд.
Этот проект был создан для поста и удален после написания поста. Поэтому там нечего мигрировать.
Спасибо за пост. Почему вы выбрали Sentry для хранения трейсов, а не Jaeger, tempo, VictoriaTrace? Сколько у вас событий на вкладке stats?
А где ссылка на репозиторий? Думаю стоит расписать побольше о проекте
Спасибо за пост. Добавьте пожалуйста скриншоты/картинки grafana дашбордов созданных на базе этих метрик.
а зачем им нужен доступ в k8s ? у вас 40 devops инженеров?
Спасибо за статью. А сколько у вас Пользователей ходят в k8s?
А как узнать какое приложение отправляет большие трейсы?
Спасибо за стать! Подскажите как настроить OpenTelemetry Collector чтобы найти виновника высокого значения trace_too_large ?
В статье есть "Ожидаемый результат:" и сокращенный вывод. Вывод каких команд добавить?
Да, можно сделать один Gateway и два listener, но я сделал сознательно для разделения Gateway в разных YAML (gateway-redis1.yaml и gateway-redis2.yaml). Потому что их скорее всего будет много, а разные файлы читать легче чем один большой.
еще https://github.com/VictoriaMetrics/VictoriaLogs
Если failover pg организован в Managed postgresql в yandex cloud, то как голосовать?
Спасибо за комментарий. Скриншотов нет, потому что все делается из консоли. Но я везде добавил консольный вывод чтобы можно было проверить и сравнить вывод
Спасибо за пост. Рассматривали ли VictoriaMetrics? Как вы собираете логи? Собираете ли трейсы?
Спасибо за пост. Скажите за чем вам столько много виртуалок. Сейчас же популярны облака и kubernetes.
Установлен паралельно Loki. Смотрим в Loki и в VictoriaLogs
ELK слишком жирный. Вместо ELK лучше использовать https://github.com/VictoriaMetrics/VictoriaLogs/