Сегодня мы рады объявить об уведомлениях об уровне ошибок Origin: новом сложном способе обнаружения и уведомления вас, когда Cloudflare обнаруживает повышенный уровень ошибок 5xx от вашего источника.
В 2019 году мы анонсировали оповещения о пассивном мониторинге происхождения, чтобы уведомить вас, когда ваш источник выходит из строя. Пассивный мониторинг происхождения великолепен — он сообщает вам, если каждый запрос к вашему источнику возвращает ошибку 521 (веб-сервер не работает) в течение полных пяти минут. Но иногда этого недостаточно. Вы не хотите ждать все ваших пользователей иметь проблемы; вы хотите получать уведомления, когда больше пользователей, чем обычно возникают проблемы до того, как это станет большой проблемой.
Расчет аномалий
Ни один сервис не идеален — мы знаем, что очень небольшой процент ваших исходных ответов, скорее всего, будет ошибкой 5xx. В большинстве случаев эти проблемы являются единичными, и на самом деле ничего не нужно делать. Однако для интернет-ресурсов с очень высоким трафиком даже очень небольшой процент потенциально может быть большим числом. Если мы будем предупреждать вас о каждой из этих ошибок, вы никогда не перестанете получать бесполезные уведомления. Когда дело доходит до уведомления, вопрос не в том, есть ли любой ошибки, но сколько ошибки должны существовать, прежде чем они станут проблемой.
Так как же нам узнать, есть ли проблема? Нам, людям, относительно легко взглянуть на график, определить всплеск и подумать: «Хм, этого не должно быть». Для компьютера все становится немного сложнее. В отличие от людей, обладающих интуицией и способных выносить суждения в серых областях, компьютеру нужен точный набор критериев, чтобы определить, есть ли что-то необычное.
Самый простой способ обнаружить отклонения в наборе данных временных рядов — установить единый порог — например, «уведомлять меня, когда более 5% запросов к моим интернет-ресурсам приводят к ошибкам». К сожалению, подобрать эффективный порог действительно сложно. Слишком высоко, и вы никогда не получите уведомление; слишком низко, и вы тонете в уведомлениях:
Даже когда мы находим эту золотую середину, мы все равно можем пропустить проблемы, которые горят «медленно и медленно». Здесь нет очевидного резкого всплеска, но что-то давно идет не так:
Мы можем попробовать наслоить несколько порогов. Например: уведомить вас, если коэффициент ошибок когда-либо превышает 10%, или же если он превышает 5% дольше пяти минут, или же если оно больше 2%, дольше 10 минут. Это не только быстро усложняется, но и не учитывает периодические проблемы, такие как перезапуск модулей kubernetes или регулярное развертывание. Что, если частота ошибок превышает 5% всего за четыре минуты, но это происходит каждые пять минут? Мы знаем, что это затронуло многих ваших конечных пользователей, но даже длинный набор правил, перечисленных выше, не поймет это.
Таким образом, пороговые значения, вероятно, недостаточно сложны для обнаружения проблем с происхождением. Вместо этого мы обращаемся к Руководству Google SRE для предупреждений на основе целей уровня обслуживания (SLO). SLO — это часть соглашения между клиентом и поставщиком услуг. Это определенная метрика и значение, с которыми согласны обе стороны. Одним из наиболее распространенных типов SLO является доступность, или «услуга будет доступна в течение определенного процента времени». В этом случае служба является вашим источником, и соглашение заключается между вами и вашими конечными пользователями. Конечные пользователи ожидают, что ваш источник будет доступен определенный процент времени.
Если мы вернемся к нашей исходной концепции, мы поймем, что вас устраивает, что ваше происхождение возвращает определенное количество ошибок. Мы определяем этот номер как ваш SLO. SLO 99,9 означает, что 0,01% всех ваших запросов за месяц являются ошибками. Следовательно, 0,01% всех запросов, которые достигают вашего источника, составляет ваш общий бюджет ошибок — вы можете получить столько ошибок в месяц и никогда не получать уведомления, потому что вы определили это как приемлемое.
Что вы действительно хотите знать, так это то, что вы слишком быстро сжигаете этот бюджет ошибок — это, вероятно, означает, что что-то действительно идет не так (а не единовременно). Мы можем измерить скорость сжигания, чтобы определить, насколько быстро вы прожигаете свой бюджет ошибок, учитывая частоту ошибок, которые мы наблюдаем в настоящее время. Скорость сжигания, равная единице, означает, что весь бюджет ошибок будет использован точно в установленный период времени — идеальный сценарий. Нулевая скорость записи даже лучше, поскольку мы вообще не видим никаких ошибок, но в конечном итоге это довольно нереально. Скорее всего, проблема в скорости записи 10 — если эта скорость будет сохраняться в течение всего месяца, у вас будет в 10 раз больше ошибок, чем вы первоначально заявили, что это приемлемо.
Даже при использовании скорости сжигания вместо пороговых значений мы все равно хотим иметь несколько критериев. Мы хотим измерить короткий период времени с высокой скоростью сжигания (короткий показатель). Это покрывает вашу потребность «быстро предупреждать меня, когда происходит что-то драматическое». Но мы также хотим иметь более длительный период времени с более низкой скоростью сжигания (длинный индикатор), чтобы покрыть вашу потребность «не предупреждать меня о проблемах, которые быстро решаются». Таким образом, мы можем гарантировать быстрое оповещение, не отправляя слишком много ложных срабатываний.
Давайте посмотрим на жизнь инцидента, используя эту методологию. В нашем первом измерении короткий индикатор сообщает нам, что, похоже, что-то пошло не так. Однако длинный индикатор все еще находится в разумных пределах. Бить тревогу пока не будем.
Когда мы проводим следующие измерения, мы видим, что проблема еще хуже. Теперь мы находимся в точке, когда возникает достаточно ошибок, когда не только короткий индикатор говорит нам, что что-то не так, но и длинный индикатор тоже пострадал. Мы уверены, что проблема возникла, и пора вас уведомить.
Пару циклов спустя инцидент закончился. Длинный индикатор все еще говорит нам, что что-то не так, потому что инцидент все еще находится в пределах длительного периода времени. Однако короткий индикатор показывает, что на данный момент ничего не стоит. Поскольку у нас нет обоих индикаторов, говорящих о том, что что-то не так, мы не будем уведомлять вас. Это удерживает нас от отправки уведомлений об уже минувших инцидентах.
Эта методология хороша тем, насколько хорошо она реагирует на разные инциденты. Если бы первоначальный всплеск был более драматичным, он бы немедленно сработал как для длинных, так и для коротких индикаторов. Чем больше ошибок мы видим, тем больше мы уверены в наличии проблемы и тем быстрее сможем вас уведомить.
Даже используя эту методологию, мы знаем, что разные сервисы ведут себя по-разному. Таким образом, для этого уведомления вы можете выбрать целевой уровень обслуживания (SLO), который вы хотите использовать для мониторинга своего интернет-ресурса: 99,9% (высокая чувствительность), 99,8% (средняя чувствительность) или 99,7% (низкая чувствительность). Вы также можете выбрать, какие свойства Интернета вы хотите отслеживать — нет необходимости получать уведомления для тестовых свойств или доменов с более низким приоритетом.
Начни сегодня
Уведомления о частоте ошибок источника HTTP можно настроить на вкладке «Уведомления» на панели управления. Выбирать Предупреждение о частоте ошибок источника как тип вашего оповещения. Как и во всех уведомлениях Cloudflare, вы можете назвать и описать свое уведомление, а также выбрать способ получения уведомлений. Оттуда вы можете выбрать, какие домены вы хотите отслеживать и на каком SLO.
Это уведомление доступно всем корпоративным клиентам. Если вы заинтересованы в отслеживании своего происхождения, мы рекомендуем вам попробовать.
Наша команда нанимает сотрудников в Остине, Лиссабоне и Лондоне.
