Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 lautethttps://my-app-1234567890.my-instance.databricksapps.com, sind Protokolle unterhttps://my-app-1234567890.my-instance.databricksapps.com/logzverfü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 ".
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.