Implementowanie przesyłania strumieniowego dzienników za pomocą usługi Azure Log Analytics

Gdy środowisko usługi Azure Databricks wykracza poza pojedynczy obszar roboczy, śledzenie tego, co dzieje się w klastrach, zadaniach i użytkownikach, staje się wyzwaniem. Przesyłanie strumieniowe dzienników do Azure Log Analytics rozwiązuje ten problem, centralizując wszystkie dzienniki diagnostyczne i inspekcyjne w jednym miejscu oraz umożliwiając wykonywanie zapytań, ustawianie alertów i tworzenie pulpitów nawigacyjnych.

W tej lekcji dowiesz się, jak działa przesyłanie strumieniowe dzienników, jak wykonywać zapytania dotyczące dzienników usługi Databricks w usłudze Azure Log Analytics oraz jak tworzyć alerty na potrzeby proaktywnego monitorowania.

Zrozumienie architektury przesyłania dzienników w strumieniu

Przesyłanie strumieniowe dzienników wysyła dane diagnostyczne z Azure Databricks do Azure Log Analytics, zazwyczaj w ciągu 15 minut od zdarzenia. Ta integracja używa ustawień diagnostycznych platformy Azure, które przechwytują zdarzenia z obszaru roboczego usługi Azure Databricks i kierują je do obszaru roboczego usługi Log Analytics. Ustawienia diagnostyczne mogą również archiwizować dzienniki na koncie magazynu lub przesyłać je strumieniowo do centrum zdarzeń.

Rozważ typowy scenariusz: Twoja organizacja uruchamia wiele obszarów roboczych usługi Azure Databricks w różnych zespołach. Bez scentralizowanego rejestrowania badanie zadania, które zakończyło się niepowodzeniem, wymaga połączenia z poszczególnymi obszarami roboczymi i przeszukiwania rozproszonych dzienników. Po skonfigurowaniu przesyłania strumieniowego dzienników wysyłasz zapytania dotyczące wszystkich zdarzeń z jednego interfejsu.

Przepływ danych działa w następujący sposób:

1. Usługa Azure Databricks generuje zdarzenia inspekcji i diagnostyki dla akcji takich jak tworzenie klastra, uruchomienia zadań, wykonywanie notebooku i zmiany uprawnień.
2. Ustawienia diagnostyczne platformy Azure przechwytują te zdarzenia i przesyłają je strumieniowo do skonfigurowanego miejsca docelowego.
3. Usługa Log Analytics pozyska zdarzenia do tabel specyficznych dla usługi.
4. Tworzysz zapytania, wizualizujesz i ostrzegasz na podstawie tych danych przy użyciu języka Kusto Query Language (KQL).

Diagram wyjaśniający architekturę log streaming.

Administratorzy platformy zazwyczaj konfigurują ustawienia diagnostyczne za pośrednictwem portalu Azure, wybierając pozycję Ustawienia diagnostyczne w sekcji Monitorowanie zasobu Azure Databricks i wybierając pozycję Wyślij do Log Analytics. Jako inżynier danych skupiasz się na używaniu dzienników do monitorowania i rozwiązywania problemów.

Eksplorowanie tabel dzienników usługi Azure Databricks

Usługa Azure Log Analytics organizuje dzienniki usługi Azure Databricks w tabelach specyficznych dla celu. Każda tabela przechwytuje zdarzenia z określonej usługi lub funkcji, co ułatwia skoncentrowanie zapytań.

Najczęściej używane tabele to:

Każda tabela zawiera standardowe kolumny do śledzenia zdarzeń:

• TimeGenerated - Kiedy wystąpiło zdarzenie
• OperationName - Akcja została wykonana
• Identity - Użytkownik lub jednostka usługi, która zainicjowała akcję
• SourceIPAddress - Gdzie pochodzi żądanie
• RequestParams - Szczegóły dotyczące żądania
• Response - Wynik zawierający kody stanu

Zrozumienie tych tabel ułatwia efektywne kierowanie zapytań. W przypadku problemów związanych z zadaniami zacznij od DatabricksJobs. W przypadku badań dotyczących zabezpieczeń skoncentruj się na elementach DatabricksSecrets i DatabricksUnityCatalog.

Wykonywanie zapytań dotyczących dzienników za pomocą języka zapytań Kusto

Język zapytań Kusto (KQL) umożliwia wyszukiwanie, filtrowanie i analizowanie dzienników usługi Azure Databricks. Dostęp do usługi Log Analytics można uzyskać, przechodząc do obszaru roboczego w witrynie Azure Portal i wybierając pozycję Dzienniki na pasku bocznym.

Zacznij od prostego zapytania, by zobaczyć ostatnie zdarzenia związane z zadaniami:

DatabricksJobs
| where TimeGenerated > ago(24h)
| project TimeGenerated, OperationName, Identity, SourceIPAddress
| order by TimeGenerated desc
| take 100

To zapytanie pobiera najnowsze 100 zdarzeń związanych z zadaniami z ostatnich 24 godzin, wyświetlając znacznik czasu, operację, użytkownika i źródłowy adres IP.

Badanie przebiegów zadań, które zakończyły się niepowodzeniem

Gdy zadania kończą się niepowodzeniem, należy zidentyfikować wzorce. Następujące zapytanie wyszukuje wszystkie błędy zadań i grupuje je według operacji:

DatabricksJobs
| where TimeGenerated > ago(7d)
| where Response contains "error" or Response contains "failed"
| summarize FailureCount = count() by OperationName, bin(TimeGenerated, 1h)
| order by FailureCount desc

To zapytanie ujawnia, które operacje kończą się niepowodzeniem najczęściej i gdy występują błędy klastra, ułatwiając wykrycie problemów systemowych.

Śledzenie wzorców użycia klastra

Zrozumienie zachowania klastra pomaga zoptymalizować koszty. To zapytanie pokazuje zdarzenia klastra według typu:

DatabricksClusters
| where TimeGenerated > ago(7d)
| summarize EventCount = count() by OperationName
| order by EventCount desc

Monitorowanie wzorców dostępu do tabel

Aby uzyskać informacje o zabezpieczeniach i zgodności, śledź, kto tworzy, modyfikuje lub usuwa tabele w obszarach roboczych:

DatabricksUnityCatalog
| where TimeGenerated > ago(24h)
| where ActionName in~ ("createTable", "deleteTable", "updateTables")
| project TimeGenerated, Identity, ActionName, RequestParams
| order by TimeGenerated desc

Tworzenie alertów na potrzeby proaktywnego monitorowania

Zapytania ułatwiają badanie przeszłych zdarzeń. Alerty powiadamiają o wystąpieniu określonych warunków, włączając proaktywną odpowiedź.

Aby utworzyć alert na podstawie zapytania:

1. Uruchom zapytanie w usłudze Log Analytics.
2. Wybierz pozycję Nowa reguła alertu na pasku narzędzi.
3. Skonfiguruj warunek z progami odpowiadającymi twoim wymaganiom.
4. Zdefiniuj grupę akcji , aby określić, kto odbiera powiadomienia i jak.

Rozważ skonfigurowanie alertów dla tych typowych scenariuszy:

Błędy zadań przekraczają próg: alert, gdy w ciągu godziny wystąpiło więcej niż pięć niepowodzeń zadań.

DatabricksJobs
| where TimeGenerated > ago(1h)
| where Response contains "error" or Response contains "failed"
| summarize FailureCount = count()
| where FailureCount > 5

Nietypowe operacje tabeli: Alert, gdy operacje tworzenia lub usuwania tabeli występują poza godzinami pracy, co może wskazywać na nieautoryzowaną modyfikację danych.

DatabricksUnityCatalog
| where TimeGenerated > ago(1h)
| where hourofday(TimeGenerated) < 6 or hourofday(TimeGenerated) > 20
| where ActionName in~ ("createTable", "deleteTable")
| summarize OperationCount = count() by Identity
| where OperationCount > 5

Skoki tworzenia klastra: alert, gdy zdarzenia tworzenia klastra przekraczają normalne wzorce, co może wskazywać na brak automatyzacji lub nieautoryzowane działanie.

Grupy akcji obsługują wiele metod powiadomień, w tym wiadomości e-mail, wiadomości SMS, aplikacji mobilnej platformy Azure i integracji z narzędziami do zarządzania usługami IT.

Stosowanie analizy dzienników na potrzeby rozwiązywania problemów

Przesyłanie strumieniowe dzienników przekształca rozwiązywanie problemów z reaktywnego badania na systematyczną analizę. Poniżej przedstawiono praktyczne podejścia do typowych scenariuszy:

Diagnozowanie błędów zadań: rozpocznij od tabeli, aby znaleźć przebieg, który DatabricksJobs zakończył się niepowodzeniem. Aby sprawdzić, czy podstawowy klaster miał problemy, odwołaj się do DatabricksClusters. Przejrzyj DatabricksNotebook dzienniki, jeśli zadanie uruchamia kod notatnika.

Badanie problemów z wydajnością: Wykonywanie zapytań dotyczących zdarzeń klastra w celu identyfikowania wzorców skalowania. Poszukaj częstych zdarzeń skalowania automatycznego, które mogą wskazywać na niedowymiarowe konfiguracje początkowe.

Reagowanie na incydenty zabezpieczeń: użyj tabel DatabricksUnityCatalog i DatabricksSecrets aby śledzić dostęp do danych. Skoreluj z SourceIPAddress w celu zidentyfikowania nietypowych lokalizacji dostępu.

Przypisywanie kosztów: połącz dzienniki klastrów i zadań z danymi kosztów platformy Azure, aby zrozumieć, które zespoły lub projekty napędzają zużycie.

Dzięki dziennikom scentralizowanym w Azure Log Analytics można tworzyć widoki środowiska Azure Databricks. Ta widoczność obsługuje zarówno codzienne operacje, jak i długoterminowe decyzje dotyczące planowania.