Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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
/logzke URL aplikasi Anda. Misalnya, jika URL aplikasi Anda adalahhttps://my-app-1234567890.my-instance.databricksapps.com, log tersedia dihttps://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.
Praktik pencatatan yang direkomendasikan
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.