Комментарии 4
Вариант № 6 - поставить рядом с pod еще один sidecar контейнер, скрейпить данные и пулить данные в victoriametrics или clickhouse и не зависеть от инфраструктурного мониторинга.
Спасибо за статью, добавила в закладки. Был опыт использования варианта 2, значение перцентиль выносила в переменные графаны, во время просмотра просто переключала значения перцентиль, на практике всегда хватало 90.
Все беды из-за линейной интерполяции и большого числа ваших данных. В сервисах в небольшим RPC, погрешность из-за линейной интерполяции наиболее высока. Условно: если из 10 запросов в бакете у вас 1 выброс, то его будет видно, но если туда влезла 1000, то этот выброс "слижется" в прямую. Делая бакеты максимально узкими, вы уменьшаете число запросов в бакете, а если сделать 1 бакет - 1 запрос то вообще не увидите интерполяции. Но вместе с этим и потеряете весь смысл: большое число бакетов просто повесит интерфейс вашей графаны и вы не сможете посмотреть статистику за месяц, неделю, год.
В связи с этим предлагаю оставить общие графики в покое, они показывают температуру по больнице.
А для мониторинга выбросов использовать:
логировать выбросы, ELK позволит посмотреть графики логов чтобы оценить число выбросов в моменте
писать запросы с высоким RT в тот же прометеус отдельной метрикой. В этом случае бакеты будут достаточно маленькими и никакая интерполяция их не "слижет"
простите за духоту, долго работала на проекте с gps отслеживанием и я тот человек, который писал все эти интерполяции с миллионами gps точек )
Поправочка: в сервисах с большим RPC, погрешность из-за линейной интерполяции наиболее высока.
По моему опыту с детектированием серьёзных выбросов проблем как раз нет. Например, когда вы меряете что-то, что может почти неограниченно расти из-за того, что очередь на обработку очень большая и обработчик не успевает её разгребать. В таких случаях время обработки с точки зрения клиента растёт экспоненциально и это отлично видно на графиках. Проблемы с пониманием как раз начинаются тогда, когда происходит умеренная деградация обработчика, и время ответа продолжает укладываться в тот же самый бакет.
Насчет вопроса "что хуже: большой RPS или маленький" - я бы скорее обратил внимание не на количество запросов, а на их распределение. Бакеты способы принять в себя любое число запросов, точность результата зависит скорее от самого набора бакетов, в которые уложились запросы.
Про логирование выбросов вы правильно подметили. Логи и метрики с отдельными метками для ошибок очень помогают разбираться в неоднозначных ситуациях. Наша платформа предоставляет нам отдельные графики с RT для всех типов неуспешных запросов.
Дело о несрабатывающем тайм-ауте. Проблемы гистограмм Prometheus