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

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

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

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 с этими цифрами.

Однажды мне понадобилось внедрить метрики в сервисы своей команды. С самого начала я не понимал, что именно хочу получить: одно дело — прикрутить библиотеку и нарисовать графики, другое дело — показывать осмысленные данные.

Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.

Гайд будет выходить как цикл статей. Сначала посмотрим на архитектуру: как собираются метрики и где хранятся. Дальше разберемся с типами метрик — они не так просты, как кажется. Потом придется немного отвлечься на математику (но только с инженерной точки зрения!). И, наконец, научимся писать запросы, но не просто так: сразу посмотрим на разные грабли и неочевидные моменты.

Это вторая статья из цикла. В первой, вводной, я рассказывал, как устроены метрики для сервисов, чем отличаются от логов, и какую задачу вообще решают. Теперь подробнее про то, как их готовить.

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

Как и многие другие вендоры ПО, 1С давно предлагает свои продукты в облачном варианте. Это, в первую очередь, наши облачные сервисы 1С:ГРМ (Готовое Рабочее Место) и 1cFresh. Предоставление облачных сервисов требует наличия соответствующей инфраструктуры – прежде всего серверов, на которых размещаются виртуальные машины с приложениями, и софта, управляющего физическими и виртуальными машинами.

Чем сложнее инфраструктура, тем выше вероятность возникновения ошибок. Своевременно исправлять ошибки (а ещё лучше – предсказывать их возникновение и своевременно реагировать) – одна из главных задач провайдера облачных сервисов. Для таких задач разрабатываются системы интеллектуального мониторинга, которые помогают в сопровождении больших облачных продуктов. И у нас такая система тоже есть, мы разработали её сами на Java. О ней мы и хотим рассказать.

Это третья статья из цикла. В прошлой части мы разбирали типы метрик, и уже там начали встречаться перцентили. Это полезная штука, но для неподготовленного читателя она выглядит просто как математическая дичь. Эта статья поможет разобраться в перцентилях по-инженерному, не заканчивая профильный факультет.

Это четвертая, финальная часть из цикла статей про метрики. В первой — вводной — я рассказал, почему метрики для сервисов устроены именно так, чем они отличаются от логов, и какую задачу решают. Во второй разобрались с форматом и типами метрик. В третьей — с перцентилями. Теперь, наконец, можно пойти и вывести что-нибудь на графики! На этот раз будет более хардкорно.