Azure Log Analytics: как не допустить взрывного роста затрат на мониторинг Azure
By Mirko Peters ·
Узнайте, как контролировать стоимость Azure Log Analytics, оптимизировать планы таблиц рабочей области, фильтровать избыточный объём приёма данных и не допустить взрывного роста затрат на облачный мониторинг.
Automatically translated with AI from the original post. Read the English original

Контроль стоимости Azure Log Analytics требует понимания объёма приёма данных, планов хранения таблиц и затрат на долгосрочное хранение. Применяя раннюю фильтрацию данных с помощью KQL, выбирая подходящие планы, такие как Basic и Auxiliary, и отказываясь от опасных ежедневных ограничений на сбор данных, администраторы могут не допустить выхода счетов за мониторинг Azure из-под контроля.
Главное
- Стоимость Azure Log Analytics определяется в первую очередь объёмом принятых данных и продолжительностью их хранения.
- План таблицы существенно влияет на расходы: хранение в плане Basic может быть заметно дешевле стандартной аналитики, а планы Auxiliary предлагают очень большие скидки для массового архивного хранения.
- Фильтрация шумных, никем не читаемых строк журналов на границе сбора с помощью правил сбора данных — самый эффективный рычаг снижения затрат на облачный мониторинг.
- Жёсткие ежедневные ограничения на приём данных могут непреднамеренно лишить ваши команды безопасности и эксплуатации видимости, остановив сбор всех данных в середине дня.
- Баланс между окном интерактивного хранения и долгосрочным холодным хранилищем обеспечивает соответствие требованиям без переплаты за высокоскоростные возможности запросов.
Ключевые факторы стоимости Log Analytics
Когда организации впервые внедряют облачный мониторинг, внимание почти полностью сосредоточено на видимости — на том, чтобы системы взаимодействовали друг с другом и каждая ошибка фиксировалась. Однако реальность наступает, когда приходит ежемесячный счёт за облако. Log Analytics тарифицируется в первую очередь по двум параметрам потребления: объёму гигабайтов, передаваемых в рабочую область, и продолжительности, в течение которой эти записи остаются доступными для интерактивных запросов.
Само создание рабочей области ничего не стоит, и это часто создаёт ложное чувство безопасности. Команды склонны относиться к своим репозиториям журналов как к бесконечным цифровым ящикам для всякого хлама, сваливая в один контейнер подробные отладочные данные приложений, избыточные сигналы heartbeat и непроверенные трассировки. Поскольку вы платите за каждый гигабайт, попадающий в рабочую область, независимо от того, открывал ли кто-нибудь эту таблицу, неконтролируемый приём данных быстро приводит к превышению бюджета.
Выбор планов таблиц: Analytics, Basic и Auxiliary
Одно из самых значимых решений, которое может принять администратор, — назначение правильного плана стоимости для отдельных таблиц. Не все журналы требуют одинакового уровня производительности, и Microsoft предлагает многоуровневые планы, отражающие эти операционные компромиссы.
Стандартный уровень Analytics
Стандартный план Analytics предназначен для данных, которые вы отслеживаете в режиме реального времени и которые нужно запрашивать мгновенно. Он поддерживает обнаружение угроз в реальном времени и быструю диагностику неполадок. Однако это также самый дорогой вариант. Он поддерживает полную индексацию, что позволяет выполнять запросы на языке Kusto Query Language (KQL) за доли секунды даже в сложных выражениях.
Уровни Basic и Auxiliary
Для данных, которые вы просматриваете только реактивно, когда что-то ломается, или для большого объёма записей, которые хранятся исключительно для аудита, планы Basic и Auxiliary обеспечивают значительную экономию. Если стандартная аналитика может стоить около 2,30 $ за гигабайт, то Basic способен заметно снизить эту цену, а уровни Auxiliary могут опустить стоимость до доли стандартного тарифа (в нижней границе — до чем в 46 раз дешевле).
Главная сложность — в функциональности. Дешёвые планы работают медленнее при поиске, не поддерживают полную индексацию и совершенно не подходят для оперативных оповещений о безопасности. Комбинируя планы в одной рабочей области, вы можете направлять критичные сигналы безопасности в дорогие высокоскоростные таблицы, а шумные журналы соответствия размещать в дешёвом вспомогательном хранилище.
Как сократить расходы с помощью ранней фильтрации и правил сбора данных
Самая распространённая ошибка администраторов — попытка очистить данные уже после того, как они попали в рабочую область. К моменту сохранения записи журнала вы уже платите за её приём.
Правильный подход — использовать правила сбора данных (Data Collection Rules, DCR) вместе с Azure Monitor Agent. DCR задают наборы инструкций, которые развёртываются на виртуальных машинах и кластерах контейнеров. Они определяют, какие события собирать, как их преобразовывать и в какую таблицу направлять. Что важнее, они позволяют отсекать повторяющийся шум уже на источнике.
Если приложение каждый час генерирует тысячи однотипных журналов уровня info, которые ваша команда никогда не запрашивает, отсекайте их на входе. Преобразование и фильтрация данных до попадания в хранилище гарантируют, что вы не будете платить за телеметрию, которой не пользуетесь.
Опасность ежедневных ограничений приёма
Столкнувшись с непредсказуемыми счетами за облако, многие руководители финансов и ИТ рассматривают функцию ежедневного ограничения Azure Log Analytics как абсолютную страховку. Ежедневное ограничение устанавливает жёсткий лимит на приём данных: как только порог достигнут, рабочая область перестаёт принимать новые записи до конца дня.
Хотя это предотвращает неожиданные всплески расходов, Microsoft прямо предупреждает against полагаться на него для повседневного управления затратами. Когда срабатывает ежедневное ограничение, сбор данных полностью останавливается. Аналитики безопасности теряют видимость, операционные команды работают вслепую, и вы пропустите критичные оповещения, если ночью произойдёт сбой системы. Внезапная потеря видимости во время сбоя почти всегда обходится дороже, чем немного более высокий счёт за мониторинг в облаке.
Баланс между интерактивным хранением и долгосрочными архивами
Контроль затрат касается не только приёма, но и того, как долго данные хранятся. По умолчанию интерактивное хранение обеспечивает быстрый доступ к запросам в течение 31 дня (или 90 дней, если включён Microsoft Sentinel). По истечении этого периода данные не исчезают, а переходят в долгосрочное хранилище.
Хранение данных для интерактивных запросов обходится значительно дороже за гигабайт в месяц, чем архивирование в долгосрочном хранилище. Для требований соответствия, предписывающих хранить данные годами, архивное хранилище стоит копейки за гигабайт. Только помните: для извлечения архивных данных нужно запускать задания поиска, а не выполнять мгновенные интерактивные запросы, поэтому продуманная стратегия заранее необходима.
Итоги и следующие шаги
Управление ценообразованием Azure Log Analytics — это вопрос осознанной архитектуры. Отказавшись от стратегии «собирать всё подряд», используя планы для отдельных таблиц и внедряя строгие правила сбора данных на границе, вы сможете сохранить видимость корпоративного уровня и не выйти за рамки облачного бюджета.
Чтобы глубже разобраться в принципах работы этих систем, обязательно послушайте полный выпуск подкаста M365 FM — понятный без жаргона разбор рабочих областей, таблиц и основ запросов KQL.
Часто задаваемые вопросы
Бесплатно ли создание рабочей области Azure Log Analytics?
Да, создание рабочей области не предполагает базовой платы. Вы платите только за объём данных, принятых в рабочую область, и за срок их хранения.
В чём разница между планами Analytics, Basic и Auxiliary?
План Analytics обеспечивает высокоскоростное полностью индексированное хранилище, оптимизированное для оперативных оповещений о безопасности и быстрых интерактивных запросов. Планы Basic и Auxiliary предлагают значительно более дешёвое хранение для данных, которые запрашиваются редко или хранятся главным образом для соответствия требованиям и архивирования.
Почему следует избегать ежедневных ограничений приёма?
Ежедневные ограничения приёма полностью останавливают сбор данных, как только достигнут порог расходов. Это лишает ваши системы безопасности и мониторинга видимости до конца дня и создаёт недопустимые риски во время сбоев систем или утечек безопасности.
Как снизить затраты на приём данных в Log Analytics?
Самая эффективная стратегия снижения затрат — отфильтровывать ненужные журналы на уровне источника с помощью правил сбора данных (DCR), чтобы шумные отладочные журналы, которые никто не читает, отбрасывались до попадания в платную рабочую область.