Комментарии 13
Если количество запросов, которые завершились ошибкой, превышает 1%, — это критический инцидент. Если в течение 15 минут в прайм-тайм процент ошибок превышает 0,1% — то это также считается критическим инцидентом.
Как часто вы тюните это процент? Абсолютное число запросов не учитываете вообще?
Из-за того что round-robin направлял запросы с 1 по последний апстрим по порядку, и каждый релоад nginx начинал сначала, на первые апстримы всегда приходилось больше запросов, чем на остальные
Это сколько раз в секунду вы nginx релоадите, чтобы такое поведение заметно сказалось на балансировке?
Как часто вы тюните это процент? Абсолютное число запросов не учитываете вообще?
Пока что не было нужды тюнить эти цифры, но за абсолютными значениями поглядываем.
Это сколько раз в секунду вы nginx релоадите, чтобы такое поведение заметно сказалось на балансировке?
5-15 раз в минуту.
Ужос.
15 раз в минуту? А расскажите о причинах, как вы к этом пришли?
Мы используем nomad+consul в качестве оркестратора контейнеров. По этому на фронтах апстримы обновляются consul_template.
Поскольку у нас постоянно какие-то сервисы едут на бой — consul-template постоянно перезагружает nginx. Когда несколько сервисов едут на бой одновременно — nginx перезагружается действительно часто.
Поскольку у нас постоянно какие-то сервисы едут на бой — consul-template постоянно перезагружает nginx. Когда несколько сервисов едут на бой одновременно — nginx перезагружается действительно часто.
Какие-то детские грабли, если честно :)
Так делать получается пока у вас ELK стек жив и его никто не шатает. В первое же окно обслуживания ELK вы потеряете такую статистику.
Мы же мониторим RPS через метрики nginx ingress controller через Prometheus. А логи ELK — только как инструмент номер 2 и для логов по фронтам.
Просто те же перцентили по фронтам вообще не интересны для SRE — это ничего не говорит ответственным за сервис инженерам в случае с тысячами микросервисов и полного отсутствия монолитов.
Например, можно использовать ELK для того, чтобы наблюдать за rps на каждый backend каждого upstream, следить за их временем ответа с точки зрения nginx.
Так делать получается пока у вас ELK стек жив и его никто не шатает. В первое же окно обслуживания ELK вы потеряете такую статистику.
Мы же мониторим RPS через метрики nginx ingress controller через Prometheus. А логи ELK — только как инструмент номер 2 и для логов по фронтам.
Просто те же перцентили по фронтам вообще не интересны для SRE — это ничего не говорит ответственным за сервис инженерам в случае с тысячами микросервисов и полного отсутствия монолитов.
Возможно я не достаточно детально осветил этот момент. Мы обнаружили это по метрикам ELK. Если бы он лежал — такие же показания были и на прочих метриках.
Помимо ELK есть еще метрики nginx-module-vts, которые лежат Prometheus. Особо важные метрики перекладываются в graphite кластер и там остаются на годы, подчиняяcь retention политикам кластера.
В мониторинг сильно не углублялся, это большая тема на отдельную статью.
Помимо ELK есть еще метрики nginx-module-vts, которые лежат Prometheus. Особо важные метрики перекладываются в graphite кластер и там остаются на годы, подчиняяcь retention политикам кластера.
В мониторинг сильно не углублялся, это большая тема на отдельную статью.
А что не так с ms sql?
Кроме того, зоопарк ваш велик — postgress, cassandra, ms, да и lua-конфиги прибитые к версии тоже дорогого стоят… А по администрированию — любопытно, когда топ 5 факапов начинаются со слов "нам захотелось".
По MS SQL средняя загрузка 50%+ тоже обескураживает
Раньше у нас были сервера, на которых было много баз. Эти базы росли и им стало тесно вместе. Мы начали процесс переноса больших/важных баз на отдельные сервера. Приложение не всегда переключалось на новые сервера без даунтайма. Также MaintenencePlan или бекапы пару раз слишком нагружали сервера, от чего страдало время выполнения запросов.
все компоненты зарезервированы n-2, а на время работ мы можем опускать этот уровень до n-1.
привык резервировать N+1, N+2, N+N, но в минус никогда не догадывался уходить. надо попробовать.
Самое нужное нововведение на ЦИАНе было полгода назад, раз нет возможности выпиливать фейковые объявления. У частных риелторов хорошо подгорело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Топ факапов Циан