Прим. перев.: это перевод статьи, подготовленной по мотивам недавнего выступления Richard Hartmann — заметного представителя команды разработчиков Prometheus, директора по сообществам из Grafana Labs, основателя проекта OpenMetrics и председателя группы SIG Observability в CNCF. Автор подводит итоги последнего года в жизни Open Source-проекта (и сообщества) Prometheus, а также рассказывает об основных трудностях и ближайших перспективах.
Во время PromCon Online 2020 я выступил с докладом под названием «Будущее Prometheus и его экосистемы». И хочу поделиться с вами его ключевыми моментами.
Со времени прошлой конференции PromCon — 2019 — в Prometheus произошло множество изменений.
В версии 2.14 появился новый интерфейс на React. Хотя по функциональности он пока отстает от старого, мы над ним работаем и продолжаем улучшать.
Версия 2.15 прошла под знаком API метаданных. Формат экспозиции Prometheus уже давно поддерживает специальные выражения
В версии 2.16 основное внимание было уделено различным улучшениям и стабильности. Например, пользователи еще с 2016 года просили о возможности выбора локального времени в UI, а также о реализации журнала запросов — было приятно закрыть эти проблемы.
К слову о затянувшихся запросах на фичи: версия 2.17, наконец, дала долгожданную «I» в ACID для БД: изолированность.
В 2.18 были улучшены трассировка и поддержка экземпляров в формате экспозиции. Экземпляры — это первый заметный для пользователя эффект от внедрения OpenMetrics в Prometheus. Объединив их с Grafana, можно достичь удобной детализации, позволяющей переходить от:
… к:
В 2.19 сократили потребление памяти на целых 50%! Даже несмотря на то, что Prometheus уже весьма эффективна, остается значительный потенциал для оптимизации — это одновременно и воодушевляет, и пугает.
Такой график — прекрасная тому иллюстрация:
Версия 2.20 может похвастаться самым длинным списком изменений с момента выхода v2.6(!). Главным, вероятно, является родная поддержка обнаружения сервисов для Docker Swarm и DigitalOcean.
Но есть и более важное изменение, превосходящее по значимости реализацию двух независимых механизмов обнаружения сервисов: мы «разбираем» Prometheus по частям и по-новому смотрим на многие старые решения и устоявшиеся подходы. Мир изменился (возможно, к этому и мы приложили руку) — это необходимо учитывать как в самом проекте, так и в других.
Подводя итог, хочу заметить, что node_exporter достиг версии 1.0 и теперь включает в себя ЭКСПЕРИМЕНТАЛЬНУЮ поддержку TLS. Фонд Cloud Native Computing Foundation проспонсировал аудит node_exporter'а компанией Cure53 (он охватывал как экспортер в целом, так и нашу реализацию TLS в частности). И он того стоил вдвойне: мы не только проверили TLS перед тем, как копировать его в другие экспортеры, но и использовали node_exporter как подопытного кролика, с которого копируются и иные паттерны.
Иногда у меня возникает ощущение, что мы как проект почиваем на лаврах. Некоторое время назад я запустил мозговой штурм внутри Grafana под девизом «Prometheus'у не хватает функций» и призвал Red Hat поступить так же. Попутно мы создали доступный для всей команды Prometheus документ сразу обо ВСЕМ. Он служит основой для рассмотрения конкретных тем, разбитых на пункты для обсуждения во время dev-саммитов (по мере готовности этих пунктов).
В прошлом году у нас было два dev-саммита: один — после KubeCon EU, второй — после PromCon. Планировалось то же самое сделать в 2020 году, но помешал COVID. В этом году пока саммитов не было, но я полагаю, что мы нашли выход: более короткие, частые и виртуальные встречи. Мы проводим блоки по 4 часа вместо того, чтобы собираться сразу на 1-2 дня. Первый такой dev-саммит прошел 10 июля, а следующий, вероятно, состоится 7 августа. Мы продолжим проводить их, пока не разберем все накопившиеся вопросы (хотя их число постоянно растет по мере того, как добавляются все новые пункты из вышеупомянутого документа).
Сейчас я хочу сделать две вещи:
Метаданные начинают приносить реальную пользу в Prometheus (см. 2.15 выше). Нам нужно реализовать больше возможностей для работы с метаданными (например, распространять их через удаленное чтение/запись). Консенсус ниже не охватывает такие интересные вопросы, как «Что делать, если метаданные изменились/пропали?» или «Что делать, если они станут вектором атаки?».
Тема разгребания мусора, скопившегося в рабочих процессах, не требует особого пояснения, однако следует сказать несколько слов об устранении словоблудия (единстве терминологии). Мы серьезно настроены на очистку терминологии: это не самое важное, но то, чем мы можем заняться уже сейчас. Пока мы ждем соответствующего инструментария от GitHub. Как только он появится, попробуем привлечь к этой работе платного стажера через Community Bridge.
Я веду переговоры с Linux Foundation и CNCF о том, чтобы потенциально реализовать это во всех проектах. Отличная возможность для того, кто интересуется данной тематикой: возможность изучить множество проектов, поработать с различными инструментами, познакомиться со многими людьми. Свяжитесь со мной в Twitter (@TwitchiH) или по почте (richih на сервере grafana.com), если вам это интересно.
Это один из самых давнишних запросов на фичи и хороший пример того, как следует подходить к консенсусу. В команде Prometheus циркулирует множество разных мнений по этому поводу, и сложно прийти к общему знаменателю. Поэтому я написал ограниченное и весьма конкретное консенсус-предложение с тремя критериями: «Мы хотим поддерживать backfilling по сети хотя бы блоками, которые не пересекаются с головным блоком».
После продолжительных обсуждений и попыток прийти к консенсусу стало ясно, что сделать это так просто не получится. Поэтому я переформулировал предложение следующим образом: «Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с head block».
Только заставив каждого высказать свое определенное мнение по этому поводу, мы смогли прийти к окончательному варианту: «Мы хотели бы поддерживать backfilling по сети блоками, которые не пересекаются с head block при условии надлежащей реализации». Каждое слово здесь подобрано, чтобы отражать точную степень и границы консенсуса.
Еще одна из задач, связанных с наведением порядка. Здесь я хочу покритиковать Go: он был разработан в мире, в котором единый монореп — это норма. Google хранит весь (или основную часть) своего общего кода в единственном репозитории. Этот подход имеет много преимуществ, но плохо переносится на реальные условия. Go медленно, но верно уходит от этого наследия.
Занимательный факт: я написал консенсус-предложение практически в самом начале обсуждения. Было понятно, что мы как минимум его попробуем. Было понятно, что Ben Kochie вызовется сделать это. И было понятно, что «жертвой» станет node_exporter. Как правило, мы стремимся совершенствовать рабочий процесс, и волонтером всегда выступает Ben, а node_exporter является тем тестовым стендом, с которого мы потом копируем результаты в другие экспортеры. И да, было важно, чтобы обсуждение продолжалось некоторое время и чтобы люди сами пришли к этому, вместо того, чтобы ставить их перед фактом.
Google заблокирован в Китае, однако наши списки рассылки работают на нем. Мы решили попробовать сделать так, чтобы можно было подписываться по электронной почте. Я проверил: prometheus-users+subscribe@googlegroups.com работает. Также можно почитать архивы (https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html), если есть такое желание.
Кроме того, мы позаботились о том, чтобы все желающие могли использовать IRC через Matrix, поскольку для некоторых xkcd 1782 весьма актуален.
Позвольте повторить слова, сказанные на саммите: «Самое первое, что мне не понравилось в Prometheus в 2015, году — это документация; в 2020-м я ее просто ненавижу. Она сложна в использовании и почти бесполезна, подходит только тем, кто уже знает, что делает, или по крайней мере хорошо представляет себе концепции». Короче говоря, мы будем работать в этом направлении:
Если вам это интересно, в настоящее время мы ищем технического писателя в Grafana Cloud, который будет работать над официальной upstream-документацией для Prometheus. В конце концов, мы серьезно относимся к своим обязательствам перед сообществом.
Как обычно, записи по итогам dev-саммита будут опубликованы. Также можно почитать итоги саммита 2020-1 и саммитов прошлых лет.
Читайте также в нашем блоге:
Во время PromCon Online 2020 я выступил с докладом под названием «Будущее Prometheus и его экосистемы». И хочу поделиться с вами его ключевыми моментами.
Резюме
Со времени прошлой конференции PromCon — 2019 — в Prometheus произошло множество изменений.
2.14
В версии 2.14 появился новый интерфейс на React. Хотя по функциональности он пока отстает от старого, мы над ним работаем и продолжаем улучшать.
2.15
Версия 2.15 прошла под знаком API метаданных. Формат экспозиции Prometheus уже давно поддерживает специальные выражения
HELP, TYPE и т.п., однако сам Prometheus раньше просто отбрасывал эти данные. Теперь, когда они остаются, можно открыть внешний доступ к ним через API. Например, Grafana уже пользуется этой возможностью и предоставляет пользователям дополнительную информацию о временных рядах, с которыми те работают:2.16
В версии 2.16 основное внимание было уделено различным улучшениям и стабильности. Например, пользователи еще с 2016 года просили о возможности выбора локального времени в UI, а также о реализации журнала запросов — было приятно закрыть эти проблемы.
2.17
К слову о затянувшихся запросах на фичи: версия 2.17, наконец, дала долгожданную «I» в ACID для БД: изолированность.
2.18
В 2.18 были улучшены трассировка и поддержка экземпляров в формате экспозиции. Экземпляры — это первый заметный для пользователя эффект от внедрения OpenMetrics в Prometheus. Объединив их с Grafana, можно достичь удобной детализации, позволяющей переходить от:
… к:
2.19
В 2.19 сократили потребление памяти на целых 50%! Даже несмотря на то, что Prometheus уже весьма эффективна, остается значительный потенциал для оптимизации — это одновременно и воодушевляет, и пугает.
Такой график — прекрасная тому иллюстрация:
2.20
Версия 2.20 может похвастаться самым длинным списком изменений с момента выхода v2.6(!). Главным, вероятно, является родная поддержка обнаружения сервисов для Docker Swarm и DigitalOcean.
Но есть и более важное изменение, превосходящее по значимости реализацию двух независимых механизмов обнаружения сервисов: мы «разбираем» Prometheus по частям и по-новому смотрим на многие старые решения и устоявшиеся подходы. Мир изменился (возможно, к этому и мы приложили руку) — это необходимо учитывать как в самом проекте, так и в других.
node_exporter
Подводя итог, хочу заметить, что node_exporter достиг версии 1.0 и теперь включает в себя ЭКСПЕРИМЕНТАЛЬНУЮ поддержку TLS. Фонд Cloud Native Computing Foundation проспонсировал аудит node_exporter'а компанией Cure53 (он охватывал как экспортер в целом, так и нашу реализацию TLS в частности). И он того стоил вдвойне: мы не только проверили TLS перед тем, как копировать его в другие экспортеры, но и использовали node_exporter как подопытного кролика, с которого копируются и иные паттерны.
Будущее
Иногда у меня возникает ощущение, что мы как проект почиваем на лаврах. Некоторое время назад я запустил мозговой штурм внутри Grafana под девизом «Prometheus'у не хватает функций» и призвал Red Hat поступить так же. Попутно мы создали доступный для всей команды Prometheus документ сразу обо ВСЕМ. Он служит основой для рассмотрения конкретных тем, разбитых на пункты для обсуждения во время dev-саммитов (по мере готовности этих пунктов).
Саммиты разработчиков
В прошлом году у нас было два dev-саммита: один — после KubeCon EU, второй — после PromCon. Планировалось то же самое сделать в 2020 году, но помешал COVID. В этом году пока саммитов не было, но я полагаю, что мы нашли выход: более короткие, частые и виртуальные встречи. Мы проводим блоки по 4 часа вместо того, чтобы собираться сразу на 1-2 дня. Первый такой dev-саммит прошел 10 июля, а следующий, вероятно, состоится 7 августа. Мы продолжим проводить их, пока не разберем все накопившиеся вопросы (хотя их число постоянно растет по мере того, как добавляются все новые пункты из вышеупомянутого документа).
Сейчас я хочу сделать две вещи:
- Ознакомить вас с тем, о чем нам удалось договориться. Не думаю, что будет полезно или справедливо рассказывать о том, над чем мы пока еще активно думаем. При этом я буду поднимать темы в таком же порядке, в котором мы их обсуждали. Этот порядок определяется общим голосованием — темы, набравшие наибольшее число голосов, обсуждаются в первую очередь.
- Немного рассказать о том, как именно проходят эти встречи и о некоторых соображениях, лежащих в их основе. Хотя я, вероятно, скоро еще напишу пару заметок о ведении этих рабочих сессий.
Метаданные
Метаданные начинают приносить реальную пользу в Prometheus (см. 2.15 выше). Нам нужно реализовать больше возможностей для работы с метаданными (например, распространять их через удаленное чтение/запись). Консенсус ниже не охватывает такие интересные вопросы, как «Что делать, если метаданные изменились/пропали?» или «Что делать, если они станут вектором атаки?».
КОНСЕНСУС: Мы хотим лучше поддерживать метаданные. Работа будет вестись в специальном документе.
КОНСЕНСУС: PR 6815 пойдет в качестве ЭКСПЕРИМЕНТАЛЬНОГО временного решения. Скорее всего, оно будет другим в версиях 3.х.
Изменения в рабочем процессе и s/master/main/
Тема разгребания мусора, скопившегося в рабочих процессах, не требует особого пояснения, однако следует сказать несколько слов об устранении словоблудия (единстве терминологии). Мы серьезно настроены на очистку терминологии: это не самое важное, но то, чем мы можем заняться уже сейчас. Пока мы ждем соответствующего инструментария от GitHub. Как только он появится, попробуем привлечь к этой работе платного стажера через Community Bridge.
Я веду переговоры с Linux Foundation и CNCF о том, чтобы потенциально реализовать это во всех проектах. Отличная возможность для того, кто интересуется данной тематикой: возможность изучить множество проектов, поработать с различными инструментами, познакомиться со многими людьми. Свяжитесь со мной в Twitter (@TwitchiH) или по почте (richih на сервере grafana.com), если вам это интересно.
КОНСЕНСУС: Установить «Требовать прохождения проверок статусов перед merge'ем» во всех репозиториях prometheus/… Не допускать прямые push'и в main branch? Не допускать force push'и в main branch?
КОНСЕНСУС: Отключить force push'и во все main branches.
КОНСЕНСУС: Поведение по умолчанию разрешает push'и в main branch, однако его следует отключить для некоторых «важных» репозиториев, например, prometheus/prometheus (на усмотрение maintainer'а).
Заполнение данными (backfilling)
Это один из самых давнишних запросов на фичи и хороший пример того, как следует подходить к консенсусу. В команде Prometheus циркулирует множество разных мнений по этому поводу, и сложно прийти к общему знаменателю. Поэтому я написал ограниченное и весьма конкретное консенсус-предложение с тремя критериями: «Мы хотим поддерживать backfilling по сети хотя бы блоками, которые не пересекаются с головным блоком».
После продолжительных обсуждений и попыток прийти к консенсусу стало ясно, что сделать это так просто не получится. Поэтому я переформулировал предложение следующим образом: «Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с head block».
Только заставив каждого высказать свое определенное мнение по этому поводу, мы смогли прийти к окончательному варианту: «Мы хотели бы поддерживать backfilling по сети блоками, которые не пересекаются с head block при условии надлежащей реализации». Каждое слово здесь подобрано, чтобы отражать точную степень и границы консенсуса.
КОНСЕНСУС: Мы хотим поддерживать текстовый формат экспозиции Prometheus и OpenMetrics, и один четко определенный CSV-формат для импорта данных.
КОНСЕНСУС: Мы хотим поддерживать backfilling по сети хотя бы блоками, которые не пересекаются с головным.
НЕ КОНСЕНСУС: Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с головным блоком.
КОНСЕНСУС: Мы хотели бы поддерживать backfilling по сети блоками, которые не пересекаются с головным блоком при условии надлежащей реализации.
Вендоринг
Еще одна из задач, связанных с наведением порядка. Здесь я хочу покритиковать Go: он был разработан в мире, в котором единый монореп — это норма. Google хранит весь (или основную часть) своего общего кода в единственном репозитории. Этот подход имеет много преимуществ, но плохо переносится на реальные условия. Go медленно, но верно уходит от этого наследия.
Занимательный факт: я написал консенсус-предложение практически в самом начале обсуждения. Было понятно, что мы как минимум его попробуем. Было понятно, что Ben Kochie вызовется сделать это. И было понятно, что «жертвой» станет node_exporter. Как правило, мы стремимся совершенствовать рабочий процесс, и волонтером всегда выступает Ben, а node_exporter является тем тестовым стендом, с которого мы потом копируем результаты в другие экспортеры. И да, было важно, чтобы обсуждение продолжалось некоторое время и чтобы люди сами пришли к этому, вместо того, чтобы ставить их перед фактом.
КОНСЕНСУС: Удалить его в node_exporter и посмотреть, довольны ли мы будем результатом.
Списки рассылки и IRC
Google заблокирован в Китае, однако наши списки рассылки работают на нем. Мы решили попробовать сделать так, чтобы можно было подписываться по электронной почте. Я проверил: prometheus-users+subscribe@googlegroups.com работает. Также можно почитать архивы (https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html), если есть такое желание.
Кроме того, мы позаботились о том, чтобы все желающие могли использовать IRC через Matrix, поскольку для некоторых xkcd 1782 весьма актуален.
КОНСЕНСУС:
Посмотреть, возможно ли подписываться на наши списки рассылок без учетки Google и подключить этот функционал; для публикации по-прежнему требуется подписка.
Добавить ссылку на общедоступный архив списков рассылок в разделе docs/community и рассказать, как можно подписаться на рассылки без учетной записи Google.
Отключить требования идентификации в каналах IRC, чтобы упростить использование Matrix; вернуть все назад, если будут атаки.
Документация
Позвольте повторить слова, сказанные на саммите: «Самое первое, что мне не понравилось в Prometheus в 2015, году — это документация; в 2020-м я ее просто ненавижу. Она сложна в использовании и почти бесполезна, подходит только тем, кто уже знает, что делает, или по крайней мере хорошо представляет себе концепции». Короче говоря, мы будем работать в этом направлении:
КОНСЕНСУС:
Мы разделим документацию на три части:
* Руководство пользователя (user manual) как простой для понимания вариант по умолчанию.
* Справка (reference) по аналогии с той, что у нас сейчас есть с примерами на PromQL для ввода/вывода.
* Гайды (guides), желательно на модульной основе.
Мы попросим Diana Payton разработать единый стиль оформления, общую концепцию и т.п. для всей документации.
Мы постараемся не ломать ссылки понапрасну.
Если вам это интересно, в настоящее время мы ищем технического писателя в Grafana Cloud, который будет работать над официальной upstream-документацией для Prometheus. В конце концов, мы серьезно относимся к своим обязательствам перед сообществом.
Как обычно, записи по итогам dev-саммита будут опубликованы. Также можно почитать итоги саммита 2020-1 и саммитов прошлых лет.
P.S. от переводчика
Читайте также в нашем блоге:
amarao
Спасибо. Пример корпоративного блога, чтение которого не вызывает недоумения и чувства пустоты.
Подсказка: посты без картинки вызывают больше интереса, потому что "картинку для привлечения внимания" обычно фигачат те, кому нечего писать.
shurup Автор
Спасибо на добром слове!
По картинкам: может быть, «обычно» и да. Но мы
много раз видели, как любят наши иллюстрации (а некоторые коллеги даже ждут издания сборника избранных…)стараемся балансировать в разумных пределах ;-)