Pengelogan dan Pemantauan untuk Aplikasi Databricks

Pengelogan dan pemantauan yang efektif membantu Anda mendeteksi dan merespons peristiwa keamanan di Aplikasi Databricks. Aplikasi menghasilkan log tingkat aplikasi dan log audit platform, yang dapat Anda gunakan untuk diagnostik, pelacakan performa, dan analitik keamanan.

Log aplikasi

Untuk membuat log tersedia di UI Aplikasi Databricks atau melalui URL aplikasi Anda, aplikasi Anda harus menulis output ke stdout dan stderr.

Akses log aplikasi dengan cara berikut:

  • Antarmuka Aplikasi: Klik tab Log untuk aplikasi agar melihat output standar dan error. Untuk detailnya, lihat Menampilkan detail untuk aplikasi Databricks.
  • URL Langsung: Tambahkan /logz ke URL aplikasi Anda. Misalnya, jika URL aplikasi Anda adalah https://my-app-1234567890.my-instance.databricksapps.com, log tersedia di https://my-app-1234567890.my-instance.databricksapps.com/logz.

Nota

Azure Databricks tidak mempertahankan log saat komputasi aplikasi dimatikan. Untuk pengelogan persisten, integrasikan dengan layanan pengelogan eksternal atau tulis log ke volume atau tabel Katalog Unity.

Entri log dikelompokkan berdasarkan sumber. Di tab Logs , gunakan filter Source untuk menampilkan atau menyembunyikan entri dari setiap sumber:

  • Aplikasi: Output standar dari aplikasi Anda.
  • Sistem: Pesan platform tentang siklus hidup aplikasi, seperti deployment dan startup.
  • Build: Hasil dari penginstalan dependensi dan pembuatan build aplikasi Anda.
  • HTTP: Log akses HTTP untuk permintaan yang dilayani oleh aplikasi Anda. Lihat log akses HTTP.

Log akses HTTP

Databricks Apps mencatat entri log akses HTTP untuk setiap permintaan yang dilayani oleh aplikasi Anda. Entri-entri ini muncul di bawah sumber HTTP di tab Log dan di /logz URL, bersama dengan output dan error standar aplikasi Anda.

Log akses menangkap baik permintaan yang sudah diautentikasi maupun yang belum terautentikasi, termasuk permintaan yang ditolak sebelum sampai ke aplikasi Anda, seperti permintaan yang gagal otorisasi. Karena permintaan yang ditolak dicatat, Anda dapat mengaudit upaya otorisasi yang gagal sebagai peristiwa keamanan.

Batasan berikut berlaku untuk apa yang dicatat:

  • Untuk melindungi data sensitif, string kueri dihapus dari jalur permintaan, sehingga token atau nilai sensitif lain yang diteruskan sebagai parameter kueri tidak dicatat.
  • Untuk mengurangi gangguan, permintaan internal platform, seperti panggilan balik autentikasi dan pemeriksaan kesehatan, dikecualikan.

Di bawah beban berat, Azure Databricks mungkin menghilangkan beberapa entri log akses. Ketika entri dihapus, log menyertakan pesan sebaris yang melaporkan jumlah entri yang dihapus.

Format entri log: Setiap entri menggunakan Apache Combined Log Format. Berikut adalah contoh entri:

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"

Setiap entri berisi kolom-bidang berikut, secara berurutan. Bidang kosong muncul sebagai tanda hubung (-).

Ladang Example Description
Alamat IP Klien 203.0.113.10 Alamat IP klien yang membuat permintaan.
Pengguna jane.doe@example.com Pengguna terautentikasi, atau - untuk permintaan yang belum terautentikasi.
Timestamp [23/Jul/2026:15:04:05 +0000] Tanggal dan waktu permintaan diterima.
Jalur permintaan "GET /api/data HTTP/1.1" Metode HTTP, jalur permintaan dengan string kueri dihapus, dan protokol.
Kode status 200 kode status respons HTTP.
Ukuran respons 1234 Ukuran isi respons, dalam byte.
Pengarah "https://apps.example.com/" Nilai dari header permintaan Referer.
Agen pengguna "Mozilla/5.0" Nilai dari header permintaan User-Agent.

Mengintegrasikan dengan layanan pengelogan eksternal

Untuk kemampuan pengelogan persisten dan pemantauan tingkat lanjut, gunakan yang berikut ini:

  • Telemetri aplikasi (Beta): Kumpulkan jejak, log, dan metrik langsung ke dalam tabel Unity Catalog. Lihat Mengonfigurasi telemetri untuk Aplikasi Databricks.

  • Alat Application Performance Monitoring (APM): Gunakan alat pemantauan kinerja aplikasi New Relic, Datadog, atau serupa untuk mengumpulkan dan menganalisis log, metrik, dan jejak.

  • Persistensi log kustom: Tulis log secara berkala ke volume atau tabel Unity Catalog untuk penyimpanan dan analisis jangka panjang.

Lihat Praktik pengelogan yang direkomendasikan untuk panduan tentang pemformatan log dan konten.

Untuk berintegrasi dengan pemantauan eksternal dan sistem pemberitahuan real time:

  • Format log dalam JSON atau format yang dapat diurai mesin lainnya.
  • Catat peristiwa yang relevan dengan keamanan dengan konteks:
    • Peristiwa autentikasi dan otorisasi, termasuk identitas dan hasil pengguna
    • Detail akses data, seperti katalog, skema, dan nama tabel
    • Kesalahan terkait keamanan, seperti token yang tidak valid, penolakan izin, dan aktivitas yang mencurigakan
  • Teruskan log ke sistem eksternal. Integrasikan dengan APM atau alat agregasi log untuk mendukung pemberitahuan real time, respons insiden keamanan, analitik penggunaan dan performa, dan korelasi dengan log sistem Azure Databricks.

Pertimbangan keamanan untuk pengelogan

Aplikasi Databricks dirancang dengan kontrol bawaan berikut untuk mencegah eksfiltrasi data:

  • akses khusus API: Aplikasi hanya dapat mengakses sumber daya Azure Databricks melalui API Azure Databricks publik. API ini dapat diaudit melalui log tabel sistem.
  • Komunikasi terenkripsi: Semua lalu lintas API dienkripsi menggunakan TLS 1.2 atau yang lebih tinggi untuk memastikan transfer data yang aman.

Pemantauan keamanan dengan tabel sistem

Azure Databricks mengambil log audit untuk aktivitas terkait aplikasi dalam tabel system.access.audit. Anda dapat mengkueri log ini untuk melacak tindakan pengguna, perubahan konfigurasi aplikasi, dan peristiwa keamanan.

Gunakan kueri berikut untuk memantau aktivitas terkait keamanan dan mendeteksi potensi masalah dengan aplikasi Anda.

Memantau perubahan izin aplikasi

Gunakan kueri ini untuk mendeteksi modifikasi izin aplikasi:

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

Mengidentifikasi aplikasi dengan cakupan API pengguna

Gunakan kueri ini untuk menemukan aplikasi dengan cakupan API pengguna yang dikonfigurasi:

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

Melacak tindakan otorisasi pengguna

Gunakan kueri ini untuk mencantumkan tindakan aplikasi yang dilakukan dengan otorisasi pengguna:

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

Pemantauan operasional

Gunakan tabel sistem untuk memantau aspek operasional aplikasi Anda, seperti biaya dan penggunaan sumber daya.

Memantau biaya aplikasi

Pantau biaya Aplikasi Databricks menggunakan system.billing.usage tabel . Gunakan kueri berikut untuk mendapatkan informasi biaya yang akurat untuk aplikasi per hari atau bulan:

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

Aplikasi Databricks mendukung kebijakan penggunaan untuk membantu melacak biaya. Untuk informasi tentang mengonfigurasi kebijakan penggunaan, lihat Penggunaan atribut dengan kebijakan penggunaan tanpa server.

Pantau wawasan aplikasi

Penting

Tab Insights ada di Beta.

Tab Insight di halaman detail aplikasi memperlihatkan keterlibatan pengguna dan ketersediaan aplikasi.

Pelacakan pemirsa

Tabel Penampil melacak pengguna mana yang mengakses aplikasi Anda.

Azure Databricks merekam peristiwa tampilan saat pengguna mengakses aplikasi melalui URL aplikasi atau melalui akses API. Ini menyimpan data sebagai unik per pengguna, per aplikasi. Kunjungan berikutnya oleh pengguna yang sama akan menimpa catatan mereka sebelumnya, bukan membuat baris baru.

Tanda waktu terakhir yang dilihat mengikuti siklus refresh sesi OAuth 30 menit. Beberapa interaksi dalam jendela sesi mempertahankan waktu interaksi pertama, tetapi akses pertama setelah sesi kedaluwarsa akan mengganti tanda waktu dengan waktu interaksi baru.

Nota

Di Beta, waktu terakhir yang dilihat hanya menunjukkan Waktu Universal Terkoordinasi (UTC).

Status operasional dan kesehatan

Pantau sinyal kesehatan berikut untuk memecahkan masalah ketersediaan aplikasi.

  • App service health: Apakah infrastruktur Azure Databricks yang mendukung aplikasi tersedia. Jika tidak tersedia, terdapat masalah pada tingkat layanan platform. Hubungi Dukungan Databricks.
  • Ketersediaan aplikasi: Apakah aplikasi tertentu melayani permintaan. Jika tidak tersedia, periksa kesalahan penyebaran atau crash dalam kode Anda.