За короткое время Prometheus стал одним из самых популярных средств для мониторинга. Благодаря, в том числе, и высокой скорости своей работы. Его локальное хранилище отлично подходит для краткосрочного хранения метрик и работы с ними. Иногда хочется хранить метрики распределённо месяцы и годы, автоматически разрежая старые данные, но не меняя интерфейса работы с ними.

Как раз об этом расшифровка доклада Алексей Палажченко на RootConf 2018. В докладе: Prometheus, Local Storage TSDB, Remote Storage Prometheus, PromQL, TSDB, Сlickhouse, PromHouse, немного InfluxDB.

Кому интересно, прошу под кат.

База данных временных рядов (TSDB, time series database) в Prometheus 2 – это отличный пример инженерного решения, которое предлагает серьёзные улучшения в сравнении с хранилищем v2 в Prometheus 1 в плане скорости накопления данных и выполнения запросов, эффективности использования ресурсов. Мы внедряли Prometheus 2 в Percona Monitoring and Management (PMM), и у меня была возможность разобраться с производительностью Prometheus 2 TSDB. В этой статье я расскажу о результатах этих наблюдений.

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.

Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

Если вы совсем ничего не знаете о Prometheus или хотите лучше разобраться в нем, в его экосистеме и всех взаимодействиях, эта статья как раз для вас.

Каждая система мониторинга сталкивается с тремя видами проблем, связанных с производительностью.

Во-первых, хорошая система мониторинга должна очень быстро получать, обрабатывать и записывать поступающие извне данные. Счёт идёт на микросекунды. Навскидку это может показаться неочевидным, но когда система становится достаточно большой, все эти доли секунд суммируются, превращаясь в хорошо заметные задержки.

Как-то мне предстояло разобраться с метриками для нашего API, как всегда (нет времени?!) дописать позже — очень сложно и ещё не внедрили — значит пора внедрять. После некоторых скитаний в сети, самой популярной системой мониторинга, как мне показалось, был Prometheus.

При помощи Prometheus мы можем отслеживать различные ресурсы компьютера, такие как: память, загрузка процессора, диска, сети. Также нам может быть важно посчитать количество обращений к методам нашего API или измерить время их выполнения, ведь чем больше нагрузка на систему, тем дороже время её простоя. И тут нам на помощь приходит Prometheus. В данной статье приводятся, как мне кажется, основные моменты для понимания работы Prometheus и для добавления сбора метрик в API. Поэтому начнём с самого банального, с небольшого описания.

Расшифровка доклада 2016 года Виталия Левченко "Prometheus мониторинг микросервисных приложений"

Prometheus, в отличие от классических систем, даёт возможность легко поднять и поддерживать мониторинг быстро меняющихся и сложно организованных систем. Я расскажу об опыте внедрения, подводных камнях и неожиданном поведении, покажу способы быстрой конфигурации всей системы, включая уведомления и дашборды.

VictoriaMetrics, TimescaleDB и InfluxDB были сравнены в предыдущей статье по набору данных с миллиардом точек данных, принадлежащих 40K уникальным временным рядам.

Несколько лет назад была эпоха Zabbix. Каждый bare metal сервер имел не более нескольких показателей – использование процессора, использование оперативной памяти, использование диска и использование сети. Таким образом метрики с тысяч серверов могут поместиться в 40 тысяч уникальных временных рядов, а Zabbix может использовать MySQL в качестве бэкенда для данных временных рядов :)

В настоящее время один node_exporter с конфигурациями по умолчанию предоставляет более 500 метрик на среднем хосте. Существует множество экспортеров для различных баз данных, веб-серверов, аппаратных систем и т. д. Все они предоставляют множество полезных показателей. Все больше и больше приложений начинают выставлять различные показатели на себя. Существует Kubernetes с кластерами и pod-ами, раскрывающими множество метрик. Это приводит к тому, что серверы выставляют тысячи уникальных метрик на хост. Таким образом, уникальный временной ряд 40K больше не является высокой мощностью. Он становится мейнстримом, который должен быть легко обработан любой современной TSDB на одном сервере.

Что такое большое количество уникальных временных рядов на данный момент? Наверное, 400К или 4М? Или 40м? Давайте сравним современные TSDBs с этими цифрами.