http-check expect status 200 отвечает за выкидывания сервера из балансировки при ответе не 200 статусом на health check (синтетический запрос от haproxy на бэкенд, выполняемый раз в интервал времени). Retry — повторная попытка отправить пользовательский запрос на другой бэкенд, если один из бэкендов уже ответил не200 статусом на этот запрос.
В статье говорится о том, что haproxy не умеет делать именно retry.
Не до конца понял вопрос.
Если про ретраи между дохлыми апстримами, то количество ретраев надо ограничивать (в штуках, по времени). Снизить вероятность попадания на дохлый апстрим можно health check'ами. Вот тут я про все это рассказывал.
Про Apache Ignite сам ничего не знаю, но у них же типа "вендора" есть (gridgain если не ошибаюсь). Может просто консалтинг купить — это же быстрый способ самому в код не лезть? Более того, если даже есть задача растить экспертизу внутри команды, это будет хорошим бустом.
Автоматом можно надежно посчитать только время от уведомления до Ack.
Detection можно глазами на графиках увидеть: начались ошибки/провал бизнес-метрик, а уведомление мы знаем когда было.
Хорошая опция, но это не про повторную попытку, она лишь может пометить данный сервер "мертвым" не дожидаясь результатов health check или спровоцировать health check. Я же говорил именно про ретрай.
Справедливости ради замечу: коллеги DBA подсказывают, что длинная транзакция не может блокировать работу checkpointer'а. Так что в данном случае проблема в чем-то другом, но в чем именно по метрикам пока не понятно.
Да, именно так, но так как вендоры ничего другого не предлагают, пользователям приходится ориентироваться на этот индикатор. Да и хостеры диски меняют по этому же критерию.
Мне кажется персентили тут ничего не скажут, так как нагрузка разная. Максимальная скорость износа (которую я показал) позволит жить на таких дисках 2 года.
Но с другой стороны, если у вас дедик и хостер меняет диски по запросу, это не такая уж и проблема (если не брать во внимание, что у hetzner диски не hot-swap).
В датацентре что-то было с отводом тепла, само кончилось через 40 минут. По графику скорости падения температуры мне в FB подсказали, что у нашего хостера жидкостное охлаждение процов и что-то было с циркуляцией хладагента.
В Pyroscope тоже есть ретеншн (https://github.com/coroot/helm-charts/blob/main/charts/coroot/values.yaml#L106), возможно баг какой-то.
Про кликхаус - можно его исключить из установки (потыкайте галочки тут https://coroot.com/docs/coroot-community-edition/getting-started/installation) и настроить связку otel-collector + clickhouse + coroot руками.
Спасибо за обзор и конструктивный фидбэк! (disclaimer: я причастен к разработке Coroot)
Я не смотрел и не тестировал haproxy 2, так что по существу сказать ничего не могу.
http-check expect status 200отвечает за выкидывания сервера из балансировки при ответе не 200 статусом на health check (синтетический запрос от haproxy на бэкенд, выполняемый раз в интервал времени).Retry— повторная попытка отправить пользовательский запрос на другой бэкенд, если один из бэкендов уже ответил не200 статусом на этот запрос.В статье говорится о том, что haproxy не умеет делать именно retry.
Речь шла о пользовательском запросе, а не о health check.
Не до конца понял вопрос.
Если про ретраи между дохлыми апстримами, то количество ретраев надо ограничивать (в штуках, по времени). Снизить вероятность попадания на дохлый апстрим можно health check'ами. Вот тут я про все это рассказывал.
Про Apache Ignite сам ничего не знаю, но у них же типа "вендора" есть (gridgain если не ошибаюсь). Может просто консалтинг купить — это же быстрый способ самому в код не лезть? Более того, если даже есть задача растить экспертизу внутри команды, это будет хорошим бустом.
Автоматом можно надежно посчитать только время от уведомления до Ack.
Detection можно глазами на графиках увидеть: начались ошибки/провал бизнес-метрик, а уведомление мы знаем когда было.
Спору нет, если редко, но у многих 5 раз в день деплой с таким бугорком.
Хорошая опция, но это не про повторную попытку, она лишь может пометить данный сервер "мертвым" не дожидаясь результатов health check или спровоцировать health check. Я же говорил именно про ретрай.
Справедливости ради замечу: коллеги DBA подсказывают, что длинная транзакция не может блокировать работу checkpointer'а. Так что в данном случае проблема в чем-то другом, но в чем именно по метрикам пока не понятно.
Согласен с вами, тут явная проблема в наших процессах. Мы сейчас активно над этим работаем. Спасибо за ваши пожелания!
Это я так показал "сжигание" — то, как уменьшается показатель. Просто показать 100->92 получалось не особо наглядно.
Написал вам в личку.
Кстати, ниже 1% индикатор не опускается никогда
Да, именно так, но так как вендоры ничего другого не предлагают, пользователям приходится ориентироваться на этот индикатор. Да и хостеры диски меняют по этому же критерию.
Мне кажется персентили тут ничего не скажут, так как нагрузка разная. Максимальная скорость износа (которую я показал) позволит жить на таких дисках 2 года.
Но с другой стороны, если у вас дедик и хостер меняет диски по запросу, это не такая уж и проблема (если не брать во внимание, что у hetzner диски не hot-swap).
Да, в этом случае можно искусственно убивать один из дисков быстрее, например отрезав партицию и заюзав ее под своп или redis:)
Детектор аномалий мы будем делать, мы периодически пробуем разные подходы на реальных данных.
В датацентре что-то было с отводом тепла, само кончилось через 40 минут. По графику скорости падения температуры мне в FB подсказали, что у нашего хостера жидкостное охлаждение процов и что-то было с циркуляцией хладагента.