Чим відрізняються плани Analytics, Basic і Auxiliary для журналів?

План Analytics забезпечує швидке сховище з повною індексацією, оптимізоване для оповіщень безпеки в реальному часі та швидких інтерактивних запитів. Плани Basic і Auxiliary пропонують значно дешевші варіанти зберігання для даних, до яких звертаються рідко або які зберігаються переважно для відповідності вимогам і архівування.

Чому варто уникати денних обмежень на прийом даних?

Денні обмеження на прийом даних повністю зупиняють збір даних, щойно досягнуто порогу витрат. Через це ваші системи безпеки та моніторингу залишаються «сліпими» до кінця дня, що створює неприйнятні ризики під час збоїв систем або кіберatak.

Як зменшити витрати на прийом даних у Log Analytics?

Найефективніша стратегія зниження витрат полягає у фільтрації непотрібних журналів безпосередньо на джерелі за допомогою правил збору даних (Data Collection Rules, DCR), щоб зайві, нікому не потрібні журнали налагодження відкидалися ще до того, як потраплять до платної робочої області.

Ціни Azure Log Analytics: як не допустити, щоб витрати на моніторинг Azure вийшли з-під контролю

Q: Чи безкоштовне створення робочої області Azure Log Analytics?

Так, створення робочої області не передбачає жодної базової плати. Ви платите лише за обсяг даних, які надходять до робочої області, і за термін їх зберігання.

By Mirko Peters · 2026-10-23

Дізнайтеся, як контролювати ціни 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 може бути значно дешевшим за стандартний Analytics, а плани Auxiliary пропонують надзвичайні знижки для масивних архівних даних.
Фільтрація зайвих, нікому не потрібних рядків журналів на периферії за допомогою правил збору даних — найефективніший важіль для зниження витрат на хмарний моніторинг.
Покладання на жорсткі денні обмеження на прийом даних може ненароком осліпити команди безпеки та експлуатації, адже збір даних зупиняється посеред дня.
Баланс між інтерактивним терміном зберігання та довгостроковим холодним зберіганням забезпечує відповідність вимогам без переплати за швидкі можливості запитів.

Справжні чинники витрат Log Analytics

Коли організації тільки впроваджують хмарний моніторинг, увага зосереджена майже виключно на видимості: щоб системи взаємодіяли між собою, а кожна помилка фіксувалася. Проте реальність настає, коли приходить місячний рахунок за хмарні послуги. Log Analytics тарифікується переважно за двома складовими споживання: обсягом гігабайтів, що надходять до робочої області, і терміном, протягом якого ці записи залишаються доступними для інтерактивних запитів.

Саме створення робочої області нічого не коштує, і це часто створює хибне відчуття безпеки. Команди схильні ставитися до своїх репозиторіїв журналів як до безмежних цифрових шухляд для мотлоху: вони скидають туди детальні дані налагодження застосунків, надлишкові сигнали heartbeat і неперевірені трасування. Оскільки ви платите за кожен гігабайт, що потрапляє до системи, незалежно від того, чи хтось відкриває цю таблицю, некерований прийом даних швидко призводить до перевитрат бюджету.

Плани таблиць: Analytics, Basic і Auxiliary

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

Стандартний рівень Analytics

Стандартний план Analytics призначений для даних, за якими ви ведете пильний нагляд і які потрібно запитувати миттєво. Він підтримує виявлення загроз у реальному часі та швидке усунення несправностей. Водночас це найдорожчий варіант. Він забезпечує повну індексацію, що дає змогу виконувати складні запити мовою Kusto Query Language (KQL) за частки секунди.

Рівні Basic і Auxiliary

Для даних, які ви переглядаєте лише реактивно, коли щось ламається, або для великих обсягів записів, що зберігаються виключно для аудиту, плани Basic і Auxiliary пропонують суттєву економію. Якщо стандартний Analytics може коштувати близько 2,30 долара за гігабайт, то Basic може значно знизити цю ціну, а рівні Auxiliary можуть знизити витрати до частки стандартних тарифів (на нижній межі інколи до 46 разів дешевше).

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

Як суттєво знизити витрати за допомогою раннього фільтрування та правил збору даних

Найбільша помилка адміністраторів – намагатися очистити дані після того, як вони вже потрапили в робочу область. До моменту, коли запис журналу зберігається, ви вже платите за його приймання.

Правильний підхід передбачає використання правил збору даних (DCR) разом з Azure Monitor Agent. DCR є наборами інструкцій, які розгортаються на ваших віртуальних машинах і кластерах контейнерів. Вони точно визначають, які події збирати, як їх формувати і в яку таблицю їх записувати. Що важливіше, вони дозволяють відсікати повторюваний шум ще на джерелі.

Якщо застосунок щогодини генерує тисячі повторюваних журналів рівня info, які ваша команда ніколи не запитує, відсікайте їх на вході. Перетворення та фільтрація даних до того, як вони потраплять у сховище, гарантує, що ви ніколи не отримаєте рахунок за телеметрію, якою не користуєтеся.

Небезпека добових обмежень приймання

Стикаючись із непередбачуваними рахунками за хмарні послуги, многі фінансові керівники та ІТ-менеджери розглядають функцію добового ліміту Azure Log Analytics як абсолютну страховку. Добовий ліміт встановлює жорстку межу приймання даних: щойно порогове значення досягнуто, робоча область перестає приймати нові записи до кінця доби.

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

Баланс між інтерактивним зберіганням і довгостроковими архівами

Контроль витрат стосується не лише приймання, а й того, як довго дані зберігаються. За замовчуванням інтерактивне зберігання забезпечує швидкий доступ до запитів протягом 31 дня (або 90 днів, якщо увімкнено Microsoft Sentinel). Після закінчення цього періоду дані не зникають, а переходять у довгострокове сховище.

Зберігання даних із можливістю інтерактивних запитів щомісяця коштує значно більше за гігабайт, ніж архівування в довгостроковому сховищі. Для вимог відповідності, які передбачають зберігання даних упродовж років, архівне сховище коштує копійки за гігабайт. Пам'ятайте лише, що для отримання архівних даних потрібно запускати завдання пошуку, а не миттєві інтерактивні запити, тож попередня стратегія є обов'язковою.

Висновки та наступні кроки

Керування цінами Azure Log Analytics – це свідома архітектура. Відмовившись від стратегії збору всіх даних без розбору, використовуючи плани для окремих таблиць і запроваджуючи суворі правила збору даних на межі системи, ви зможете зберегти видимість рівня корпоративного класу, не виходячи за межі хмарного бюджету.

Щоб глибше розібратися в основах роботи цих систем, обов’язково послухайте повний епізод подкасту M365 FM, де без зайвого жаргону розібрано робочі області, таблиці та основи запитів KQL.

Поширені запитання

Чи безкоштовне створення робочої області Azure Log Analytics?

Так, створення робочої області не передбачає жодних базових платежів. Ви платите лише за обсяг даних, прийнятих робочою областю, та за строк їх зберігання.

Чим відрізняються плани Analytics, Basic та Auxiliary?

План Analytics забезпечує високошвидкісне повністю індексоване сховище, оптимізоване для сповіщень про безпеку в реальному часі та швидких інтерактивних запитів. Плани Basic та Auxiliary пропонують значно дешевше сховище для даних, до яких звертаються рідко або які зберігаються переважно для відповідності вимогам і архівування.

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

Добові обмеження приймання повністю зупиняють збір даних щойно досягнуто порогу витрат. Це позбавляє ваші системи безпеки та моніторингу видимості до кінця доби, створюючи неприйнятні ризики під час збоїв системи або порушень безпеки.

Як зменшити витрати на приймання даних Log Analytics?

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