Kusto Query Language для Azure Resource Graph: посібник для початківців
By Mirko Peters ·
Опануйте Kusto Query Language (KQL) для Azure Resource Graph. Вивчіть простий синтаксис, фільтрацію в конвеєрі, роботу з символом «|» та запити для керування вашим хмарним середовищем.
Automatically translated with AI from the original post. Read the English original

Опанування Kusto Query Language (KQL) для Azure Resource Graph дає адміністраторам хмари змогу писати чисті й блискавично швидкі запити, які без зусиль виводять інвентар хмари, ризики безпеки та відповідність політикам управління в кількох передплатах, без ручних кліків у порталі.
Головне
- Запити KQL читаються як рецепт: символ-конвеєр (|) послідовно з'єднує кроки обробки даних.
- Таблиця за замовчуванням 'resources' містить більшість того, що потрібно, щоб одночасно робити запити в кількох передплатах Azure.
- Оператори project та extend допомагають прибирати неструктурований вивід і витягувати значення вкладених властивостей без зайвого коду.
- За замовчуванням Resource Graph обмежує результати 1 000 записами як запобіжник, тож для великих середовищ потрібні токени продовження.
- Навички KQL, здобуті в Azure Resource Graph, напряму переносяться на Log Analytics та Azure Data Explorer.
Розбираємося з KQL в Azure Resource Graph
Коли ви вперше стикаєтеся з Kusto Query Language (KQL), абревіатура може здаватися лякаючою. Однак, відкинувши технічний жаргон, бачите напрочуд доступний синтаксис, схожий на англійську, який створено для інтуїтивного запитування хмарної інфраструктури. На відміну від написання складних застосунків або громіздких скриптів, KQL зосереджений виключно на тому, щоб ставити запитання та отримувати структуровані дані.
Кожне запитання, яке ви ставите в Azure Resource Graph, будується на KQL. Якщо ви колись користувалися Azure Data Explorer або Log Analytics, цей синтаксис одразу здасться знайомим. Але навіть якщо ви починаєте з нуля, крива навчання напрочуд полога. Основну частину KQL, необхідну для щоденного керування хмарою, можна засвоїти за один раз.
Анатомія запиту KQL
Запит KQL читається як покроковий рецепт. Секрет такої читабельності — символ конвеєра (|), який розділяє окремі інструкції. Ви починаєте з базової таблиці даних, а потім передаєте її далі через наступні команди, які звужують, фільтрують або змінюють формат результату.
Прочитайте запит KQL зверху вниз, і він звучатиме майже як звичайна англійська. Наприклад, розгляньмо найпростіший корисний запит, який можна написати:
resources | summarize countВимовлено вголос, ця команда означає: візьміть усе з таблиці за замовчуванням resources і порахуйте кількість. Система відповість одним, але дуже цінним числом, що відображає загальний масштаб вашої хмарної інфраструктури.
Ключові оператори для адміністраторів хмари
Щойно ви опануєте підрахунок ресурсів, захочете фільтрувати та форматувати дані. Кілька базових операторів виконують основну роботу майже в кожному адміністративному запиті:
- where: Фільтрує набір даних за заданими умовами. Наприклад, якщо змінити запит на
resources | where type == "Microsoft.Compute/virtualMachines", підрахунок обмежиться строго віртуальними машинами. - project: Визначає, які саме стовпці з'являтимуться у кінцевому результаті, дозволяючи показати лише ім'я ресурсу, розташування та ідентифікатор передплати замість величезної маси сирих даних JSON.
- order by: Сортує результати за алфавітом або за числами, перетворюючи випадковий дамп даних на впорядковану таблицю, яку зручно переглядати.
- extend: Створює тимчасовий користувацький стовпець, що дає змогу витягувати глибоко вкладені значення конфігурації та присвоювати їм короткі мітки для повторного використання.
Уникнення типових пасток KQL
KQL у деяких аспектах поблажливий, але щодо регістру правила суворі. Оператор нечутливого до регістру порівняння (записується як знак рівності з тильдою, наприклад =~) охоче ігнорує регістр, коли ви шукаєте рядкові значення, наприклад типи ресурсів. Але з іменами властивостей усе інакше. Якщо ви помилитеся в написанні імені властивості або неправильно вкажете регістр, KQL не видасть помилки синтаксису. Замість цього він мовчки поверне порожні значення, і ви шукатимете помилку там, де її немає в логіці запиту.
Використання таблиць поза базовими можливостями
Таблиця resources охоплює більшість повсякденних адміністративних перевірок, але для глибшого аналізу керування існують спеціалізовані таблиці. Коли потрібно перевірити стан безпеки, переглянути призначення політик або дослідити організаційні контейнери, зокрема групи управління, передплати та групи ресурсів, ви можете спрямувати запити KQL безпосередньо до цих таблиць.
Оскільки KQL є міжсервісним стандартом у екосистемі Microsoft, освоєння цих шаблонів одразу дає відчутний приріст у кар'єрі. Запити, які ви напишете сьогодні для очищення осиротілих груп безпеки мережі або пошуку віртуальних машин без тегів, однаково добре знадобляться під час створення сповіщень безпеки в Microsoft Defender або побудови операційних панелей у Log Analytics.
Висновки та наступні кроки
Вивчення мови запитів Kusto перетворює Azure Resource Graph із таємничого серверного рушія на ваш улюблений щоденний інструмент керування хмарою. Замінивши виснажливі клацання в порталі та крихкі скрипти короткими, зрозумілими запитами, ви отримуєте повну видимість вашого середовища з кількома передплатами.
Щоб глибше розібратися в спрощенні робочих процесів адміністрування хмари, послухайте повний епізод, де ви знайдете більше експертних порад, практичних прикладів і покрокових інструкцій щодо того, як зробити Azure Resource Graph корисним для вашої організації.
Поширені запитання
Що таке KQL і навіщо він потрібен в Azure Resource Graph?
KQL означає Kusto Query Language. Це легка й інтуїтивна мова запитів, якою ставлять питання про ваше середовище Azure в Resource Graph. Вона дає змогу миттєво фільтрувати, сортувати й групувати тисячі хмарних ресурсів за допомогою зрозумілого синтаксису з роздільником у вигляді вертикальної риски.
Як фільтрувати ресурси за типом за допомогою KQL?
Щоб фільтрувати ресурси, додайте клаузу 'where' після початкового оголошення таблиці. Наприклад, запис 'resources | where type =~ "microsoft.keyvault/vaults"' поверне лише ваші сховища ключів Azure Key Vault.
Чому мій запит KQL повертає порожні значення замість помилки?
Імена властивостей у KQL чутливі до регістру. Якщо ви неправильно вкажете регістр імені властивості, Azure Resource Graph не видасть помилки синтаксису. Замість цього він мовчки поверне порожні значення, через що налагодження стає складним.
Що таке обмеження в 1 000 записів в Azure Resource Graph?
За замовчуванням запит до resource graph повертає не більше 1 000 записів, щоб захистити користувачів від випадкового завантаження величезних обсягів даних. Це обмеження можна обійти або переглядати сторінками за допомогою токенів продовження, якщо ваше середовище містить тисячі ресурсів.