У Kubernetes появился новый лучший друг, и он называется Prometheus

Благодаря успеху контейнеров Docker и повсеместному внедрению микросервисной архитектуры потребность в оркестровке и мониторинге для повышения скорости привела к созданию Cloud Native Computing Foundation (CNCF) и его первых двух проектов-членов, посвященных оркестровке и потребности в мониторинге/оповещении соответственно. Все знают о Kubernetes и о том, как проект с открытым исходным кодом, основанный на Google «Borg», быстро стал любимым инструментом оркестровки предприятия. Успех, без сомнения, пришел благодаря времени, усилиям и деньгам, которые Google уже вложил в то, чтобы заставить контейнеры работать, задолго до того, как кто-либо даже услышал о Docker.

Как и в случае с любой новой технологией, именно предприятия с самыми глубокими карманами могут использовать ее в своих интересах быстрее всего, и это видно из историй успеха Google, Facebook, Netflix и Twitter, и это лишь некоторые из них. Теперь у Twitter и Apple были ресурсы, чтобы превратить Apache Mesos в отличный инструмент управления кластером, а Google разработала свой собственный инструмент оркестровки под названием Borg, но как насчет всех остальных? В то время Docker поставлялся со стандартным интерфейсом командной строки клиента Docker, который позволял вам управлять контейнерами в локальной системе.

Эффект домино

Контейнеры так популярны, как они есть, и вскоре стало очевидно, что обычные инструменты оркестровки просто не помогут, и Kubernetes стал ответом. Когда ключевая часть технологии, такая как сама вычислительная единица, изменяется, это создает эффект домино, который распространяется на вершину стека. Оркестрация была только началом, и предприятие быстро осознало, что традиционный мониторинг и оповещение недостаточно хороши для эффективного мониторинга системы, основанной на микросервисной архитектуре, в больших масштабах. Проблема мониторинга микросервисной архитектуры заключается в том, что нужно отслеживать гораздо больше трафика, поскольку один хост может запускать множество контейнеров, целей гораздо больше, и они постоянно меняются. Традиционный мониторинг также не позволяет вам проникнуть в слои, чтобы выяснить, что происходит для устранения неполадок.

Боргмон для Борга

Как ни странно, ответ снова пришел от инструмента, который берет свое начало в Google, хотя связи здесь немного глубже. У оригинального «Борга», по-видимому, был компаньон по имени «Боргмон». Бывшие инженеры Google Мэтт Прауд и Джулиус Волц «скучали» по своей старой инфраструктуре и построили Prometheus на основе того, что знали о Borgmon. Разочарование в существующих инструментах было причиной того, что Google в первую очередь разработал Borgmon. Прауд и Волц сделали это, потому что современные инструменты не хранили данные временных рядов в многомерном формате и не имели простого в использовании языка запросов, похожего на SQL.

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

Если Facebook не решит открыть исходный код Claspin, который является их очень популярным настраиваемым инструментом мониторинга (крайне маловероятно), Prometheus будет практически лучшим инструментом мониторинга новой эры, который предприятие должно иметь дело с современной микросервисной архитектурой. Что касается способности обрабатывать огромные числа, которые производят контейнеры, Prometheus не только собирает метрики в масштабе через HTTP, но также активно извлекает метрики из запущенных приложений. Кроме того, один узел можно использовать для запросов к тысячам целей с миллионами временных рядов со скоростью 800 000 выборок в секунду без каких-либо зависимостей и с простой масштабируемостью.

Толкать против тянуть

Такой инструмент, как Prometheus, который извлекает метрики через HTTP, имеет довольно много преимуществ, некоторые из которых заключаются в том, что вы можете запускать мониторинг на своем ноутбуке, пока разрабатываете изменения. Это упрощает определение того, когда цель не работает, с добавленной возможностью вручную проверять ее работоспособность из веб-браузера. У многих людей есть неправильное представление о том, что «вытягивание не масштабируется», что, вероятно, во многом связано с сравнением с другим инструментом, основанным на вытягивании, Nagios, который действительно имеет некоторые проблемы с масштабированием.

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

Огонь от богов

В то время как логотип Kubernetes с семью лучами, как говорят, является признанием его происхождения от Google (где проект получил прозвище семь), Prometheus считается огнем богов, и его разработчики, вероятно, имели в виду использование инструментов от гиганта. Гуглите (Бог) до простых смертных. Тот факт, что Prometheus фактически извлекает метрики из ваших сервисов, а не ждет их, хорошо сочетается с динамической облачной средой, такой как Kubernetes. Когда вы масштабируете сервис, Prometheus также автоматически начинает извлекать метрики из реплик. Точно так же, когда узлы выходят из строя и поды перезапускаются на разных, Prometheus также автоматически очищает их.

Вероятно, нет ничего лучше, чем сами боги, которые замечают это, и сама Google проявила интерес и использует Prometheus для внутреннего использования в некотором качестве, по словам Волца. CoreOS интегрировала Prometheus со своей распределенной системой управления конфигурациями etcd, а Docker интегрировала ее со своими контейнерными инструментами. DigitalOcean, Boxever, KPMG, Outbrain, Ericsson, ShowMax и Financial Times — еще несколько примеров предприятий, использующих Prometheus.

Версия 2.0 ожидается в ближайшее время

Доступна версия 1.6.1 системы мониторинга и оповещения Prometheus. В последней версии улучшено управление памятью, среди прочего, такие как экспериментальная функция поддержки удаленного чтения, улучшения пользовательского интерфейса, обнаружение Joyent Triton, новое хранилище, оповещения и метрики, связанные с оценкой. CNCF также дает нам краткий обзор Prometheus 2.0, который должен включать в себя архивы выпуска и контейнеры Docker.

Не только для высокомасштабируемых

Когда первоначальным основателям впервые удалось заставить SoundCloud поддержать их в этом начинании, они ожидали мягкого ответа, возможно, от нескольких крупных масштабаторов, которые заинтересуются новой архитектурой и тем, как она обрабатывает данные временных рядов в многомерном формате.. Однако ответ, который они получили, был далеко не умеренным, как от крупных, так и от малых предприятий, которые сразу же влюбились в простоту, масштабируемость и совместимость через «экспортеров». Экспортеры — это, по сути, плагины, которые переводят данные из других инструментов в метрики, понятные Prometheus и с которыми он может работать.

Маловероятно, что Prometheus заменит существующие инструменты, такие как Nagios или New Relic, которые до сих пор решают существующие проблемы. Однако самое замечательное в Prometheus то, что он согласованно работает почти со всеми другими инструментами и является отличным дополнением к вашему стеку. Поскольку предприятия обычно используют более 20 инструментов мониторинга одновременно, наличие инструмента нового поколения, такого как Prometheus, разработанного с учетом архитектуры микросервисов, действительно является находкой. Или, другими словами, «подарок богов».