Udostępnij przez

Konwencje składni dla dokumentacji referencyjnej

Przełącz usługi przy użyciu rozwijanej listy Wersja. Dowiedz się więcej o nawigacji.
Dotyczy: ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

W tym artykule opisano konwencje składni opisane w dokumentacji referencyjnej języka Kusto Query Language (KQL) i poleceń zarządzania .

Dobrym miejscem do rozpoczęcia nauki języka zapytań Kusto jest zrozumienie ogólnej struktury zapytań. Pierwszą rzeczą, którą zauważysz podczas przeglądania zapytania Kusto, jest użycie symbolu potoku (|). Struktura zapytania Kusto rozpoczyna się od pobierania danych ze źródła danych, a następnie przekazywania danych przez potok, a każdy krok zapewnia pewien poziom przetwarzania, a następnie przekazuje dane do następnego kroku. Na końcu potoku uzyskasz końcowy wynik. W efekcie jest to nasz potok:

Get Data | Filter | Summarize | Sort | Select

Ta koncepcja przekazywania danych w dół potoku zapewnia intuicyjną strukturę, ponieważ można łatwo utworzyć obraz mentalny danych na każdym kroku.

Aby to zilustrować, przyjrzyjmy się następującemu zapytaniu, które analizuje dzienniki logowania firmy Microsoft Entra. Podczas odczytywania poszczególnych wierszy można zobaczyć słowa kluczowe wskazujące, co dzieje się z danymi. W potoku uwzględniliśmy odpowiedni etap jako komentarz w każdym wierszu.

Uwaga / Notatka

Komentarze można dodawać do dowolnego wiersza w zapytaniu, poprzedzając je podwójnym ukośnikiem (//).

SigninLogs                              // Get data
| evaluate bag_unpack(LocationDetails)  // Ignore this line for now; we'll come back to it at the end.
| where RiskLevelDuringSignIn == 'none' // Filter
   and TimeGenerated >= ago(7d)         // Filter
| summarize Count = count() by city     // Summarize
| sort by Count desc                    // Sort
| take 5                                // Select

Ponieważ dane wyjściowe każdego kroku służą jako dane wejściowe dla poniższego kroku, kolejność kroków może określać wyniki zapytania i wpływać na jego wydajność. Ważne jest, aby uporządkować kroki zgodnie z tym, co chcesz wydostać się z zapytania.

Wskazówka

  • Dobrą regułą jest wczesne filtrowanie danych, więc przekazujesz tylko odpowiednie dane w dół potoku. Znacznie zwiększa to wydajność i zapewnia, że nie uwzględniasz przypadkowo nieistotnych danych w krokach podsumowania.
  • W tym artykule przedstawiono inne najlepsze rozwiązania, które należy wziąć pod uwagę. Aby uzyskać bardziej pełną listę, zobacz najlepsze rozwiązania dotyczące zapytań.

Konwencje składni

Convention Description
Block Literały ciągu, które mają być wprowadzane dokładnie tak, jak pokazano.
Kursywa Parametry do podania wartości przy użyciu funkcji lub polecenia.
[ ] Oznacza, że dołączony element jest opcjonalny.
( ) Oznacza, że wymagane jest co najmniej jedno z dołączonych elementów.
| (rura) Używane w nawiasach kwadratowych lub okrągłych, aby wskazać, że można określić jeden z elementów oddzielonych znakiem potoku. W tej formie potok jest odpowiednikiem operatora logicznego OR. W bloku (|) potok jest częścią składni zapytania KQL.
[, ...] Wskazuje, że powyższy parametr może być powtarzany wiele razy, rozdzielony przecinkami.
; Terminator instrukcji kwerendy.

Przykłady

Funkcja skalarna

W tym przykładzie przedstawiono składnię i przykładowe użycie funkcji skrótu, a następnie objaśnienie sposobu tłumaczenia poszczególnych składników składni na przykładowe użycie.

Składnia

hash( source [,mod])

Przykładowe użycie

hash("World")
  • Nazwa funkcji , hashi nawias otwierający są wprowadzane dokładnie tak, jak pokazano.
  • Wyrażenie "World" jest przekazywane jako argument wymaganego parametru źródłowego .
  • Dla parametru mod nie jest przekazywany żaden argument, który jest opcjonalny, co wskazuje nawiasy kwadratowe.
  • Nawias zamykający jest wprowadzany dokładnie tak, jak pokazano.

Operator tabelaryczny

W tym przykładzie przedstawiono składnię i przykładowe użycie operatora sortowania, a następnie objaśnienie sposobu tłumaczenia poszczególnych składników składni na przykładowe użycie.

Składnia

T| sort bykolumna [asc | desc] [nulls first | nulls last] [, ...]

Przykładowe użycie

StormEvents
| sort by State asc, StartTime desc
  • Tabela StormEvents jest przekazywana jako argument dla wymaganego parametru T .
  • | sort by jest wprowadzana dokładnie tak, jak pokazano. W tym przypadku znak potoku jest częścią składni instrukcji wyrażenia tabelarycznego , reprezentowanej przez tekst bloku. Aby dowiedzieć się więcej, zobacz Co to jest instrukcja zapytania.
  • Kolumna State jest przekazywana jako argument dla wymaganego parametru kolumny z opcjonalną asc flagą.
  • Po przecinkach jest przekazywany kolejny zestaw argumentów: kolumna StartTime z opcjonalną desc flagą. Składnia [, ...] wskazuje, że można przekazać więcej zestawów argumentów, ale nie są wymagane.

Praca z parametrami opcjonalnymi

Aby podać argument dla opcjonalnego parametru, który pochodzi po innym opcjonalnym parametrze, należy podać argument dla poprzedniego parametru. To wymaganie jest spowodowane tym, że argumenty muszą być zgodne z kolejnością określoną w składni. Jeśli nie masz określonej wartości do przekazania dla parametru, użyj pustej wartości tego samego typu.

Przykład sekwencyjnych parametrów opcjonalnych

Rozważ składnię wtyczki http_request:

evaluate http_request ( Identyfikator URI [, [,Opcje]])

RequestHeaders i Options to opcjonalne parametry typu dynamicznego. Aby podać argument parametru Opcje , należy również podać argument parametru RequestHeaders . W poniższym przykładzie pokazano, jak podać pustą wartość dla pierwszego opcjonalnego parametru RequestHeaders, aby móc określić wartość drugiego opcjonalnego parametru Opcje.

evaluate http_request ( "https://contoso.com/", dynamic({}), dynamic({ EmployeeName: Nicole }) )

Treści powiązane

  • Last updated on