Вы помните момент, когда узнали, что журналы не бесплатны? Я точно знаю. Это произошло сразу после того, как наша команда достигла важной вехи — мы только что запустили новый и блестящий масштабируемый сервис, который собирается заменить устаревший сервис с чрезвычайно высокой пропускной способностью и крайне неэффективным сервисом. Мы только что сократили размер парка с примерно 300 экземпляров EC2 до примерно 30 модулей в многопользовательском кластере kubernetees. Повышение надежности, снижение задержки обработки и снижение затрат на порядок.

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

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

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

Любая оптимизация начинается с измерения

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

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

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

Две классные вещи, которые могут помочь вам здесь (при использовании Kibana, но, вероятно, могут применяться где угодно) — это измерение размера журнала:

И вкладка шаблона, которая показывает наиболее распространенные шаблоны журналов:

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

Понимание использования

Для чего будут использоваться ваши журналы?

• Будут ли они использоваться только во время простоев, чтобы понять, что происходит в производстве?
• Используются ли журналы в целях аудита для понимания пути запроса? Будут ли они использоваться для отладки вариантов использования в бизнесе?
• Являются ли эти журналы ценными через час? Через день?
• Обслуживает ли система длительные запросы? Или запросы временные?
• Являются ли журналы частью каких-либо нормативных требований?
• Какова стоимость отключения?

Давайте рассмотрим несколько примеров:

Допустим, у вас есть система, где каждый запрос критичен, каждый невыполненный запрос будет негативно сказываться на бизнесе компании. Лучшим примером такой системы является сайт электронной коммерции — каждый невыполненный заказ — это упущенная выгода! Мы, вероятно, хотели бы записывать каждый шаг этого запроса, чтобы знать, что произошло, что не удалось, и, возможно, иметь возможность использовать эти журналы для ответа на такие вопросы, как «почему заказ проходит через поток X, а не через поток Y».

В таком случае журналы очень ценны и должны храниться в течение довольно длительного периода — вероятно, 7–14 дней.

Хорошее эмпирическое правило для требуемого периода хранения журнала — общее время, необходимое для поддержки запросов и ответов на них.

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

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

Кроме того, не требуется аудит на уровне запросов, никто никогда не спросит нас, почему запрос X вел себя так, а не иначе.

Этот анализ привел нас к следующим выводам:

• Одиночный запрос не имеет смысла в нашей системе
• Кроме сбоев обработки, мы не смогли придумать никаких причин для проверки журналов системы (ее поведение и SLI охвачены мониторингом метрик)
• Данные настолько временные, что через несколько часов после их обработки маловероятно, что кому-то будет интересен запрос.

Использование правильного времени удерживания

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

Но здесь тоже есть урок — уровни удержания по умолчанию в течение 7–14 дней, используемые большинством компаний, являются случайными значениями по умолчанию и могут иметь влияние на затраты от 10 до 90%.

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

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

Это имеет большое значение, если у вас есть 5 ТБ ежедневных журналов, которые вы храните в течение дня или месяца.

Значимые журналы и отказ от использования журналов в качестве показателей

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

Эти журналы совершенно бессмысленны:

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

Что касается журналов — записывайте значимые данные, если этот запрос ценен, записывайте, что это за запрос, как его найти, что делает его значимым, и это данные! Что-то из разряда:

Обслуживание учетной записи Premium <имя учетной записи>, запрос <id>, <некоторый дополнительный контекст о потоке и запросе>

Поскольку мы создали службу с высокой пропускной способностью, мы удалили «запросы на обслуживание» и «завершенный процесс x» на ~сотни ГБ , снизив затраты на ведение журнала примерно на 5–10 %.

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

Ведение журнала на основе серьезности

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

Решили пойти дальше — и поставить уровень лога на WARNING , а позже на ERROR .

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

Это сократило использование нашего журнала еще примерно на 90% без каких-либо реальных потерь удобства использования.

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

Динамическое ведение журнала

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

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

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

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

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

Выборка уровня трассировки

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

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

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

Ограничение «штормов ошибок», предсказуемые затраты на ведение журнала

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

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

Мы реализовали небольшую защелку в памяти (механизм, который «блокируется» в определенном состоянии), которая блокируется, когда одно и то же сообщение журнала регистрируется более X раз, и останавливает поток ошибок.

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

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

Ограничить привязку к поставщику и сменить поставщика

Мы смогли снизить общую стоимость примерно на 50 %, сменив поставщиков журналов.

По сути, мы платили за прославленный управляемый OpenSearch (в то время ElasticSearch), мы не использовали большую часть расширенных возможностей инструментов.

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

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

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

Не бойтесь SSH и Kubectl

В некоторых (как правило, системах без сохранения состояния) вам не обязательно иметь централизованные журналы. Если ваши требования безопасности позволяют это, вы можете по умолчанию подключиться к машине с помощью инструмента по вашему выбору, а также файлы журнала tailing , cating и less-ing и stdout. Я знаю, что это варварство и очень похоже на 1998 год. Но это работает и дешево.

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

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

Последние мысли

Вы можете подумать, что мы переборщили здесь и перестарались. Вы, вероятно, будете правы. Но:

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

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

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

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

Этого не должно быть.

Как всегда, мысли и комментарии приветствуются в твиттере @cherkaskyb