Comments 13
Если количество запросов, которые завершились ошибкой, превышает 1%, — это критический инцидент. Если в течение 15 минут в прайм-тайм процент ошибок превышает 0,1% — то это также считается критическим инцидентом.
Как часто вы тюните это процент? Абсолютное число запросов не учитываете вообще?
Из-за того что round-robin направлял запросы с 1 по последний апстрим по порядку, и каждый релоад nginx начинал сначала, на первые апстримы всегда приходилось больше запросов, чем на остальные
Это сколько раз в секунду вы nginx релоадите, чтобы такое поведение заметно сказалось на балансировке?
0
Как часто вы тюните это процент? Абсолютное число запросов не учитываете вообще?
Пока что не было нужды тюнить эти цифры, но за абсолютными значениями поглядываем.
Это сколько раз в секунду вы nginx релоадите, чтобы такое поведение заметно сказалось на балансировке?
5-15 раз в минуту.
0
Ужос.
+4
15 раз в минуту? А расскажите о причинах, как вы к этом пришли?
+1
Мы используем nomad+consul в качестве оркестратора контейнеров. По этому на фронтах апстримы обновляются consul_template.
Поскольку у нас постоянно какие-то сервисы едут на бой — consul-template постоянно перезагружает nginx. Когда несколько сервисов едут на бой одновременно — nginx перезагружается действительно часто.
Поскольку у нас постоянно какие-то сервисы едут на бой — consul-template постоянно перезагружает nginx. Когда несколько сервисов едут на бой одновременно — nginx перезагружается действительно часто.
+1
Какие-то детские грабли, если честно :)
Так делать получается пока у вас 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 — это ничего не говорит ответственным за сервис инженерам в случае с тысячами микросервисов и полного отсутствия монолитов.
+3
Возможно я не достаточно детально осветил этот момент. Мы обнаружили это по метрикам ELK. Если бы он лежал — такие же показания были и на прочих метриках.
Помимо ELK есть еще метрики nginx-module-vts, которые лежат Prometheus. Особо важные метрики перекладываются в graphite кластер и там остаются на годы, подчиняяcь retention политикам кластера.
В мониторинг сильно не углублялся, это большая тема на отдельную статью.
Помимо ELK есть еще метрики nginx-module-vts, которые лежат Prometheus. Особо важные метрики перекладываются в graphite кластер и там остаются на годы, подчиняяcь retention политикам кластера.
В мониторинг сильно не углублялся, это большая тема на отдельную статью.
+2
А что не так с ms sql?
Кроме того, зоопарк ваш велик — postgress, cassandra, ms, да и lua-конфиги прибитые к версии тоже дорогого стоят… А по администрированию — любопытно, когда топ 5 факапов начинаются со слов "нам захотелось".
0
По MS SQL средняя загрузка 50%+ тоже обескураживает
0
Раньше у нас были сервера, на которых было много баз. Эти базы росли и им стало тесно вместе. Мы начали процесс переноса больших/важных баз на отдельные сервера. Приложение не всегда переключалось на новые сервера без даунтайма. Также MaintenencePlan или бекапы пару раз слишком нагружали сервера, от чего страдало время выполнения запросов.
0
все компоненты зарезервированы n-2, а на время работ мы можем опускать этот уровень до n-1.
привык резервировать N+1, N+2, N+N, но в минус никогда не догадывался уходить. надо попробовать.
+1
Самое нужное нововведение на ЦИАНе было полгода назад, раз нет возможности выпиливать фейковые объявления. У частных риелторов хорошо подгорело.
0
Sign up to leave a comment.
Топ факапов Циан