Комментарии 8
Спасибо за обзорную статью, как раз начинаю работать с этой технологией
Спасибо было очень интересно почитать
добавить еще можно из бытового о нюансах выгребания данных, вроде 5минут+ отсутствия метрик, помогает к примеру last_over_time. также недавно столкнулся с невозможностью записывать данные в будущем в prometheus, виктория позволяет только +2дня, решает что-то простое вроде influx db.
полезными могут быть и prometheus rules, например для anomalies detection без ML.
еще можно расширить во второй части статьи примерами популярных экспортеров, вроде node_exporter(включая чтение кастомных файлов и параметрами для получения расширенной статистики по процессам), oracle_exporter, postgres_exporter и т.д. также взаимодейтвие с blackbox и json экспортерами. + популярные дашборды
в целом автор большой молодец - базу раскрыл прекрасно!
Спасибо за статью! Уже несколько лет, как начали юзать Графану, периодически возвращаюсь поднастроить какой-нибудь дашборд, и приходится сызнова освежать знания, все очень быстро выветривается.
Не могли бы вы еще пояснить за это временное окно, которое используется для получения range vector в rate и increase: что оно означает в физическом мире, по каким критериям выбирается значение? Потому что пока что впечатление, что от балды, в лучше случае графановский $rate_interval, но тогда еще больше вопросов, как тогда интерпретировать график, когда в зависимости от выбранного интервала для всего дашборда, те же данные на графике отображаются под разными углами и оказывают разное впечатление.
Если рассуждать в контексте базовых функций, то для вычисления изменения величины нам нужно минимум два измерения. Когда мы задаем временное окно, мы определяем, сколько значений попадает в расчет.
Чем больше окно, тем больше измерений включается, и график получается более сглаженным;
Чем меньше окно, тем меньше измерений участвует, что может привести к большему шуму.
Официальная документация советует, чтобы конечный пользователь выбирал временное окно, в которое попадает хотя бы 4 измерения. Это помогает избежать резких скачков и получения некорректных данных. Или другими словами:
Возвращаясь к вопросу, а как лучше выбирать временное окно, то мне кажется тут нет однозначного ответа.
Официальная документация рекомендует, что лучше избегать использования:
констант (например, 30s, 1m, 2m);
$__interval.
Вместо этого рекомендуется использовать $__rate_interval, так как он автоматически подбирается так, чтобы временное окно было как минимум в 4 раза больше, чем Scrape Interval:
We recommend using $__rate_interval in the rate and increase functions instead of $__interval or a fixed interval value. Because $__rate_interval is always at least four times the value of the Scrape interval, it avoid problems specific to Prometheus.
Обычно я использую либо константы, либо $__rate_interval. В 99% случаев этого достаточно, и проблем не возникает.
Но однажды я столкнулся с редким случаем: мне нужно было посмотреть график перезапуска Pod'ов (счётчик менялся очень медленно) на большом временном интервале. Указание константы меня подвело, и я практически не видел "столбов" перезапуска на графике (хотя перезапусков было не мало). После замены константы на $__rate_interval Grafana уже корректно отобразила результаты.
Также приложу несколько ссылок (вдруг помогут):
Спасибо за развернутый ответ!
Кроме непосредственно практического вопроса выбора значения интервала, больше волнует физическое значение этого окна в прошлое. Потому что, если значение, получаемое через irate, выглядит как всамделишная реальная скорость возрастания от скрейпа к скрейпу, то результаты rate кажутся какими то синтетическими числами, не имеющими ничего общего с реальным миром. Во многом из-за этого интервала, изменение которого, при тех же самых сырых данных, может дать сильно отличающиеся графики.
del
Подскажите, каким способом лучше Викторию разворачивать, как у вас развернута?
«База» по метрикам в Prometheus