Protokollierung und Überwachung für Databricks-Apps

Effektive Protokollierung und Überwachung helfen Ihnen, Sicherheitsereignisse in Databricks-Apps zu erkennen und darauf zu reagieren. Apps generieren sowohl Protokolle auf Anwendungsebene als auch Plattformüberwachungsprotokolle, die Sie für Diagnose, Leistungsnachverfolgung und Sicherheitsanalysen verwenden können.

Anwendungsprotokolle

Damit Protokolle in der Benutzeroberfläche von Databricks-Apps oder über die URL Ihrer App verfügbar sind, muss Ihre App die Ausgabe an stdout und stderr übergeben.

Auf folgende Weise auf Anwendungsprotokolle zugreifen:

  • App-Benutzeroberfläche: Klicken Sie auf die Registerkarte Protokolle der App, um Standardausgabe und Standardfehler anzuzeigen. Ausführliche Informationen finden Sie unter Details zu einer Databricks-App anzeigen.
  • Direkte URL: Zu Ihrer App-URL hinzufügen /logz. Wenn Ihre App-URL beispielsweise lautet https://my-app-1234567890.my-instance.databricksapps.com, sind Protokolle unter https://my-app-1234567890.my-instance.databricksapps.com/logz verfügbar.

Hinweis

Azure Databricks speichert keine Protokolle, wenn die App heruntergefahren wird. Um eine dauerhafte Protokollierung zu gewährleisten, integrieren Sie externe Protokollierungsdienste, oder schreiben Sie Protokolle in Unity Katalog-Volumes oder -Tabellen.

Logbucheinträge sind nach Quelle gruppiert. Im Logs-Tab verwenden Sie den Quellfilter , um Einträge aus jeder Quelle anzuzeigen oder auszublenden:

  • App: Standardausgabe von Ihrer App.
  • System: Plattform-Nachrichten zum Lebenszyklus der App, wie Bereitstellung und Start.
  • Build: Ausgabe aus der Installation von Abhängigkeiten und dem Erstellen deiner App.
  • HTTP: HTTP-Zugriffsprotokolle für Anfragen, die von Ihrer App bedient werden. Siehe HTTP-Zugriffsprotokolle.

HTTP-Zugriffsprotokolle

Databricks Apps protokolliert für jede Anfrage, die von Ihrer App verarbeitet wird, einen Eintrag im HTTP-Zugriffsprotokoll. Diese Einträge erscheinen unter der HTTP-Quelle im Logs-Tab und in der /logz URL, zusammen mit der Standardausgabe und dem Fehler Ihrer App.

Zugriffsprotokolle erfassen sowohl authentifizierte als auch nicht authentifizierte Anfragen, einschließlich Anfragen, die abgelehnt werden, bevor sie Ihre App erreichen, wie zum Beispiel Anfragen, bei denen die Autorisierung fehlschlägt. Da abgelehnte Anfragen protokolliert werden, können Sie fehlgeschlagene Autorisierungsversuche als Sicherheitsereignisse überprüfen.

Die folgenden Grenzen gelten für das, was protokolliert wird:

  • Um sensible Daten zu schützen, werden Abfragezeichenketten aus dem Anfragepfad entfernt, sodass Token oder andere sensible Werte, die als Abfrageparameter übermittelt werden, nicht protokolliert werden.
  • Um Rauschen zu reduzieren, werden plattforminterne Anfragen wie Authentifizierungsrückrufe und Gesundheitsprüfungen ausgeschlossen.

Bei hoher Last könnte Azure Databricks einige Zugriffsprotokolleinträge entfernen. Wenn Einträge entfernt werden, enthält das Protokoll eine Inline-Nachricht, die die Anzahl der weggelassenen Einträge angibt.

Log Entry Format: Jeder Eintrag verwendet das Apache Combined Log Format. Im Folgenden ein Beispieleintrag:

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"

Jeder Eintrag enthält folgende Felder in der richtigen Reihenfolge. Leere Felder erscheinen als Bindestrich (-).

Feld Example Beschreibung
Client-IP-Adresse 203.0.113.10 Die IP-Adresse des Clients, der die Anforderung gestellt hat.
Benutzer jane.doe@example.com Authentifizierter Nutzer oder - für eine nicht authentifizierte Anfrage.
Zeitstempel [23/Jul/2026:15:04:05 +0000] Datum und Uhrzeit der Anfrage.
Anfragezeile "GET /api/data HTTP/1.1" HTTP-Methode, Anforderungspfad mit entferntem Abfragestring und Protokoll.
Statuscode 200 HTTP-Antwortstatuscode.
Antwortgröße 1234 Größe des Inhalts der Antwort in Byte.
Referer "https://apps.example.com/" Wert des Referer Request-Headers.
Benutzer-Agent "Mozilla/5.0" Wert des User-Agent Request-Headers.

Integration mit externen Logging-Diensten

Verwenden Sie für die dauerhafte Protokollierung und erweiterte Überwachungsfunktionen Folgendes:

  • App-Telemetrie (Beta): Ablaufverfolgungen, Protokolle und Metriken direkt in Unity Catalog-Tabellen erfassen. Siehe Konfigurieren der Telemetrie für Databricks-Apps.

  • Application Performance Monitoring (APM)-Tools: Verwenden Sie New Relic, Datadog oder ähnliche Anwendungsleistungsüberwachungstools, um Protokolle, Metriken und Traces zu sammeln und zu analysieren.

  • Benutzerdefinierte Log-Persistenz: Schreiben Sie regelmäßig Logs in Unity-Catalog-Volumes oder -Tabellen zur Langzeitspeicherung und Analyse.

Anleitungen zur Protokollformatierung und -inhalte finden Sie unter "Empfohlene Protokollierungsmethoden ".

So integrieren Sie externe Überwachungs- und Echtzeitbenachrichtigungssysteme:

  • Formatieren von Protokollen in JSON- oder anderen maschinenparseierbaren Formaten.
  • Protokollieren Sie sicherheitsrelevante Ereignisse mit Kontext:
    • Authentifizierungs- und Autorisierungsereignisse, einschließlich Benutzeridentität und Ergebnis
    • Datenzugriffsdetails, z. B. Katalog-, Schema- und Tabellennamen
    • Sicherheitsbezogene Fehler, z. B. ungültige Token, Berechtigungsverweigerungen und verdächtige Aktivitäten
  • Weiterleiten von Protokollen an externe Systeme. Integration in APM- oder Protokollaggregationstools zur Unterstützung von Echtzeitwarnungen, Reaktion auf Sicherheitsvorfälle, Nutzungs- und Leistungsanalysen sowie Korrelation mit Azure Databricks Systemprotokollen.

Sicherheitsüberlegungen für die Protokollierung

Databricks-Apps wurden mit den folgenden integrierten Steuerelementen entwickelt, um Datenexfiltration zu verhindern:

  • API-only-Zugriff: Apps können nur über öffentliche Azure Databricks-APIs auf Azure Databricks Ressourcen zugreifen. Diese APIs können über Systemtabellenprotokolle überwacht werden.
  • Verschlüsselte Kommunikation: Der gesamte API-Datenverkehr wird mit TLS 1.2 oder höher verschlüsselt, um eine sichere Datenübertragung zu gewährleisten.

Sicherheitsüberwachung mit Systemtabellen

Azure Databricks erfasst Überwachungsprotokolle für app-bezogene Aktivitäten in der Tabelle system.access.audit. Sie können diese Protokolle abfragen, um Benutzeraktionen, App-Konfigurationsänderungen und Sicherheitsereignisse nachzuverfolgen.

Verwenden Sie die folgenden Abfragen, um sicherheitsbezogene Aktivitäten zu überwachen und potenzielle Probleme mit Ihren Apps zu erkennen.

Überwachen von App-Berechtigungsänderungen

Verwenden Sie diese Abfrage, um App-Berechtigungsänderungen zu erkennen:

-- 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

Apps mit Benutzer-API-Zugriffsberechtigungen identifizieren

Verwenden Sie diese Abfrage, um Apps mit konfigurierten Benutzer-API-Bereichen zu finden:

-- 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

Nachverfolgen von Benutzerautorisierungsaktionen

Verwenden Sie diese Abfrage zum Auflisten von App-Aktionen, die mit benutzerautorisierung ausgeführt werden:

-- 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;

Betriebsüberwachung

Verwenden Sie Systemtabellen, um betriebliche Aspekte Ihrer Apps zu überwachen, z. B. Kosten und Ressourcennutzung.

Überwachen der App-Kosten

Überwachen sie die Kosten von Databricks Apps mithilfe der system.billing.usage Tabelle. Verwenden Sie die folgende Abfrage, um genaue Kosteninformationen für Apps pro Tag oder Monat zu erhalten:

-- 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

Databricks Apps unterstützt Nutzungsrichtlinien, um Kosten nachzuverfolgen. Informationen zum Konfigurieren von Verwendungsrichtlinien finden Sie unter Attributverwendung mit serverlosen Verwendungsrichtlinien.

Überwachen von App-Insights

Von Bedeutung

Die Registerkarte "Insights" befindet sich in der Betaversion.

Auf der Registerkarte "Insights " auf der Seite "App-Details" wird die Benutzerbindung und die App-Verfügbarkeit angezeigt.

Viewer-Überwachung

In der Tabelle "Viewers" wird nachverfolgt, welche Benutzer auf Ihre Anwendung zugreifen.

Azure Databricks zeichnet ein Ansichtsereignis auf, wenn ein Benutzer über die App-URL oder über DEN API-Zugriff auf die App zugreift. Es speichert Daten als eindeutig, für jeden Benutzer und jede App. Nachfolgende Besuche durch denselben Benutzer überschreiben ihren vorherigen Datensatz, anstatt eine neue Zeile zu erstellen.

Der letzte angezeigte Zeitstempel folgt einem 30-minütigen OAuth-Sitzungsaktualisierungszyklus. Mehrere Besuche im Sitzungsfenster behalten die anfängliche Besuchszeit bei, aber der erste Zugriff nach Ablauf der Sitzung überschreibt den Zeitstempel mit der neuen Besuchszeit.

Hinweis

In der Betaversion zeigt die letzte angezeigte Zeit nur koordinierte Weltzeit (UTC) an.

Betriebszeit und Gesundheitsstatus

Überwachen Sie die folgenden Gesundheitssignale, um die Verfügbarkeit der App zu überwachen.

  • App-Dienststatus: Gibt an, ob die Azure Databricks Infrastruktur verfügbar ist, die die App unterstützt. Wenn nicht verfügbar, gibt es ein Problem auf Serviceebene mit der Plattform. Wenden Sie sich an den Databricks-Support.
  • App-Verfügbarkeit: Gibt an, ob die spezifische Anwendung Anforderungen erfüllt. Wenn nicht verfügbar, überprüfen Sie, ob Bereitstellungsfehler oder Abstürze in Ihrem Code auftreten.