Как стать автором
Обновить

Комментарии 12

Блин, напишу просто, чтобы сказать спасибо огромное за ваш труд. Очень чувствуется что вкладываетесь в свои доклады. Надеюсь оно у вас окупается в дальнейшем и вы не перестанете осведомлять IT сообщество своим опытом.

Спасибо. У нас достаточно большие планы, надеюсь все сложится.

Спидометр показывает скорость. Если измерять скорость раз в минуту по спидометру, то средняя скорость, которую мы посчитаем на основе этих данных, не будет совпадать с данными одометра.

Как вы решили эту проблему? Судя по цитате ниже, не решили, или поправьте меня.
Таким образом, первая инсталляция Prometheus работает по-прежнему (обращается каждые 60 или, например, 30 секунд) ко всем целям в кластере Kubernetes, а вторая — раз в 5 минут получает данные с первой и хранит их для возможности смотреть данные за большой период (но без глубокой детализации).

Большая часть показателей, которые экспортируются всеми системами — это "одометры" (тип counter), так что в целом эта проблема более-менее решена. Например, данные по CPU контейнера приходят как counter с количеством потраченных секунд. Соотвественно в основном Prometheus'е у нас данные за каждые 30 секунд, а в longterm за каждые 5 минут, но и по тем и по другим абсолютно корректно считать среднее, предварительно взяв "производную" (см. функцию rate). Дальше вопрос упирается в возможности источника данных — в ядре Linux многие вещи считаются (и есть возможность получать) правильно, в "одометрах", а вот в redis, например, это не так.


Для всяких штук, типа "время ответа по HTTP" (или "размер HTTP ответа"), для которых средний показатель имеет очень ограниченный смысл, мы активно используем Histogram'ы.

Спасибо.
Моменты сброса counter в 0 создают ли какие-то проблемы на практике?
Спасибо за доклад:)

Идея про «одометры» здравая!
Но, даже если считать метрики через аккумулирующие счётчики, то возникает вопрос в дальнейшей агрегации.

Допустим мы 1 раз в 15 секунд смотрим на суммарное потребление процессорного времени с момента старта, что на графике показывать? Число ядро*15секунд? Ну неудобно как-то. Нормировать и делить на 15 секунд? Ну это уже получается средняя скорость по одометру, не совсем то.

А если пользователь выбрал агрегацию за последний месяц, и в точке хранятся почасовые данные, что показывать: сумму (одометр) или среднее (спидометр) ?:)
Разверните тестовый Прометеус. Большая часть вопросов снимется.

ЗЫ
CPU может отдаваться отдельно по каждому ядру.
И все же мое мнение для мониторинга чего либо использовать стек TICK(Telegraf, Influx, (Chronograf/Grafana), Kapasitor) все куда проще, гибче и удобней, написание своих плагинов одно удовольствие, а также работа с Kapasitor. Спасибо за доклад но TICK — это будущее.

Я тоже так раньше думал, но нет. Увидим!

А для логов k8s что нибудь посоветовать можете?
Или может есть решения которые совмещают эти функции?
Не поделитесь конфигом с адекватными алертами? спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий