Logboekregistratie en bewaking voor Databricks-apps

Effectieve logboekregistratie en bewaking helpen u bij het detecteren en reageren op beveiligingsevenementen in Databricks-apps. Apps genereren zowel logboeken op toepassingsniveau als platformcontrolelogboeken, die u kunt gebruiken voor diagnostische gegevens, het bijhouden van prestaties en beveiligingsanalyses.

Toepassingslogboeken

Als u logboeken beschikbaar wilt maken in de gebruikersinterface van Databricks Apps of via de URL van uw app, moet uw app uitvoer schrijven naar stdout en stderr.

Toegang tot toepassingslogboeken op de volgende manieren:

Apps UI: Klik op het tabblad Logs voor de app om standaard output en fouten te bekijken. Voor meer informatie, zie Bekijk de details van een Databricks-app.
Directe URL: Toevoegen /logz aan de URL van uw app. Als uw app-URL bijvoorbeeld is https://my-app-1234567890.my-instance.databricksapps.com, zijn logboeken beschikbaar op https://my-app-1234567890.my-instance.databricksapps.com/logz.

Opmerking

Azure Databricks bewaart geen logboeken wanneer de rekenkracht van de app wordt afgesloten. Voor permanente logboekregistratie integreert u met externe logboekregistratieservices of schrijft u logboeken naar Unity Catalog-volumes of -tabellen.

Logboekvermeldingen zijn gegroepeerd op bron. Gebruik in het tabblad Logs het Bronfilter om vermeldingen van elke bron te tonen of te verbergen:

App: Standaard output van je app.
Systeem: Platformberichten over de levenscyclus van de app, zoals deployment en opstart.
Build: Uitvoer van het installeren van afhankelijkheden en het bouwen van je app.
HTTP: HTTP-toegangslogboeken voor verzoeken die door je app worden geleverd. Zie HTTP-toegangslogboeken.

HTTP-toegangslogboeken

Databricks Apps registreert een HTTP-toegangslogboek voor elk verzoek dat door je app wordt uitgevoerd. Deze vermeldingen verschijnen onder de HTTP-bron in het tabblad Logs en op de /logz URL, samen met de standaard output en foutmelding van je app.

Toegangslogboeken registreren zowel geauthenticeerde als niet-geauthenticeerde verzoeken, inclusief verzoeken die worden afgewezen voordat ze je app bereiken, zoals verzoeken die de autorisatie niet doorstaan. Omdat afgewezen verzoeken worden geregistreerd, kun je mislukte autorisatiepogingen als beveiligingsgebeurtenissen controleren.

De volgende limieten gelden voor wat er wordt geregistreerd:

Om gevoelige gegevens te beschermen, worden querystrings verwijderd uit het verzoekpad, zodat tokens of andere gevoelige waarden die als queryparameters worden doorgegeven, niet worden gelogd.
Om ruis te verminderen, worden platforminterne verzoeken, zoals authenticatie-callbacks en gezondheidscontroles, uitgesloten.

Onder zware belasting kan Azure Databricks enkele toegangslogboekvermeldingen laten vallen. Wanneer entries worden verwijderd, bevat het logboek een inline bericht dat het aantal verwijderde vermeldingen rapporteert.

Logboekindelingsformaat: Elke vermelding gebruikt het Apache Combined Log Format. Hieronder volgt een voorbeeldartikel:

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"

Elke vermelding bevat de volgende velden, in volgorde. Lege velden verschijnen als een koppelteken (-).

Veld	Example	Description
Client-IP-adres	`203.0.113.10`	IP-adres van de client die de aanvraag heeft ingediend.
Gebruiker	`jane.doe@example.com`	Geauthenticeerde gebruiker, of `-` voor een niet-geauthenticeerd verzoek.
Tijdstempel	`[23/Jul/2026:15:04:05 +0000]`	Datum en tijd van ontvangst.
Verzoeklijn	`"GET /api/data HTTP/1.1"`	HTTP-methode, verzoekpad met verwijderde querystring en protocol.
Statuscode	`200`	HTTP-antwoordstatuscode.
Antwoordgrootte	`1234`	Grootte van het responslichaam, in bytes.
Verwijzende functie	`"https://apps.example.com/"`	Waarde van de `Referer` aanvraagheader.
Gebruikersagent	`"Mozilla/5.0"`	Waarde van de `User-Agent` aanvraagheader.

Integreren met externe logboekregistratieservices

Gebruik het volgende voor permanente logboekregistratie en geavanceerde bewakingsmogelijkheden:

App-telemetrie (Bèta): Verzamel sporen, logs en metrics direct naar Unity Catalog-tabellen. Zie Telemetrie configureren voor Databricks-apps.
Application Performance Monitoring (APM) tools: Gebruik New Relic, Datadog of vergelijkbare applicatieprestatiemonitoringtools om logs, metrics en traces te verzamelen en te analyseren.
Aangepaste logpersistentie: Schrijf periodiek logs naar Unity Catalog-volumes of tabellen voor langdurige opslag en analyse.

Zie aanbevolen procedures voor logboekregistratie voor hulp bij het opmaken en inhoud van logboeken.

Aanbevolen procedures voor logboekregistratie

Integreren met externe bewakings- en realtime waarschuwingssystemen:

Maak logboeken op in JSON of andere machine-parseerbare indelingen.
Logboekbeveiligingsgebeurtenissen met context:
- Verificatie- en autorisatie-gebeurtenissen, waaronder gebruikersidentiteit en resultaat
- Gegevenstoegangsdetails, zoals catalogus-, schema- en tabelnamen
- Beveiligingsfouten, zoals ongeldige tokens, weigeringen van machtigingen en verdachte activiteiten
Logboeken doorsturen naar externe systemen. Integreer met APM of hulpprogramma's voor logboekaggregatie ter ondersteuning van realtime waarschuwingen, reactie op beveiligingsincidenten, gebruiks- en prestatieanalyses en correlatie met Azure Databricks systeemlogboeken.

Beveiligingsoverwegingen voor logboekregistratie

Databricks-apps zijn ontworpen met de volgende ingebouwde besturingselementen om gegevensexfiltratie te voorkomen:

API-toegang: Apps hebben alleen toegang tot Azure Databricks resources via openbare Azure Databricks API's. Deze API's kunnen worden gecontroleerd via systeemtabellogboeken.
Versleutelde communicatie: alle API-verkeer wordt versleuteld met TLS 1.2 of hoger om beveiligde gegevensoverdracht te garanderen.

Beveiligingsbewaking met systeemtabellen

Azure Databricks legt auditlogboeken vast voor app-gerelateerde activiteiten in de tabel system.access.audit. U kunt deze logboeken opvragen om gebruikersacties, wijzigingen in app-configuratie en beveiligingsevenementen bij te houden.

Gebruik de volgende query's om beveiligingsgerelateerde activiteiten te bewaken en potentiële problemen met uw apps te detecteren.

App-machtigingswijzigingen bewaken

Gebruik deze query om app-machtigingswijzigingen te detecteren:

-- 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 identificeren met API-toegangstags van gebruikers

Gebruik deze query om apps te vinden waarvoor gebruikers-API-bereiken zijn geconfigureerd:

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

Acties voor gebruikersautorisatie bijhouden

Gebruik deze query om app-acties weer te geven die zijn uitgevoerd met gebruikersautorisatie:

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

Operationele bewaking

Gebruik systeemtabellen om operationele aspecten van uw apps te bewaken, zoals kosten- en resourcegebruik.

App-uitgaven monitoren

Kosten voor Databricks-apps bewaken met behulp van de system.billing.usage tabel. Gebruik de volgende query om nauwkeurige kosteninformatie voor apps per dag of maand op te halen:

-- 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 ondersteunt gebruiksbeleid om kosten bij te houden. Zie Kenmerkgebruik met serverloze gebruiksbeleidsregels voor meer informatie over het configureren van gebruiksbeleid.

App-inzichten monitoren

Belangrijk

Het tabblad Inzichten bevindt zich in de bètaversie.

Op het tabblad Inzichten op de pagina met app-details ziet u de betrokkenheid van gebruikers en de beschikbaarheid van apps.

Viewer bijhouden

In de tabel Viewers wordt bijgehouden welke gebruikers toegang hebben tot uw toepassing.

Azure Databricks registreert een weergave-gebeurtenis wanneer een gebruiker de app opent via de APP-URL of via API-toegang. Er worden gegevens opgeslagen als uniek per gebruiker, per app. Volgende bezoeken door dezelfde gebruiker overschrijven hun vorige record in plaats van een nieuwe rij te maken.

De laatst bekeken tijdstempel volgt een vernieuwingscyclus van 30 minuten voor OAuth-sessies. Meerdere bezoeken in het sessievenster behouden de eerste bezoektijd, maar de eerste toegang nadat de sessie is verlopen, overschrijft de tijdstempel met de nieuwe bezoektijd.