Ringkasan metrik penyerapan

Didukung di:

Google SecOps menyediakan metrik penyerapan mendetail untuk memberikan visibilitas ke dalam kondisi, volume, dan status pemrosesan pipeline data keamanan Anda. Memantau metrik ini sangat penting untuk memastikan data mengalir dengan benar, mengidentifikasi potensi masalah, dan mengoptimalkan deployment Google SecOps Anda.

Alasan Pentingnya Metrik Penyerapan

  • Pemantauan Kesehatan: Melacak status feed data dan agen pengumpulan Anda.
  • Pemecahan masalah: Diagnosis masalah dengan cepat seperti penurunan data, error penguraian, atau masalah konektivitas.
  • Pelacakan Volume: Pahami jumlah data yang di-ingest dari berbagai sumber, yang berguna untuk perencanaan kapasitas dan pengelolaan biaya.
  • Insight Normalisasi: Pantau rasio keberhasilan log yang diurai ke dalam Unified Data Model (UDM).
  • Pemberitahuan: Konfigurasikan notifikasi untuk anomali dalam aliran data, error, atau perubahan volume.

Tempat Mengakses Metrik Penyerapan

  • Google Cloud Monitoring:

    • Mengintegrasikan metrik Google SecOps ke dalam Cloud Monitoring, sehingga Anda dapat membuat dasbor dan menyiapkan kebijakan pemberitahuan berdasarkan batas untuk metrik seperti jumlah log yang di-ingest, ukuran, dan peristiwa normalisasi.
    • Metrik tersedia di bawah awalan seperti Chronicle Collector dan Chronicle Log Type.
    • Referensi: Menggunakan Cloud Monitoring untuk insight penyerapan

  • Google SecOps Health Hub:

    • Health Hub menyediakan tampilan terpusat dalam platform Google SecOps untuk memantau status sumber data, volume penyerapan, dan kondisi penguraian. Bagian ini menyoroti error dan menyediakan link untuk mempelajari lebih lanjut.
    • Referensi: Menggunakan Hub Kesehatan

  • BigQuery Export:

Kategori dan Kolom Metrik Utama

Metrik penyerapan dikelompokkan berdasarkan berbagai komponen pipeline penyerapan (misalnya, Forwarder, Ingestion API, Normalizer, Feed). Berikut adalah beberapa kolom utama yang akan Anda temui:

  • Metrik Volume:

    • log_count: Jumlah entri log mentah yang diterima atau diproses.
    • log_volume: Total ukuran log yang diterima atau diproses (dalam byte).
    • event_count: Jumlah peristiwa UDM yang dihasilkan setelah penguraian.

  • Metrik Normalisasi:

    • state: Hasil proses normalisasi untuk log (misalnya, parsed, failed_parsing, failed_validation).
    • total_events: Jumlah peristiwa UDM yang berhasil divalidasi.
    • total_error_events: Jumlah peristiwa yang gagal diuraikan atau divalidasi.
    • drop_reason_code: Alasan log atau peristiwa dihapus.

  • Kesehatan & Performa:

    • last_heartbeat_time: Menunjukkan waktu terakhir kali kolektor atau feed aktif.
    • drop_count: Jumlah log yang dihilangkan oleh komponen.
    • cpu_used, memory_used, disk_used: Pemakaian resource untuk komponen lokal seperti Agen Bindplane atau Forwarder lama.
    • latency_count: Metrik yang terkait dengan waktu yang diperlukan antara penyerapan dan normalisasi.

  • Metrik Kuota (Ingestion API):

    • quota_rejected_long_term_log_volume: Volume log ditolak karena melebihi batas kuota.

Memahami Dimensi

Metrik biasanya dikelompokkan menurut dimensi, sehingga Anda dapat memfilter dan mengelompokkan data:

  • component: Bagian pipeline penyerapan yang dirujuk oleh metrik (misalnya, Forwarder, Ingestion API, Normalizer, Out-of-Band Processor).
  • log_type: Jenis sumber log (misalnya, WINDOWS_DNS, CS_EDR).
  • collector_id / feed_id: ID unik untuk instance kolektor atau feed data tertentu.
  • namespace: Untuk mengatur log, sering digunakan dalam penyerapan API.

Catatan: Seperti yang dinyatakan dalam Skema metrik penyerapan, metrik penyerapan gabungan harus diperlakukan sebagai indikator perkiraan volume, bukan jumlah pasti untuk rentang waktu tertentu.

Perbedaan antara volume log mentah dan volume log dasbor

Total ingestion.log_volume yang dilaporkan di dasbor Google SecOps (misalnya, saat membuat kueri ingestion.component = "Ingestion API") dapat berbeda secara signifikan dari total volume log mentah yang disimpan di instance Anda. Antarmuka Google SecOps tidak menampilkan penghitung penyerapan kumulatif sepanjang waktu sejak instance Anda disediakan. Karena setiap alat pelaporan menerapkan periode lihat balik maksimum, Anda tidak dapat menghitung total kumulatif sepanjang waktu setelah instance Anda lebih lama dari batas retensi alat.

Perbedaan ini terjadi karena alasan berikut:

  • Rentang waktu dan batas lihat balik yang berbeda:

    • Penyimpanan log mentah: Mempertahankan data sesuai dengan kebijakan retensi instance yang Anda konfigurasi. Instance Anda mungkin telah menyerap log selama beberapa tahun sejak penyediaan.
    • Dasbor Google SecOps: Menghitung ingestion.log_volume hanya untuk rentang waktu yang dipilih, hingga batas lihat kembali maksimum 365 hari (atau hingga 24 bulan di Cloud Monitoring untuk instance Bring Your Own Project (BYOP)). Jika instance Anda telah menyerap data selama lebih dari 365 hari, kueri dasbor akan melaporkan total yang lebih rendah daripada volume penyerapan historis kumulatif Anda.

  • Berbagai sumber data dan pipeline pengumpulan:

    • Penyimpanan log mentah: Mencatat ukuran byte langsung dari batch log mentah yang diserap dan disimpan di Google SecOps.
    • Dasbor Google SecOps: Buat kueri ingestion.log_volume dari tabel ingestion_metrics, yang mengumpulkan telemetri secara asinkron dengan interval sekitar 5 menit. Karena pipeline telemetri ini dapat mengalami latensi pengumpulan, pengambilan sampel, atau penurunan metrik sementara, kueri dasbor memberikan perkiraan volume, bukan jumlah byte yang tepat.

Tempat menghitung volume penyerapan dan perbedaan nilai

Karena antarmuka Google SecOps tidak menampilkan penghitung penyerapan kumulatif sepanjang waktu dari waktu mulai instance, gunakan lokasi berikut untuk menghitung volume penyerapan bergantung pada rentang waktu yang Anda perlukan:

  • Dasbor Google SecOps (hingga 365 hari):

    • Tempat menghitung: Buka Dashboards & Reports > Dashboards, lalu lihat widget Throughput di dasbor Main atau Data Ingestion and Health (termasuk diagram Ingestion - Throughput (All-Time)). Anda juga dapat menjalankan kueri dasbor kustom untuk sum($event.ingestion.log_volume) yang difilter menurut $event.ingestion.component = "Ingestion API".
    • Rentang waktu maksimum: Kueri dibatasi hingga maksimum 365 hari, bahkan pada diagram Penyerapan - Throughput (Sepanjang Waktu) yang dikurasi.
    • Perbedaan nilai: Dasbor mengkueri tabel ingestion_metrics asinkron, yang mengumpulkan telemetri dengan interval sekitar 5 menit dan dapat mengalami latensi pengumpulan atau penurunan metrik sementara. Nilai bersifat perkiraan dan hanya mencerminkan log yang diproses melalui Ingestion API selama rentang waktu yang dipilih, bukan byte log mentah sepanjang waktu atau volume yang ditagih akhir.

  • Metrics Explorer Cloud Monitoring (hingga 24 bulan untuk instance BYOP):

    • Tempat menghitung: Buka Monitoring > Metrics explorer di konsol Google Cloud , lalu jalankan kueri untuk chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"} (untuk petunjuk langkah demi langkah, lihat Melihat volume penyerapan yang ditagih).
    • Rentang waktu maksimum: Kueri dibatasi hingga maksimum 24 bulan, berdasarkan retensi metrik Cloud Monitoring.
    • Perbedaan nilai: Cloud Monitoring mengkueri jumlah byte penyerapan tingkat kolektor selama periode waktu yang Anda pilih. Nilai mencakup periode lihat kembali yang lebih panjang daripada dasbor Google SecOps (hingga 24 bulan, bukan 365 hari), tetapi tidak mencerminkan total sepanjang waktu jika instance Anda lebih lama dari 24 bulan.

  • BigQuery Export (lebih dari 365 hari, berdasarkan retensi set data Anda):

    • Tempat penghitungan: Buka project BigQuery Anda setelah mengekspor tabel ingestion_metrics, lalu jalankan kueri untuk SUM(log_volume) (atau total_size_bytes di Looker dan BigQuery) yang difilter menurut component = "Ingestion API".
    • Rentang waktu maksimum: Kueri dibatasi pada periode retensi yang dikonfigurasi untuk tabel BigQuery Anda sejak Anda mengaktifkan ekspor, bukan batas dasbor 365 hari.
    • Perbedaan nilai: BigQuery mengkueri tabel ingestion_metrics asinkron yang sama dengan dasbor Google SecOps. Nilai cocok dengan kueri dasbor untuk rentang waktu yang sama, tetapi tetap menjadi indikator telemetri perkiraan, bukan byte log mentah sepanjang waktu atau volume yang ditagih akhir.

Menggunakan Metrik Penyerapan

  • Pemecahan masalah: Filter menurut log_type dan state (misalnya, failed_parsing) di metrik Normalizer untuk menemukan masalah penguraian. Periksa drop_count dan drop_reason_code untuk mengetahui apakah ada kehilangan data.

  • Pemberitahuan: Siapkan pemberitahuan di Cloud Monitoring untuk memantau penurunan tiba-tiba dalam log_count untuk sumber log penting, atau tingkat total_error_events yang tinggi. Untuk memantau volume penyerapan harian Anda terhadap batas kontrak, gunakan metrik Total ingested log size (chronicle.googleapis.com/ingestion/log/bytes_count). Jangan gunakan metrik chronicle.googleapis.com/ingestion/quota_limit untuk pemberitahuan volume harian, karena alasan berikut:

    • Metrik quota_limit mengukur kedekatan dengan batas backend dinamis, bukan volume data yang diserap sebenarnya.
    • Menggunakan quota_limit untuk pemberitahuan volume harian dapat menyebabkan alarm palsu saat nilai minimum backend disesuaikan.

    Untuk mengetahui langkah-langkah menyiapkan kebijakan pemberitahuan volume harian, lihat Menyiapkan contoh kebijakan untuk memantau volume penyerapan harian.

  • Perencanaan Kapasitas: Analisis tren log_volume di BigQuery untuk memperkirakan kebutuhan mendatang.

  • Memvalidasi Konfigurasi: Setelah menyiapkan sumber data baru, periksa metrik untuk mengonfirmasi bahwa data mengalir dan diuraikan seperti yang diharapkan.

Dengan memantau dan memahami metrik penyerapan ini secara rutin, Anda dapat memastikan pipeline data yang andal dan efisien untuk instance Google SecOps Anda.

Perlu bantuan lain? Dapatkan jawaban dari anggota Komunitas dan profesional Google SecOps.