Men-deploy agen Bindplane untuk pengumpulan

Didukung di:

Dokumen ini menjelaskan Bindplane untuk Google Security Operations.

Bindplane adalah pipeline telemetri, yang dapat mengumpulkan, menyaring, dan mengekspor log dari sumber mana pun ke Google SecOps.

Bindplane menawarkan dua edisi khusus untuk Google.

Bindplane mencakup komponen utama berikut:

  • Kolektor Bindplane. Agen open source, berdasarkan Collector OpenTelemetry (OTel). Agen ini mengumpulkan log dari berbagai sumber, termasuk log peristiwa Microsoft Windows, dan mengirimkannya ke Google SecOps. Anda dapat menginstal kolektor di infrastruktur lokal atau di cloud.

    Komponen ini juga dapat disebut sebagai Bindplane Distribution for OpenTelemetry (BDOT) Collector, bindplane agent, collection agent, collector, atau agent.

  • Server Bindplane. Platform yang komprehensif dan terpadu untuk mengelola deployment kolektor OTel Anda. Deployment ini dapat berada di Google SecOps dan Google Cloud. Banyak pelanggan Google SecOps menggunakan Bindplane Server, tetapi penggunaannya bersifat opsional. Bindplane Server dapat berjalan secara lokal atau di cloud Bindplane. Untuk mengetahui informasi selengkapnya tentang server, lihat Server Bindplane.

    Komponen ini juga dapat disebut sebagai konsol Bindplane Observability Pipeline (OP) Management atau konsol Bindplane Management.

Edisi Google Bindplane

Bindplane menawarkan dua edisi khusus untuk Google: Bindplane (Google Edition) dan Bindplane Enterprise (Google Edition).

Bindplane (Google Edition)

Bindplane (Google Edition) disediakan untuk semua pelanggan Google SecOps.

Anda dapat menggunakan Bindplane (Google Edition) secara mandiri di cloud Bindplane.

Untuk mulai menginstal dan menghosting sendiri Bindplane (Google Edition) atau membuat kunci untuk server Bindplane lokal, lihat Bindplane (Google Edition).

Bindplane Enterprise (Google Edition)—untuk pelanggan Google SecOps Enterprise Plus dan Google Unified Security (GUS)

Bindplane Enterprise (Google Edition) disertakan untuk pelanggan Google SecOps Enterprise Plus dan GUS.

Bindplane Enterprise (Google Edition) direkomendasikan untuk deployment skala besar.

Download kunci lisensi Bindplane Enterprise Anda

Pelanggan Google SecOps Enterprise Plus dan GUS dapat mendownload kunci lisensi Bindplane Enterprise (Google Edition) langsung dari konsol platform:

  1. Di konsol Google SecOps, buka Settings > Pengelolaan Data > Collection Agents.
  2. Di kartu Bindplane License, klik Download License untuk menyimpan file kunci lisensi Anda.
  3. Terapkan kunci lisensi yang didownload ke penginstalan Bindplane Server Anda. Untuk mengetahui detailnya, lihat Menerapkan lisensi Bindplane.

Bindplane edisi Google—perbedaan

Tabel berikut mencantumkan perbedaan dalam edisi Bindplane Google:

Topik/fitur Bindplane (Google Edition) Bindplane Enterprise (Google Edition)
Biaya Disertakan tanpa biaya tambahan untuk semua pelanggan Google SecOps Disertakan tanpa biaya untuk pelanggan Google SecOps Enterprise Plus
Perutean/Tujuan Khusus Google, termasuk Google SecOps, Cloud Logging, BigQuery, dan Cloud Storage melalui Google SecOps Google, termasuk pemilihan rute ke tujuan non-Google selama 12 bulan untuk migrasi SIEM
Pemfilteran Filter dasar dengan ekspresi reguler Pemroses pemfilteran lanjutan (misalnya, filter menurut kondisi, kolom, tingkat keparahan, dan sebagainya), pengurangan data, pengambilan sampel log, penghapusan duplikat
Penyamaran T/A Penyamaran PII
Transformasi Menambahkan kolom, memindahkan kolom, mengurai data (KV, JSON, CSV, XML, stempel waktu, mengurai berdasarkan ekspresi reguler), mengganti nama kolom, pemisah peristiwa Mencakup semua kemampuan yang didukung di Bindplane (Google Edition) ditambah hapus kolom, hapus nilai kosong, gabungkan
Fitur umum tingkat platform Gateway (menggabungkan data dari kolektor), kolektor Bindplane, server Bindplane (lapisan pengelolaan Bindplane) yang dihosting secara lokal atau di cloud, semua sumber, pemantauan silent-host melalui pemroses Google SecOps, antrean persisten, pengayaan telemetri, ketersediaan tinggi, RBAC, kedua API penyerapan Google SecOps didukung, obfuscation kredensial, pengelolaan fleet lanjutan termasuk pengelompokan kolektor, penetapan jenis log dinamis Semua kemampuan yang didukung di Bindplane (Google Edition)

Arsitektur kolektor Bindplane

Bindplane menggunakan BDOT Collector—yang secara umum disebut sebagai kolektor—untuk menstandarkan pengelolaan telemetri dengan Open Agent Management Protocol (OpAMP). Anda juga dapat membuat dan mengelola distribusi OpenTelemetry Collector kustom dengan Bindplane.

Kolektor dapat berjalan di Linux atau Docker sebagai server web ringan tanpa dependensi eksternal.

Untuk mempelajari lebih lanjut arsitektur deployment kolektor OpenTelemetry Bindplane, lihat Deployment.

Bagian berikut menjelaskan opsi arsitektur yang tersedia.

Kolektor mengirim log ke kolektor yang bertindak sebagai gateway

Untuk deployment berskala besar, sebaiknya gunakan kolektor yang bertindak sebagai gateway. Gateway ini menerima telemetri dari kolektor lain melalui jaringan, secara opsional melakukan pemrosesan tambahan, dan mengarahkan data ke Google SecOps.

Kolektor yang bertindak sebagai gateway menggunakan biner yang sama dengan semua kolektor lainnya.

Diagram berikut menunjukkan kolektor yang mengirim log ke kolektor yang bertindak sebagai gateway:

Kolektor mengirim log ke kolektor yang bertindak sebagai gateway

Kolektor mengirim log langsung ke API penyerapan Google SecOps

Diagram berikut menunjukkan kolektor yang mengirim log langsung ke API penyerapan Google SecOps:

Kolektor mengirim log langsung ke API penyerapan Google SecOps

Kolektor mengirim log langsung ke Cloud Logging

Diagram berikut menunjukkan kolektor yang mengirim log langsung ke Cloud Logging:

Kolektor mengirim log langsung ke Cloud Logging

Kolektor mengirim log ke beberapa tujuan

Diagram berikut menunjukkan kolektor yang mengirim log ke beberapa tujuan:

Collector mengirimkan log ke beberapa tujuan

Server Bindplane

Server Bindplane menawarkan fitur utama berikut:

  • Pengelolaan terpusat. Server ini memungkinkan Anda mengelola semua deployment kolektor OTel di seluruh Google Cloud. Anda dapat melihat status setiap deployment dan melakukan tugas pengelolaan umum seperti memulai, menghentikan, dan memulai ulang kolektor.
  • Pemantauan real-time. Server ini menyediakan pemantauan real-time untuk deployment kolektor OTel Anda. Anda dapat melacak metrik seperti penggunaan CPU, penggunaan memori, dan throughput. Anda juga dapat melihat log dan trace untuk memecahkan masalah.
  • Pemberitahuan dan notifikasi. Server ini memungkinkan Anda menyiapkan pemberitahuan dan notifikasi untuk peristiwa penting, seperti saat kolektor tidak berfungsi atau saat batas metrik terlampaui.
  • Pengelolaan konfigurasi. Server ini memungkinkan Anda mengelola konfigurasi kolektor OTel secara terpusat. Anda dapat mengedit file konfigurasi, menetapkan variabel lingkungan, dan menerapkan kebijakan keamanan ke semua deployment Anda.
  • Integrasi dengan Google Cloud. Anda dapat membuat dan mengelola deployment kolektor OTel di Google Cloud dan menggunakan server untuk mengakses resource Google Cloud Anda.

Bindplane menawarkan opsi deployment cloud dan lokal. Untuk mengetahui informasi selengkapnya, lihat Menggunakan server Bindplane.

Persyaratan dan rekomendasi teknis

Bagian ini menjelaskan persyaratan dan rekomendasi teknis untuk menginstal dan menjalankan Bindplane dengan Google SecOps.

Persyaratan bandwidth

Bindplane mengelola koneksi jaringan untuk hal berikut:

  • Pengelolaan kolektor
  • Pengukuran throughput kolektor
  • Antarmuka pengguna web dan command line

Persyaratan konektivitas

Bindplane memproses port 3001 secara default. Port ini dapat dikonfigurasi.

Port Bindplane digunakan untuk:

  • Perintah dan kontrol kolektor menggunakan OpAMP (WebSocket)
  • Permintaan pengukuran throughput kolektor (permintaan HTTP POST)
  • Pengguna browser dan CLI (HTTP dan WebSocket)

Kolektor harus dapat memulai koneksi ke Bindplane untuk OpAMP (WebSocket) dan pengukuran throughput (HTTP).

Bindplane tidak pernah memulai koneksi ke kolektor. Anda dapat mengonfigurasi firewall untuk mencegah Bindplane menjangkau jaringan kolektor; namun, jaringan kolektor harus dapat menjangkau Bindplane di port yang dikonfigurasi.

Persyaratan teknis umum kolektor Bindplane

Untuk mempelajari persyaratan teknis umum untuk kolektor Bindplane, lihat referensi berikut:

Persyaratan resource kolektor

Persyaratan resource Bindplane berbeda-beda berdasarkan jumlah kolektor terkelola. Seiring bertambahnya jumlah kolektor terkelola, konsumsi CPU, memori, throughput/IOPS disk, dan jaringan juga meningkat.

Gunakan tabel berikut untuk menentukan ukuran CPU, memori, dan kapasitas penyimpanan:

Jumlah kolektor Node Bindplane Fault-tolerance Core CPU Memori Database
1-100 1 T/A 2 4 GB bbolt
100-25.000 1 T/A 4 16 GB postgres
1-60.000 3 1 2 8 GB postgres
60.001-125.000 5 1 2 8 GB postgres
125.001-250.000 10 2 2 8 GB postgres

Merencanakan penginstalan dan deployment Anda

Bagian berikut mencakup rekomendasi dan praktik terbaik, yang harus Anda pertimbangkan saat merencanakan deployment Bindplane.

Mempertimbangkan penskalaan dan fault tolerance

Penskalaan horizontal lebih disukai karena memberikan fault tolerance dan dapat menghilangkan bottleneck pengekspor.

Saat menjalankan kolektor Bindplane dalam mode gateway, sebaiknya pasangkan dengan load balancer untuk memberikan fault tolerance dan penskalaan horizontal.

Menghitung jumlah kolektor yang Anda butuhkan

Saat menghitung jumlah kolektor yang diperlukan untuk workload Anda, pertimbangkan throughput atau rasio log yang diantisipasi, dan gunakan tabel berikut. Tabel ini mengasumsikan bahwa setiap kolektor memiliki empat core CPU dan memori 16 GB. Tabel ini tidak menyertakan penghitungan dengan pemroses; saat pemroses ditambahkan, persyaratan komputasi akan meningkat.

Throughput telemetri Log/detik Kolektor
5 GB/m 250.000 2
10 GB/m 500.000 3
20 GB/m 1.000.000 5
100 GB/bln 5.000.000 25

Menyediakan fleet kolektor secara berlebihan untuk fault tolerance

Menyediakan fleet kolektor secara berlebihan untuk memastikan fault tolerance. Jika satu atau beberapa sistem kolektor gagal atau dinonaktifkan untuk pemeliharaan, kolektor yang tersisa harus memiliki kapasitas yang cukup untuk mengelola throughput telemetri.

Jika Anda menggunakan jumlah kolektor yang tetap, Anda dapat menerapkan penskalaan vertikal CPU dan memorinya untuk meningkatkan throughput.

Mengurangi beban pemrosesan

Umumnya, Anda ingin kolektor melakukan pekerjaan sesedikit mungkin. Jika Anda memiliki persyaratan pemrosesan yang berat, sebaiknya pindahkan pemrosesan tersebut ke fleet gateway collector. Misalnya, daripada memfilter telemetri dengan operasi ekspresi reguler yang mahal, Anda dapat meminta kolektor gateway melakukan tugas tersebut. Umumnya, kolektor gateway berjalan di sistem khusus. Hal ini membenarkan overhead pemrosesan karena tidak menggunakan daya komputasi layanan lain yang berjalan di sistem yang sama, tidak seperti kolektor non-gateway yang mungkin berjalan di server database.

Praktik terbaik untuk mode gateway

Saat menjalankan kolektor Bindplane dalam mode gateway, sebaiknya rencanakan deployment Anda dengan praktik terbaik berikut:

  • Tempatkan setidaknya dua kolektor di belakang load balancer.
  • Setiap kolektor harus memiliki minimal dua core.
  • Setiap kolektor harus memiliki memori minimal 8 GB.
  • Setiap kolektor harus memiliki ruang yang dapat digunakan sebesar 60 GB untuk antrean persisten.

Menggunakan load balancer jika diperlukan

Load balancer diperlukan saat Anda mengoperasikan Bindplane dalam mode ketersediaan tinggi.

Saat Anda menjalankan kolektor Bindplane dalam mode gateway, gunakan load balancer untuk meningkatkan performa dan redundansi. Load balancing juga memungkinkan penskalaan horizontal fleet gateway Anda dan kemampuan untuk bertahan dari kegagalan tanpa menyebabkan pemadaman layanan.

Kolektor Bindplane dapat berfungsi dengan berbagai load balancer.

Untuk mempelajari lebih lanjut, lihat Konfigurasi Load Balancer.

Port dan protokol load balancing

Bindplane memproses port 3001 secara default.

Untuk mendukung berbagai penerima berbasis jaringan di OpenTelemetry, load balancer harus mendukung:

  • Protokol transport TCP/UDP
  • Protokol aplikasi HTTP dan gRPC

Penentuan ukuran load balancing

Node Bindplane tidak boleh mengelola lebih dari 30.000 kolektor untuk toleransi kesalahan maksimum. Setiap kolektor membuka dua koneksi ke Bindplane (satu untuk pengelolaan jarak jauh OpAMP dan satu untuk memublikasikan metrik throughput). Batas ini membantu memastikan bahwa Anda tidak melebihi batas koneksi sekitar 65.535 per backend instance yang diberlakukan oleh sebagian besar load balancer.

Jika organisasi memiliki 100.000 kolektor, ukuran cluster tiga tidak akan cukup. Setiap node akan bertanggung jawab atas sekitar 33.000 kolektor, yang berarti 66.000 koneksi TCP per instance Bindplane. Situasi ini akan memburuk jika satu node dinonaktifkan untuk pemeliharaan, karena setiap instance Bindplane yang tersisa akan mengelola 50.000 kolektor, atau 100.000 koneksi TCP.

Praktik terbaik penentuan ukuran load balancing

  • Terapkan health check. Konfigurasi load balancer untuk memastikan kolektor siap menerima traffic.
  • Distribusikan koneksi secara merata. Koneksi harus didistribusikan secara merata di antara kolektor.

  • Mendukung protokol yang diperlukan. Untuk mendukung berbagai penerima berbasis jaringan di OpenTelemetry, load balancer harus mendukung:

    • Protokol transport TCP/UDP
    • Protokol aplikasi HTTP dan gRPC

Untuk mempelajari lebih lanjut, lihat Ketahanan Kolektor.

Load balancing jenis sumber

Jenis sumber apa pun yang menerima telemetri dari sistem jarak jauh melalui jaringan adalah kandidat yang cocok untuk load balancing, termasuk:

  • OTLP
  • Syslog
  • TCP/UDP
  • HEC Splunk
  • Fluent Forward

Menggunakan mode ketersediaan tinggi di lingkungan produksi

Anda dapat men-deploy instance Bindplane dalam konfigurasi instance tunggal atau multi-instance. Untuk deployment produksi yang memerlukan ketersediaan tinggi (HA) dan ketahanan, sebaiknya gunakan model deployment multi-instance (HA).

Jika Bindplane mengelola lebih dari 25.000 kolektor, sebaiknya operasikan Bindplane dalam mode ketersediaan tinggi (HA).

Untuk mempelajari HA di Bindplane, lihat Ketersediaan Tinggi.

Menghitung jumlah kolektor dan server Bindplane untuk HA

Saat mengoperasikan Bindplane dalam mode HA, Anda harus mempertimbangkan jumlah kolektor yang Anda harapkan akan ditangani oleh setiap server Bindplane.

Ambil jumlah total instance Bindplane, dan kurangi jumlah maksimum node yang diperkirakan tidak akan tersedia karena pemeliharaan. Pastikan setiap node mengelola tidak lebih dari 30.000 kolektor selama pemadaman layanan node.

Postgres untuk HA

Postgres adalah prasyarat saat Anda mengoperasikan Bindplane dalam mode HA.

Prometheus untuk HA

Prometheus diperlukan saat Anda mengoperasikan Bindplane dalam mode HA.

Untuk mempelajari lebih lanjut, lihat Prometheus.

Bus peristiwa untuk HA

Bindplane menggunakan bus peristiwa untuk berkomunikasi antar-komponen dalam Bindplane. Saat mengoperasikan Bindplane dalam mode HA, Anda dapat menggunakan bus peristiwa untuk mengirim peristiwa antarserver Bindplane.

Untuk mempelajari lebih lanjut, lihat Event Bus.

Menggunakan deployment instance tunggal untuk lingkungan pengujian atau bukti konsep

Untuk lingkungan pengujian atau bukti konsep, sebaiknya gunakan deployment instance tunggal.

Untuk mempelajari lebih lanjut, lihat Instance Tunggal.

Mengisolasi kredensial backend

Daripada men-deploy kredensial ke semua sistem kolektor, Anda dapat menyimpan kredensial secara eksklusif di kolektor gateway. Hal ini menyederhanakan rotasi kredensial dan mengurangi permukaan serangan keamanan dengan membatasi deployment kredensial ke subset sistem Anda.

Memasang firewall pada kolektor gateway Anda

Anda dapat menempatkan kolektor gateway dalam jaringan perimeter, yang dilindungi firewall dari jaringan internal. Anda dapat mengonfigurasi jaringan untuk mengizinkan kolektor lain meneruskan data ke kolektor gateway sekaligus memblokir kolektor gateway agar tidak mengakses jaringan aplikasi Anda. Hal ini memungkinkan Anda mengirim telemetri ke backend berbasis cloud tanpa memberikan akses langsung ke internet kepada endpoint Anda.

Firewall harus mengizinkan traffic HTTP menjangkau Bindplane di port yang dikonfigurasi.

Memverifikasi konfigurasi firewall (Ingestion API)

Setiap firewall atau proxy yang diautentikasi antara kolektor dan internet memerlukan aturan untuk membuka akses ke host berikut:

Jenis koneksi Tujuan Port
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP europe-west12-malachiteingestion-pa.googleapis.com 443
TCP me-central1-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP oauth2.googleapis.com 443

Prasyarat untuk penyerapan Google SecOps dengan Bindplane

Bagian ini menguraikan prasyarat yang diperlukan agar berhasil menyerap data ke Google SecOps menggunakan Bindplane, terutama saat memanfaatkan Chronicle Ingestion API.

Persyaratan jaringan untuk Chronicle API (HTTPS)

Saat menggunakan Bindplane dengan Chronicle Ingestion API, yang menggunakan HTTPS, pastikan konfigurasi jaringan dan firewall Anda mengizinkan koneksi keluar ke endpoint Chronicle API.

Jika organisasi Anda menerapkan batasan firewall berbasis IP, Anda harus memperhitungkan sifat dinamis alamat IP Google Cloud . Karena Google SecOps tidak mendukung daftar alamat IP statis yang diizinkan untuk Ingestion API, mengandalkan IP statis saja tidak direkomendasikan dan dapat menyebabkan kegagalan penyerapan.

Untuk mempertahankan penyerapan data berkelanjutan, pertimbangkan hal berikut:

  • Daftar yang Diizinkan Berbasis Domain: Praktik terbaik yang direkomendasikan adalah mengonfigurasi firewall Anda untuk mengaktifkan traffic HTTPS keluar (port 443) ke seluruh domain *.chronicle.googleapis.com.
  • Endpoint Regional: Bindplane harus dikonfigurasi untuk menggunakan endpoint regional yang sesuai untuk instance Google SecOps Anda, seperti us-chronicle.googleapis.com, europe-chronicle.googleapis.com, dll. Daftar lengkap endpoint regional tersedia dalam dokumentasi Bermigrasi dari API SIEM lama ke Chronicle API.
  • Pembaruan IP Otomatis: Jika daftar yang diizinkan berbasis domain tidak memungkinkan, Anda harus menerapkan sistem otomatis untuk mengambil dan memperbarui rentang IP yang terkait dengan *.chronicle.googleapis.com secara berkala. Rentang IP saat ini untuk Google API dapat diperoleh dari file goog.json dan cloud.json, seperti yang dijelaskan dalam dokumentasi alamat IP Google. Terapkan sistem untuk memperbarui aturan firewall Anda secara dinamis berdasarkan sumber ini.

Menggunakan PostgreSQL untuk deployment produksi

Postgres diperlukan untuk deployment produksi Bindplane.

Postgres adalah prasyarat bagi Anda untuk mengoperasikan Bindplane dalam mode HA.

Jumlah core CPU dan memori yang tersedia umumnya membatasi performa backend penyimpanan PostgreSQL. Sebaiknya dukung penyimpanan PostgreSQL dengan penyimpanan berlatensi rendah dan throughput tinggi, seperti solid-state drive (SSD).

Jumlah kolektor Core CPU Memori
1-60.000 4 16 GB
60.001-125.000 8 32 GB
125.001-250.000 16 64 GB

Untuk mempelajari lebih lanjut, lihat referensi berikut:

Menerapkan autentikasi yang tepat

Bindplane mendukung autentikasi dengan protokol dan layanan berikut; pastikan protokol dan layanan tersebut diterapkan dengan benar:

Menggunakan server Bindplane

Sebagian besar pelanggan Google SecOps menggunakan server Bindplane, tetapi penggunaannya bersifat opsional. Jika Anda menginstal server Bindplane, Anda memerlukan akses ke storage.googleapis.com. Jika Anda hanya menginstal kolektor, akses ini tidak diperlukan.

Untuk demo yang menunjukkan cara mengonfigurasi server Bindplane untuk menstandarkan log dan mengekspornya ke Google SecOps, buka Demo Kasus Penggunaan Bindplane, lalu pilih Konfigurasi Google SecOps.

Menggunakan server Bindplane Cloud

Bindplane Cloud tersedia untuk pelanggan Google.

Login ke Google Edition.

Untuk masalah apa pun yang terkait dengan Bindplane Cloud Server, hubungi dukungan Bindplane. Untuk masalah apa pun yang terkait dengan Bindplane Server lokal, hubungi dukungan Google SecOps.

Menggunakan server Bindplane di Google Cloud

Untuk mengetahui informasi tentang cara menjalankan server Bindplane di Google Cloud, lihat Bindplane Enterprise Edition.

Menggunakan server lokal Bindplane

Penggunaan server Bindplane lokal diatur oleh Persyaratan LayananGoogle Cloud yang ada.

Menginstal server lokal di Linux

Anda dapat menginstal server Bindplane lokal di Linux dengan menjalankan skrip (direkomendasikan) atau mendownload file biner dan menginstalnya secara manual. Untuk mempelajari lebih lanjut, lihat Menginstal Bindplane Server.

Untuk menginstal server Bindplane lokal di Linux dengan skrip, lakukan hal berikut:

  1. Jalankan skrip ini:

    curl -fsSlL https://downloads.bindplane.com/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

  2. Ikuti petunjuk yang memandu Anda hingga inisialisasi server.

Untuk menginstal server Bindplane lokal di Linux dengan file biner, lakukan hal berikut:

  1. Download salah satu file berikut:

  2. Perbarui file konfigurasi menggunakan petunjuk di Mengonfigurasi Server Bindplane.

Distribusi Linux yang didukung:
  • Red Hat, Centos, Oracle Linux 7, 8, 9
  • Debian 11 dan 12
  • Ubuntu LTS 20.04 dan 22.04
  • SUSE Linux 12 dan 15
  • Alma dan Rocky Linux

Untuk mempelajari lebih lanjut, lihat referensi berikut:

Deployment lokal Docker

Untuk mempelajari lebih lanjut, lihat Menginstal Bindplane Server.

Anda dapat menemukan image container Docker Bindplane di lokasi berikut:

  • Paket GitHub: ghcr.io/observiq/Bindplane-ee
  • Repositori artefak Google: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
  • Docker hub: observiq/bindplane-ee

Image container diberi tag dengan versi rilis: misalnya, Rilis v1.35.0 akan memiliki tag observiq/bindplane-ee:1.35.0.

Menginstal kolektor Bindplane

Bagian ini menjelaskan cara menginstal kolektor Bindplane untuk Google SecOps di berbagai sistem.

Kolektor biasanya menggunakan resource minimal. Namun, saat menangani log dalam jumlah besar, perhatikan konsumsi resource agar tidak memengaruhi layanan lain. Untuk mengetahui informasi selengkapnya, lihat Persyaratan dan rekomendasi teknis, Merencanakan penginstalan dan deployment, serta Penentuan Ukuran dan Penskalaan Agen.

Untuk mempelajari cara menginstal kolektor (yaitu, agen OTel), lihat Bindplane OTel Collector.

Anda juga dapat membaca dokumentasi GitHub bindplane-otel-collector.

Untuk menginstal kolektor, Anda memerlukan hal berikut:

  • File autentikasi penyerapan Google SecOps

    Untuk mendownload file autentikasi, ikuti langkah-langkah berikut:

    1. Buka konsol Google SecOps.
    2. Buka Settings > Data Management > Collection Agents.
    3. Download file autentikasi penyerapan Google SecOps. Langkah berikutnya bergantung pada metode transfer Anda:
      • gRPC: Gunakan file autentikasi yang didownload.
      • HTTPS: Buat akun layanan di project Google Cloud yang ditautkan ke Google SecOps dan tetapkan peran Chronicle Editor ke akun tersebut.

  • ID pelanggan Google SecOps

    Untuk menemukan ID pelanggan, ikuti langkah-langkah berikut:

    1. Buka konsol Google SecOps.
    2. Buka Setelan > Administrasi > Profil.
    3. Salin ID pelanggan dari bagian Detail Organisasi.

  • Windows 2012 SP2 atau yang lebih baru atau host Linux dengan systemd

  • Konektivitas internet

  • Akses GitHub

Alat deployment

Bagian ini menjelaskan alat deployment untuk Bindplane.

GitOps

Deploy resource Bindplane menggunakan model GitOps, yang mencakup hal berikut:

  • Autentikasi Bindplane
  • Bindplane CLI
  • Akses jaringan
  • Integrasi dengan repositori GitHub dan GitHub Actions
  • Mengekspor resource yang ada
  • Mengelola nilai sensitif
  • Membuat alur kerja GitHub Action
  • Petunjuk langkah demi langkah untuk meng-commit dan menguji konfigurasi, mengaktifkan peluncuran otomatis, dan mengupdate resource menggunakan pengeditan langsung atau metode ekspor UI
  • Memperbarui nilai sensitif dan menggunakan RBAC

Untuk mempelajari lebih lanjut, lihat GitOps.

Ansible

Untuk mempelajari cara men-deploy Bindplane dengan Ansible, lihat bindplane-agent-ansible.

Bindplane CLI

Untuk mempelajari Bindplane CLI, lihat GitOps.

Terraform

Untuk mempelajari cara menggunakan Terraform untuk mengonfigurasi resource Bindplane, lihat Penyedia Bindplane.

Kubernetes

Untuk mempelajari Kubernetes dengan Bindplane, lihat referensi berikut:

Menginstal kolektor Bindplane di Windows

Untuk menginstal kolektor Bindplane di Windows, jalankan perintah PowerShell berikut:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Atau, untuk menginstal menggunakan wizard penginstalan, download penginstal terbaru untuk Windows. Setelah mendownload penginstal, buka wizard penginstalan dan ikuti petunjuk untuk mengonfigurasi dan menginstal kolektor Bindplane.

Untuk mempelajari lebih lanjut cara menginstal kolektor Bindplane di Windows, lihat Penginstalan Windows.

Menginstal kolektor Bindplane di Linux

Anda dapat menginstal kolektor di Linux menggunakan skrip yang otomatis menentukan paket yang akan diinstal. Anda juga dapat menggunakan skrip yang sama untuk mengupdate penginstalan yang ada.

Untuk menginstal menggunakan skrip penginstalan, jalankan skrip berikut:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Penginstalan dari paket lokal

Untuk menginstal kolektor dari paket lokal, gunakan -f dengan jalur ke paket.

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

Penginstalan RPM

Download paket RPM untuk arsitektur Anda dari halaman rilis dan instal paket menggunakan rpm. Lihat contoh berikut untuk menginstal paket amd64:

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

Ganti VERSION dengan versi paket yang Anda download.

Penginstalan DEB

Download paket DEB untuk arsitektur Anda dari halaman rilis dan instal paket menggunakan dpkg. Lihat contoh berikut untuk menginstal paket amd64:

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

Ganti VERSION dengan versi paket yang Anda download.

Mengonfigurasi kolektor Bindplane

Setelah menginstal kolektor, layanan observiq-otel-collector akan berjalan dan siap untuk dikonfigurasi.

Anda dapat mengonfigurasi kolektor secara manual atau menggunakan server Bindplane.

Jika mengonfigurasi kolektor secara manual, Anda perlu memperbarui parameter pengekspor untuk memastikan bahwa kolektor melakukan autentikasi dengan Google SecOps.

File konfigurasi kolektor OTel

Di Linux, file konfigurasi kolektor dapat ditemukan di /opt/observiq-otel-collector/config.yaml.

Layanan dan log kolektor OTel

Kolektor mencatat log ke C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log secara default.

Log error standar untuk proses kolektor dapat ditemukan di C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Di Linux, untuk melihat log dari kolektor, jalankan sudo tail -F /opt/observiq-otel-collector/log/collector.log.

Perintah layanan kolektor OTel Linux yang umum:

  • Untuk menghentikan layanan kolektor OTel, jalankan sudo systemctl stop observiq-otel-collector.

  • Untuk memulai layanan kolektor OTel, jalankan sudo systemctl start observiq-otel-collector.

  • Untuk memulai ulang layanan kolektor OTel, jalankan sudo systemctl restart observiq-otel-collector.

  • Untuk mengaktifkan layanan kolektor OTel saat memulai, jalankan sudo systemctl enable observiq-otel-collector.

Mulai ulang layanan kolektor untuk perubahan konfigurasi

Saat mengubah konfigurasi, Anda harus memulai ulang layanan kolektor agar perubahan konfigurasi diterapkan (sudo systemctl restart observiq-otel-collector).

Menggunakan file konfigurasi contoh default

Secara default, file konfigurasi kolektor berada di C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

Untuk mendownload contoh file konfigurasi dan token autentikasi yang digunakan oleh kolektor:

  • Buka konsol Google SecOps, lalu buka Settings > Manajemen Data > Collection Agents.

Sesuaikan dua bagian berikut dalam file konfigurasi:

  • Penerima: menentukan log yang harus dikumpulkan dan dikirim oleh kolektor ke Google SecOps.
  • Exporter: menentukan tujuan tempat kolektor mengirim log. Eksportir berikut didukung:
    • Google SecOps exporter: mengirimkan log langsung ke API penyerapan Google SecOps.
    • Pengekspor forwarder Google SecOps: mengirimkan log ke forwarder Google SecOps.
    • Cloud Logging exporter: mengirim log ke (Cloud Logging).

Di pengekspor, sesuaikan hal berikut:

  • customer_id: ID pelanggan Google SecOps Anda.
  • endpoint: Endpoint regional Google SecOps Anda.

  • creds: Token autentikasi Anda.

    Atau, Anda dapat menggunakan creds_file_path untuk mereferensikan file kredensial secara langsung. Untuk konfigurasi Windows, escape jalur dengan garis miring terbalik.

  • log_type: Jenis log. Sebaiknya pilih WINDOWS_DNS sebagai Log Type.

  • ingestion_labels: Label penyerapan. Label ini mengidentifikasi log di Google SecOps.

  • namespace: Namespace opsional.

    Setiap jenis log mengharuskan Anda mengonfigurasi pengekspor.

Contoh konfigurasi pengumpulan log

Bagian berikut berisi contoh konfigurasi untuk pengumpulan log.

Mengirim peristiwa Windows dan sysmon langsung ke Google SecOps

Konfigurasikan parameter ini dalam contoh:

Contoh konfigurasi:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

Mengirim peristiwa Windows dan syslog langsung ke Google SecOps

Konfigurasikan parameter ini dalam contoh:

Contoh konfigurasi:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Mengirim peristiwa Windows dan syslog ke forwarder Google SecOps

Konfigurasikan parameter ini dalam contoh:

Contoh konfigurasi:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

Mengirim syslog langsung ke Google SecOps

Konfigurasikan parameter ini dalam contoh:

Contoh konfigurasi:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Mengumpulkan peristiwa Windows dari jarak jauh dan mengirimkannya langsung ke Google SecOps

Konfigurasikan parameter ini dalam contoh:

  • windowseventlogreceiver
    • username
    • password
    • server
  • chronicleexporter
    • namespace
    • ingestion_labels
    • log_type
    • customer_id
    • creds

Contoh konfigurasi:

receivers:
    windowseventlog/system:
        channel: system
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "remote-server"
    windowseventlog/application:
        channel: application
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
    windowseventlog/security:
        channel: security
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: WINEVTLOG
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/system
                - windowseventlog/application
                - windowseventlog/security
            exporters:
                - chronicle/chronicle_w_labels

Mengirim data ke Cloud Logging

Konfigurasikan parameter credentials_file dalam contoh.

Contoh konfigurasi:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

Membuat kueri database SQL dan mengirim hasilnya ke Google SecOps

Konfigurasikan parameter ini dalam contoh:

Contoh konfigurasi:

receivers:
  sqlquery/source0:
    datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
    driver: postgres
    queries:
      - logs:
          - body_column: log_body
        sql: select * from my_logs where log_id > $$1
        tracking_column: log_id
        tracking_start_value: "10000"
processors:
  transform/source0_processor0__logs:
    error_mode: ignore
    log_statements:
      - context: log
        statements:
          - set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
  chronicle/chronicle_sql:
    compression: gzip
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}' 
    customer_id: customer_id
    endpoint: malachiteingestion-pa.googleapis.com
    log_type: POSTGRESQL
    namespace: null
    raw_log_field: body
    retry_on_failure:
      enabled: false
    sending_queue:
      enabled: false
service:
  pipelines:
    logs/source0_chronicle_sql-0:
      receivers:
        - sqlquery/source0
      processors:
        - transform/source0_processor0__logs
      exporters:
        - chronicle/chronicle_sql

Menghapus log yang cocok dengan ekspresi reguler

Anda dapat mengonfigurasi kolektor untuk menghapus log yang cocok dengan ekspresi reguler. Hal ini berguna untuk memfilter log yang tidak diinginkan, seperti error umum atau pesan proses debug.

Untuk menghapus log yang cocok dengan ekspresi reguler, tambahkan pemroses jenis filter/drop-matching-logs-to-Chronicle ke konfigurasi Anda. Pemroses ini menggunakan fungsi IsMatch untuk mengevaluasi isi log terhadap ekspresi reguler. Jika fungsi menampilkan true, log akan dihapus.

Contoh konfigurasi berikut menghapus log yang berisi string <EventID>10</EventID> atau <EventID>4799</EventID> dalam isi log.

Anda dapat menyesuaikan ekspresi reguler agar sesuai dengan pola yang Anda butuhkan. Fungsi IsMatch menggunakan sintaksis ekspresi reguler RE2.

Contoh konfigurasi:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

Contoh berikut menambahkan pemroses ke pipeline dalam konfigurasi yang sama:

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

Operasi dan pemeliharaan Bindplane

Bagian ini menjelaskan tindakan operasi dan pemeliharaan rutin.

Memverifikasi konfigurasi OTel

Untuk mempelajari cara memverifikasi konfigurasi OTel Bindplane, lihat OTelBin.

Update rilis kolektor

Bindplane dapat melakukan polling pada bindplane-otel-collector/releases untuk mendeteksi rilis kolektor baru. Fitur ini bersifat opsional.

Anda dapat menonaktifkan polling GitHub dengan menetapkan agentVersions.syncInterval ke 0 dalam konfigurasi Bindplane:

agentVersions:
syncInterval: 0

Pencadangan dan pemulihan dari bencana (disaster recovery)

Untuk mempelajari pencadangan dan pemulihan dari bencana (disaster recovery) dengan Bindplane, lihat resource Bindplane.

Pencadangan dan pemulihan dari bencana (disaster recovery) PostgreSQL

Untuk mempelajari pencadangan dan pemulihan dari bencana (disaster recovery) PostgreSQL dengan Bindplane, lihat dokumentasi PostgreSQL.

Pencadangan dan pemulihan dari bencana (disaster recovery) BBolt

Untuk mempelajari pencadangan dan pemulihan dari bencana BBolt (tidak digunakan lagi) dengan Bindplane, lihat dokumentasi BBolt Store.

Ketahanan dan percobaan ulang

Percobaan ulang diaktifkan secara default di semua tujuan yang mendukungnya. Secara default, permintaan yang gagal akan dicoba lagi setelah lima detik dan secara progresif akan mundur hingga 30 detik. Setelah lima menit, permintaan akan dihapus secara permanen.

Untuk mempelajari lebih lanjut, lihat Ketahanan Kolektor.

Mengurangi volume log dengan filter tingkat keparahan

Untuk mempelajari cara mengurangi volume log, lihat Mengurangi Volume Log dengan Filter Keparahan.

Integrasi Bindplane dengan kolektor pihak ketiga

Meskipun Bindplane lebih efektif saat Anda menggunakan kolektor Bindplane untuk pengumpulan di edge, dalam sebagian besar kasus, Bindplane dapat tetap berada dalam infrastruktur yang ada. Misalnya, jika Anda sudah menggunakan Fluent Bit atau Splunk Universal Forwarder, Anda dapat terus menggunakannya.

Integrasi Bindplane dengan Splunk

Untuk mempelajari Splunk dengan Bindplane, lihat referensi berikut:

Integrasi Bindplane dengan kolektor pihak ketiga lainnya

Untuk mempelajari integrasi Bindplane dengan kolektor pihak ketiga, lihat Menghubungkan Kolektor OpenTelemetry Lain Menggunakan Ekstensi OpAMP.

Pemantauan Host Senyap

Pemantauan Host Senyap Google Security Operations memungkinkan Anda membuat pemberitahuan untuk perubahan rasio penyerapan menggunakan Google Cloud Monitoring. Fitur ini menghasilkan pemberitahuan per kolektor dan memberi tahu Anda saat tingkat penyerapan turun di bawah batas yang Anda tentukan, yang menandakan potensi penghentian kolektor.

Untuk mengetahui informasi tentang penggunaan Bindplane untuk pemantauan host senyap, lihat referensi berikut:

Mengupgrade Bindplane di Linux

Menjalankan perintah penginstalan tanpa flag --init di akhir sudah cukup untuk mengupgrade Bindplane. Jalankan skrip ini di server Bindplane Anda untuk mengupgrade Bindplane. Untuk mempelajari lebih lanjut, lihat Mengupgrade, Men-downgrade, atau Meng-uninstal Bindplane Server.

Memantau Bindplane

Untuk mempelajari cara memantau Bindplane, lihat Memantau Bindplane.

Memantau Kubernetes di Bindplane

Untuk mempelajari cara memantau Kubernetes di Bindplane, lihat Pemantauan Kubernetes.

Dokumentasi tambahan

Untuk mempelajari lebih lanjut Bindplane (sebelumnya dikenal sebagai observIQ), lihat referensi berikut:

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