Алгоритм прометей: Прометей ВКонтакте. Как попасть?

Содержание

Прометей ВКонтакте. Как попасть?

«Прометей» отметил наше сообщество Targetgirl, и мы стали частью Пантеона авторов.

Я еще не писала об алгоритме «Прометей», хотя каждый уважающий себя автор, связанный с тематикой SMM, уже тысячу раз рассказал о секретах получения заветного огонька – даже не имея опыта его получения!

 

«Прометей» – это алгоритм, созданный для поиска и поддержки интересных авторов и сообществ. Искусственный интеллект постоянно находит создателей уникального контента и следит за их достижениями.

 

Зачем каждому SMM-специалисту нужно стремиться получить эту метку?

  1. Метка выдается всего на семь дней, в это время ваши посты получают тысячный охват среди пользователей ВК совершенно бесплатно.

  2. В мобильных приложениях сервис Рекомендаций покажет записи сообщества людям, которые еще не знакомы с ним, но, возможно, заинтересованы в нём.

  3. Сообщество попадет в список приложения «Пантеон авторов».

Так за одну неделю вы можете увеличить охват сообщества в десятки тысяч раз абсолютно бесплатно!

Метка выдается всего на неделю, получить «огонек» можно неограниченное количество раз.

Почему же до сих пор я воздерживалась от рассказов об этом алгоритме?

Думаю, прежде чем говорить о методах его работы и способах получения «огня», сначала нужно стать обладателем этой метки.

Что могу посоветовать тому, кто стремится получить огонек?

Первая категория - творчество:
⁃ Например, вы пишите музыку ⁃ Или стихи ⁃ А может быть фотографируете или рисуете

Получить заветную метку не составит труда. Притом совершенно неважно, сколько в вашем сообществе человек: 10 или 5000. Главное – это уникальность контента. «Прометей» в первую очередь поощряет авторов, которые создают творческие некоммерческие проекты. И это довольно честно – я говорю как человек, который долгое время увлекался фотографией. Зарабатывать на творчестве довольно трудно, поэтому вкладывать в продвижение затратно и неудобно. Как говорится, «художник должен быть голодным». ВКонтакте с авторами делают хорошее дело, помогая пробиться начинающим талантам.

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

Вторая категория, которой тоже очень легко получить огонёк от «Прометея» – это путешественники.
Travel-блогинг с каждым днем набирает обороты и приобретает все большую популярность среди людей. Если вы часто путешествуете и постоянно ведете свой блог, выкладываете интересные заметки о культуре и жизни разных стран, снимаете видеоотчеты и красивые фотокарточки, то вам не составит труда получить метку.

Третья категория: это всевозможные коммерческие проекты.
Да, нам с вами придется попотеть, чтобы заинтересовать «Прометея».
Почему? Да потому что мы являемся кормильцами компании ВКонтакте. Мы и есть рекламодатели, которые готовы платить за рекламу и продвижение наших сообществ. Довольно справедливо, однако даже у нас с вами есть шанс заполучить огонек.

 

  1. Создавайте уникальный контент – это принцип, от которого не отойти. Забудьте о рерайтинге, ищите себе SMMщиков, которые умеют писать (что самое главное) и способны разобраться в вашей теме (т.е. если ваша компания продает психологические тренинги, сммщик обязан разбираться в психологии).

  2. Помимо уникальных текстов вам понадобятся и уникальные картинки высокого качества: фотографии, иллюстрации. Наймите фотографа или найдите себе иллюстратора, который сможет обеспечить вас уникальными изображениями по ТЗ.

Мы рисуем комиксы и иллюстрации к каждому посту

  1. Создавайте контент, который будет вовлекать пользователей в дискуссии. Это могут быть неоднозначные посты на спорные тематики. Главное не переборщите, в интернете очень легко наткнуться на негативных троллей 🙂 Умейте вежливо отстаивать свою точку зрения в комментариях. Боритесь с негативом, ни в коем случаи не игнорируйте его.
    Как, например, тут

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

  3. Думайте о своей аудитории. Интересуйтесь, что они хотели бы знать. Не игнорируйте их сообщения. Изучайте свою аудиторию и создавайте по-настоящему полезный и интересный контент для неё.

  4. Проводите интересные трансляции от сообщества.

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

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

 

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

 

Как работает «умная» лента и алгоритм поиска талантов «Прометей» во ВКонтакте

Социальные сети открывают творческим людям прямой канал для связи с аудиторией. Канал без посредников. Современных талантов на большую эстраду несут на руках тысячи преданных фанов, а не продюсеры в деловых костюмах. В России молодые звёзды приходят из ВКонтакте. Художники Duran, Gudim и Покрас, музыкант Макс Корж, рэперы Face и Скриптонит. Для автора публиковать свои работы ВКонтакте — возможность завоевать популярность.

Чтобы связать автора с аудиторией мы используем технологии машинного обучения и нейронные сети, алгоритмы которых, лежат в основе таких продуктов как «умная лента новостей», раздел «Рекомендации» в мобильном приложении и механике поиска талантов «Прометей». Они появились во ВКонтакте в сентябре 2017 года.

Сейчас Рекомендации посещает каждый третий пользователь ВКонтакте. С момента запуска среднее количество просмотров записей на пользователя в рекомендациях выросло на 40%, а количество отметок «Мне нравится» — на 118%. Раздел Рекомендаций постоянно обучается. Чем больше пользователи взаимодействуют с сервисом, тем точнее алгоритмы угадывают их предпочтения.

Искусственный интеллект Прометей находит создателей интересного контента и следит за их достижениями. За публикации, отмеченные особым вниманием пользователей, автор или его сообщество получает знак огня и повышенные охваты в разделе Рекомендаций. Метка выдаётся на семь дней, столько же длится поддержка охватами. Получить «огонёк» можно неограниченное количество раз.

За время работы Прометей нашёл более 4000 авторов и помог им обрести сотни тысяч новых заинтересованных подписчиков.

fs disable

Как и у древнегреческого тёзки, вокруг алгоритма «Прометей» собралось множество мифов. В этой статье мы обсудим самые популярные из них и выясним:

  • сколько нужно подписчиков, чтобы автора заметил Прометей;
  • чему должно быть посвящено его творчество;
  • от чего зависит прирост новых участников.

Миф первый: Прометей отмечает только крупные сообщества и популярных пользователей с большим количеством подписчиков

Как на самом деле?

Метку огня действительно получали такие гиганты, как вДудь, Duran, Bird Born, History Porn, поэт Ах Астахова и писатель Александр Полярный. Но только ли известные авторы могут претендовать на внимание алгоритма? Для ответа на этот вопрос, перейдём к примерам пользователей и сообществ, которых отмечал Прометей.

  • Canceled — в сообществе собрана информация по невыпущенным играм, альфа/бета-версиям, вырезанному контенту и концепт-артам. Всё то, что так и не вышло в свет, но заслуживает внимания;
  • Количество подписчиков: 5956.

fs disable

  • В сообществе Понимай кино собраны пасхалки из фильмов, скрытые послания режиссеров, отсылки к старым классическим лентам и литературным произведениям;
  • Количество подписчиков — 3678.

fs disable

  • Александр Фёдоров — фотожурналист, который путешествует по самым опасных уголкам планеты и никогда не выпускает камеру из рук. Однажды ему пришлось двое суток провести в тундре и спать на голом снегу;
  • Количество подписчиков: 1700.

fs disable

  • Новгородская группа SHEDDA — это задорные кельтские мотивы, скандинавские баллады и разудалые морские песни, приправленные фолк-роком: https://vk.com/wall-4230052_1483, https://vk.com/wall-4230052_1462.
  • Количество подписчиков: 1600.

Вывод

Для того, чтобы автора заметил Прометей, необязательно иметь сотни-десятки тысяч поклонников. У алгоритма нет минимального порога — среди отмеченных огнём есть пользователи и сообщества, количество подписчиков которых не превышало и сотни. Так, например, у группы философа Маркий до знакомства с Прометеем было 32 участника, сейчас в сообществе больше 2000 подписчиков.

Миф второй: «Прометей» влияет на охваты, но не привлекает новых подписчиков

Как на самом деле?

В среднем охват за неделю огня у всех авторов возрастает десятикратно. Прометей действительно показывает материалы огромной аудитории, но помогает ли алгоритм заполучить новых подписчиков? Посмотрим на статистику нескольких огненных авторов.

  • Дома — сообщество, в котором подписчики со всех уголков света делятся фотографиями своих квартир. В группе можно найти убежище на любой вкус: от шикарных интерьеров с лепниной до ламповых коммуналок с высокими потолками и великолепными рассветами;
  • Количество подписчиков — 45 766;
  • За неделю Прометея + 7200 новых участников.

fs disable

  • Развитие жизни на земле — проект, посвящённый эволюции. В сообществе собрана информация о развитии жизни на нашей планете, описания необычных существ, когда-то населявших Землю, и причины их вымирания;
  • Количество подписчиков: 10 367;
  • За неделю Прометея + 4900 новых участников.

fs disable

  • Старый фонд — это коллекция дореволюционного Петербурга, скрытого от глаз простых прохожих. Интерьеры квартир, искалеченных коммунальным бытом и слоями краски, но не убитых евроремонтами. Изразцовые печи, камины, двустворчатые двери, высокие потолки и мраморные подоконники;
  • Количество подписчиков: 41 935;
  • За две недели Прометея + 5000 новых участников.
  • Сообщество космонавта-испытателя Сергея Рязанского рассказывает о рабочих буднях на борту МКС, об экзаменах, которые проходит экипаж перед отлётом, и о жизни в невесомости. Здесь можно полюбоваться на неповторимые ночные таймлапсы, фотографии песчаных штормов, вулканов и городов;
  • Количество подписчиков: 27 032;
  • За три недели Прометея + 7500 новых участников.

fs disable

Вывод

Прирост новых подписчиков зависит от самого автора, его активности и качества публикуемого контента. Большой охват — это здорово, но если автор не сможет заинтересовать новых пользователей, количество подписчиков не увеличится.

Так, например, художник TOXANDREEV после того, как его сообщество отметил «Прометей», опубликовал приветственную серию иллюстраций для новых участников.

Миф третий: «Прометей» отмечает только творческих пользователей популярных тематик (иллюстраторы, фотографы, писатели и музыканты)

Как на самом деле?

«Прометей» сумел найти довольно нетипичных авторов, не имея предпочтений по каким-либо темам.

fs disable

  • Elena Samko Cosplay. Костюмы и грим этого косплеера — произведение искусства. Помимо популярных персонажей Елена перевоплощается в антигероев: в коллекции жуткая «кухарка» из Ведьмака, женский вариант Фредди Крюгера и даже септа Юнелла из сериала «Игра престолов».
  • Из окна вагона — железная дорога, поезда и мелькающие за окном пейзажи.

fs disable

Среди авторов, отмеченных огнём, есть не только представители творчества. Так, например, сообщество, посвященное растяжке, СтретчингДома за одну неделю «Прометея» получило почти 8 тысяч новых заинтересованных участников.

fs disable

А беговой клуб «GoRun», где участники делятся результатами пробежек, за неделю огня получил 1300 новых подписчиков.

fs disable

Вывод

Для «Прометея» неважно, что делает автор. Собирает ли стадионы или публикует подборки фотографий из окна поезда. Пишет пейзажи или примеряет трамваям анимешные прически. У каждого создателя контента есть своя аудитория, и алгоритм поможет её найти.

Подведём итоги

  • Для «Прометея» не имеет значения количество подписчиков. Нет необходимого минимума для получения метки огня;
  • Количество новых подписчиков зависит от самого автора. Если он взаимодействует с аудиторией и публикует качественный контент, прирост участников не заставит себя ждать;
  • У «Прометея» нет предпочтений и любимых тематик. Будь то известный музыкант с миллионом фанатов или тестировщик мебели ИКЕА. Если человек увлекательно рассказывает о работе и жизни, он — автор. А значит «Прометей» рано или поздно отметит и его.

Как получить метку огня?

  • Творите. Создавайте интересные материалы и публикуйте их ВКонтакте;
  • Следите за оформлением страницы и сообщества, не нарушайте правила сайта;
  • Оставайтесь собой. Автору не нужно соответствовать общепринятым ролям или чьим-то нормам — «Прометей» заглядывает во все уголки ВКонтакте и выходит за пределы известных кластеров;
  • Наберитесь терпения. «Прометей» находит новых авторов ежедневно, но даже искусственный интеллект не отметит всех и сразу. В противном случае раздел рекомендаций содрогнулся бы от наплыва интересных материалов.

Завершим наше расследование отзывами пользователей, получивших «огонёк».

Как заставить работать "Прометея" ВКонтакте?

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

Система «Прометей» ВКонтаке — это искусственный интеллект, который отбирает пользователей или сообщества с наиболее интересным контентом. Бот работает на основе нейронных сетей и постоянно развивается, обретая новые функции.

До создания «Прометея» в сентябре 2017 года, в сети ВКонтакте уже работала «Умная лента», которая предлагала пользователю записи, основываясь на двух факторах:

  1. Наиболее высокая скорость набора лайков и репостов
  2. Интересы друзей, то есть то, что нравится и просматривают друзья пользователя

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

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

Схема работы алгоритма достаточно проста. Бот работает с двумя основными переменными:

  • Пользователи
  • Авторы

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

Что касается последних, то «Прометей» анализирует все публикуемые Вконтакте записи и выискивает наиболее уникальный и интересный контент. Главным критерием отбора является оригинальность и содержательность, по этой причине не приветствуются репосты, копирование чужого материала и анонсы. Программа также анализирует насколько записи соответствуют общей тематике блога, а фото и видеоматериалы – прикрепленному тексту. Важной составляющей является активность пользователей, их реакции и взаимодействие с автором. Учитывается и то, возвращаются ли пользователи к записям и надолго ли задерживаются, при этом рассматривается не один конкретный пост, а статистика всей страницы в целом.

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

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

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

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

Правило №1. Оригинальность и авторство

Существует мнение, что наиболее популярными темами, способными заполучить огонь, являются творчество, путешествия и коммерческие проекты. Однако это не так, «Прометей» обращает внимание на целостность и уникальность публикаций, а не на их тему. Единственное, что алгоритм обходит стороной, – это материалы, содержащие возрастные ограничения и нарушающие законодательство РФ. Оставайтесь собой и создавайте то, что интересно в первую очередь вам самим. Так получится избежать мучительных поисков идей для постов и соблазна к копированию чужого.

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

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

Правило №2. Регулярность

Радуйте публикациями своих подписчиков как можно чаще. Ежедневные обновления позволят не терять контакт с аудиторией и постепенно повышать активность. Вовлеченность подписчиков и регулярность постов гарантированно понравятся «Прометею». Однако все же стоит соблюдать баланс и не заваливать читателей бесконечным потоком информации. Оптимальным считается до 5-7 записей в день.

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

Правило №3. Загрузка контента без посредников

«Прометей» может работать только с материалами загруженными Вконтакте напрямую. Данные, предоставленные с помощью ссылок на другие ресурсы, бот не распознает и не включает в свой анализ.

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

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

Правило №4. Качественное оформление

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

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

 

Соблюдая описанные выше правила, ваши шансы на внимание «Прометея» станут повышаться с каждой опубликованной записью и написанным комментарием.

Огонь «Прометея» – замечательная возможность для самостоятельного продвижения сообщества. Получив огонь, авторы награждаются рядом преимуществ, способствующих более скоростному развитию, а также ботом-помощником с полезными советами по работе со статистикой, которая у многих вызывает вопросы.

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

Все обладатели огонька попадают в пантеон авторов – место, где в одном каталоге собраны все носители метки «Прометея» за последние 4 недели. Участники пантеона обладают возможностью первыми опробовать новые функции и инструменты, запускаемые разработчиками Вконтакте, например, редактором статьей. Самые интересные и прорывные проекты появляются на официальной странице алгоритма ВК, получая тем самым дополнительную бесплатную рекламу.

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

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

Согласно статистике, сегодня раздел рекомендаций посещает один из трех пользователей Вконтакте. Благодаря системе «Прометей» количество просмотров на одного человека увеличилось на 40%, а процент отметок «мне нравится» возрос в почти в полтора раза.

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

Что дает блогеру отметка «Прометея» во ВКонтакте

С конца прошлого года у пользователей ВКонтакте начал появляться значок огня на личной странице или в сообществе. В соцсети заработал новый алгоритм поиска талантов «Прометей». Мы опросили блогеров, которые успели оценить на себе действие алгоритма, и выяснили, чем он полезен авторам.

Что такое «Прометей»

«Прометей» — механика поиска талантов, которая появилась во ВКонтакте в сентябре 2017 года. Искусственный интеллект находит создателей интересного контента. Выделяет их на 7 дней значком огня, который появляется рядом с именем или названием сообщества. Алгоритм помогает получить больше внимания и новых подписчиков. По данным на начало февраля, «Прометей» отметил значком более 4000 авторов.

Как «Прометей» привлекает внимание к авторам? Страницы, которые выбрал искусственный интеллект, получают повышенный охват в разделе «Рекомендации». Раздел посещает каждый третий пользователь соцсети. Авторы с «огоньком» оказываются в центре внимания и получают новых подписчиков.

Кого выбирает «Прометей»? Чтобы алгоритм заметил автора, ему необязательно иметь популярную страницу. Среди отмеченных знаком огня есть сообщества с сотней подписчиков и многотысячные гиганты. Считается, что «Прометей» выделяет творческие сообщества: писателей, иллюстраторов, фотографов. На самом деле, если пользователь делает увлекательный контент, скажем, о жизни в коммуналке, то алгоритм тоже поможет ему найти больше подписчиков.

Как получить огонь «Прометея»? Социальная сеть поддерживает активных пользователей, которые делают интересный авторский контент. Пишите, снимайте видео, рисуйте или фотографируйте что вам нравится. Будьте собой, но не забывайте об оформлении страницы – оно должно соответствовать правилам сайта. И немного терпения – талантов много, а алгоритм один.

Какой эффект дает «огонек»

Многие авторы, чьи страницы отмечает «Прометей», замечают эффект от действия алгоритма почти сразу. Помимо визуального символа в личные сообщения приходит пояснение от «Прометея» и резко возрастает охват аудитории у постов.

Богдан Дьяконов, создатель и администратор группы «Развитие жизни на Земле (The Evolution Of Life)», 18 тыс. подписчиков
Когда горит огонь, количество просмотров, лайков и комментариев гораздо больше. Порой доходило до 500 лайков, а запись видело 318 000 человек. Для меня это было очень приятно. Ведь сообщество слабо развивалось, а тут такой скачок.

Когда я в первый раз получил огонек, количество людей в группе было примерно 1600. После этого я еще два раза получал огонек, второй раз почти сразу. И в итоге уже почти 17 000 — увеличение больше чем в десять раз. Появилось много заинтересованных людей, стали задавать вопросы. А я просто продвигаю то, что мне самому нравится. Благодаря «Прометею» мои труды хоть как-то вознаграждены.

Никита Савянин, администратор сообщества Canceled, 6 тыс. подписчиков, группа не обновляется с 22 января
Отклика, каких-то изменений не произошло. Я ощутимого прироста не заметил.

Артем Ремизов, киноблогер, 1,3 тыс. подписчиков
Из-за моей активной деятельности в ВК «Прометей» рухнул мне одному из первых. В глаза бросились два ключевых фактора: охваты на постах, которые раньше еле-еле выходили за тысячу, увеличились в несколько десятков, а то и сотен раз. Плюс на меня начали подписываться пользователи. Если до этого в месяц могло прийти 10-12 человек, то тут буквально за неделю количество пришедших переступило порог в 50 человек.


Такое сообщение получил Артем от «Прометея»

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

В результате увеличил количество подписчиков и комментариев под постами.

Алексей Бесфамильный, автор сообщества «Дома», 52 тыс. подписчиков
Отклик нашей аудитории на время действия «Прометея» никак не изменился, люди реагируют так же: им нравится наш контент. Только теперь зрителей стало больше, это круто. Результаты можно посмотреть в статистике:


Паблик получал значок огня дважды. Действие последнего еще идет

Влада Аксенова, автор паблика «Нормальная», 940 подписчиков
Первый эффект был до появления «огонька» — сначала у последнего поста резко возросли просмотры в течение дня, а на следующий день появился значок. Число комментариев не особо увеличилось, а «лайки» возросли только на последнем посте, на других осталось то же количество.

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

Дарья, создатель группы «Живописность русских коммуналок», 45 тыс. подписчиков
Первый эффект — посты в группе стало видеть больше людей. Увеличилось количества лайков и репостов. Из минусов только одно: увеличился флуд в комментариях, появились агрессоры и рекламщики своих пабликов и разного рода платформ. В итоге количество участников группы увеличилось почти вдвое. Улучшились статистические показатели. Стало больше рекламных предложений.

Как использовать отметку «Прометея»

С увеличением охвата важно не прекращать обновления и продолжать радовать читателей интересными постами — так, как вы умеете это делать.

Артем Ремизов
Когда получил значок «огня», я продолжал писать в свое удовольствие. Я этим занимаюсь не ради денег. Да, от славы я не откажусь, конечно, но как-то подстраивать свой контент под «Прометея» я не стал.

Алексей Бесфамильный
Ничего нового мы не делаем. Продолжаем публиковать тот контент, который нравится нашим подписчикам.

Влада Аксенова
Я постила каждый день и через день. Но у меня не тот контент, который просто генерировать каждый день — я рисую и это требует времени, поэтому хороший контент был вперемешку с проходным. Причем «Прометей» пиарил самые ненужные посты. У меня в группе есть постоянные хештэги. Не знаю, как именно работает «Прометей», но почему-то он не продвигал посты с хэштегами. В них как раз и содержался самый интересный и целевой контент. Зато он продвигал проходные посты, у которых не было хэштега.

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

Дарья
Мы ввели новые рубрики, чтобы заинтересовать новопришедшую аудиторию.

В чем польза для блогера

Опрошенные Hello Blogger авторы и создатели сообществ отмечают, что «Прометей» позволил ВКонтакте предложить аудитории «свежую кровь» — новых, молодых авторов, которых люди не знают. Раньше эти люди не могли достучаться до читателей из-за главенства в ленте постов крупнейших пабликов.

Богдан Дьяконов
Функция очень полезная. Люди нечасто ставят лайки и делают репосты, так что порой о хороших или интересных сообществах никто и не знает. А на пике популярности — лишь пропиаренные группы. Функция позволяет таким простым людям, как я, доносить до других важную или интересную информацию.

Алексей Бесфамильный
Мне кажется, это очень круто и неплохо поможет тем, кто создает уникальный контент. Функцию оцениваю только позитивно.

Артем Ремизов
Как автор «с улицы» могу сказать, что эта фича хорошая. Но главное, чтобы она реально принесла пользу простым ребятам, любящим писать, рассказывать и делиться чем-то. Уверен, что работы с ней у ребят из ВК еще пруд пруди, но сам факт появления такого инструмента меня радует.

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

Олег Курочкин
До «Прометея» казалось, что ВК вошел в стадию стагнации. Популярные паблики, созданные уже давно, публикуют одни и те же материалы. Было ощущение, что аудитория пользуется этими пабликами больше по привычке. То есть ВК в какой-то момент превратился в «царство копипаста». И вероятно, что пользователи просто даже перестали предъявлять контенту в ВК такие требования, как оригинальность и свежесть. Потому что возникало ощущение, будто оригинального и свежего контента здесь просто нет! Новым пабликам с уникальным контентом было сложно заявить о себе в таких условиях. «Прометей» начал эту историю исправлять. Он находит и продвигает именно первоисточник. При этом совершенно бесплатно.

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

Изображение на обложке из статьи ВК

Прокачайте страницу в ВК

Автор: Ольга Дубро

Поделиться

Поделиться

Твитнуть

Плюсануть

Запинить

Класснуть

Отправить

Вотсапнуть

Вам может понравиться

[email protected]
+7 (812) 409-38-28

ул. Большая Посадская, 1/10
Санкт-Петербург

Подпишитесь на нас в соцсетях:

5 принципов получения огня «Прометея» на отдельную запись во ВКонтакте

Неделю назад команда ВКонтакте провела закрытую встречу с авторами, отмеченными огнем «Прометея». Эта отметка дает пабликам дополнительные охваты аудитории за счет продвижения записей через раздел «Рекомендации». На мероприятии разработчики рассказали о нововведениях, которые соцсеть запустит для привлечения талантов. Первое заработало в минувшую пятницу — «Прометей» стал отмечать не только сообщества, но и отдельные интересные записи. Hello Blogger рассказывает, как устроена новая функция.

  1. Чтобы получить отметку «Прометея», запись должна быть интересной, уникальной и соответствовать тематике страницы. Понятие интереса субъективно, поэтому разработчики рекомендуют авторам ориентироваться на свои вкусы — писать о том, что интересно самому. Уникальный — не скопированный ниоткуда. Соответствие тематике тоже надо понимать буквально: если паблик о рецептах, то «огонек» может получить запись с рецептом, а запись с обзором смартфона — не может.
  2. Получению «огня» поможет трафик из внешних источников, репосты в соцсети и регулярность публикаций в паблике. Ставьте ссылки на новые записи в ВК на других платформах. Пишите то, что читателя захотят сохранить в свою ленту, сделав репост. Делайте публикации постоянно, хотя бы два-три раза в неделю.
  3. Алгоритм выдает отметку на сутки. «Прометей» для пабликов дает повышенное охваты на семь дней, а отдельный пост будет продвигаться только 24 часа.
  4. «Прометей» автоматически снимет отметку, если публикацию отредактировали. Менять содержание поста после получения «Прометея» нельзя, иначе продвижение прекратиться. Это сделано, чтобы не допустить в «Рекомендациях» рекламу, кликбейт и спам.
  5. Если продолжать в том же духе, алгоритм подарит «огонек» всему паблику. Выпускайте новые записи, которые будут «лайкать», репостить и комментировать — получите «Прометей» на семь дней, для всех новых записей.

Изображение на обложке из поста разработчиков ВКонтакте

Автор: Илья Новиков

Прометей: Как получить «огонек» Вконтакте и что он дает? Разбор кейса

Замечали такую пиктограмму рядом с названием сообществ?

Это функция ВКонтакте, запущенная в октябре 2017 года. Алгоритм называется «Прометей». Он призван помочь талантливым авторам найти свою аудиторию.

В ноябре прошлого года впервые получили огонек на сообществе клиента. Статья написана в то же время, но до публикации руки дошли только сейчас. После, еще не раз получали «огоньки», и написанное ниже полностью соответствует последним результатам. Так что материал актуален, поэтому публикуем.

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

О «Прометее»

Суть: алгоритм отслеживает контент, который публикуют сообщества ВКонтакте, и реакцию пользователей на этот контент. Если он видит, что посты сообщества находят хороший отклик у пользователей, он может отметить его особой меткой — пиктограммой «огонька», которое отображается рядом с названием. Дается она на 7 суток. В течении этого времени посты сообщества будут показываться пользователям, которые на него не подписаны, но которым, по мнению алгоритма, может быть интересен этот контент.

В мобильном приложении ВКонтакте появилась вкладка «Рекомендации». Как раз сюда попадают материалы от сообществ, которые отмечены огоньком. Таким образом охват постов увеличивается от 2-х до 17-ти раз.

Дается этот огонек на 7 дней. В течении этого периода все посты сообщества получат дополнительный охват.

Как получить огонек?

Однозначный ответ дать сложно. Если совсем просто — публиковать качественный контент. Но что это значит? Официальная справка ВКонтакте дает такие рекомендации:

  • Публикуйте уникальный контент. Уникальный текст, картинки, видео.
    (Комментарий от меня: ВК определяет уникальность контента (текста, картинки, видео) внутри сети. То есть если у вас есть контент на других площадках, которого пока нет в VK — это будет считать уникальным материалом.)
  • Загружайте видео напрямую ВКонтакте (не через плеер YouTube).
    (Комментарий от меня: Это же касается и клипов. VK стремительно сужает охваты записей с ютубовским плеером стремясь продвигать свой видеосервис. Вопрос для музыкантов важный поэтому обсудим его позже в отдельной статье)
  • Делайте истории
  • Делайте прямые трансляции

Это уже от меня (не из официального релиза):

  • Старайтесь не делать репостов в группу. Лучше сделайте отдельную запись в сообществе. В этом случае охват будет больше. Если репост все же необходим — делайте уникальную подпись.
  • Используйте формат лонгридов. Проверено: записи подобного типа получают дополнительный охват (по нашему опыту, охват увеличивается в 2-3 раза). Например у этого поста охват почти в 3 раза больше, чем в среднем по сообществу.
  • Периодически заходите во вкладку «Статистика» > «Записи». И сортируйте записи по количеству лайков, репостов, комментариев. Так вы сможете понять, какой тип контента лучше «заходит» вашей аудитории. Можно, конечно, использовать более продвинутые сервисы, типа Popsters, но для большинства задач достаточно и встроенной в VK аналитики. Чаще публикуйте посты, которые нравятся вашей аудитории.

Ссылка на официальные рекомендации ВК по алгоритму «Прометей»: vk.com/page-76477496_55227511
Более подробно о том, как увеличить охваты постов, и что на это влияет я рассказывал тут.

Как получили галочку мы:

18 ноября, в личные сообщения пришло это:

С этого момента начались 7 дней с «огоньком».

Как получили? Делали все как рекомендует ВК. Публиковали уникальный контент. Анализировали, как пользователи на него реагируют. Старались его улучшить, в соотвествии с наблюдениями.

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

Что дает:

Как писали выше — в течении 7 дней дает дополнительный охват пользователей, которые на вас не подписаны, но которым, в теории, может быть интересен ваш контент. Что по факту? Об этом ниже.

Что делали на время «Огонька»

На период действия алгоритма мы увеличили количество публикаций контента в 3 раза (3 поста в день, против стандартного одного). Также ускорили все интересные публикации и постарались выпустить их в период действия «огонька». Больше публиковали материалов, которые могут быть понятны человеку «со стороны», не знакомому с творчество артиста.

Эти меры логичны и оправданы: мы получаем дополнительный бесплатный охват на протяжении короткого промежутка времени. Хорошо бы это использовать по максимуму.

Фактический результат

Реальный результат следующий: охваты постов действительно возросли до 10 раз. В первую очередь дополнительный охват получили те посты, которые и так не плохо «заходили» нашей аудитории.

Однако подписчиков это практически не дало — среднее дневное количество подписок во время работы алгоритма менялось в пределах погрешности.

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

Выводы и перспективы алгоритма

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

Но пока не все не так радостно: сейчас это дает скорее моральное удовлетворение от работы. Фактический результат от него слабый.

Вопросы и ответы

Влияет ли количество подписчиков на вероятность получения огонька?
Нет, не влияет. В этом легко убедиться посмотрев на паблики во вкладке «Рекомендации», которые пометил огонек. Там попадаются и совсем небольшие.

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

Можно ли получить «Огонек» через администрацию ВКонтакте?
Нет. Это противоречит философии этого инструмента — чтобы не было редакции, предвзятости и человеческого фактора. Огонек может дать только алгоритм Прометей.

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

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

Дополнительные материалы:

Тут вы можете послушать о Прометее от официального представителя ВКонтакте:

Рекомендуем подписать на официальное сообщество «ВКонтакте с авторами». Тут публикуют все обновления для авторов первыми.

Получали огонек? Расскажи ваш опыт в комментариях!

новая статистика и платформа для связи с рекламодателями. Читайте на Cossa.ru

8 июня 2018 года ВКонтакте провела VK Talents Event — закрытую встречу с авторами, отмеченных огнём Прометея. На мероприятии соцсеть анонсировала новинки для создателей контента.

VK Talents

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

Новая статистика

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


На первом этапе, который стартует в ближайшие дни, новая статистика будет доступна только авторам и сообществам, которые получали огонь Прометея.

Публикации с огнём

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


Платформа для связи рекламодателей с «огненными» авторами

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

Выключение комментариев к отдельным записям

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


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

Ранее ВКонтакте представила масштабное обновление системы медиапродуктов на VK Media Day 2018. На мероприятии соцсеть анонсировала запуск платформы подкастов и алгоритма защиты уникального контента Немезида, обновление раздела «Рекомендации» и другие новинки.

Хотите подсказать новость или поделиться экспертным мнением? Пишите: [email protected]

Data-driven без чепухи: спецпроект для практиков

Коллеги из E-Promo объясняют, как data-driven подход помогает проектировать сильные маркетинговые стратегии:

  • Откуда брать ценные для бизнеса данные;
  • Как их корректно агрегировать и анализировать;
  • Как устроено data-driven продвижение на примерах свежих кейсов;
  • И каких результатов можно достичь, интегрировав ИИ-сервисы в работу маркетологов.

2021 — год умного маркетинга, заряженного технологиями и большими данными, не отставайте →

Реклама

Поделиться

Поделиться

гистограмм и сводок | Прометей

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

Поддержка библиотеки

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

Некоторые библиотеки поддерживают только один из двух типов или поддерживают сводки. только ограниченно (без расчета квантилей).

Подсчет и сумма наблюдений

Гистограммы и сводки обоих выборочных наблюдений, обычно запрашиваются продолжительность или размер ответа. Они отслеживают количество наблюдений и сумма наблюдаемых значений, позволяющая вычислить среднее значение наблюдаемых значений. Обратите внимание, что количество наблюдений (отображается в Prometheus как временной ряд с суффиксом _count ) по своей сути счетчик (как описано выше, он только растет).Сумма наблюдения (отображаются как временной ряд с суффиксом _sum ) тоже ведет себя как счетчик, пока нет отрицательных наблюдения. Очевидно, что продолжительность запроса или размер ответа никогда не отрицательный. В принципе, однако, вы можете использовать сводки и гистограммы для наблюдения отрицательных значений (например, температуры в по Цельсию). В этом случае сумма наблюдений может уменьшиться, поэтому вы не может больше применять к нему rate () . В тех редких случаях, когда нужно применить rate () и не избежать отрицательных наблюдений, вы можете использовать два отдельные резюме, одно для положительных и одно для отрицательных наблюдений (последний с перевернутым знаком), а затем объедините результаты с подходящими Выражения PromQL.

Для расчета средней длительности запроса за последние 5 минут из гистограммы или сводки под названием http_request_duration_seconds , используйте следующее выражение:

  скорость (http_request_duration_seconds_sum [5m])
/
  скорость (http_request_duration_seconds_count [5m])
  

оценка Apdex

Прямое использование гистограмм (но не сводок) заключается в подсчете наблюдения, попадающие в определенные периоды наблюдения значения.

У вас может быть SLO для обслуживания 95% запросов в течение 300 мс.В этом случае, настройте гистограмму, чтобы иметь сегмент с верхним пределом 0,3 секунды. Затем вы можете напрямую выразить относительное количество запросы обслуживаются в течение 300 мс и легко предупреждают, если значение упадет ниже 0,95. Следующее выражение вычисляет его по заданию для запросов служил за последние 5 минут. Продолжительность запросов была собрана с гистограмма называется http_request_duration_seconds .

  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (заданию)
/
  сумма (ставка (http_request_duration_seconds_count [5m])) по (задание)
  

Вы можете приблизиться к известному Apdex забейте аналогичным образом.Настроить ведро с целевой продолжительностью запроса в качестве верхней границы и другое ведро с допустимой продолжительностью запроса (обычно 4 раза длительность целевого запроса) в качестве верхней границы. Пример: цель длительность запроса - 300 мс. Допустимая длительность запроса - 1,2 с. В следующее выражение дает оценку Apdex для каждого задания за последний 5 минут:

  (
  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (задание)
+
  сумма (ставка (http_request_duration_seconds_bucket {le = "1.2 "} [5m])) от (работа)
) / 2 / sum (rate (http_request_duration_seconds_count [5m])) по (job)
  

Обратите внимание, что мы делим сумму обоих сегментов. Причина в том, что гистограмма ведра кумулятивная. В le = "0.3" сегмент также содержится в сегменте le = "1.2" ; разделив его на 2 исправляет для этого.

Расчет не совсем соответствует традиционной оценке Apdex, так как включает ошибки в удовлетворительной и допустимой частях расчета.

квантилей

Вы можете использовать как сводки, так и гистограммы для вычисления так называемых φ-квантилей, где 0 ≤ φ ≤ 1.Φ-квантиль - это значение наблюдения, которое находится под номером φ * N среди N наблюдений. Примеры φ-квантилей: 0,5-квантиль известная как медиана. Квантиль 0,95 - это 95-й процентиль.

Существенное различие между сводками и гистограммами состоит в том, что сводки вычислять потоковые φ-квантили на стороне клиента и выставлять их напрямую, в то время как гистограммы показывают подсчеты наблюдений с интервалами и расчет квантили из сегментов гистограммы происходит на стороне сервера с использованием histogram_quantile () функция.

Эти два подхода имеют ряд различных последствий:

Гистограмма Сводка
Требуемая конфигурация Подбирайте ковши, соответствующие ожидаемому диапазону наблюдаемых значений. Выберите желаемые φ-квантили и скользящее окно. Другие φ-квантили и скользящие окна не могут быть рассчитаны позже.
Производительность клиента Наблюдения очень дешевы, так как им нужно только увеличивать счетчики. Наблюдения дороги из-за вычисления квантиля потоковой передачи.
Производительность сервера Сервер должен вычислить квантили. Вы можете использовать правила записи, если специальный расчет занимает слишком много времени (например, на большой панели инструментов). Низкая стоимость на стороне сервера.
Количество временных рядов (помимо серий _sum и _count ) Один временной ряд на сконфигурированный сегмент. Один временной ряд на сконфигурированный квантиль.
Квантильная ошибка (подробности см. Ниже) Ошибка ограничена размером наблюдаемых значений шириной соответствующей корзины. Ошибка ограничена размером φ настраиваемым значением.
Спецификация φ-квантиля и скользящего временного окна Ad-hoc с выражениями Прометея. Предварительно настроен клиентом.
Агрегация Ad-hoc с выражениями Прометея. В целом не агрегатируется.

Обратите внимание на важность последнего элемента в таблице. Вернемся к SLO обслуживает 95% запросов в течение 300 мс. На этот раз ты не хотите отобразить процент запросов, обслуженных в течение 300 мс, но вместо этого 95-й процентиль, то есть продолжительность запроса, в течение которой вы обслужили 95% запросов. Для этого вы можете настроить сводка с квантилем 0,95 и (например) 5-минутным спадом времени, или вы настраиваете гистограмму с несколькими сегментами около 300 мс марка, e.грамм. {le = "0.1"} , {le = "0.2"} , {le = "0.3"} и {le = "0.45"} . Если ваша служба реплицируется с несколькими экземпляров, вы будете собирать длительность запросов от каждого из их, а затем вы хотите объединить все в общую 95-ю процентиль. Однако агрегирование предварительно вычисленных квантилей из резюме редко имеет смысл. В данном конкретном случае усреднение квантили дает статистически бессмысленные значения.

  в среднем (http_request_duration_seconds {quantile = "0.95 "}) // ПЛОХО!
  

Используя гистограммы, агрегирование вполне возможно с histogram_quantile () функция.

  histogram_quantile (0.95, sum (rate (http_request_duration_seconds_bucket [5m])) by (le)) // ХОРОШО.
  

Кроме того, если ваш SLO изменится, и теперь вы захотите построить 90-е процентиль, или вы хотите учесть последние 10 минут вместо последних 5 минут вам нужно только скорректировать выражение выше, и вам не нужно перенастраивать клиентов.

Ошибки квантильной оценки

квантилей, независимо от того, вычисляются ли они на стороне клиента или на стороне сервера. по оценкам. Важно понимать ошибки этого оценка.

Продолжая пример гистограммы сверху, представьте свой обычный длительность запросов почти все очень близка к 220 мс, или в других словами, если бы вы могли построить "истинную" гистограмму, вы бы увидели очень резкий всплеск на 220 мс. В метрике гистограммы Прометея, как настроено выше, почти все наблюдения и, следовательно, 95-й процентиль, попадет в корзину с надписью {le = "0.3 "} , т. Е. Ковш от От 200 мс до 300 мс. Реализация гистограммы гарантирует, что истинное 95-й процентиль находится где-то между 200 мс и 300 мс. Чтобы вернуть одно значение (а не интервал), применяется линейный интерполяция, которая в данном случае дает 295 мс. Расчетный квантиль создает впечатление, что вы близки к нарушению SLO, но на самом деле 95-й процентиль чуть выше 220 мс, достаточно комфортное расстояние до вашего SLO.

Следующий шаг в нашем мысленном эксперименте: изменение внутренней маршрутизации добавляет фиксированное количество 100 мс ко всем длительностям запроса.Теперь просьба длительность имеет резкий всплеск на уровне 320 мс, и почти все наблюдения будут попадают в ведро от 300 мс до 450 мс. 95-й процентиль рассчитано равным 442,5 мс, хотя правильное значение близко к 320 мс. Хотя вы лишь немного выходите за рамки своего SLO, Расчетный 95-й квантиль выглядит намного хуже.

В сводке не возникло бы проблем с вычислением правильного процентиля. значение в обоих случаях, по крайней мере, если он использует соответствующий алгоритм на клиентская сторона (например, та, что используется Go клиент).К несчастью, вы не можете использовать сводку, если вам нужно агрегировать наблюдения из ряда экземпляров.

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

Давайте теперь еще раз модифицируем эксперимент. В новой настройке Распределение продолжительности запросов имеет всплеск в 150 мс, но это не так. такой же резкий, как и раньше, и составляет только 90% наблюдения. 10% наблюдений равномерно распределены в длинных хвост между 150 мс и 450 мс. При таком распределении 95-й процентиль оказывается точно на нашем SLO в 300 мс. С гистограмме рассчитанное значение является точным, так как значение 95-го процентиль совпадает с одной из границ сегмента.Четный немного другие значения все равно будут точными, поскольку (надуманные) равномерное распределение в соответствующих сегментах - это именно то, что предполагает линейную интерполяцию внутри ведра.

Ошибка квантиля, сообщаемая сводкой, становится более интересной. сейчас. Ошибка квантиля в сводке настраивается в размер φ. В нашем случае мы могли бы настроить 0,95 ± 0,01, то есть рассчитанное значение будет между 94-м и 96-м. процентиль. 94-й квантиль с описанным выше распределением равен 270 мс, 96-й квантиль - 330 мс.Расчетное значение 95-го процентиль, сообщаемый сводкой, может быть в любом месте интервала между 270 мс и 330 мс, и это, к сожалению, вся разница между явно в пределах SLO и явно вне SLO.

Итог: если вы используете сводку, вы контролируете ошибку в размер φ. Если вы используете гистограмму, вы контролируете ошибку в размер наблюдаемого значения (путем выбора соответствующего ведра макет). При широком распределении небольшие изменения φ приводят к большие отклонения от наблюдаемого значения.При резком распределении малый интервал наблюдаемых значений покрывает большой интервал φ.

Два практических правила:

  1. Если вам нужно агрегировать, выберите гистограммы.

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

Что делать, если моя клиентская библиотека не поддерживает нужный мне тип метрики?

Реализуйте это! Добавления кода приветствуются.В общем, мы ожидайте, что гистограммы будут нужны более срочно, чем сводки. Гистограммы также проще реализовать в клиентской библиотеке, поэтому мы рекомендуем реализовать сначала гистограммы, если есть сомнения.

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

гистограмм и сводок | Прометей

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

Поддержка библиотеки

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

Некоторые библиотеки поддерживают только один из двух типов или поддерживают сводки. только ограниченно (без расчета квантилей).

Подсчет и сумма наблюдений

Гистограммы и сводки обоих выборочных наблюдений, обычно запрашиваются продолжительность или размер ответа.Они отслеживают количество наблюдений и сумма наблюдаемых значений, позволяющая вычислить среднее значение наблюдаемых значений. Обратите внимание, что количество наблюдений (отображается в Prometheus как временной ряд с суффиксом _count ) по своей сути счетчик (как описано выше, он только растет). Сумма наблюдения (отображаются как временной ряд с суффиксом _sum ) тоже ведет себя как счетчик, пока нет отрицательных наблюдения.Очевидно, что продолжительность запроса или размер ответа никогда не отрицательный. В принципе, однако, вы можете использовать сводки и гистограммы для наблюдения отрицательных значений (например, температуры в по Цельсию). В этом случае сумма наблюдений может уменьшиться, поэтому вы не может больше применять к нему rate () . В тех редких случаях, когда нужно применить rate () и не избежать отрицательных наблюдений, вы можете использовать два отдельные резюме, одно для положительных и одно для отрицательных наблюдений (последний с перевернутым знаком), а затем объедините результаты с подходящими Выражения PromQL.

Для расчета средней длительности запроса за последние 5 минут из гистограммы или сводки под названием http_request_duration_seconds , используйте следующее выражение:

  скорость (http_request_duration_seconds_sum [5m])
/
  скорость (http_request_duration_seconds_count [5m])
  

оценка Apdex

Прямое использование гистограмм (но не сводок) заключается в подсчете наблюдения, попадающие в определенные периоды наблюдения значения.

У вас может быть SLO для обслуживания 95% запросов в течение 300 мс.В этом случае, настройте гистограмму, чтобы иметь сегмент с верхним пределом 0,3 секунды. Затем вы можете напрямую выразить относительное количество запросы обслуживаются в течение 300 мс и легко предупреждают, если значение упадет ниже 0,95. Следующее выражение вычисляет его по заданию для запросов служил за последние 5 минут. Продолжительность запросов была собрана с гистограмма называется http_request_duration_seconds .

  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (заданию)
/
  сумма (ставка (http_request_duration_seconds_count [5m])) по (задание)
  

Вы можете приблизиться к известному Apdex забейте аналогичным образом.Настроить ведро с целевой продолжительностью запроса в качестве верхней границы и другое ведро с допустимой продолжительностью запроса (обычно 4 раза длительность целевого запроса) в качестве верхней границы. Пример: цель длительность запроса - 300 мс. Допустимая длительность запроса - 1,2 с. В следующее выражение дает оценку Apdex для каждого задания за последний 5 минут:

  (
  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (задание)
+
  сумма (ставка (http_request_duration_seconds_bucket {le = "1.2 "} [5m])) от (работа)
) / 2 / sum (rate (http_request_duration_seconds_count [5m])) по (job)
  

Обратите внимание, что мы делим сумму обоих сегментов. Причина в том, что гистограмма ведра кумулятивная. В le = "0.3" сегмент также содержится в сегменте le = "1.2" ; разделив его на 2 исправляет для этого.

Расчет не совсем соответствует традиционной оценке Apdex, так как включает ошибки в удовлетворительной и допустимой частях расчета.

квантилей

Вы можете использовать как сводки, так и гистограммы для вычисления так называемых φ-квантилей, где 0 ≤ φ ≤ 1.Φ-квантиль - это значение наблюдения, которое находится под номером φ * N среди N наблюдений. Примеры φ-квантилей: 0,5-квантиль известная как медиана. Квантиль 0,95 - это 95-й процентиль.

Существенное различие между сводками и гистограммами состоит в том, что сводки вычислять потоковые φ-квантили на стороне клиента и выставлять их напрямую, в то время как гистограммы показывают подсчеты наблюдений с интервалами и расчет квантили из сегментов гистограммы происходит на стороне сервера с использованием histogram_quantile () функция.

Эти два подхода имеют ряд различных последствий:

Гистограмма Сводка
Требуемая конфигурация Подбирайте ковши, соответствующие ожидаемому диапазону наблюдаемых значений. Выберите желаемые φ-квантили и скользящее окно. Другие φ-квантили и скользящие окна не могут быть рассчитаны позже.
Производительность клиента Наблюдения очень дешевы, так как им нужно только увеличивать счетчики. Наблюдения дороги из-за вычисления квантиля потоковой передачи.
Производительность сервера Сервер должен вычислить квантили. Вы можете использовать правила записи, если специальный расчет занимает слишком много времени (например, на большой панели инструментов). Низкая стоимость на стороне сервера.
Количество временных рядов (помимо серий _sum и _count ) Один временной ряд на сконфигурированный сегмент. Один временной ряд на сконфигурированный квантиль.
Квантильная ошибка (подробности см. Ниже) Ошибка ограничена размером наблюдаемых значений шириной соответствующей корзины. Ошибка ограничена размером φ настраиваемым значением.
Спецификация φ-квантиля и скользящего временного окна Ad-hoc с выражениями Прометея. Предварительно настроен клиентом.
Агрегация Ad-hoc с выражениями Прометея. В целом не агрегатируется.

Обратите внимание на важность последнего элемента в таблице. Вернемся к SLO обслуживает 95% запросов в течение 300 мс. На этот раз ты не хотите отобразить процент запросов, обслуженных в течение 300 мс, но вместо этого 95-й процентиль, то есть продолжительность запроса, в течение которой вы обслужили 95% запросов. Для этого вы можете настроить сводка с квантилем 0,95 и (например) 5-минутным спадом времени, или вы настраиваете гистограмму с несколькими сегментами около 300 мс марка, e.грамм. {le = "0.1"} , {le = "0.2"} , {le = "0.3"} и {le = "0.45"} . Если ваша служба реплицируется с несколькими экземпляров, вы будете собирать длительность запросов от каждого из их, а затем вы хотите объединить все в общую 95-ю процентиль. Однако агрегирование предварительно вычисленных квантилей из резюме редко имеет смысл. В данном конкретном случае усреднение квантили дает статистически бессмысленные значения.

  в среднем (http_request_duration_seconds {quantile = "0.95 "}) // ПЛОХО!
  

Используя гистограммы, агрегирование вполне возможно с histogram_quantile () функция.

  histogram_quantile (0.95, sum (rate (http_request_duration_seconds_bucket [5m])) by (le)) // ХОРОШО.
  

Кроме того, если ваш SLO изменится, и теперь вы захотите построить 90-е процентиль, или вы хотите учесть последние 10 минут вместо последних 5 минут вам нужно только скорректировать выражение выше, и вам не нужно перенастраивать клиентов.

Ошибки квантильной оценки

квантилей, независимо от того, вычисляются ли они на стороне клиента или на стороне сервера. по оценкам. Важно понимать ошибки этого оценка.

Продолжая пример гистограммы сверху, представьте свой обычный длительность запросов почти все очень близка к 220 мс, или в других словами, если бы вы могли построить "истинную" гистограмму, вы бы увидели очень резкий всплеск на 220 мс. В метрике гистограммы Прометея, как настроено выше, почти все наблюдения и, следовательно, 95-й процентиль, попадет в корзину с надписью {le = "0.3 "} , т. Е. Ковш от От 200 мс до 300 мс. Реализация гистограммы гарантирует, что истинное 95-й процентиль находится где-то между 200 мс и 300 мс. Чтобы вернуть одно значение (а не интервал), применяется линейный интерполяция, которая в данном случае дает 295 мс. Расчетный квантиль создает впечатление, что вы близки к нарушению SLO, но на самом деле 95-й процентиль чуть выше 220 мс, достаточно комфортное расстояние до вашего SLO.

Следующий шаг в нашем мысленном эксперименте: изменение внутренней маршрутизации добавляет фиксированное количество 100 мс ко всем длительностям запроса.Теперь просьба длительность имеет резкий всплеск на уровне 320 мс, и почти все наблюдения будут попадают в ведро от 300 мс до 450 мс. 95-й процентиль рассчитано равным 442,5 мс, хотя правильное значение близко к 320 мс. Хотя вы лишь немного выходите за рамки своего SLO, Расчетный 95-й квантиль выглядит намного хуже.

В сводке не возникло бы проблем с вычислением правильного процентиля. значение в обоих случаях, по крайней мере, если он использует соответствующий алгоритм на клиентская сторона (например, та, что используется Go клиент).К несчастью, вы не можете использовать сводку, если вам нужно агрегировать наблюдения из ряда экземпляров.

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

Давайте теперь еще раз модифицируем эксперимент. В новой настройке Распределение продолжительности запросов имеет всплеск в 150 мс, но это не так. такой же резкий, как и раньше, и составляет только 90% наблюдения. 10% наблюдений равномерно распределены в длинных хвост между 150 мс и 450 мс. При таком распределении 95-й процентиль оказывается точно на нашем SLO в 300 мс. С гистограмме рассчитанное значение является точным, так как значение 95-го процентиль совпадает с одной из границ сегмента.Четный немного другие значения все равно будут точными, поскольку (надуманные) равномерное распределение в соответствующих сегментах - это именно то, что предполагает линейную интерполяцию внутри ведра.

Ошибка квантиля, сообщаемая сводкой, становится более интересной. сейчас. Ошибка квантиля в сводке настраивается в размер φ. В нашем случае мы могли бы настроить 0,95 ± 0,01, то есть рассчитанное значение будет между 94-м и 96-м. процентиль. 94-й квантиль с описанным выше распределением равен 270 мс, 96-й квантиль - 330 мс.Расчетное значение 95-го процентиль, сообщаемый сводкой, может быть в любом месте интервала между 270 мс и 330 мс, и это, к сожалению, вся разница между явно в пределах SLO и явно вне SLO.

Итог: если вы используете сводку, вы контролируете ошибку в размер φ. Если вы используете гистограмму, вы контролируете ошибку в размер наблюдаемого значения (путем выбора соответствующего ведра макет). При широком распределении небольшие изменения φ приводят к большие отклонения от наблюдаемого значения.При резком распределении малый интервал наблюдаемых значений покрывает большой интервал φ.

Два практических правила:

  1. Если вам нужно агрегировать, выберите гистограммы.

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

Что делать, если моя клиентская библиотека не поддерживает нужный мне тип метрики?

Реализуйте это! Добавления кода приветствуются.В общем, мы ожидайте, что гистограммы будут нужны более срочно, чем сводки. Гистограммы также проще реализовать в клиентской библиотеке, поэтому мы рекомендуем реализовать сначала гистограммы, если есть сомнения.

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

гистограмм и сводок | Прометей

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

Поддержка библиотеки

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

Некоторые библиотеки поддерживают только один из двух типов или поддерживают сводки. только ограниченно (без расчета квантилей).

Подсчет и сумма наблюдений

Гистограммы и сводки обоих выборочных наблюдений, обычно запрашиваются продолжительность или размер ответа.Они отслеживают количество наблюдений и сумма наблюдаемых значений, позволяющая вычислить среднее значение наблюдаемых значений. Обратите внимание, что количество наблюдений (отображается в Prometheus как временной ряд с суффиксом _count ) по своей сути счетчик (как описано выше, он только растет). Сумма наблюдения (отображаются как временной ряд с суффиксом _sum ) тоже ведет себя как счетчик, пока нет отрицательных наблюдения.Очевидно, что продолжительность запроса или размер ответа никогда не отрицательный. В принципе, однако, вы можете использовать сводки и гистограммы для наблюдения отрицательных значений (например, температуры в по Цельсию). В этом случае сумма наблюдений может уменьшиться, поэтому вы не может больше применять к нему rate () . В тех редких случаях, когда нужно применить rate () и не избежать отрицательных наблюдений, вы можете использовать два отдельные резюме, одно для положительных и одно для отрицательных наблюдений (последний с перевернутым знаком), а затем объедините результаты с подходящими Выражения PromQL.

Для расчета средней длительности запроса за последние 5 минут из гистограммы или сводки под названием http_request_duration_seconds , используйте следующее выражение:

  скорость (http_request_duration_seconds_sum [5m])
/
  скорость (http_request_duration_seconds_count [5m])
  

оценка Apdex

Прямое использование гистограмм (но не сводок) заключается в подсчете наблюдения, попадающие в определенные периоды наблюдения значения.

У вас может быть SLO для обслуживания 95% запросов в течение 300 мс.В этом случае, настройте гистограмму, чтобы иметь сегмент с верхним пределом 0,3 секунды. Затем вы можете напрямую выразить относительное количество запросы обслуживаются в течение 300 мс и легко предупреждают, если значение упадет ниже 0,95. Следующее выражение вычисляет его по заданию для запросов служил за последние 5 минут. Продолжительность запросов была собрана с гистограмма называется http_request_duration_seconds .

  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (заданию)
/
  сумма (ставка (http_request_duration_seconds_count [5m])) по (задание)
  

Вы можете приблизиться к известному Apdex забейте аналогичным образом.Настроить ведро с целевой продолжительностью запроса в качестве верхней границы и другое ведро с допустимой продолжительностью запроса (обычно 4 раза длительность целевого запроса) в качестве верхней границы. Пример: цель длительность запроса - 300 мс. Допустимая длительность запроса - 1,2 с. В следующее выражение дает оценку Apdex для каждого задания за последний 5 минут:

  (
  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (задание)
+
  сумма (ставка (http_request_duration_seconds_bucket {le = "1.2 "} [5m])) от (работа)
) / 2 / sum (rate (http_request_duration_seconds_count [5m])) по (job)
  

Обратите внимание, что мы делим сумму обоих сегментов. Причина в том, что гистограмма ведра кумулятивная. В le = "0.3" сегмент также содержится в сегменте le = "1.2" ; разделив его на 2 исправляет для этого.

Расчет не совсем соответствует традиционной оценке Apdex, так как включает ошибки в удовлетворительной и допустимой частях расчета.

квантилей

Вы можете использовать как сводки, так и гистограммы для вычисления так называемых φ-квантилей, где 0 ≤ φ ≤ 1.Φ-квантиль - это значение наблюдения, которое находится под номером φ * N среди N наблюдений. Примеры φ-квантилей: 0,5-квантиль известная как медиана. Квантиль 0,95 - это 95-й процентиль.

Существенное различие между сводками и гистограммами состоит в том, что сводки вычислять потоковые φ-квантили на стороне клиента и выставлять их напрямую, в то время как гистограммы показывают подсчеты наблюдений с интервалами и расчет квантили из сегментов гистограммы происходит на стороне сервера с использованием histogram_quantile () функция.

Эти два подхода имеют ряд различных последствий:

Гистограмма Сводка
Требуемая конфигурация Подбирайте ковши, соответствующие ожидаемому диапазону наблюдаемых значений. Выберите желаемые φ-квантили и скользящее окно. Другие φ-квантили и скользящие окна не могут быть рассчитаны позже.
Производительность клиента Наблюдения очень дешевы, так как им нужно только увеличивать счетчики. Наблюдения дороги из-за вычисления квантиля потоковой передачи.
Производительность сервера Сервер должен вычислить квантили. Вы можете использовать правила записи, если специальный расчет занимает слишком много времени (например, на большой панели инструментов). Низкая стоимость на стороне сервера.
Количество временных рядов (помимо серий _sum и _count ) Один временной ряд на сконфигурированный сегмент. Один временной ряд на сконфигурированный квантиль.
Квантильная ошибка (подробности см. Ниже) Ошибка ограничена размером наблюдаемых значений шириной соответствующей корзины. Ошибка ограничена размером φ настраиваемым значением.
Спецификация φ-квантиля и скользящего временного окна Ad-hoc с выражениями Прометея. Предварительно настроен клиентом.
Агрегация Ad-hoc с выражениями Прометея. В целом не агрегатируется.

Обратите внимание на важность последнего элемента в таблице. Вернемся к SLO обслуживает 95% запросов в течение 300 мс. На этот раз ты не хотите отобразить процент запросов, обслуженных в течение 300 мс, но вместо этого 95-й процентиль, то есть продолжительность запроса, в течение которой вы обслужили 95% запросов. Для этого вы можете настроить сводка с квантилем 0,95 и (например) 5-минутным спадом времени, или вы настраиваете гистограмму с несколькими сегментами около 300 мс марка, e.грамм. {le = "0.1"} , {le = "0.2"} , {le = "0.3"} и {le = "0.45"} . Если ваша служба реплицируется с несколькими экземпляров, вы будете собирать длительность запросов от каждого из их, а затем вы хотите объединить все в общую 95-ю процентиль. Однако агрегирование предварительно вычисленных квантилей из резюме редко имеет смысл. В данном конкретном случае усреднение квантили дает статистически бессмысленные значения.

  в среднем (http_request_duration_seconds {quantile = "0.95 "}) // ПЛОХО!
  

Используя гистограммы, агрегирование вполне возможно с histogram_quantile () функция.

  histogram_quantile (0.95, sum (rate (http_request_duration_seconds_bucket [5m])) by (le)) // ХОРОШО.
  

Кроме того, если ваш SLO изменится, и теперь вы захотите построить 90-е процентиль, или вы хотите учесть последние 10 минут вместо последних 5 минут вам нужно только скорректировать выражение выше, и вам не нужно перенастраивать клиентов.

Ошибки квантильной оценки

квантилей, независимо от того, вычисляются ли они на стороне клиента или на стороне сервера. по оценкам. Важно понимать ошибки этого оценка.

Продолжая пример гистограммы сверху, представьте свой обычный длительность запросов почти все очень близка к 220 мс, или в других словами, если бы вы могли построить "истинную" гистограмму, вы бы увидели очень резкий всплеск на 220 мс. В метрике гистограммы Прометея, как настроено выше, почти все наблюдения и, следовательно, 95-й процентиль, попадет в корзину с надписью {le = "0.3 "} , т. Е. Ковш от От 200 мс до 300 мс. Реализация гистограммы гарантирует, что истинное 95-й процентиль находится где-то между 200 мс и 300 мс. Чтобы вернуть одно значение (а не интервал), применяется линейный интерполяция, которая в данном случае дает 295 мс. Расчетный квантиль создает впечатление, что вы близки к нарушению SLO, но на самом деле 95-й процентиль чуть выше 220 мс, достаточно комфортное расстояние до вашего SLO.

Следующий шаг в нашем мысленном эксперименте: изменение внутренней маршрутизации добавляет фиксированное количество 100 мс ко всем длительностям запроса.Теперь просьба длительность имеет резкий всплеск на уровне 320 мс, и почти все наблюдения будут попадают в ведро от 300 мс до 450 мс. 95-й процентиль рассчитано равным 442,5 мс, хотя правильное значение близко к 320 мс. Хотя вы лишь немного выходите за рамки своего SLO, Расчетный 95-й квантиль выглядит намного хуже.

В сводке не возникло бы проблем с вычислением правильного процентиля. значение в обоих случаях, по крайней мере, если он использует соответствующий алгоритм на клиентская сторона (например, та, что используется Go клиент).К несчастью, вы не можете использовать сводку, если вам нужно агрегировать наблюдения из ряда экземпляров.

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

Давайте теперь еще раз модифицируем эксперимент. В новой настройке Распределение продолжительности запросов имеет всплеск в 150 мс, но это не так. такой же резкий, как и раньше, и составляет только 90% наблюдения. 10% наблюдений равномерно распределены в длинных хвост между 150 мс и 450 мс. При таком распределении 95-й процентиль оказывается точно на нашем SLO в 300 мс. С гистограмме рассчитанное значение является точным, так как значение 95-го процентиль совпадает с одной из границ сегмента.Четный немного другие значения все равно будут точными, поскольку (надуманные) равномерное распределение в соответствующих сегментах - это именно то, что предполагает линейную интерполяцию внутри ведра.

Ошибка квантиля, сообщаемая сводкой, становится более интересной. сейчас. Ошибка квантиля в сводке настраивается в размер φ. В нашем случае мы могли бы настроить 0,95 ± 0,01, то есть рассчитанное значение будет между 94-м и 96-м. процентиль. 94-й квантиль с описанным выше распределением равен 270 мс, 96-й квантиль - 330 мс.Расчетное значение 95-го процентиль, сообщаемый сводкой, может быть в любом месте интервала между 270 мс и 330 мс, и это, к сожалению, вся разница между явно в пределах SLO и явно вне SLO.

Итог: если вы используете сводку, вы контролируете ошибку в размер φ. Если вы используете гистограмму, вы контролируете ошибку в размер наблюдаемого значения (путем выбора соответствующего ведра макет). При широком распределении небольшие изменения φ приводят к большие отклонения от наблюдаемого значения.При резком распределении малый интервал наблюдаемых значений покрывает большой интервал φ.

Два практических правила:

  1. Если вам нужно агрегировать, выберите гистограммы.

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

Что делать, если моя клиентская библиотека не поддерживает нужный мне тип метрики?

Реализуйте это! Добавления кода приветствуются.В общем, мы ожидайте, что гистограммы будут нужны более срочно, чем сводки. Гистограммы также проще реализовать в клиентской библиотеке, поэтому мы рекомендуем реализовать сначала гистограммы, если есть сомнения.

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

гистограмм и сводок | Прометей

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

Поддержка библиотеки

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

Некоторые библиотеки поддерживают только один из двух типов или поддерживают сводки. только ограниченно (без расчета квантилей).

Подсчет и сумма наблюдений

Гистограммы и сводки обоих выборочных наблюдений, обычно запрашиваются продолжительность или размер ответа.Они отслеживают количество наблюдений и сумма наблюдаемых значений, позволяющая вычислить среднее значение наблюдаемых значений. Обратите внимание, что количество наблюдений (отображается в Prometheus как временной ряд с суффиксом _count ) по своей сути счетчик (как описано выше, он только растет). Сумма наблюдения (отображаются как временной ряд с суффиксом _sum ) тоже ведет себя как счетчик, пока нет отрицательных наблюдения.Очевидно, что продолжительность запроса или размер ответа никогда не отрицательный. В принципе, однако, вы можете использовать сводки и гистограммы для наблюдения отрицательных значений (например, температуры в по Цельсию). В этом случае сумма наблюдений может уменьшиться, поэтому вы не может больше применять к нему rate () . В тех редких случаях, когда нужно применить rate () и не избежать отрицательных наблюдений, вы можете использовать два отдельные резюме, одно для положительных и одно для отрицательных наблюдений (последний с перевернутым знаком), а затем объедините результаты с подходящими Выражения PromQL.

Для расчета средней длительности запроса за последние 5 минут из гистограммы или сводки под названием http_request_duration_seconds , используйте следующее выражение:

  скорость (http_request_duration_seconds_sum [5m])
/
  скорость (http_request_duration_seconds_count [5m])
  

оценка Apdex

Прямое использование гистограмм (но не сводок) заключается в подсчете наблюдения, попадающие в определенные периоды наблюдения значения.

У вас может быть SLO для обслуживания 95% запросов в течение 300 мс.В этом случае, настройте гистограмму, чтобы иметь сегмент с верхним пределом 0,3 секунды. Затем вы можете напрямую выразить относительное количество запросы обслуживаются в течение 300 мс и легко предупреждают, если значение упадет ниже 0,95. Следующее выражение вычисляет его по заданию для запросов служил за последние 5 минут. Продолжительность запросов была собрана с гистограмма называется http_request_duration_seconds .

  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (заданию)
/
  сумма (ставка (http_request_duration_seconds_count [5m])) по (задание)
  

Вы можете приблизиться к известному Apdex забейте аналогичным образом.Настроить ведро с целевой продолжительностью запроса в качестве верхней границы и другое ведро с допустимой продолжительностью запроса (обычно 4 раза длительность целевого запроса) в качестве верхней границы. Пример: цель длительность запроса - 300 мс. Допустимая длительность запроса - 1,2 с. В следующее выражение дает оценку Apdex для каждого задания за последний 5 минут:

  (
  сумма (ставка (http_request_duration_seconds_bucket {le = "0.3"} [5m])) по (задание)
+
  сумма (ставка (http_request_duration_seconds_bucket {le = "1.2 "} [5m])) от (работа)
) / 2 / sum (rate (http_request_duration_seconds_count [5m])) по (job)
  

Обратите внимание, что мы делим сумму обоих сегментов. Причина в том, что гистограмма ведра кумулятивная. В le = "0.3" сегмент также содержится в сегменте le = "1.2" ; разделив его на 2 исправляет для этого.

Расчет не совсем соответствует традиционной оценке Apdex, так как включает ошибки в удовлетворительной и допустимой частях расчета.

квантилей

Вы можете использовать как сводки, так и гистограммы для вычисления так называемых φ-квантилей, где 0 ≤ φ ≤ 1.Φ-квантиль - это значение наблюдения, которое находится под номером φ * N среди N наблюдений. Примеры φ-квантилей: 0,5-квантиль известная как медиана. Квантиль 0,95 - это 95-й процентиль.

Существенное различие между сводками и гистограммами состоит в том, что сводки вычислять потоковые φ-квантили на стороне клиента и выставлять их напрямую, в то время как гистограммы показывают подсчеты наблюдений с интервалами и расчет квантили из сегментов гистограммы происходит на стороне сервера с использованием histogram_quantile () функция.

Эти два подхода имеют ряд различных последствий:

Гистограмма Сводка
Требуемая конфигурация Подбирайте ковши, соответствующие ожидаемому диапазону наблюдаемых значений. Выберите желаемые φ-квантили и скользящее окно. Другие φ-квантили и скользящие окна не могут быть рассчитаны позже.
Производительность клиента Наблюдения очень дешевы, так как им нужно только увеличивать счетчики. Наблюдения дороги из-за вычисления квантиля потоковой передачи.
Производительность сервера Сервер должен вычислить квантили. Вы можете использовать правила записи, если специальный расчет занимает слишком много времени (например, на большой панели инструментов). Низкая стоимость на стороне сервера.
Количество временных рядов (помимо серий _sum и _count ) Один временной ряд на сконфигурированный сегмент. Один временной ряд на сконфигурированный квантиль.
Квантильная ошибка (подробности см. Ниже) Ошибка ограничена размером наблюдаемых значений шириной соответствующей корзины. Ошибка ограничена размером φ настраиваемым значением.
Спецификация φ-квантиля и скользящего временного окна Ad-hoc с выражениями Прометея. Предварительно настроен клиентом.
Агрегация Ad-hoc с выражениями Прометея. В целом не агрегатируется.

Обратите внимание на важность последнего элемента в таблице. Вернемся к SLO обслуживает 95% запросов в течение 300 мс. На этот раз ты не хотите отобразить процент запросов, обслуженных в течение 300 мс, но вместо этого 95-й процентиль, то есть продолжительность запроса, в течение которой вы обслужили 95% запросов. Для этого вы можете настроить сводка с квантилем 0,95 и (например) 5-минутным спадом времени, или вы настраиваете гистограмму с несколькими сегментами около 300 мс марка, e.грамм. {le = "0.1"} , {le = "0.2"} , {le = "0.3"} и {le = "0.45"} . Если ваша служба реплицируется с несколькими экземпляров, вы будете собирать длительность запросов от каждого из их, а затем вы хотите объединить все в общую 95-ю процентиль. Однако агрегирование предварительно вычисленных квантилей из резюме редко имеет смысл. В данном конкретном случае усреднение квантили дает статистически бессмысленные значения.

  в среднем (http_request_duration_seconds {quantile = "0.95 "}) // ПЛОХО!
  

Используя гистограммы, агрегирование вполне возможно с histogram_quantile () функция.

  histogram_quantile (0.95, sum (rate (http_request_duration_seconds_bucket [5m])) by (le)) // ХОРОШО.
  

Кроме того, если ваш SLO изменится, и теперь вы захотите построить 90-е процентиль, или вы хотите учесть последние 10 минут вместо последних 5 минут вам нужно только скорректировать выражение выше, и вам не нужно перенастраивать клиентов.

Ошибки квантильной оценки

квантилей, независимо от того, вычисляются ли они на стороне клиента или на стороне сервера. по оценкам. Важно понимать ошибки этого оценка.

Продолжая пример гистограммы сверху, представьте свой обычный длительность запросов почти все очень близка к 220 мс, или в других словами, если бы вы могли построить "истинную" гистограмму, вы бы увидели очень резкий всплеск на 220 мс. В метрике гистограммы Прометея, как настроено выше, почти все наблюдения и, следовательно, 95-й процентиль, попадет в корзину с надписью {le = "0.3 "} , т. Е. Ковш от От 200 мс до 300 мс. Реализация гистограммы гарантирует, что истинное 95-й процентиль находится где-то между 200 мс и 300 мс. Чтобы вернуть одно значение (а не интервал), применяется линейный интерполяция, которая в данном случае дает 295 мс. Расчетный квантиль создает впечатление, что вы близки к нарушению SLO, но на самом деле 95-й процентиль чуть выше 220 мс, достаточно комфортное расстояние до вашего SLO.

Следующий шаг в нашем мысленном эксперименте: изменение внутренней маршрутизации добавляет фиксированное количество 100 мс ко всем длительностям запроса.Теперь просьба длительность имеет резкий всплеск на уровне 320 мс, и почти все наблюдения будут попадают в ведро от 300 мс до 450 мс. 95-й процентиль рассчитано равным 442,5 мс, хотя правильное значение близко к 320 мс. Хотя вы лишь немного выходите за рамки своего SLO, Расчетный 95-й квантиль выглядит намного хуже.

В сводке не возникло бы проблем с вычислением правильного процентиля. значение в обоих случаях, по крайней мере, если он использует соответствующий алгоритм на клиентская сторона (например, та, что используется Go клиент).К несчастью, вы не можете использовать сводку, если вам нужно агрегировать наблюдения из ряда экземпляров.

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

Давайте теперь еще раз модифицируем эксперимент. В новой настройке Распределение продолжительности запросов имеет всплеск в 150 мс, но это не так. такой же резкий, как и раньше, и составляет только 90% наблюдения. 10% наблюдений равномерно распределены в длинных хвост между 150 мс и 450 мс. При таком распределении 95-й процентиль оказывается точно на нашем SLO в 300 мс. С гистограмме рассчитанное значение является точным, так как значение 95-го процентиль совпадает с одной из границ сегмента.Четный немного другие значения все равно будут точными, поскольку (надуманные) равномерное распределение в соответствующих сегментах - это именно то, что предполагает линейную интерполяцию внутри ведра.

Ошибка квантиля, сообщаемая сводкой, становится более интересной. сейчас. Ошибка квантиля в сводке настраивается в размер φ. В нашем случае мы могли бы настроить 0,95 ± 0,01, то есть рассчитанное значение будет между 94-м и 96-м. процентиль. 94-й квантиль с описанным выше распределением равен 270 мс, 96-й квантиль - 330 мс.Расчетное значение 95-го процентиль, сообщаемый сводкой, может быть в любом месте интервала между 270 мс и 330 мс, и это, к сожалению, вся разница между явно в пределах SLO и явно вне SLO.

Итог: если вы используете сводку, вы контролируете ошибку в размер φ. Если вы используете гистограмму, вы контролируете ошибку в размер наблюдаемого значения (путем выбора соответствующего ведра макет). При широком распределении небольшие изменения φ приводят к большие отклонения от наблюдаемого значения.При резком распределении малый интервал наблюдаемых значений покрывает большой интервал φ.

Два практических правила:

  1. Если вам нужно агрегировать, выберите гистограммы.

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

Что делать, если моя клиентская библиотека не поддерживает нужный мне тип метрики?

Реализуйте это! Добавления кода приветствуются.В общем, мы ожидайте, что гистограммы будут нужны более срочно, чем сводки. Гистограммы также проще реализовать в клиентской библиотеке, поэтому мы рекомендуем реализовать сначала гистограммы, если есть сомнения.

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

Основы запросов | Прометей

Prometheus предоставляет функциональный язык запросов под названием PromQL (Prometheus Query Language), который позволяет пользователю выбирать и агрегировать данные временных рядов в реальном время.Результат выражения может быть отображен в виде графика в виде табличные данные в браузере выражений Prometheus или потребляются внешними систем через HTTP API.

Примеры

Этот документ является справочным. Для обучения может быть проще Начнем с пары примеров.

Типы данных языка выражений

В языке выражений Прометея выражение или подвыражение может оцените один из четырех типов:

  • Мгновенный вектор - набор временных рядов, содержащих одну выборку для каждого временного ряда, у всех одна и та же временная метка
  • Вектор диапазона - набор временных рядов, содержащих диапазон точек данных во времени для каждого временного ряда
  • Scalar - простое числовое значение с плавающей запятой
  • String - простое строковое значение; в настоящее время не используется

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

Литералы

Строковые литералы

Строки могут быть указаны как литералы в одинарных кавычках, двойных кавычках или обратные кавычки.

PromQL следует тем же правилам экранирования, что и Идти. В одинарных или двойных кавычках обратная косая черта начинает escape-последовательность, за которой могут следовать a , b , f , n , r , t , v или \ .Конкретные символы могут быть указаны с помощью восьмеричного ( \ nnn ) или шестнадцатеричный ( \ xnn , \ unnnn и \ Unnnnnnnn ).

Внутри обратных кавычек экранирование не выполняется. В отличие от Go, Prometheus не удаляет символы новой строки внутри обратных кавычек.

Пример:

  "это строка"
'это неэкранированные: \ n \\ \ t'
`это не безэкранированные: \ n '" \ t`
  

литералы с плавающей запятой

Скалярные значения с плавающей запятой могут быть записаны как буквальные целые числа или числа с плавающей запятой в формате (пробелы включены только для лучшей читаемости):

  [- +]? (
      [0-9] * \.? [0-9] + ([eE] [- +]? [0-9] +)?
    | 0 [xX] [0-9a-fA-F] +
    | [nN] [aA] [nN]
    | [iI] [nN] [fF]
)
  

Примеры:

  23
-2,43
3,4e-9
0x8f
-Inf
NaN
  

Селекторы временных рядов

Мгновенные селекторы векторов

Селекторы мгновенного вектора позволяют выбирать набор временных рядов и одно значение выборки для каждого в заданную метку времени (момент): в простейшем форме указывается только название метрики. Это приводит к мгновенному вектору содержащие элементы для всех временных рядов с этим названием метрики.

В этом примере выбираются все временные ряды с метрикой http_requests_total название:

  http_requests_total
  

Можно дополнительно отфильтровать эти временные ряды, добавив список меток, разделенных запятыми. сопоставители в фигурных скобках ( {} ).

В этом примере выбираются только те временные ряды с http_requests_total имя метрики, у которого также есть метка job , установленная на prometheus и их группа этикетка установлена ​​на канарейка :

  http_requests_total {job = "prometheus", group = "canary"}
  

Также возможно отрицательное совпадение значения метки или совпадение значений метки против регулярных выражений.Существуют следующие операторы сопоставления меток:

  • = : выберите метки, которые точно соответствуют указанной строке.
  • ! = : выберите метки, не совпадающие с указанной строкой.
  • = ~ : выберите метки, регулярное выражение которых соответствует указанной строке.
  • ! ~ : выберите метки, регулярное выражение которых не соответствует указанной строке.

Например, это выбирает все http_requests_total временных рядов для промежуточного уровня , тестирует и разрабатывает среды и методы HTTP, отличные от GET .

  http_requests_total {environment = ~ "staging | testing | development", method! = "GET"}
  

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

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

  {job = ~ ".*"} # Плохо!
  

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

  {job = ~ ". +"} # Хорошо!
{job = ~ ". *", method = "get"} # Хорошо!
  

Средства сопоставления меток также могут применяться к названиям показателей путем сопоставления с внутренними __name__ этикетка. Например, выражение http_requests_total эквивалентно {__name __ = "http_requests_total"} . Также могут использоваться сопоставители, отличные от = (! = , = ~ , ! ~ ).Следующее выражение выбирает все показатели, имена которых начинаются с job: :

  {__name __ = ~ "job:. *"}
  

Имя метрики не должно быть одним из ключевых слов bool , на , игнорируя , group_left и group_right . Следующее выражение недопустимо:

  на {} # Bad!
  

Чтобы обойти это ограничение, используйте метку __name__ :

  {__name __ = "on"} # Хорошо!
  

Все регулярные выражения в Prometheus используют RE2 синтаксис.

Селекторы вектора диапазона

Векторные литералы диапазона работают как мгновенные векторные литералы, за исключением того, что они выберите диапазон выборок с текущего момента. Синтаксически время продолжительность добавляется в квадратные скобки ( [] ) в конце векторный селектор, чтобы указать, как далеко назад во времени должны быть извлечены значения для каждый результирующий элемент вектора диапазона.

В этом примере мы выбираем все значения, которые мы записали за последние 5 минут для всех временных рядов с именем метрики http_requests_total и job label set to prometheus :

  http_requests_total {job = "prometheus"} [5 мин.]
  

Продолжительность времени

Продолжительность времени указывается в виде числа, за которым сразу следует одно из следующие единицы:

  • мс - миллисекунды
  • с - секунды
  • м - минут
  • ч - часы
  • d - дни - при условии, что в сутках всегда 24 часа
  • w - недели - при условии, что в неделе всегда было 7d
  • y - годы - при условии, что год всегда был 365d

Продолжительность времени может быть объединена путем конкатенации.Блоки необходимо заказывать в от самого длинного к самому короткому. Данный отряд должен появляться только один раз за время.

Вот несколько примеров допустимой продолжительности времени:

  5ч
1ч40м
5м
10 с
  

Модификатор смещения

Модификатор смещения позволяет изменять смещение времени для отдельных мгновенные и дальномерные векторы в запросе.

Например, следующее выражение возвращает значение http_requests_total 5 минут назад относительно текущего время оценки запроса:

  http_requests_total смещение 5 м
  

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

  сумма (http_requests_total {method = "GET"} смещение 5 м) // ХОРОШО.
  

Тогда как неверно :

  сумма (http_requests_total {method = "GET"}) смещение 5 м // НЕДЕЙСТВИТЕЛЬНО.
  

То же самое работает с векторами дальности. Это возвращает 5-минутную скорость, которая http_requests_total неделю назад:

  скорость (http_requests_total [5m], смещение 1w)
  

Для сравнения с временными сдвигами вперед во времени используется отрицательное смещение. можно указать:

  скорость (http_requests_total [5m] смещение -1w)
  

Эта функция включается установкой --enable-feature = promql-negative-offset флаг.См. Отключенные функции для получения дополнительных сведений о этот флаг.

@ модификатор

Модификатор @ позволяет изменять время оценки для отдельного момента и ранжировать векторы в запросе. Время, передаваемое модификатору @ - это временная метка unix, описываемая литералом с плавающей запятой.

Например, следующее выражение возвращает значение http_requests_total в 2021-01-04T07: 40: 00 + 00: 00 :

  http_requests_total @ 1609746000
  

Обратите внимание, что модификатор @ всегда должен следовать за селектором. немедленно, т.е.е. следующее будет правильным:

  сумма (http_requests_total {method = "GET"} @ 1609746000) // ХОРОШО.
  

Тогда как неверно :

  сумма (http_requests_total {method = "GET"}) @ 1609746000 // НЕДЕЙСТВИТЕЛЬНО.
  

То же самое работает с векторами дальности. Это возвращает 5-минутную скорость, которая http_requests_total было по адресу 2021-01-04T07: 40: 00 + 00: 00 :

  скорость (http_requests_total [5m] @ 1609746000)
  

Модификатор @ поддерживает все описанные представления литералов с плавающей запятой. выше в пределах int64 .Его также можно использовать вместе с модификатором смещения , где смещение применяется относительно @ время модификатора независимо от того, какой модификатор записан первым. Эти 2 запроса дадут одинаковый результат.

  # смещение после @
http_requests_total @ 1609746000 смещение 5 м
# смещение перед @
http_requests_total смещение 5 м @ 1609746000
  

Этот модификатор по умолчанию отключен, так как он нарушает инвариант PromQL. не опережает время оценки образцов.Его можно включить, установив --enable-feature = promql-at-modifier флаг. См. Отключенные функции для получения дополнительных сведений об этом флаге.

Кроме того, start () и end () также могут использоваться как значения для модификатора @ как специальные значения.

Для запроса диапазона они разрешаются в начало и конец запроса диапазона соответственно и остаются одинаковыми для всех шагов.

Для мгновенного запроса start () и end () оба разрешают время оценки.

  http_requests_total @ start ()
скорость (http_requests_total [5m] @ end ())
  

Подзапрос

Подзапрос

позволяет выполнять мгновенный запрос для заданного диапазона и разрешения. Результатом подзапроса является вектор диапазона.

Синтаксис: '[' ':' [] ']' [@ ] [offset ]

  • <разрешение> не является обязательным. По умолчанию - это глобальный интервал оценки.

Операторы

Prometheus поддерживает множество бинарных операторов и операторов агрегирования. Они описаны подробно на странице операторов языка выражений.

Функции

Prometheus поддерживает несколько функций для работы с данными. Они описаны подробно на странице функций языка выражений.

PromQL поддерживает строковые комментарии, начинающиеся с # . Пример:

  # Это комментарий
  

Попался

Несвежие

При выполнении запросов выбираются временные метки для выборки данных. независимо от фактических данных текущего временного ряда.Это в основном для поддержки случаи, такие как агрегирование ( сумма , среднее и т. д.), когда несколько агрегированных временные ряды не точно совпадают по времени. Благодаря своей независимости, Прометею необходимо присвоить значение в эти временные метки для каждого соответствующего времени. ряд. Он делает это, просто беря самую новую выборку до этой отметки времени.

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

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

Если образец не найден (по умолчанию) за 5 минут до отметки времени выборки, на данный момент для этого временного ряда значение не возвращается. Этот фактически означает, что временные ряды «исчезают» с графиков в те моменты, когда их последний собранный образец старше 5 минут или после того, как он помечен как устаревший.

Устойчивость не будет отмечена для временных рядов, для которых есть временные метки, включенные в их царапины. В этом случае будет применяться только 5-минутный порог.

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

Если запрос должен работать с очень большим объемом данных, его графическое отображение может тайм-аут или перегрузка сервера или браузера. Таким образом, при построении запросов над неизвестными данными, всегда начинайте строить запрос в табличном представлении Браузер выражений Прометея, пока набор результатов не станет разумным (максимум сотни, а не тысячи временных рядов).Только когда вы отфильтровали или достаточно агрегировали ваши данные, переключитесь в режим графика. Если выражение по-прежнему занимает слишком много времени для построения графика ad-hoc, предварительно запишите его с помощью записи правило.

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

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

1. Что такое Прометей? - Прометей: все работает [Книга]

Prometheus - это система мониторинга на основе метрик с открытым исходным кодом. Конечно, Прометей далеко не единственный из них, так что же его примечательный?

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

С самого начала, когда в SoundCloud в 2012 году, сообщество и экосистема выросли вокруг Prometheus. Prometheus в основном написан на Go и имеет лицензию Apache 2.0. лицензия. Сотни людей внесли свой вклад в проект. сам по себе, который не контролируется ни одной компанией.Всегда трудно сказать сколько пользователей у проекта с открытым исходным кодом, но по моим оценкам, по состоянию на 2018 год десятки тысяч организаций используют Prometheus в производственной среде. В В 2016 году проект Prometheus стал вторым участником 1 Cloud Native Computing Foundation (CNCF).

Для инструментария вашего собственного кода есть клиентские библиотеки во всех популярных языки и среды выполнения, включая Go, Java / JVM, C # /. Net, Python, Ruby, Node.js, Haskell, Erlang и Rust. Программное обеспечение вроде Kubernetes и Docker уже оснащенный клиентскими библиотеками Prometheus.Для стороннего программного обеспечения, которое предоставляет метрики в формате, отличном от формата Prometheus, существуют сотни доступны интеграции. Они называются экспортерами и включают HAProxy, MySQL, PostgreSQL, Redis, JMX, SNMP, Consul и Kafka. Мой друг даже добавил поддержка мониторинга серверов Minecraft, так как он очень заботится о своих фреймах в секунду.

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

Модель данных идентифицирует каждый временной ряд не только по имени, но и по неупорядоченный набор пар ключ-значение, называемых метками. Язык запросов PromQL позволяет агрегировать по любой из этих меток, поэтому вы можете анализировать не только по процесса, но также для каждого центра обработки данных и для каждой службы или любых других ярлыков, которые вы определили.Их можно отобразить в виде графиков в таких системах панелей, как Grafana.

Оповещения

могут быть определены с использованием того же языка запросов PromQL, который вы используете. для построения графиков. Если вы можете построить график, вы можете предупредить об этом. Этикетки делают обслуживание оповещения проще, так как вы можете создать единое оповещение, охватывающее все возможные метки значения. В некоторых других системах мониторинга вам придется индивидуально создавать предупреждение для каждой машины / приложения. Соответственно, обнаружение сервисов может автоматически определять, с каких приложений и машин нужно убирать такие источники, как Kubernetes, Consul, Amazon Elastic Compute Cloud (EC2), Azure, Google Compute Engine (GCE) и OpenStack.

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

Теперь, когда у вас есть обзор того, что такое Прометей, давайте отступите на минуту и ​​посмотрите, что подразумевается под «мониторингом», чтобы предоставить некоторый контекст. После этого я рассмотрю, какие основные компоненты Прометей есть, а Прометей нет.

В средней школе один из моих учителей сказал нам, что если вы спросите десять экономисты, что означает экономика, вы получите одиннадцать ответов. Мониторинг имеет аналогичное отсутствие консенсуса относительно того, что именно это означает.Когда я рассказываю другим, что делаю, люди думают, что моя работа влечет за собой все: следить за температурой на фабриках, чтобы сотрудники следили за тем, где я тот, чтобы узнать, кто заходил в Facebook в рабочее время, и даже обнаружение злоумышленников в сети.

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

Так что же в этом контексте означает мониторинг? Мне нравится сужать этот вид оперативный мониторинг компьютерных систем до четырех вещей:

Оповещение

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

Отладка

Теперь, когда вы вызвали человека, ему нужно провести расследование, чтобы определить первопричину и в конечном итоге решить любую проблему.

В тренде

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

Сантехника

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

В зависимости от того, с кем вы разговариваете, и их происхождения, они могут рассматривать только некоторые из них для мониторинга. Это приводит к многочисленным дискуссиям о мониторинге по кругу, оставив всех разочарованными. Чтобы помочь вам понять, где другие исходят из, я собираюсь посмотреть на Немного истории мониторинга.

Краткая и неполная история мониторинга

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

Когда я говорю Nagios, я включаю любое программное обеспечение в одно и то же семейство, например как Icinga, Zmon и Sensu. Они работают в основном за счет регулярного выполнения скриптов. называется чеки. Если проверка завершается неудачно из-за ненулевого кода выхода, выдается предупреждение. сгенерировано.Первоначально Nagios был запущен Итаном Галстадом в 1996 году как MS-DOS. приложение, используемое для выполнения пингов. Впервые он был выпущен как NetSaint в 1999 году, и переименован в Nagios в 2002 году.

Чтобы поговорить об истории Graphite, мне нужно вернуться в 1994 год. Тобиас Компания Oetiker создала сценарий Perl, который стал называться Multi Router Traffic Grapher или MRTG. 1.0, в 1995 году. Как видно из названия, в основном он использовался для мониторинга сети. через простой протокол управления сетью (SNMP). Он также может получать метрики путем выполнения скриптов. 3 1997 год принес большие изменения с переносом некоторого кода на C, и создание базы данных Round Robin (RRD), которая использовалась для хранения метрических данных. Это принесло заметные улучшения производительности, и RRD послужил основой для других инструменты, включая копчение и графит.

Начиная с 2006 года, Graphite использует Whisper для хранения метрик, который имеет похожий дизайн на RRD. Графит сам не собирает данные, а отправляет с помощью таких инструментов сбора, как collectd и Statsd, которые были созданы в 2005 г. и 2010, соответственно.

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

Еще один пережиток той эпохи - относительно ручной подход к администрирование компьютерных услуг. Сервисы были развернуты на отдельных машинах и о них с любовью заботятся системные администраторы.Оповещения, которые потенциально могут указывают на то, что на проблему обратились преданные инженеры. Как облако и облако нативные технологии, такие как EC2, Docker и Kubernetes, получили известность, обращение с отдельными машинами и услугами как с домашними животными, когда каждому уделяется индивидуальное внимание, не масштабируется. Скорее они следует рассматривать скорее как крупный рогатый скот, а управлять и контролировать как группу. В так же, как отрасль перешла от ручного управления к такие инструменты, как Chef и Ansible, чтобы теперь начать использовать такие технологии, как Kubernetes, мониторинг также должен сделать аналогичный переход от проверок на отдельные процессы на отдельных машинах для мониторинга на основе состояния службы в целом.

Вы могли заметить, что я не упомянул ведение журнала. Исторически журналы использовались как нечто, что вы использовали вручную с помощью tail, grep и awk. Возможно, у вас был инструмент анализа, такой как AWStats, для создания отчетов раз в час или день. В большем в последние годы они также использовались в качестве важной части мониторинга, например как и в случае стека Elasticsearch, Logstash и Kibana (ELK).

Теперь, когда мы немного рассмотрели графики и предупреждения, давайте посмотрим, как метрики и бревна вписываются в вещи.Есть ли больше категорий мониторинга, чем эти две?

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

В конце концов, большинство мониторингов - это одно и то же: события. События может быть почти что угодно, в том числе:

  • Получение HTTP-запроса

  • Отправка ответа HTTP 400

  • Вход в функцию

  • Достижение else из if выписка

  • Выход из функции

  • Пользователь входит в систему

  • Запись данных на диск

  • Чтение данных из сети

  • Запрос дополнительной памяти у ядра

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

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

Профилирование

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

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

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

В ядре Linux расширенные фильтры пакетов Berkeley (eBPF) позволяют подробно профилирование событий ядра от операций файловой системы до сетевых странностей.Они обеспечивают доступ к уровню понимания, который обычно не был доступен ранее, и я бы рекомендовал прочитать Работы Брендана Грегга по этому поводу.

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

Розыск

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

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

Распределенная трассировка делает еще один шаг вперед. Это позволяет отслеживать процессы, прикрепляя уникальные идентификаторы к запросам, которые передаются от одного процесса другому в удаленных вызовах процедур (RPC) в дополнение к тому, это тот, который следует проследить. Следы от разных процессов и машины могут быть сшиты вместе на основе идентификатора запроса. Это жизненно важно инструмент для отладки распределенных архитектур микросервисов.Технологии в это пространство включает OpenZipkin и Jaeger.

Для отслеживания это выборка, в которой хранятся объемы данных и инструментарий. влияние на производительность в разумных пределах.

Лесозаготовки

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

Например, для сервера, обрабатывающего тысячу запросов в секунду, запись в журнале со сотней полей, каждое из которых занимает десять байтов, получается мегабайт в секунду. Это нетривиальная доля сетевой карты на 100 Мбит и хранилища объемом 84 ГБ. в сутки только для регистрации.

Большим преимуществом ведения журнала является то, что (обычно) нет выборки событий, поэтому даже несмотря на то, что количество полей ограничено, полезно определить, насколько медленные запросы влияют на одного конкретного пользователя, разговаривающего с одним конкретная конечная точка API.

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

Журналы транзакций

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

Журнал запросов

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

Журналы приложений

Не все логи посвящены запросам; некоторые о самом процессе. Запускать сообщения, фоновые задачи обслуживания и другие строки журнала на уровне процессов. типичный.Эти журналы часто читаются напрямую человеком, поэтому старайтесь избегать имея более нескольких в минуту при нормальной работе.

Журналы отладки

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

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

Примеры систем регистрации включают стек ELK и Graylog.

Метрики

Метрики в основном игнорируют контекст, вместо этого отслеживая агрегирование с течением времени. разные типы мероприятий.Чтобы сохранить разумное использование ресурсов, количество различных отслеживаемых чисел должно быть ограничено: десять тысяч на процесс - это разумная верхняя граница, которую вам следует иметь в виду.

Примеры метрик, которые у вас могут быть: количество раз, когда вы получил HTTP-запросы, сколько времени было потрачено на обработку запросов и сколько запросы в настоящее время обрабатываются. Исключая любую информацию о контексте, объемы данных и требуемая обработка остаются разумными.

Однако нельзя сказать, что этот контекст всегда игнорируется.Для HTTP-запроса вы можете выбрать метрику для каждого пути URL. Но десять тысяч метрических необходимо помнить о руководстве, поскольку каждый отдельный путь теперь считается метрическая. Использование контекста, такого как адрес электронной почты пользователя, было бы неразумным, поскольку они имеют неограниченную мощность. 4

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

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

В качестве системы мониторинга на основе метрик Prometheus предназначен для отслеживания общее состояние системы, поведение и производительность, а не отдельные События. Другими словами, Прометей заботится о том, чтобы было 15 запросов в за последнюю минуту, на обработку которой потребовалось 4 секунды, было создано 40 баз данных звонков, 17 обращений в кеш и 2 покупки покупателями. Стоимость и код пути отдельных вызовов будут проблемой профилирования или регистрации.

Теперь, когда вы понимаете, какое место Прометей занимает в общем мониторинга космоса, давайте посмотрим на различные компоненты Prometheus.

На рис. 1-1 показана общая архитектура Prometheus. Прометей обнаруживает цели, которые нужно очистить от обнаружения сервисов. Это может быть ваш собственный инструментальные приложения или сторонние приложения, которые вы можете очистить через экспортер. Полученные данные сохраняются, и вы можете использовать их в дашборды с использованием PromQL или отправка предупреждений в Alertmanager, который преобразует их в страницы, электронные письма и другие уведомления.

Рисунок 1-1. Архитектура Прометея

Клиентские библиотеки

Метрики обычно не возникают из приложений волшебным образом; у кого-то есть добавить приборы, которые их производят.Здесь клиентские библиотеки войдите. Обычно с двумя или тремя строками кода вы можете определить метрику и добавьте желаемый инструментарий в код, который вы контролируете. Это называется непосредственным приборостроением.

Клиентские библиотеки доступны для всех основных языков и сред выполнения. В Проект Prometheus предоставляет официальные клиентские библиотеки на Go, Python, Java / JVM и Рубин. Также существует множество сторонних клиентских библиотек, например для C # /. Net, Node.js, Haskell, Erlang и Rust.

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

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

Некоторые метрики обычно предоставляются клиентскими библиотеками прямо из коробки, например, загрузка ЦП. и статистика сборки мусора в зависимости от библиотеки и среды выполнения.

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

Экспортеры

Не весь код, который вы запускаете, является кодом, который вы можете контролировать или даже иметь доступ, и, следовательно, добавление инструментов напрямую не вариант. Например, это Маловероятно, что ядра операционной системы в ближайшее время начнут выводить метрики в формате Prometheus через HTTP.

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

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

В отличие от прямого инструментария, который вы использовали бы для кода, который вы контролируете, экспортеры используют другой стиль инструментария, известный как пользовательские сборщики или ConstMetrics . 5

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

Обнаружение услуг

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

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

Prometheus имеет интеграцию со многими распространенными механизмами обнаружения сервисов, такими как Kubernetes, EC2 и Consul. Также существует универсальная интеграция для тех, чей установка находится немного в стороне от проторенного пути (см. «Файл»).

Это все еще оставляет проблему. Просто потому, что у Прометея есть список машин и услуги не означает, что мы знаем, как они вписываются в вашу архитектуру. Например, вы можете использовать тег EC2 Name 6 , чтобы указать, какое приложение выполняется на машине, тогда как другие могут использовать тег под названием app .

Поскольку каждая организация делает это немного по-своему, Prometheus позволяет вам настроить, как метаданные из обнаружения службы сопоставляются с целями мониторинга и их этикетки с использованием , перемаркировки .

Соскоб

Обнаружение и перемаркировка сервисов дают нам список целей, которые нужно контролируется. Теперь Прометею нужно получить метрики. Прометей делает это отправка HTTP-запроса под названием scrape . Ответ на царапину анализируется и принимается. в хранилище. Также добавлено несколько полезных показателей, например, если удалось и сколько времени это заняло. Царапины случаются регулярно; обычно ты бы настройте это так, чтобы оно происходило каждые 10-60 секунд для каждой цели.

Хранилище

Prometheus хранит данные локально в настраиваемой базе данных. Распределенные системы сложно сделать надежными, поэтому Прометей не пытается делать какие-либо формы кластеризации. Помимо надежности, это упрощает запуск Prometheus.

За прошедшие годы хранилище претерпело ряд изменений: система в Prometheus 2.0 является третьей итерацией. Система хранения может обрабатывать миллионы выборок в секунду, что позволяет контролировать тысячи машин с одним сервером Prometheus.Сжатие используемый алгоритм может достигать 1,3 байта на выборку для реальных данных. SSD - это рекомендуется, но не обязательно.

Панели мониторинга

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

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

Рисунок 1-2. Приборная панель Grafana

Правила записи и предупреждения

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

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

Управление оповещениями

Alertmanager получает оповещения от серверов Prometheus и переключает их в уведомления. Уведомления могут включать электронную почту, чат-приложения, такие как Slack и такие сервисы, как PagerDuty.

Alertmanager не просто слепо превращает предупреждения в уведомления на индивидуальной основе. Связанные оповещения могут быть объединены в одно уведомление, которое регулируется. для уменьшения пейджинговых штормов, 7 и различные выходы маршрутизации и уведомлений могут быть настроены для каждого из ваших команды. Предупреждения также можно отключить, возможно, чтобы отложить проблему, о которой вы уже знаете заранее, когда вы знаете, что запланировано техническое обслуживание.

Роль Alertmanager ограничивается отправкой уведомлений; управлять человеком реагирование на инциденты, вам следует использовать такие сервисы, как PagerDuty и Ticketing системы.

Подсказка

Оповещения и их пороги настраиваются в Prometheus, а не в Alertmanager.

Долгосрочное хранение

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

Prometheus не предлагает кластерное решение для хранения данных. на нескольких машинах, но есть API удаленного чтения и записи которые позволяют другим системам подключиться и взять на себя эту роль.Это позволяет PromQL запросы для прозрачного выполнения как для локальных, так и для удаленных данных.

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

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

Prometheus предназначен для оперативного мониторинга, где небольшие неточности и условия гонки из-за таких факторов, как планирование ядра и неудачные попытки очистки факт жизни. Прометей идет на компромисс и предпочитает предоставлять вам данные, которые 99,9% исправили ошибку вашего мониторинга, ожидая точных данных. Таким образом, в приложениях, связанных с деньгами или выставлением счетов, Prometheus следует использовать с осторожностью.

В следующей главе я покажу вам, как запустить Prometheus и выполнить некоторые основные мониторинг.

1 Kubernetes был первым участником.

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

3 У меня остались приятные воспоминания о настройке MRTG в начале 2000-х, написании сценариев для отчетов о температуре и использовании сети на моих домашних компьютерах.

4 Адреса электронной почты также, как правило, представляют собой информацию, позволяющую установить личность (PII), что влечет за собой проблемы с соблюдением требований и конфиденциальности, которых лучше избегать при мониторинге.

5 Термин ConstMetric является разговорным и происходит от функции MustNewConstMetric клиентской библиотеки Go, используемой для создания показателей экспортерами, написанными на Go.

6 Тег EC2 Name - это отображаемое имя экземпляра EC2 в веб-консоли EC2.

7 стр. - это уведомление для инженера по вызову, которое они, как ожидается, провозгласят исследованием или обработкой. Хотя вы можете получить страницу через традиционный радиопейджер, в наши дни она, скорее всего, приходит на ваш мобильный телефон в виде SMS-сообщения, уведомления или телефонного звонка.Пейджер-шторм - это когда вы получаете строку страниц в быстрой последовательности.

8 Однако современные машины могут хранить довольно много данных локально, поэтому отдельная кластерная система хранения может вам не понадобиться.

Как использовать Prometheus для обнаружения аномалий в GitLab | GitLab

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

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

Почему полезно обнаружение аномалий?

Есть четыре основные причины, по которым обнаружение аномалий важно для GitLab:

  1. Диагностика инцидентов : мы можем быстро определить, какие службы работают за пределами своих нормальных границ, и сократить среднее время, необходимое для обнаружения инцидента (MTTD), что приведет к более быстрому разрешению.
  2. Обнаружение регрессии производительности приложения : Например, если введена регрессия n + 1, которая приводит к тому, что одна служба вызывает другую с очень высокой скоростью, мы можем быстро отследить проблему и решить ее.
  3. Выявление и устранение злоупотреблений : GitLab предлагает бесплатные вычисления (GitLab CI / CD) и хостинг (GitLab Pages), и есть небольшая группа пользователей, которые могут воспользоваться этим.
  4. Безопасность : Обнаружение аномалий необходимо для выявления необычных тенденций в данных временных рядов GitLab.

По этим и многим другим причинам Эндрю исследовал возможность обнаружения аномалий в данных временных рядов GitLab, просто используя запросы и правила Prometheus.

Какой уровень агрегирования правильный?

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

  http_requests_total {
 job = "apiserver",
 method = "ПОЛУЧИТЬ",
 controller = "ProjectsController",
 status_code = "200",
 environment = "prod"
}
  

В этом примере метрики есть дополнительные измерения : метод , контроллер , код_статуса , среда , а также измерения, которые добавляет Prometheus, такие как экземпляр и задание .

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

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

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

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

  - запись: job: http_requests: rate5m
выражение: сумма без (экземпляр, метод, контроллер, код_статуса)
(оценка (http_requests_total [5m]))
# -> job: http_requests: rate5m {job = "apiserver", environment = "prod"} 21321
# -> job: http_requests: rate5m {job = "gitserver", environment = "prod"} 2212
# -> job: http_requests: rate5m {job = "webserver", environment = "prod"} 53091
  

Использование z-показателя для обнаружения аномалий

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

Если мы знаем среднее значение и стандартное отклонение (σ) ряда Прометея, мы можем использовать любую выборку в ряду для расчета z-показателя. Z-оценка измеряется в количестве стандартных отклонений от среднего. Таким образом, z-оценка 0 будет означать, что z-оценка идентична среднему значению в наборе данных с нормальным распределением, тогда как z-оценка 1 равна 1,0 σ от среднего и т. Д.

Если исходные данные имеют нормальное распределение, 99,7% выборок должны иметь z-оценку от нуля до трех.Чем дальше z-оценка от нуля, тем меньше вероятность ее существования. Мы применяем это свойство для обнаружения аномалий в серии Prometheus.

  1. Рассчитайте среднее значение и стандартное отклонение для показателя, используя данные с большим размером выборки. В этом примере мы используем данные за одну неделю. Если предположить, что мы оцениваем правило записи раз в минуту, в течение недели у нас будет чуть более 10 000 образцов.
  # Долгосрочное среднее значение серии
- запись: задание: http_requests: rate5m: avg_over_time_1w
выражение: avg_over_time (задание: http_requests: rate5m [1 нед])

# Долгосрочное стандартное отклонение для серии
- запись: задание: http_requests: rate5m: stddev_over_time_1w
выражение: stddev_over_time (задание: http_requests: rate5m [1 нед])
  
  1. Мы можем вычислить z-оценку для запроса Prometheus, если у нас есть среднее значение и стандартное отклонение для агрегирования.
  # Z-Score для агрегирования
(
задание: http_requests: rate5m -
задание: http_requests: rate5m: avg_over_time_1w
) / задание: http_requests: rate5m: stddev_over_time_1w
  

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

GitLab.com Pages обслуживают запросы в секунду в течение 48 часов, область значений z ± 3, выделенная зеленым цветом

Z-score немного неудобно интерпретировать на графике, потому что у них нет единицы измерения. Но аномалии на этом графике легко обнаружить. Все, что появляется за пределами зеленой зоны (которая обозначает z-значения, попадающие в диапазон +3 или -3), является аномалией.

Что делать, если у вас нет нормального распределения?

Но подождите : мы делаем большой скачок, предполагая, что наша базовая агрегация имеет нормальное распределение.Если мы рассчитаем z-оценку с данными, которые не имеют нормального распределения, наши результаты будут неверными.

Существует множество статистических методов для проверки ваших данных на нормальное распределение, но лучший вариант - проверить, что ваши базовые данные имеют z-оценку примерно от +4 до -4 .

  (
 max_over_time (задание: http_requests: rate5m [1w]) - avg_over_time (job: http_requests: rate5m [1w])
) / stddev_over_time (задание: http_requests: rate5m [1 нед])
# -> {job = "apiserver", environment = "prod"} 4.01
# -> {job = "gitserver", environment = "prod"} 3.96.
# -> {job = "webserver", environment = "prod"} 2.96

(
 min_over_time (задание: http_requests: rate5m [1w]) - avg_over_time (job: http_requests: rate5m [1w])
) / stddev_over_time (задание: http_requests: rate5m [1 нед])
# -> {job = "apiserver", environment = "prod"} -3,8
# -> {job = "gitserver", environment = "prod"} -4.1
# -> {job = "webserver", environment = "prod"} -3,2
  

Два запроса Prometheus, проверяющие минимальный и максимальный z-значения.

Если ваши результаты возвращаются с диапазоном от +20 до -20, хвост слишком длинный, и ваши результаты будут искажены.Помните также, что это нужно запускать для агрегированных, а не неагрегированных рядов. Метрики, которые, вероятно, не имеют нормального распределения, включают такие вещи, как частота ошибок, задержки, длина очереди и т. Д., Но многие из этих метрик в любом случае будут лучше работать с фиксированными пороговыми значениями для предупреждений.

Обнаружение аномалий по сезонности

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

запросов Gitaly в секунду (RPS), понедельник-воскресенье, в течение четырех недель подряд

На этом графике показано количество запросов в секунду (запросов в секунду) для Gitaly за семь дней, с понедельника по воскресенье, за четыре недели подряд. Семидневный диапазон называется «смещением», что означает образец, который будет измеряться.

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

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

Как мы используем сезонность?

Для расчета сезонности с помощью Prometheus мы использовали несколько различных статистических принципов.

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

  - запись: job: http_requests: rate5m_prediction
  expr:>
    job: http_requests: rate5m offset 1w # Значение за последний период
    + job: http_requests: rate5m: avg_over_time_1w # Тенденция роста за неделю
    - job: http_requests: rate5m: avg_over_time_1w смещение 1w
  

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

Во второй итерации мы расширяем область действия, беря среднее значение четырехчасового периода за предыдущую неделю и сравнивая его с текущей неделей. Итак, если мы пытаемся спрогнозировать значение показателя в 8:00 утра понедельника, вместо того, чтобы использовать то же пятиминутное окно за неделю до этого, мы используем среднее значение показателя с 6:00 до 10:00 для предыдущего утро.

  - запись: job: http_requests: rate5m_prediction
  expr:>
    avg_over_time (job: http_requests: rate5m [4h] offset 166h) # Округленное значение за последний период
    + job: http_requests: rate5m: avg_over_time_1w # Добавить тенденцию роста на 1 неделю
    - job: http_requests: rate5m: avg_over_time_1w смещение 1w
  

Мы используем 166 часов в запросе вместо одной недели, потому что мы хотим использовать четырехчасовой период, основанный на текущем времени суток, поэтому нам нужно, чтобы смещение было на два часа меньше полной недели.

Gitaly service RPS (желтый) против прогноза (синий), более двух недель.

Сравнение фактического Gitaly RPS (желтый) с нашим прогнозом (синий) показывает, что наши расчеты были довольно точными. Однако у этого метода есть недостаток.

Использование GitLab было ниже, чем в обычную среду, потому что 1 мая был Международный день труда, праздник, отмечаемый во многих странах. Поскольку наши темпы роста зависят от использования на предыдущей неделе, наши прогнозы на следующую неделю, в среду, 8 мая, были для более низкого RPS, чем это было бы, если бы среда, 1 мая, не была выходным днем.

Это можно исправить, сделав три прогноза на три недели подряд до среды, 1 мая; за предыдущую среду, среду перед этим и среду перед этим. Запрос остается прежним, но смещение корректируется.

  - запись: job: http_requests: rate5m_prediction
  expr:>
   квантиль (0,5,
     label_replace (
       avg_over_time (задание: http_requests: rate5m [4h] смещение 166h)
       + job: http_requests: rate5m: avg_over_time_1w - job: http_requests: rate5m: avg_over_time_1w смещение 1w
       , "смещение", "1w", "", "")
     или же
     label_replace (
       avg_over_time (задание: http_requests: rate5m [4h] смещение 334h)
       + job: http_requests: rate5m: avg_over_time_1w - job: http_requests: rate5m: avg_over_time_1w смещение 2w
       , "смещение", "2w", "", "")
     или же
     label_replace (
       avg_over_time (задание: http_requests: rate5m [4h] смещение 502h)
       + job: http_requests: rate5m: avg_over_time_1w - job: http_requests: rate5m: avg_over_time_1w смещение 3w
       , "смещение", "3w", "", "")
   )
   без (смещения)
  

Три прогноза для трех сред по сравнению с фактическим RPS Гитали, среда, 8 мая (одна неделя после Международного дня труда)

На графике мы построили среду, 8 мая, и три прогноза на три недели подряд до 8 мая.Мы видим, что два прогноза верны, но прогноз на 1 мая все еще далек от основания.

Кроме того, нам не нужны три предсказания, нам нужно , одно предсказание . Взятие среднего значения не вариант, потому что оно будет разбавлено нашими искаженными данными о количестве запросов в секунду на 1 мая. Вместо этого мы хотим вычислить медиану. У Prometheus нет медианного запроса, но мы можем использовать квантильное агрегирование вместо медианы.

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

  - запись: job: http_requests: rate5m_prediction
  expr:>
   квантиль (0,5,
     label_replace (
       avg_over_time (задание: http_requests: rate5m [4h] смещение 166h)
       + job: http_requests: rate5m: avg_over_time_1w - job: http_requests: rate5m: avg_over_time_1w смещение 1w
       , "смещение", "1w", "", "")
     или же
     label_replace (
       avg_over_time (задание: http_requests: rate5m [4h] смещение 334h)
       + job: http_requests: rate5m: avg_over_time_1w - job: http_requests: rate5m: avg_over_time_1w смещение 2w
       , "смещение", "2w", "", "")
     или же
     label_replace (
       avg_over_time (задание: http_requests: rate5m [4h] смещение 502h)
       + job: http_requests: rate5m: avg_over_time_1w - job: http_requests: rate5m: avg_over_time_1w смещение 3w
       , "смещение", "3w", "", "")
   )
   без (смещения)
  

Теперь наш прогноз, основанный на среднем значении из серии трех агрегатов, намного точнее.

Медиана прогнозов по сравнению с фактическими показателями Gitaly RPS, среда, 8 мая (одна неделя после Международного дня труда)

Как мы узнаем, что наш прогноз действительно точен?

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

Прогнозируемый нормальный диапазон ± 1,5σ для Gitaly Service

Мы можем обновить нашу диаграмму Grafana, чтобы использовать сезонный прогноз, а не еженедельное скользящее среднее значение. Диапазон нормальности для определенного времени суток заштрихован зеленым. Все, что выходит за пределы затененной зеленой зоны, считается выбросом. В этом случае выброс произошел в воскресенье днем, когда наш облачный провайдер столкнулся с некоторыми проблемами сети.

Использование границ ± 2σ по обе стороны от нашего прогноза - довольно хорошее измерение для определения выброса с сезонными прогнозами.

Как настроить оповещение с помощью Prometheus

Если вы хотите настроить оповещения для аномальных событий, вы можете применить к Prometheus довольно простое правило, которое проверяет, находится ли z-оценка метрики между стандартным отклонением +2 или -2 .

  - предупреждение: RequestRateOutsideNormalRange
  expr:>
   абс (
     (
       задание: http_requests: rate5m - задание: http_requests: rate5m_prediction
     ) / задание: http_requests: rate5m: stddev_over_time_1w
   )> 2
  для: 10м
  ярлыки:
    серьезность: предупреждение
  аннотации:
    резюме: Запросы на вакансию {{$ label.job}} находятся за пределами ожидаемых рабочих параметров
  

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

На вынос

  1. Prometheus может использоваться для некоторых типов обнаружения аномалий
  2. Правильный уровень агрегирования данных - ключ к обнаружению аномалий
  3. Z-скоринг - эффективный метод, если ваши данные имеют нормальное распределение
  4. Сезонные метрики могут дать отличные результаты для обнаружения аномалий

Посмотреть полную презентацию Эндрю из Monitorama 2019.Если у вас есть вопросы к Эндрю, свяжитесь с ним в Slack по адресу # talk-andrew-newdigate. Вы также можете узнать больше о том, зачем вам Прометей.

«. @ Su Suprememoocow показывает, как язык запросов @PrometheusIO можно использовать для обнаружения аномалий в @gitlab» - Сара Кассабиан

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *