Rejestrowanie i monitorowanie aplikacji usługi Databricks

Efektywne rejestrowanie i monitorowanie pomaga wykrywać zdarzenia zabezpieczeń i reagować na nie w usłudze Databricks Apps. Aplikacje generują dzienniki na poziomie aplikacji i dzienniki inspekcji platformy, których można użyć do diagnostyki, śledzenia wydajności i analizy zabezpieczeń.

Dzienniki aplikacji

Aby udostępnić dzienniki w interfejsie użytkownika aplikacji Databricks lub za pośrednictwem adresu URL aplikacji, Twoja aplikacja musi zapisywać dane wyjściowe w stdout i stderr.

Uzyskaj dostęp do dzienników aplikacji na następujące sposoby:

Interfejs aplikacji: Kliknij zakładkę Logs , aby zobaczyć standardowe wyniki i błędy. Aby uzyskać szczegółowe informacje, zobacz Wyświetl szczegóły dotyczące aplikacji Databricks.
Bezpośredni adres URL: dołącz /logz do adresu URL aplikacji. Jeśli na przykład adres URL aplikacji to https://my-app-1234567890.my-instance.databricksapps.com, dzienniki są dostępne pod adresem https://my-app-1234567890.my-instance.databricksapps.com/logz.

Uwaga / Notatka

Azure Databricks nie utrwala dzienników po zamknięciu obliczeń aplikacji. W przypadku długoterminowego rejestrowania należy zintegrować się z zewnętrznymi usługami rejestrowania lub zapisywać dzienniki w sekcjach lub tabelach katalogowych Unity Catalog.

Wpisy w dzienniku są grupowane według źródła. W zakładce Logi użyj filtra Źródło , aby pokazać lub ukryć wpisy z każdego źródła:

Aplikacja: Standardowe wyjście z Twojej aplikacji.
System: Komunikaty platformy dotyczące cyklu życia aplikacji, takie jak wdrożenie i uruchomienie.
Build: Dane wyjściowe z instalowania zależności i kompilowania aplikacji.
HTTP: logi dostępu HTTP do żądań obsługiwanych przez Twoją aplikację. Zobacz logi dostępu HTTP.

Logi dostępu HTTP

Databricks Apps rejestruje wpis w dzienniku dostępu HTTP dla każdego żądania obsługiwanego przez Twoją aplikację. Te wpisy pojawiają się pod źródłem HTTP na karcie Logi oraz pod adresem URL /logz, obok standardowego wyjścia aplikacji i standardowego wyjścia błędów.

Logi dostępu rejestrują zarówno zweryfikowane, jak i nieuwierzytelnione żądania, w tym te odrzucane zanim dotrą do Twojej aplikacji, na przykład te, które nie przechodzą autoryzacji. Ponieważ odrzucone żądania są rejestrowane, możesz audytować nieudane próby autoryzacji jako zdarzenia bezpieczeństwa.

Następujące ograniczenia dotyczą tego, co jest rejestrowane:

Aby chronić dane wrażliwe, ciągi zapytań są usuwane ze ścieżki żądania, więc tokeny lub inne wrażliwe wartości przekazywane jako parametry zapytania nie są rejestrowane.
Aby zmniejszyć szum, wyłączone są żądania wewnętrzne platformy, takie jak oddzwonienia uwierzytelniające i kontrole stanu technicznego.

Pod dużym obciążeniem Azure Databricks może zrezygnować z niektórych wpisów w logach dostępu. Po odrzuceniu wpisów dziennik zawiera komunikat w linii raportujący liczbę odrzuconych wpisów.

Format wpisów dziennika: Każdy wpis używa formatu Apache Combined Log Format. Poniżej znajduje się przykładowy wpis:

203.0.113.10 - jane.doe@example.com [23/Jul/2026:15:04:05 +0000] "GET /api/data HTTP/1.1" 200 1234 "https://apps.example.com/" "Mozilla/5.0"

Każdy wpis zawiera następujące pola, w kolejności. Puste pola pojawiają się jako łącznik (-).

Pole	Example	Description
Adres IP klienta	`203.0.113.10`	Adres IP klienta, który złożył żądanie.
Użytkownik	`jane.doe@example.com`	Uwierzytelniony użytkownik, lub `-` w przypadku nieuwierzytelnionego żądania.
Sygnatura czasowa	`[23/Jul/2026:15:04:05 +0000]`	Data i godzina otrzymania prośby.
Linia żądania	`"GET /api/data HTTP/1.1"`	Metoda HTTP, ścieżka żądań z usuniętym ciągiem zapytań oraz protokół.
Kod stanu	`200`	Kod stanu odpowiedzi HTTP.
Rozmiar odpowiedzi	`1234`	Rozmiar korpusu odpowiedzi, w bajtach.
Odsyłacz	`"https://apps.example.com/"`	Wartość nagłówka `Referer` żądania.
Agent użytkownika	`"Mozilla/5.0"`	Wartość nagłówka `User-Agent` żądania.

Integracja z zewnętrznymi usługami logowania

W przypadku trwałych funkcji rejestrowania i zaawansowanego monitorowania należy użyć następujących elementów:

Telemetria aplikacji (Beta): Zbieraj ślady, logi i metryki bezpośrednio do tabel katalogu Unity. Zobacz Konfigurowanie telemetrii dla aplikacji usługi Databricks.
Narzędzia do monitorowania wydajności aplikacji (APM): Używaj narzędzi do monitorowania wydajności aplikacji New Relic, Datadog lub podobnych narzędzi do zbierania i analizy logów, metryk i śladów.
Niestandardowa trwałość logów: Okresowo zapisuj logi do woluminów lub tabel Unity Catalog do długoterminowego przechowywania i analizy.

Zobacz Zalecane praktyki rejestrowania , aby uzyskać wskazówki dotyczące formatowania dzienników i zawartości.

Zalecane praktyki logowania

Aby zintegrować z zewnętrznymi systemami monitorowania i alertów w czasie rzeczywistym:

Formatuj dzienniki w formacie JSON lub w innych formatach możliwych do analizowania maszyn.
Rejestruj zdarzenia związane z zabezpieczeniami z kontekstem:
- Zdarzenia uwierzytelniania i autoryzacji, w tym tożsamość użytkownika i wynik
- Szczegóły dostępu do danych, takie jak wykaz, schemat i nazwy tabel
- Błędy związane z zabezpieczeniami, takie jak nieprawidłowe tokeny, odmowa uprawnień i podejrzane działania
Przekazywanie dzienników do systemów zewnętrznych. Integracja z narzędziami agregacji APM lub dzienników w celu obsługi alertów w czasie rzeczywistym, reagowania na zdarzenia zabezpieczeń, analizy użycia i wydajności oraz korelacji z dziennikami systemu Azure Databricks.

Zagadnienia dotyczące zabezpieczeń w logowaniu

Aplikacje usługi Databricks zostały zaprojektowane z następującymi wbudowanymi kontrolkami, aby zapobiec eksfiltracji danych:

Dostęp tylko przez API : Aplikacje mogą uzyskiwać dostęp do zasobów Azure Databricks jedynie za pośrednictwem publicznych interfejsów API Azure Databricks. Te interfejsy API są audytowalne przez logi systemowych tabel.
Zaszyfrowana komunikacja: cały ruch interfejsu API jest szyfrowany przy użyciu protokołu TLS 1.2 lub nowszego w celu zapewnienia bezpiecznego transferu danych.

Monitorowanie zabezpieczeń przy użyciu tabel systemowych

Azure Databricks przechwytuje logi audytowe dla aktywności związanych z aplikacją w tabeli system.access.audit. Możesz wykonywać zapytania dotyczące tych dzienników w celu śledzenia akcji użytkownika, zmian konfiguracji aplikacji i zdarzeń zabezpieczeń.

Użyj następujących zapytań, aby monitorować działania związane z zabezpieczeniami i wykrywać potencjalne problemy z aplikacjami.

Monitorowanie zmian uprawnień aplikacji

Użyj tego zapytania, aby wykryć modyfikacje uprawnień aplikacji:

-- Monitor all app permission modifications in the last 30 days
WITH permission_changes AS (
  SELECT
    event_date,
    workspace_id,
    request_params.request_object_id AS app_name,
    user_identity.email AS modified_by,
    explode(from_json(
      request_params.access_control_list,
      'array<struct<user_name:string,group_name:string,permission_level:string>>'
    )) AS permission
  FROM system.access.audit
  WHERE action_name = 'changeAppsAcl'
    AND event_date >= current_date() - 30
)
SELECT
  event_date,
  app_name,
  modified_by,
  permission.user_name,
  permission.group_name,
  permission.permission_level
FROM permission_changes
ORDER BY event_date DESC

Identyfikowanie aplikacji z uprawnieniami interfejsu API użytkownika

Użyj tego zapytania, aby znaleźć aplikacje ze skonfigurowanymi zakresami interfejsu API użytkownika:

-- Find apps created or updated in the last 30 days with user API scopes configured
SELECT
  event_date,
  get_json_object(request_params.app, '$.name') AS app_name,
  user_identity.email AS creator_email,
  get_json_object(request_params.app, '$.user_api_scopes') AS user_api_scopes
FROM system.access.audit
WHERE
  action_name IN ('createApp', 'updateApp')
  AND get_json_object(request_params.app, '$.user_api_scopes') IS NOT NULL
  AND event_date >= current_date() - INTERVAL 30 DAYS

Śledzenie akcji autoryzacji użytkownika

Użyj tego zapytania, aby wyświetlić listę akcji aplikacji wykonywanych z autoryzacją użytkownika:

-- List app actions performed on behalf of users in the last 30 days
WITH obo_events AS (
  SELECT
    event_date,
    workspace_id,
    audit_level,
    identity_metadata.acting_resource AS app_id,   -- OAuth App ID or name
    user_identity.email AS user_email,             -- Logged-in user
    service_name,
    action_name
  FROM system.access.audit
  WHERE event_date >= current_date() - 30
    AND identity_metadata.acting_resource IS NOT NULL
)
SELECT
  event_date,
  app_id,
  user_email,
  service_name,
  action_name,
  audit_level,
  COUNT(*) AS event_count
FROM obo_events
GROUP BY
  event_date, app_id, user_email, service_name, action_name, audit_level
ORDER BY event_date DESC;

Monitorowanie operacyjne

Tabele systemowe umożliwiają monitorowanie aspektów operacyjnych aplikacji, takich jak koszty i użycie zasobów.

Monitorowanie kosztów aplikacji

Monitorowanie kosztów usługi Databricks Apps przy użyciu system.billing.usage tabeli . Użyj następującego zapytania, aby uzyskać dokładne informacje o kosztach aplikacji dziennie lub miesiąca:

-- Get Databricks Apps cost by app per day for the last 30 days
SELECT
  us.usage_date,
  us.usage_metadata.app_id,
  us.usage_metadata.app_name,
  SUM(us.usage_quantity) AS dbus,
  SUM(us.usage_quantity * lp.pricing.effective_list.default) AS dollars
FROM
  system.billing.usage us
LEFT JOIN system.billing.list_prices lp
  ON lp.sku_name = us.sku_name
  AND us.usage_start_time BETWEEN lp.price_start_time AND COALESCE(lp.price_end_time, NOW())
WHERE
  billing_origin_product = 'APPS'
  AND us.usage_unit = 'DBU'
  AND us.usage_date >= DATE_SUB(NOW(), 30)
GROUP BY ALL

Usługa Databricks Apps obsługuje zasady użycia, aby ułatwić śledzenie kosztów. Aby uzyskać informacje na temat konfigurowania zasad użycia, zobacz Atrybut użycia z zasadami użycia bezserwerowego.

Monitorowanie szczegółowych informacji o aplikacji

Ważne

Karta Wglądy jest w wersji beta.

Karta Szczegółowe informacje na stronie szczegółów aplikacji pokazuje zaangażowanie użytkowników i dostępność aplikacji.

Śledzenie widzów

Tabela Odbiorcy śledzi, którzy użytkownicy uzyskują dostęp do Twojej aplikacji.

Azure Databricks rejestruje zdarzenie widoku, gdy użytkownik uzyskuje dostęp do aplikacji za pośrednictwem adresu URL aplikacji lub dostępu do interfejsu API. Przechowuje dane jako unikatowe dla użytkownika i dla aplikacji. Kolejne wizyty tego samego użytkownika zastępują poprzedni rekord, zamiast tworzyć nowy wiersz.

Ostatnio wyświetlany znacznik czasu jest zgodny z 30-minutowym cyklem odświeżania sesji OAuth. Wiele wizyt w okresie sesji zachowuje początkowy czas wizyty, ale pierwszy dostęp po wygaśnięciu sesji ponownie zastępuje znacznik czasu nową godziną wizyty.