Apache NiFi di Azure

Azure Application Gateway
Azure Log Analytics
Azure Virtual Machines
Azure Virtual Network
Azure Virtual Machine Scale Sets

Perhatian

Artikel ini mereferensikan CentOS, distribusi Linux yang merupakan End Of Life (EOL). Harap pertimbangkan penggunaan dan rencanakan yang sesuai. Untuk informasi selengkapnya, lihat panduan Akhir Masa Pakai CentOS.

Contoh skenario ini menunjukkan cara menjalankan Apache NiFi di Azure. NiFi menyediakan sistem untuk memproses dan mendistribusikan data.

Apache®, Apache NiFi®, dan NiFi® adalah merek dagang terdaftar atau merek dagang dari Apache Software Foundation di Amerika Serikat dan/atau negara lain. Tidak ada dukungan oleh The Apache Software Foundation yang tersirat oleh penggunaan tanda ini.

Sistem

Diagram arsitektur yang menunjukkan aliran data otomatis melalui solusi Azure yang menggunakan Apache NiFi dan Apache ZooKeeper.

Unduh file Visio arsitektur ini.

Alur kerja

  • Aplikasi NiFi berjalan pada VM di node kluster NiFi. VM berada dalam set skala mesin virtual yang disebarkan konfigurasi di seluruh zona ketersediaan.

  • Apache ZooKeeper berjalan pada VM di kluster terpisah. NiFi menggunakan kluster ZooKeeper untuk tujuan ini:

    • Untuk memilih node koordinator kluster
    • Untuk mengoordinasikan aliran data
  • Azure Application Gateway menyediakan penyeimbangan beban lapisan-7 untuk antarmuka pengguna yang berjalan pada node NiFi.

  • Monitor dan fitur Analitik Log-nya mengumpulkan, menganalisis, dan bertindak berdasarkan telemetri dari sistem NiFi. Telemetri mencakup log sistem NiFi, metrik kesehatan sistem, dan metrik performa.

  • Azure Key Vault menyimpan sertifikat dan kunci untuk kluster NiFi dengan aman.

  • MICROSOFT Entra ID menyediakan akses menyeluruh (SSO) dan autentikasi multifaktor.

Komponen

  • NiFi menyediakan sistem untuk memproses dan mendistribusikan data.
  • ZooKeeper adalah server sumber terbuka yang mengelola sistem terdistribusi.
  • Virtual Machines merupakan infrastruktur layanan (IaaS) yang ditawarkan. Anda dapat menggunakan Virtual Machines untuk menyebarkan sumber daya komputasi sesuai permintaan dan terukur. Virtual Machines memberikan fleksibilitas virtualisasi tetapi menghilangkan keharusan pemeliharaan perangkat keras.
  • Azure Virtual Machine Scale Sets menyediakan cara untuk mengelola grup VM beban seimbang. Jumlah instans VM dalam satu set dapat bertambah atau berkurang secara otomatis sebagai respons terhadap permintaan atau jadwal yang ditentukan.
  • Zona Ketersediaan adalah lokasi fisik yang unik dalam wilayah Azure. Penawaran ketersediaan tinggi ini melindungi aplikasi dan data dari kegagalan pusat data.
  • Application Gateway adalah penyeimbang beban yang mengelola lalu lintas ke aplikasi web.
  • Monitor mengumpulkan dan menganalisis data tentang lingkungan dan sumber daya Azure. Data ini mencakup telemetri aplikasi, seperti metrik performa dan log aktivitas. Untuk informasi selengkapnya, lihat Memantau pertimbangan di artikel ini nanti.
  • Analitik Log adalah alat portal Azure yang menjalankan kueri pada data log Monitor. Analitik Log juga menyediakan fitur untuk memetakan dan menganalisis hasil kueri secara statistik.
  • Azure DevOps Services menyediakan layanan, alat, dan lingkungan untuk mengelola penyebaran dan proyek pengodean.
  • Key Vault dengan aman menyimpan dan mengontrol akses ke rahasia sistem, seperti kunci API, kata sandi, sertifikat, dan kunci kriptografi.
  • MICROSOFT Entra ID adalah layanan identitas berbasis cloud yang mengontrol akses ke Azure dan aplikasi cloud lainnya.

Alternatif

Detail skenario

Dalam skenario ini, NiFi berjalan dalam konfigurasi berkerumun di seluruh Azure Virtual Machines dalam satu set skala. Tetapi sebagian besar rekomendasi artikel ini juga berlaku untuk skenario yang menjalankan NiFi dalam mode instans tunggal pada satu mesin virtual (VM). Praktik terbaik dalam artikel ini menunjukkan penyebaran yang dapat diskalakan, sangat tersedia, dan aman.

Kemungkinan kasus penggunaan

NiFi bekerja dengan baik untuk memindahkan data dan mengelola aliran data:

  • Menghubungkan sistem yang dipisahkan di cloud
  • Memindahkan data masuk dan keluar dari Azure Storage dan penyimpanan data lainnya
  • Mengintegrasikan aplikasi edge-ke-cloud dan cloud hibrid dengan Azure IoT, Azure Stack, dan Azure Kubernetes Service (AKS)

Oleh karena itu, solusi ini berlaku untuk banyak area:

  • Gudang data modern (MDW) menyatukan data terstruktur dan tidak terstruktur dalam skala besar. Gudang data mengumpulkan dan menyimpan data dari berbagai sumber, sink, dan format. NiFi unggul dalam menyerap data ke MDW berbasis Azure karena alasan berikut:

    • Lebih dari 200 prosesor tersedia untuk membaca, menulis, dan memanipulasi data.
    • Sistem mendukung layanan Storage seperti Azure Blob Storage, Azure Data Lake Storage, Azure Event Hubs, Azure Queue Storage, Azure Cosmos DB, dan Azure Synapse Analytics.
    • Kemampuan asal data yang kuat memungkinkan untuk menerapkan solusi yang sesuai. Untuk informasi tentang menangkap asal data di fitur Analitik Log dari Azure Monitor, lihat Melaporkan pertimbangan di artikel ini nanti.
  • NiFi dapat berjalan secara mandiri pada perangkat jejak kecil. Dalam kasus seperti itu, NiFi memungkinkan untuk memproses data tepi dan memindahkan data tersebut ke instans atau kluster NiFi yang lebih besar di cloud. NiFi membantu memfilter, mengubah, dan memprioritaskan data tepi yang bergerak, memastikan aliran data yang andal dan efisien.

  • Solusi IoT Industrial (IIoT) mengelola aliran data dari tepi ke pusat data. Aliran itu dimulai dengan akuisisi data dari peralatan dan sistem kontrol industri. Data kemudian beralih ke solusi manajemen data dan MDW. NiFi menawarkan kemampuan yang membuatnya cocok untuk akuisisi dan pergerakan data:

    • Fungsionalitas pemrosesan data tepi
    • Dukungan untuk protokol yang digunakan oleh gateway dan perangkat IoT
    • Integrasi dengan Pusat Aktivitas dan layanan Storage

    Aplikasi IoT di area pemeliharaan prediktif dan manajemen rantai pasokan dapat menggunakan fungsi ini.

Rekomendasi

Ingatlah hal-hal berikut saat Anda menggunakan solusi ini:

Saat Anda menjalankan solusi ini di Azure, kami merekomendasikan untuk menggunakan NiFi versi 1.13.2+. Anda dapat menjalankan versi lain, tetapi mungkin memerlukan konfigurasi yang berbeda dari yang ada dalam panduan ini.

Untuk menginstal NiFi di Azure VM, sebaiknya unduh biner kenyamanan dari halaman unduhan NiFi. Anda juga dapat membuat biner dari kode sumber.

Untuk contoh beban kerja ini, kami merekomendasikan untuk menggunakan versi 3.5.5 dan yang lebih baru atau 3.6.x dari ZooKeeper.

Anda dapat menginstal ZooKeeper di Azure VM dengan menggunakan biner kenyamanan resmi atau kode sumber. Keduanya tersedia di halaman rilis Apache ZooKeeper.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Untuk informasi tentang mengonfigurasi NiFi, lihat Panduan Administrator Sistem Apache NiFi. Ingat juga pertimbangan ini ketika Anda menerapkan solusi ini.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

  • Gunakan Kalkulator Harga Azure untuk memperkirakan biaya sumber daya dalam arsitektur ini.
  • Untuk perkiraan yang mencakup semua layanan dalam arsitektur ini kecuali solusi peringatan kustom, lihat contoh profil biaya ini.

Pertimbangan VM

Bagian berikut memberikan kerangka rinci tentang cara mengonfigurasi VM NiFi:

Ukuran komputer virtual

Tabel ini mencantumkan ukuran VM yang direkomendasikan untuk memulai. Untuk sebagian besar aliran data tujuan umum, Standard_D16s_v3 adalah yang terbaik. Tetapi setiap aliran data di NiFi memiliki persyaratan yang berbeda. Uji aliran Anda dan ubah ukuran sesuai kebutuhan berdasarkan persyaratan aliran yang sebenarnya.

Pertimbangkan untuk mengaktifkan jaringan yang dipercepat pada VM untuk meningkatkan performa jaringan. Untuk informasi lebih lanjut, lihat Jaringan untuk set skala komputer virtual Azure.

Ukuran komputer virtual vCPU Memori dalam GB Throughput disk data maksimal yang tidak di-cache dalam operasi I/O per detik (IOPS) per MBps* Antarmuka jaringan (NIC)/Bandwidth jaringan yang diharapkan (Mbps) maksimal
Standard_D8s_v3 8 32 12.800/192 4/4.000
Standard_D16s_v3** 16 64 25.600/384 8/8.000
Standard_D32s_v3 32 128 51.200/768 8/16.000
Standard_M16m 16 437,5 10.000/250 8/4.000

* Nonaktifkan caching penulisan disk data untuk semua disk data yang Anda gunakan pada node NiFi.

** Kami merekomendasikan SKU ini untuk sebagian besar aliran data tujuan umum. SKU Azure VM dengan vCPU dan konfigurasi memori yang serupa juga harus memadai.

Sistem operasi (OS) VM

Kami merekomendasikan untuk menjalankan NiFi di Azure pada salah satu sistem operasi tamu berikut:

  • Ubuntu 18.04 LTS atau yang lebih baru
  • CentOS 7.9

Untuk memenuhi persyaratan khusus aliran data Anda, penting untuk menyesuaikan beberapa pengaturan tingkat OS termasuk:

  • Proses bercabang maksimum.
  • Penanganan file maksimum.
  • Waktu akses, atime.

Setelah Anda menyesuaikan OS agar sesuai dengan kasus penggunaan yang Anda harapkan, gunakan Azure VM Image Builder untuk mengodifikasi pembuatan gambar yang disetel tersebut. Untuk panduan khusus NiFi, lihat Praktik Terbaik Konfigurasi di Panduan Administrator Sistem Apache NiFi.

Penyimpanan

Simpan berbagai repositori NiFi pada disk data dan bukan pada disk OS karena tiga alasan utama:

  • Aliran sering memiliki persyaratan throughput disk yang tinggi yang tidak dapat dipenuhi oleh satu disk.
  • Sangat direkomendasikan untuk memisahkan operasi disk NiFi dari operasi disk OS.
  • Repositori seharusnya tidak berada di penyimpanan sementara.

Bagian berikut menguraikan panduan untuk mengonfigurasi disk data. Panduan ini dikhususkan untuk Azure. Untuk informasi selengkapnya tentang mengonfigurasi repositori, lihat Manajemen Status di Panduan Administrator Sistem Apache NiFi.

Jenis dan ukuran disk data

Pertimbangkan faktor-faktor ini saat Anda mengonfigurasi disk data untuk NiFi:

  • Jenis disk OS
  • Ukuran Disk
  • Jumlah total disk

Catatan

Untuk informasi terbaru tentang jenis, ukuran, dan harga disk, lihat Pengantar disk terkelola Azure.

Tabel berikut memperlihatkan jenis disk terkelola yang saat ini tersedia di Azure. Anda dapat menggunakan NiFi dengan salah satu jenis disk ini. Tetapi, untuk aliran data dengan throughput tinggi, kami merekomendasikan SSD Premium.

Ultra Disk (NVM Express (NVMe)) SSD Premium SSD Standar HDD Standar
Jenis disk SSD SSD SSD HDD
Ukuran disk maks 65.536 GB 32.767 GB 32.767 GB 32.767 GB
Throughput maks 2.000 MiB/dtk 900 MiB/dtk 750 MiB/dtk 500 MiB/dtk
IOPS Maks 160.000 20.000 6.000 2.000

Gunakan setidaknya tiga disk data untuk meningkatkan throughput aliran data. Untuk praktik terbaik dalam mengonfigurasi repositori pada disk, lihat Konfigurasi repositori di artikel ini nanti.

Tabel berikut mencantumkan ukuran dan angka throughput yang relevan untuk setiap ukuran dan jenis disk.

HDD Standar S15 HDD Standar S20 HDD Standar S30 SSD Standar S15 SSD Standar S20 SSD Standar S30 SSD Premium P15 SSD Premium P20 SSD Premium P30
Ukuran disk dalam GB 256 512 1,024 256 512 1,024 256 512 1,024
IOPS per disk Hingga 500 Hingga 500 Hingga 500 Hingga 500 Hingga 500 Hingga 500 1.100 2.300 5\.000
Throughput per disk Hingga 60 MBps Hingga 60 MBps Hingga 60 MBps Hingga 60 MBps Hingga 60 MBps Hingga 60 MBps 125 MBps 150 MBps 200 MBps

Jika sistem Anda mencapai batas VM, menambahkan lebih banyak disk mungkin tidak meningkatkan throughput:

  • Batas IOPS dan throughput bergantung pada ukuran disk.
  • Ukuran VM yang Anda pilih menempatkan IOPS dan batas throughput untuk VM di semua disk data.

Untuk batas throughput disk tingkat VM, lihat Ukuran untuk mesin virtual Linux di Azure.

Caching disk VM

Pada Azure VM, fitur Host Caching mengelola caching penulisan disk. Untuk meningkatkan throughput pada disk data yang Anda gunakan untuk repositori, nonaktifkan cache penulisan disk dengan mengatur Host Caching ke None.

Konfigurasi repositori

Panduan praktik terbaik untuk NiFi adalah menggunakan satu atau beberapa disk terpisah untuk masing-masing repositori ini:

  • Konten
  • FlowFile
  • Asal

Pendekatan ini membutuhkan minimal tiga disk.

NiFi juga mendukung penghapusan tingkat aplikasi. Fungsi ini meningkatkan ukuran atau performa penyimpanan data.

Kutipan berikut berasal dari file konfigurasi nifi.properties. Konfigurasi ini mempartisi dan menghapus repositori di seluruh disk terkelola yang dilampirkan ke VM:

nifi.provenance.repository.directory.stripe1=/mnt/disk1/ provenance_repository
nifi.provenance.repository.directory.stripe2=/mnt/disk2/ provenance_repository
nifi.provenance.repository.directory.stripe3=/mnt/disk3/ provenance_repository
nifi.content.repository.directory.stripe1=/mnt/disk4/ content_repository
nifi.content.repository.directory.stripe2=/mnt/disk5/ content_repository
nifi.content.repository.directory.stripe3=/mnt/disk6/ content_repository
nifi.flowfile.repository.directory=/mnt/disk7/ flowfile_repository

Untuk informasi selengkapnya tentang mendesain penyimpanan dengan performa tinggi, lihat Penyimpanan premium Azure: desain untuk performa tinggi.

Pelaporan

NiFi menyertakan tugas pelaporan asal untuk fitur Analitik Log.

Anda dapat menggunakan tugas pelaporan ini untuk memindahkan peristiwa asal ke penyimpanan jangka panjang yang hemat biaya dan tahan lama. Fitur Analitik Log menyediakan antarmuka kueri untuk melihat dan membuat grafik dari setiap peristiwa. Untuk informasi selengkapnya tentang kueri ini, lihat Kueri Analitik Log di artikel ini nanti.

Anda juga dapat menggunakan tugas ini dengan penyimpanan asal dalam memori yang mudah menguap. Dalam banyak skenario, Anda kemudian dapat mencapai peningkatan throughput. Tetapi pendekatan ini berisiko jika Anda perlu menyimpan data peristiwa. Pastikan penyimpanan yang mudah menguap memenuhi persyaratan daya tahan Anda untuk peristiwa asal. Untuk informasi selengkapnya, lihat Repositori Asal di Panduan Administrator Sistem Apache NiFi.

Sebelum menggunakan proses ini, buat ruang kerja analitik log di langganan Azure Anda. Sangat direkomendasikan untuk menyiapkan ruang kerja di wilayah yang sama dengan beban kerja Anda.

Untuk mengonfigurasi tugas pelaporan asal:

  1. Buka pengaturan pengontrol di NiFi.
  2. Pilih menu tugas pelaporan.
  3. Pilih Buat tugas pelaporan baru.
  4. Pilih Tugas Pelaporan Analitik Log Azure.

Cuplikan layar berikut menunjukkan menu properti untuk tugas pelaporan ini:

Cuplikan layar jendela Tugas Pelaporan Konfigurasi NiFi. Menu Properti terlihat. Ini mencantumkan nilai pengaturan Analitik Log.

Dua properti yang diperlukan:

  • ID ruang kerja analitik log
  • Kunci ruang kerja analitik log

Anda dapat menemukan nilai ini di portal Azure dengan membuka ruang kerja Analisis Log Anda.

Opsi lain juga tersedia untuk menyesuaikan dan memfilter peristiwa asal yang dikirim sistem.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Anda dapat mengamankan NiFi dari sudut pandang autentikasi dan otorisasi. Anda juga dapat mengamankan NiFi untuk semua komunikasi jaringan termasuk:

  • Di dalam kluster.
  • Antara kluster dan ZooKeeper.

Lihat Panduan Administrator Apache NiFi untuk petunjuk tentang mengaktifkan opsi berikut:

  • Kerberos
  • Protokol Akses Direktori Ringan (LDAP)
  • Autentikasi dan otorisasi berbasis sertifikat
  • Secure Sockets Layer (SSL) dua arah untuk komunikasi kluster

Jika Anda mengaktifkan akses klien aman ZooKeeper, konfigurasi NiFi dengan menambahkan properti terkait ke file konfigurasi bootstrap.conf-nya. Entri konfigurasi berikut memberikan contoh:

java.arg.18=-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
java.arg.19=-Dzookeeper.client.secure=true
java.arg.20=-Dzookeeper.ssl.keyStore.location=/path/to/keystore.jks
java.arg.21=-Dzookeeper.ssl.keyStore.password=[KEYSTORE PASSWORD]
java.arg.22=-Dzookeeper.ssl.trustStore.location=/path/to/truststore.jks
java.arg.23=-Dzookeeper.ssl.trustStore.password=[TRUSTSTORE PASSWORD]

Untuk rekomendasi umum, lihat garis besar keamanan Linux.

Keamanan jaringan

Saat Anda menerapkan solusi ini, ingatlah poin-poin berikut tentang keamanan jaringan:

Grup keamanan jaringan

Di Azure, Anda dapat menggunakan grup keamanan jaringan untuk membatasi lalu lintas jaringan.

Kami merekomendasikan jumpbox untuk menyambungkan ke kluster NiFi untuk tugas administratif. Gunakan VM yang diperkuat keamanan ini dengan akses just-in-time (JIT) atau Azure Bastion. Siapkan grup keamanan jaringan untuk mengontrol cara Anda memberikan akses ke jumpbox atau Azure Bastion. Anda dapat menerapkan isolasi dan kontrol jaringan dengan menggunakan grup keamanan jaringan secara bijaksana pada berbagai subnet arsitektur.

Cuplikan layar berikut menunjukkan komponen dalam jaringan virtual yang khas. Ini berisi subnet umum untuk jumpbox, set skala mesin virtual, dan VM ZooKeeper. Topologi jaringan yang disederhanakan ini mengelompokkan komponen ke dalam satu subnet. Ikuti panduan organisasi Anda untuk pemisahan tugas dan desain jaringan.

Cuplikan layar tabel yang mencantumkan perangkat, jenis, dan subnet komponen jaringan virtual.

Pertimbangan akses internet keluar

NiFi di Azure tidak memerlukan akses ke internet publik untuk dijalankan. Jika aliran data tidak memerlukan akses internet untuk mengambil data, tingkatkan keamanan kluster dengan mengikuti langkah-langkah berikut untuk menonaktifkan akses internet keluar:

  1. Buat aturan tambahan untuk grup keamanan jaringan di jaringan virtual.

  2. Gunakan pengaturan ini:

    • Sumber: Any
    • Tujuan: Internet
    • Tindakan: Deny

Cuplikan layar yang memperlihatkan nilai setelan aturan keamanan keluar seperti Prioritas, Nama, Port, Protokol, Sumber, Tujuan, dan Tindakan.

Dengan aturan ini, Anda masih dapat mengakses beberapa layanan Azure dari aliran data jika Anda mengonfigurasi titik akhir privat di jaringan virtual. Gunakan Azure Private Link untuk tujuan ini. Layanan ini menyediakan cara bagi lalu lintas Anda untuk melakukan perjalanan di jaringan tulang punggung Microsoft tanpa memerlukan akses jaringan eksternal lainnya. NiFi saat ini mendukung Private Link untuk prosesor Blob Storage dan Data Lake Storage. Jika server Network Time Protocol (NTP) tidak tersedia di jaringan privat Anda, izinkan akses keluar ke NTP. Untuk informasi terperinci, lihat Sinkronisasi waktu untuk VM Linux di Azure.

Perlindungan data

Bukan hal mustahil untuk mengoperasikan NiFi tanpa jaminan, tanpa enkripsi kabel, manajemen identitas dan akses (IAM), atau enkripsi data. Namun, sangat direkomendasikan untuk mengamankan produksi dan penyebaran cloud publik dengan cara berikut:

  • Mengenkripsi komunikasi dengan Keamanan Lapisan Transportasi (TLS)
  • Menggunakan mekanisme autentikasi dan otorisasi yang didukung
  • Mengenkripsi data tidak aktif

Azure Storage menyediakan enkripsi data transparan sisi server. Tetapi mulai dari rilis 1.13.2, NiFi tidak mengonfigurasi enkripsi kabel atau IAM secara default. Perilaku ini mungkin berubah dalam rilis mendatang.

Bagian berikut menunjukkan cara mengamankan penyebaran dengan cara berikut:

  • Aktifkan enkripsi kabel dengan TLS
  • Mengonfigurasi autentikasi yang didasarkan pada sertifikat atau ID Microsoft Entra
  • Kelola penyimpanan terenkripsi di Azure
Enkripsi disk

Untuk meningkatkan keamanan, gunakan enkripsi disk Azure. Untuk prosedur terperinci, lihat Mengenkripsi OS dan disk data yang dilampirkan dalam set skala mesin virtual dengan Azure CLI. Dokumen itu juga berisi instruksi untuk menyediakan kunci enkripsi Anda sendiri. Langkah-langkah berikut menguraikan contoh dasar untuk NiFi yang berfungsi untuk sebagian besar penyebaran:

  1. Untuk mengaktifkan enkripsi disk dalam instans Key Vault yang ada, gunakan perintah Azure CLI berikut:

    az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
    
  2. Aktifkan enkripsi disk data set skala mesin virtual dengan perintah berikut:

    az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
    
  3. Anda dapat secara opsional menggunakan kunci enkripsi kunci (KEK). Gunakan perintah Azure CLI berikut untuk mengenkripsi dengan KEK:

    az vmss encryption enable --resource-group myResourceGroup --name  myScaleSet  \
    --disk-encryption-keyvault myKeyVaultID \
    --key-encryption-keyvault myKeyVaultID \
    --key-encryption-key https://<mykeyvaultname>.vault.azure.net/keys/myKey/<version> \
    --volume-type DATA
    
    

Catatan

Jika Anda mengonfigurasi set skala mesin virtual untuk mode pembaruan manual, jalankan perintah update-instances. Sertakan versi kunci enkripsi yang Anda simpan di Key Vault.

Enkripsi saat transit

NiFi mendukung TLS 1.2 untuk enkripsi saat transit. Protokol ini menawarkan perlindungan untuk akses pengguna ke UI. Dengan kluster, protokol melindungi komunikasi antara node NiFi. Protokol juga dapat melindungi komunikasi dengan ZooKeeper. Saat Anda mengaktifkan TLS, NiFi menggunakan TLS bersama (mTLS) untuk autentikasi bersama untuk:

  • Autentikasi klien berbasis sertifikat jika Anda mengonfigurasi jenis autentikasi ini.
  • Semua komunikasi intra-kluster.

Untuk mengaktifkan TLS, lakukan langkah-langkah berikut:

  1. Buat keystore dan truststore untuk komunikasi dan autentikasi klien-server dan intra-kluster.

  2. Konfigurasi $NIFI_HOME/conf/nifi.properties. Tetapkan nilai berikut:

    • Nama host
    • Port
    • Properti keystore
    • Properti truststore
    • Properti keamanan Kluster dan ZooKeeper, jika berlaku
  3. Konfigurasi autentikasi di $NIFI_HOME/conf/authorizers.xml, biasanya dengan pengguna awal yang memiliki autentikasi berbasis sertifikat atau opsi lain.

  4. Secara opsional, konfigurasikan mTLS dan kebijakan baca proksi antara NiFi dan semua proksi, penyeimbang beban, atau titik akhir eksternal.

Untuk panduan lengkap, lihat Mengamankan NiFi dengan TLS di dokumentasi proyek Apache.

Catatan

Pada versi 1.13.2:

  • NiFi tidak mengaktifkan TLS secara default.
  • Tidak ada dukungan siap pakai untuk akses pengguna tunggal dan anonim untuk instans NiFi berkemampuan TLS.

Untuk mengaktifkan TLS untuk enkripsi saat transit, konfigurasikan grup pengguna dan penyedia kebijakan untuk autentikasi dan otorisasi di $NIFI_HOME/conf/authorizers.xml. Untuk informasi selengkapnya, lihat Identitas dan kontrol akses di artikel ini nanti.

Sertifikat, kunci, dan penyimpanan kunci

Untuk mendukung TLS, buat sertifikat, simpan di KeyStore dan TrustStore Java, dan distribusikan ke seluruh kluster NiFi. Ada dua opsi umum untuk sertifikat:

  • Sertifikat yang ditandatangani sendiri
  • Sertifikat yang ditandatangani oleh otoritas bersertifikat (CA)

Dengan sertifikat yang ditandatangani CA, sangat direkomendasikan untuk menggunakan CA perantara untuk menghasilkan sertifikat untuk node dalam kluster.

KeyStore dan TrustStore adalah kontainer kunci dan sertifikat di platform Java. KeyStore menyimpan kunci pribadi dan sertifikat sebuah node di dalam kluster. TrustStore menyimpan salah satu jenis sertifikat berikut:

  • Semua sertifikat tepercaya, untuk sertifikat yang ditandatangani sendiri di KeyStore
  • Sertifikat dari CA, untuk sertifikat yang ditandatangani CA di KeyStore

Ingatlah skalabilitas kluster NiFi Anda saat memilih kontainer. Misalnya, Anda mungkin ingin menambah atau mengurangi jumlah node dalam sebuah kluster di masa mendatang. Pilih sertifikat yang ditandatangani CA di KeyStore dan satu atau beberapa sertifikat dari CA di TrustStore dalam hal ini. Dengan opsi ini, tidak perlu memperbarui TrustStore yang ada di node kluster yang ada. TrustStore yang ada mempercayai dan menerima sertifikat dari jenis node berikut:

  • Node yang Anda tambahkan ke kluster
  • Node yang menggantikan node lain dalam kluster
Konfigurasi NiFi

Untuk mengaktifkan TLS untuk NiFi, gunakan $NIFI_HOME/conf/nifi.properties untuk mengonfigurasi properti di tabel ini. Pastikan properti berikut menyertakan nama host yang Anda gunakan untuk mengakses NiFi:

  • nifi.web.https.host atau nifi.web.proxy.host
  • Nama alternatif subjek atau nama yang ditunjuk oleh sertifikat host

Jika tidak, kegagalan verifikasi nama host atau kegagalan verifikasi header HOST HTTP dapat mengakibatkan, menolak Akses Anda.

Nama properti Deskripsi Contoh nilai
nifi.web.https.host Nama host atau alamat IP yang akan digunakan untuk UI dan REST API. Nilai ini harus dapat diselesaikan secara internal. Kami merekomendasikan untuk tidak menggunakan nama yang dapat diakses publik. nifi.internal.cloudapp.net
nifi.web.https.port Port HTTPS yang akan digunakan untuk UI dan REST API. 9443 (default)
nifi.web.proxy.host Daftar nama host alternatif yang dipisahkan koma yang digunakan klien untuk mengakses UI dan REST API. Daftar ini biasanya menyertakan nama host apa pun yang ditentukan sebagai nama alternatif subjek (SAN) dalam sertifikat server. Daftar ini juga dapat menyertakan nama host dan port apa pun yang digunakan oleh pengontrol ingress Kubernetes, penyeimbang beban, atau proksi. 40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore Jalur menuju keystore JKS atau PKCS12 yang berisi kunci pribadi sertifikat. ./conf/keystore.jks
nifi.security.keystoreType Jenis keystore. JKS atau PKCS12
nifi.security.keystorePasswd Kata sandi keystore. O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd (Opsional) Kata sandi untuk kunci pribadi.
nifi.security.truststore Jalur menuju truststore JKS atau PKCS12 yang berisi sertifikat atau sertifikat CA yang mengautentikasi pengguna tepercaya dan node kluster. ./conf/truststore.jks
nifi.security.truststoreType Jenis truststore. JKS atau PKCS12
nifi.security.truststorePasswd Kata sandi truststore. RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure Status TLS untuk komunikasi intra-kluster. Jika nifi.cluster.is.node adalah true, atur nilai ini menjadi true untuk mengaktifkan TLS kluster. true
nifi.remote.input.secure Status TLS untuk komunikasi situs-ke-situs. true

Contoh berikut menunjukkan bagaimana properti ini muncul di $NIFI_HOME/conf/nifi.properties. Perhatikan bahwa nilai nifi.web.http.host dan nifi.web.http.port kosong.

nifi.remote.input.secure=true
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=nifi.internal.cloudapp.net
nifi.web.https.port=9443
nifi.web.proxy.host=40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore=./conf/keystore.jks 
nifi.security.keystoreType=JKS          
nifi.security.keystorePasswd=O8SitLBYpCz7g/RpsqH+zM                  
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks                                   
nifi.security.truststoreType=JKS
nifi.security.truststorePasswd=RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure=true
Konfigurasi Zookeeper

Untuk petunjuk tentang mengaktifkan TLS di Apache ZooKeeper untuk komunikasi kuorum dan akses klien, lihat Panduan Administrator ZooKeeper. Hanya versi 3.5.5 atau yang lebih baru yang mendukung fungsi ini.

NiFi menggunakan ZooKeeper untuk pengklusteran zero-leader dan koordinasi klusternya. Dimulai dengan versi 1.13.0, NiFi mendukung akses klien yang aman ke instans ZooKeeper yang mendukung TLS. ZooKeeper menyimpan keanggotaan kluster dan status prosesor yang dicakup kluster dalam teks biasa. Jadi, penting untuk menggunakan akses klien yang aman ke ZooKeeper untuk mengautentikasi permintaan klien ZooKeeper. Juga mengenkripsi nilai sensitif saat transit.

Untuk mengaktifkan TLS untuk akses klien NiFi ke ZooKeeper, atur properti berikut di $NIFI_HOME/conf/nifi.properties. Jika Anda mengatur nifi.zookeeper.client.secure true tanpa mengonfigurasi nifi.zookeeper.security properti, NiFi kembali ke keystore dan truststore yang Anda tentukan di nifi.securityproperties.

Nama properti Deskripsi Contoh nilai
nifi.zookeeper.client.secure Status TLS klien saat terhubung ke ZooKeeper. true
nifi.zookeeper.security.keystore Jalur ke keystore JKS, PKCS12, atau PEM yang berisi kunci privat dari sertifikat yang diberikan ke ZooKeeper untuk proses autentikasi. ./conf/zookeeper.keystore.jks
nifi.zookeeper.security.keystoreType Jenis keystore. JKS, PKCS12, PEM, atau deteksi otomatis menurut ekstensi
nifi.zookeeper.security.keystorePasswd Kata sandi keystore. caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd (Opsional) Kata sandi untuk kunci pribadi.
nifi.zookeeper.security.truststore Jalur ke keystore JKS, PKCS12, atau PEM yang berisi sertifikat atau sertifikat CA yang digunakan untuk mengautentikasi ZooKeeper. ./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType Jenis truststore. JKS, PKCS12, PEM, atau deteksi otomatis menurut ekstensi
nifi.zookeeper.security.truststorePasswd Kata sandi truststore. qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string String koneksi ke host atau kuorum ZooKeeper. String ini adalah daftar nilai host:port yang dipisahkan koma. Biasanya nilai secureClientPort tidak sama dengan nilai clientPort. Lihat konfigurasi ZooKeeper Anda untuk nilai yang benar. zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281

Contoh berikut menunjukkan bagaimana properti ini muncul di $NIFI_HOME/conf/nifi.properties:

nifi.zookeeper.client.secure=true
nifi.zookeeper.security.keystore=./conf/keystore.jks
nifi.zookeeper.security.keystoreType=JKS
nifi.zookeeper.security.keystorePasswd=caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd=
nifi.zookeeper.security.truststore=./conf/truststore.jks
nifi.zookeeper.security.truststoreType=JKS
nifi.zookeeper.security.truststorePasswd=qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string=zookeeper1.internal.cloudapp.net:2281,zookeeper2.internal.cloudapp.net:2281,zookeeper3.internal.cloudapp.net:2281

Untuk informasi selengkapnya tentang mengamankan ZooKeeper dengan TLS, lihat Panduan Administrasi Apache NiFi.

Identitas dan Access Control

Di NiFi, kontrol akses dan identitas dicapai melalui autentikasi dan otorisasi pengguna. Untuk autentikasi pengguna, NiFi memiliki beberapa opsi untuk dipilih: Pengguna Tunggal, LDAP, Kerberos, Security Assertion Markup Language (SAML), dan OpenID Connect (OIDC). Jika Anda tidak mengonfigurasi opsi, NiFi menggunakan sertifikat klien untuk mengautentikasi pengguna melalui HTTPS.

Jika Anda mempertimbangkan autentikasi multifaktor, kami sarankan kombinasi MICROSOFT Entra ID dan OIDC. MICROSOFT Entra ID mendukung akses menyeluruh (SSO) cloud-native dengan OIDC. Dengan kombinasi ini, pengguna dapat memanfaatkan banyak fitur keamanan perusahaan:

  • Mencatat dan memberi tahu aktivitas mencurigakan dari akun pengguna
  • Memantau upaya untuk mengakses kredensial yang dinonaktifkan
  • Memperingatkan perilaku masuk akun yang tidak biasa

Untuk otorisasi, NiFi menyediakan penegakan yang didasarkan pada kebijakan akses, pengguna, dan grup. NiFi menyediakan penegakan ini melalui UserGroupProviders dan AccessPolicyProviders. Secara default, penyedia menyertakan UserGroupProviders berbasis Azure Graph, File, LDAP, dan Shell. Dengan AzureGraphUserGroupProvider, Anda dapat sumber grup pengguna dari ID Microsoft Entra. Anda kemudian dapat menetapkan kebijakan ke grup ini. Untuk petunjuk konfigurasi, lihat Panduan Administrasi Apache NiFi.

AccessPolicyProviders yang didasarkan pada file dan Apache Ranger saat ini tersedia untuk mengelola dan menyimpan kebijakan pengguna dan grup. Untuk informasi terperinci, lihat dokumentasi Apache NiFi dan dokumentasi Apache Ranger.

Gateway aplikasi

Gateway aplikasi menyediakan penyeimbang beban lapisan-7 terkelola untuk antarmuka NiFi. Konfigurasikan gateway aplikasi untuk menggunakan set skala mesin virtual dari node NiFi sebagai kumpulan ujung belakangnya.

Untuk sebagian besar penginstalan NiFi, kami menyarankan konfigurasi Application Gateway berikut:

  • Tingkat: Standar
  • Ukuran SKU: sedang
  • Jumlah instans: dua atau lebih

Gunakan pemeriksaan kesehatan untuk memantau kesehatan server web pada setiap node. Hapus node yang tidak sehat dari rotasi penyeimbang beban. Pendekatan ini memudahkan untuk melihat antarmuka pengguna ketika keseluruhan kluster tidak sehat. Browser hanya mengarahkan Anda ke node yang saat ini sehat dan merespons permintaan.

Ada dua pemeriksaan kesehatan utama yang perlu dipertimbangkan. Bersama-sama, mereka memberikan heartbeat yang teratur pada kesehatan keseluruhan dari setiap node di kluster. Konfigurasikan pemeriksaan kesehatan pertama yang mengarah ke jalur /NiFi. Probe ini menentukan kesehatan antarmuka pengguna NiFi pada setiap node. Konfigurasikan pemeriksaan kesehatan kedua untuk jalur /nifi-api/controller/cluster. Probe ini menunjukkan apakah setiap node saat ini sehat dan bergabung ke kluster secara keseluruhan.

Anda memiliki dua opsi untuk mengonfigurasi alamat IP ujung depan gateway aplikasi:

  • Dengan alamat IP publik
  • Dengan alamat IP subnet privat

Hanya sertakan alamat IP publik jika pengguna perlu mengakses UI melalui internet publik. Jika akses internet publik untuk pengguna tidak diperlukan, akses ujung depan penyeimbang beban dari jumpbox di jaringan virtual atau melalui peering ke jaringan pribadi Anda. Jika Anda mengonfigurasi gateway aplikasi dengan alamat IP publik, sebaiknya aktifkan autentikasi sertifikat klien untuk NiFi dan aktifkan TLS untuk UI NiFi. Anda juga dapat menggunakan grup keamanan jaringan di subnet gateway aplikasi yang didelegasikan untuk membatasi alamat IP sumber.

Diagnostik dan pemantauan kesehatan

Dalam pengaturan diagnostik Application Gateway, ada opsi konfigurasi untuk mengirim metrik dan log akses. Dengan menggunakan opsi ini, Anda dapat mengirim informasi ini dari penyeimbang beban ke berbagai tempat:

  • Akun penyimpanan
  • Event Hubs
  • Ruang kerja Log Analytics

Mengaktifkan pengaturan ini berguna untuk melakukan penelusuran masalah penyeimbangan beban dan untuk mendapatkan wawasan tentang kesehatan node kluster.

Kueri Analitik Log berikut menunjukkan kondisi node kluster dari waktu ke waktu dari perspektif Application Gateway. Anda dapat menggunakan kueri serupa untuk menghasilkan peringatan atau tindakan perbaikan otomatis untuk node yang tidak sehat.

AzureDiagnostics
| summarize UnHealthyNodes = max(unHealthyHostCount_d), HealthyNodes = max(healthyHostCount_d) by bin(TimeGenerated, 5m)
| render timechart

Bagan hasil kueri berikut menunjukkan tampilan waktu kesehatan kluster:

Cuplikan layar bagan batang. Batang menunjukkan jumlah node yang sehat secara konstan selama periode 24 jam dan tidak ada node yang tidak sehat.

Ketersediaan

Saat Anda menerapkan solusi ini, ingatlah poin-poin berikut tentang ketersediaan:

Load Balancer

Gunakan penyeimbang beban untuk UI guna meningkatkan ketersediaan UI selama waktu henti node.

VM terpisah

Untuk meningkatkan ketersediaan, sebarkan kluster ZooKeeper pada VM terpisah dari VM di kluster NiFi. Untuk informasi selengkapnya tentang mengonfigurasi ZooKeeper, lihat Manajemen Status di Panduan Administrator Sistem Apache NiFi.

Zona ketersediaan

Sebarkan set skala mesin virtual NiFi dan kluster ZooKeeper dalam konfigurasi lintas zona untuk memaksimalkan ketersediaan. Ketika komunikasi antara node dalam kluster melintasi zona ketersediaan, ini memperkenalkan sejumlah kecil latensi. Tetapi latensi ini biasanya memiliki efek keseluruhan yang minimal pada throughput kluster.

Kumpulan skala komputer virtual

Kami merekomendasikan penyebaran node NiFi ke dalam satu set skala mesin virtual yang mencakup zona ketersediaan jika tersedia. Untuk informasi terperinci tentang menggunakan kumpulan timbangan dengan cara ini, lihat Membuat set skala mesin virtual yang menggunakan Zona Ketersediaan.

Pemantauan

Untuk memantau kesehatan dan performa kluster NiFi, gunakan tugas pelaporan.

Melaporkan pemantauan berbasis tugas

Untuk pemantauan, Anda dapat menggunakan tugas pelaporan yang Anda konfigurasikan dan jalankan di NiFi. Seperti yang dibahas Diagnostik dan pemantauan kesehatan, Analitik Log menyediakan tugas pelaporan dalam bundel NiFi Azure. Anda dapat menggunakan tugas pelaporan tersebut untuk mengintegrasikan pemantauan dengan Analitik Log dan sistem pemantauan atau pencatatan yang ada.

Kueri Log Analytics

Contoh kueri di bagian berikut dapat membantu Anda memulai. Untuk gambaran umum tentang cara mengkueri data Analitik Log, lihat kueri log Azure Monitor.

Kueri log di Monitor dan Analitik Log menggunakan versi Bahasa Kueri Kusto. Tetapi ada perbedaan antara kueri log dan kueri Kusto. Untuk informasi selengkapnya, lihat Gambaran umum kueri Kusto.

Untuk pembelajaran yang lebih terstruktur, lihat tutorial ini:

Tugas pelaporan Analitik Log

Secara default, NiFi mengirimkan data metrik ke tabel nifimetrics. Tetapi Anda dapat mengonfigurasi tujuan yang berbeda di properti tugas pelaporan. Tugas pelaporan menangkap metrik NiFi berikut:

Jenis metrik Nama metrik
Metrik NiFi FlowFilesReceived
Metrik NiFi FlowFilesSent
Metrik NiFi FlowFilesQueued
Metrik NiFi BytesReceived
Metrik NiFi BytesWritten
Metrik NiFi BytesRead
Metrik NiFi BytesSent
Metrik NiFi BytesQueued
Metrik status port InputCount
Metrik status port InputBytes
Metrik status koneksi QueuedCount
Metrik status koneksi QueuedBytes
Metrik status port OutputCount
Metrik status port OutputBytes
Metrik komputer virtual Java (JVM) jvm.uptime
Metrik JVM jvm.heap_used
Metrik JVM jvm.heap_usage
Metrik JVM jvm.non_heap_usage
Metrik JVM jvm.thread_states.runnable
Metrik JVM jvm.thread_states.blocked
Metrik JVM jvm.thread_states.timed_waiting
Metrik JVM jvm.thread_states.terminated
Metrik JVM jvm.thread_count
Metrik JVM jvm.daemon_thread_count
Metrik JVM jvm.file_descriptor_usage
Metrik JVM jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation
Metrik JVM jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation
Metrik JVM jvm.buff_pool_direct_capacity
Metrik JVM jvm.buff_pool_direct_count
Metrik JVM jvm.buff_pool_direct_mem_used
Metrik JVM jvm.buff_pool_mapped_capacity
Metrik JVM jvm.buff_pool_mapped_count
Metrik JVM jvm.buff_pool_mapped_mem_used
Metrik JVM jvm.mem_pool_code_cache
Metrik JVM jvm.mem_pool_compressed_class_space
Metrik JVM jvm.mem_pool_g1_eden_space
Metrik JVM jvm.mem_pool_g1_old_gen
Metrik JVM jvm.mem_pool_g1_survivor_space
Metrik JVM jvm.mem_pool_metaspace
Metrik JVM jvm.thread_states.new
Metrik JVM jvm.thread_states.waiting
Metrik Tingkat Prosesor BytesRead
Metrik Tingkat Prosesor BytesWritten
Metrik Tingkat Prosesor FlowFilesReceived
Metrik Tingkat Prosesor FlowFilesSent

Berikut ini kueri sampel untuk metrik BytesQueued kluster:

let table_name = nifimetrics_CL;
let metric = "BytesQueued";
table_name
| where Name_s == metric
| where Computer contains {ComputerName}
| project TimeGenerated, Computer, ProcessGroupName_s,  Count_d, Name_s
| summarize sum(Count_d) by bin(TimeGenerated, 1m),  Computer, Name_s
| render timechart 

Kueri itu menghasilkan bagan seperti yang ada di cuplikan layar ini:

Cuplikan layar bagan garis. Garis menunjukkan jumlah byte yang mengantre selama periode empat jam.

Catatan

Saat Anda menjalankan NiFi di Azure, Anda tidak terbatas pada tugas pelaporan Analitik Log. NiFi mendukung tugas pelaporan untuk banyak teknologi pemantauan pihak ketiga. Untuk daftar tugas pelaporan yang didukung, lihat bagian Tugas Pelaporan dari indeks Dokumentasi Apache NiFi.

Pemantauan infrastruktur NiFi

Selain tugas pelaporan, instal ekstensi VM Analitik Log pada node NiFi dan ZooKeeper. Ekstensi ini mengumpulkan log, metrik tingkat VM tambahan, dan metrik dari ZooKeeper.

Log kustom untuk aplikasi NiFi, pengguna, bootstrap, dan ZooKeeper

Untuk menangkap lebih banyak log, ikuti langkah-langkah berikut:

  1. Di portal Azure, pilih Ruang kerja Analitik Log, lalu pilih ruang kerja Anda.

  2. Di bawah Pengaturan, pilih Log kustom.

    Cuplikan layar halaman MyWorkspace di portal Azure. Pengaturan dan Log kustom dipanggil.

  3. Pilih Tambahkan log kustom.

    Cuplikan layar halaman Log kustom di portal Azure dengan Tambahkan log kustom dipanggil.

  4. Siapkan log kustom dengan nilai-nilai ini:

    • Nama: NiFiAppLogs
    • Jenis jalur: Linux
    • Nama jalur: /opt/nifi/logs/nifi-app.log

    Cuplikan layar jendela NiFi. Nilai konfigurasi log kustom untuk aplikasi NiFi terlihat.

  5. Siapkan log kustom dengan nilai-nilai ini:

    • Nama: NiFiBootstrapAndUser
    • Jenis jalur pertama: Linux
    • Nama jalur pertama: /opt/nifi/logs/nifi-user.log
    • Jenis jalur kedua: Linux
    • Nama jalur kedua: /opt/nifi/logs/nifi-bootstrap.log

    Cuplikan layar jendela NiFi. Nilai konfigurasi dari log kustom untuk pengguna dan bootstrap NiFi terlihat.

  6. Siapkan log kustom dengan nilai-nilai ini:

    • Nama: NiFiZK
    • Jenis jalur: Linux
    • Nama jalur: /opt/zookeeper/logs/*.out

    Cuplikan layar jendela NiFi. Nilai konfigurasi log kustom untuk ZooKeeper terlihat.

Berikut ini kueri sampel dari tabel khusus NiFiAppLogs yang dibuat oleh contoh pertama:

NiFiAppLogs_CL
| where TimeGenerated > ago(24h)
| where Computer contains {ComputerName} and RawData contains "error"
| limit 10

Kueri tersebut menghasilkan hasil yang mirip dengan hasil berikut:

Cuplikan layar hasil kueri yang menyertakan stempel waktu, komputer, data mentah, jenis, dan I D sumber daya.

Konfigurasi log infrastruktur

Anda dapat menggunakan Monitor untuk memantau dan mengelola VM atau komputer fisik. Sumber daya ini dapat berada di pusat data lokal Anda atau lingkungan cloud lainnya. Untuk menyiapkan pemantauan ini, sebarkan agen Analitik Log. Konfigurasikan agen untuk melapor ke ruang kerja Analitik Log. Untuk informasi selengkapnya, lihat Gambaran umum agen Analitik Log.

Cuplikan layar berikut menunjukkan contoh konfigurasi agen untuk VM NiFi. Tabel Perf ​​menyimpan data yang dikumpulkan.

Cuplikan layar menampilkan jendela Pengaturan tingkat lanjut. Menu Data dan Penghitung Performa Linux disorot. Pengaturan penghitung performa terlihat.

Berikut adalah kueri sampel untuk log Perf aplikasi NiFi:

let cluster_name = {ComputerName};
// The hourly average of CPU usage across all computers.
Perf
| where Computer contains {ComputerName}
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| where ObjectName == "Processor"
| summarize CPU_Time_Avg = avg(CounterValue) by bin(TimeGenerated, 30m), Computer

Kueri tersebut menghasilkan laporan seperti yang ada di cuplikan layar ini:

Cuplikan layar diagram garis. Garis menunjukkan persentase CPU yang digunakan VM NiFi selama periode empat jam.

Peringatan

Gunakan Monitor untuk membuat peringatan tentang kesehatan dan performa kluster NiFi. Contoh peringatan meliputi:

  • Jumlah antrean total telah melampaui ambang batas.
  • Nilai BytesWritten berada di bawah ambang yang diharapkan.
  • Nilai FlowFilesReceived berada di bawah ambang.
  • Kluster tidak sehat.

Untuk informasi selengkapnya tentang menyiapkan peringatan di Monitor, lihat Gambaran umum peringatan di Microsoft Azure.

Parameter konfigurasi

Bagian berikut membahas konfigurasi non-default yang direkomendasikan untuk NiFi dan dependensinya, termasuk ZooKeeper dan Java. Pengaturan ini cocok untuk ukuran kluster yang dimungkinkan di cloud. Atur properti di file konfigurasi berikut:

  • $NIFI_HOME/conf/nifi.properties
  • $NIFI_HOME/conf/bootstrap.conf
  • $ZOOKEEPER_HOME/conf/zoo.cfg
  • $ZOOKEEPER_HOME/bin/zkEnv.sh

Untuk informasi terperinci tentang properti dan file konfigurasi yang tersedia, lihat Panduan Administrator Sistem Apache NiFi dan Panduan Administrator ZooKeeper.

NiFi

Untuk penyebaran Azure, pertimbangkan untuk menyesuaikan properti di $NIFI_HOME/conf/nifi.properties. Tabel berikut mencantumkan properti yang paling penting. Untuk rekomendasi dan wawasan lebih lanjut, lihat milis Apache NiFi.

Parameter Deskripsi Default Rekomendasi
nifi.cluster.node.connection.timeout Berapa lama waktu yang dibutuhkan untuk menunggu saat membuka koneksi ke node kluster lain. 5 detik 60 detik
nifi.cluster.node.read.timeout Berapa lama waktu yang dibutuhkan untuk menunggu respons saat membuat permintaan ke node kluster lain. 5 detik 60 detik
nifi.cluster.protocol.heartbeat.interval Seberapa sering waktu yang dibutuhkan untuk mengirim heartbeat kembali ke koordinator kluster. 5 detik 60 detik
nifi.cluster.node.max.concurrent.requests Tingkat paralelisme apa yang digunakan saat mereplikasi panggilan HTTP seperti panggilan REST API ke node kluster lainnya. 100 500
nifi.cluster.node.protocol.threads Ukuran kumpulan utas awal untuk komunikasi yang direplikasi/antar-kluster. 10 50
nifi.cluster.node.protocol.max.threads Jumlah maksimum utas yang digunakan untuk komunikasi yang direplikasi/antar-kluster. 50 75
nifi.cluster.flow.election.max.candidates Jumlah node yang akan digunakan saat memutuskan aliran saat ini. Nilai ini membuat hubungan arus pendek pada suara untuk nomor yang ditentukan. kosong 75
nifi.cluster.flow.election.max.wait.time Berapa lama waktu yang dibutuhkan untuk menunggu di node sebelum memutuskan apa aliran saat ini. 5 menit 5 menit

Perilaku kluster

Saat Anda mengonfigurasi kluster, perhatikan poin-poin berikut.

Waktu habis

Untuk memastikan kesehatan keseluruhan dari kluster dan node-nya, akan bermanfaat untuk meningkatkan waktu tunggu. Praktik ini membantu menjamin bahwa kegagalan tidak diakibatkan oleh masalah jaringan sementara atau beban tinggi.

Dalam sistem terdistribusi, performa sistem individu dapat bervariasi. Variasi ini mencakup komunikasi jaringan dan latensi, yang biasanya memengaruhi komunikasi antar-node dan antar-kluster. Infrastruktur jaringan atau sistem itu sendiri dapat menyebabkan variasi ini. Oleh karena itu, kemungkinan variasi sangat mungkin terjadi dalam kelompok besar sistem. Dalam aplikasi Java yang sedang dimuat, jeda dalam pengumpulan sampah (GC) di mesin virtual Java (JVM) juga dapat memengaruhi waktu respons permintaan.

Gunakan properti di bagian berikut untuk mengonfigurasi batas waktu yang sesuai dengan kebutuhan sistem Anda:

nifi.cluster.node.connection.timeout dan nifi.cluster.node.read.timeout

Properti nifi.cluster.node.connection.timeout menentukan berapa lama waktu yang dibutuhkan untuk menunggu saat membuka koneksi. Properti nifi.cluster.node.read.timeout menentukan berapa lama waktu yang dibutuhkan untuk menunggu saat menerima data di antara permintaan. Nilai default untuk setiap properti adalah lima detik. Properti ini berlaku untuk permintaan node-ke-node. Meningkatkan nilai-nilai ini membantu meringankan beberapa masalah terkait:

  • Terputus oleh koordinator kluster karena gangguan heartbeat
  • Gagal mendapatkan aliran dari koordinator saat bergabung dengan kluster
  • Membangun komunikasi penyeimbangan beban dan situs-ke-stius (S2S)

Kecuali jika kluster Anda memiliki set skala yang sangat kecil, misalnya tiga node atau kurang, gunakan nilai yang lebih besar dari nilai default.

nifi.cluster.protocol.heartbeat.interval

Sebagai bagian dari strategi pengelompokan NiFi, setiap node memancarkan heartbeat untuk mengomunikasikan status sehatnya. Secara default, node mengirim heartbeat setiap lima detik. Jika koordinator kluster mendeteksi bahwa delapan heartbeat berturut-turut dari sebuah node telah gagal, koordinator kluster memutuskan koneksi node tersebut. Tingkatkan interval yang diatur di properti nifi.cluster.protocol.heartbeat.interval untuk membantu mengakomodasi detak jantung yang lambat dan mencegah kluster memutuskan node yang tidak perlu.

Konkurensi

Gunakan properti di bagian berikut untuk mengonfigurasi pengaturan konkurensi:

nifi.cluster.node.protocol.threads dan nifi.cluster.node.protocol.max.threads

Properti nifi.cluster.node.protocol.max.threads menentukan jumlah maksimum utas yang akan digunakan untuk semua komunikasi kluster seperti penyeimbangan beban S2S dan agregasi UI. Jumlah default untuk properti ini adalah 50 utas. Untuk kluster besar, tingkatkan nilai ini untuk memperhitungkan jumlah permintaan yang lebih besar yang diperlukan operasi ini.

Properti nifi.cluster.node.protocol.threads menentukan ukuran kumpulan utas awal. Nilai default adalah 10 utas. Nilai ini adalah minimum. Nilai tersebut tumbuh sesuai kebutuhan hingga set maksimum di nifi.cluster.node.protocol.max.threads. Tingkatkan nilai nifi.cluster.node.protocol.threads untuk kluster yang menggunakan set skala besar saat peluncuran.

nifi.cluster.node.max.concurrent.requests

Banyak permintaan HTTP seperti panggilan REST API dan panggilan UI perlu direplikasi ke node lain dalam kluster. Seiring bertambahnya ukuran kluster, semakin banyak permintaan yang direplikasi. Properti nifi.cluster.node.max.concurrent.requests membatasi jumlah permintaan yang tersisa. Nilainya harus melebihi ukuran kluster yang diharapkan. Nilai default adalah 100 permintaan bersamaan. Kecuali Anda menjalankan kluster kecil yang terdiri dari tiga atau lebih sedikit node, cegah permintaan yang gagal dengan meningkatkan nilai ini.

Pemilihan Flow

Gunakan properti di bagian berikut untuk mengonfigurasi pengaturan pemilihan alur:

nifi.cluster.flow.election.max.candidates

NiFi menggunakan pengelompokan zero-leader, yang berarti tidak ada satu node otoritatif tertentu. Oleh karena itu, node memilih definisi aliran mana yang dianggap benar. Mereka juga memilih untuk memutuskan node mana yang bergabung dengan kluster.

Secara default, properti nifi.cluster.flow.election.max.candidates adalah waktu tunggu maksimum yang ditentukan oleh properti nifi.cluster.flow.election.max.wait.time. Ketika nilai ini terlalu tinggi, proses mulai bisa menjadi lambat. Nilai default untuk nifi.cluster.flow.election.max.wait.time adalah lima menit. Atur jumlah maksimum kandidat ke nilai non-kosong seperti 1 atau lebih besar untuk memastikan bahwa penantian tidak lebih lama dari yang dibutuhkan. Jika Anda mengatur properti ini, tetapkan nilai yang sesuai dengan ukuran kluster atau sebagian besar dari ukuran kluster yang diharapkan. Untuk kluster statis kecil yang terdiri dari 10 atau lebih sedikit node, atur nilai ini ke jumlah node dalam kluster.

nifi.cluster.flow.election.max.wait.time

Dalam lingkungan cloud yang elastis, waktu untuk memprovisikan host mempengaruhi waktu mulai aplikasi. Properti nifi.cluster.flow.election.max.wait.time menentukan berapa lama NiFi menunggu sebelum memutuskan aliran. Jadikan nilai ini sepadan dengan keseluruhan waktu peluncuran kluster pada ukuran awalnya. Dalam pengujian awal, lima menit lebih dari cukup di semua wilayah Azure dengan jenis instans yang direkomendasikan. Tetapi Anda dapat meningkatkan nilai ini jika waktu provisi secara teratur melebihi default.

Java

Sebaiknya gunakan rilis LTS dari Java. Dari rilis ini, Java 11 sedikit lebih disukai daripada Java 8 karena Java 11 mendukung implementasi pengumpulan sampah yang lebih cepat. Namun, penyebaran NiFi berperforma tinggi dimungkinkan dengan menggunakan salah satu rilis.

Bagian berikut membahas konfigurasi JVM umum untuk digunakan saat menjalankan NiFi. Atur parameter JVM di file konfigurasi bootstrap di $NIFI_HOME/conf/bootstrap.conf.

Pengumpul sampah

Jika Anda menjalankan Java 11, sebaiknya gunakan pengumpul sampah G1 (G1GC) di sebagian besar situasi. G1GC telah meningkatkan performa jika dibandingkan ParallelGC karena G1GC mengurangi panjang jeda GC. G1GC adalah pengaturan default di Java 11, tetapi Anda dapat mengonfigurasinya secara eksplisit dengan mengatur nilai berikut di bootstrap.conf:

java.arg.13=-XX:+UseG1GC

Jika Anda menjalankan Java 8, jangan gunakan G1GC. Gunakan ParallelGC sebagai gantinya. Ada kekurangan dalam implementasi G1GC di Java 8 yang mencegah Anda untuk menggunakannya dengan implementasi repositori yang direkomendasikan. ParallelGC lebih lambat dari G1GC. Tetapi dengan ParallelGC, Anda masih dapat memiliki penyebaran NiFi berperforma tinggi dengan Java 8.

Heap

Satu set properti dalam file bootstrap.conf menentukan konfigurasi tumpukan NiFi JVM. Untuk aliran standar, konfigurasikan tumpukan 32 GB dengan menggunakan pengaturan berikut:

java.arg.3=-Xmx32g
java.arg.2=-Xms32g

Untuk memilih ukuran tumpukan yang optimal untuk diterapkan pada proses JVM, pertimbangkan dua faktor:

  • Karakteristik aliran data
  • Cara NiFi menggunakan memori dalam pemrosesannya

Untuk dokumentasi terperinci, lihat Apache NiFi in Depth.

Buat tumpukan hanya sebesar yang diperlukan untuk memenuhi persyaratan pemrosesan. Pendekatan ini meminimalkan panjang jeda GC. Untuk pertimbangan umum untuk pengumpulan sampah Java, lihat panduan penyetelan pengumpulan sampah untuk versi Java Anda.

Saat menyesuaikan pengaturan memori JVM, pertimbangkan faktor-faktor penting berikut:

  • Jumlah FlowFiles, atau catatan data NiFi, yang aktif dalam periode tertentu. Jumlah ini termasuk FlowFiles yang diantrekan atau ditekan kembali.

  • Jumlah atribut yang ditentukan dalam FlowFiles.

  • Jumlah memori yang dibutuhkan prosesor untuk memproses konten tertentu.

  • Cara prosesor memproses data:

    • Data streaming
    • Menggunakan prosesor berorientasi rekaman
    • Menyimpan semua data dalam memori sekaligus

Detail ini penting. Selama pemrosesan, NiFi menyimpan referensi dan atribut untuk setiap FlowFile dalam memori. Pada performa puncak, jumlah memori yang digunakan sistem sebanding dengan jumlah FlowFiles langsung dan semua atribut yang ada di dalamnya. Jumlah ini termasuk FlowFiles yang mengantre. NiFi dapat bertukar ke disk. Namun, hindari opsi ini karena merugikan performa.

Perlu diingat juga tentang penggunaan memori objek dasar. Secara khusus, buat tumpukan Anda cukup besar untuk menampung objek dalam memori. Pertimbangkan tips berikut untuk mengonfigurasi pengaturan memori:

  • Jalankan aliran Anda dengan data perwakilan dan tekanan balik minimal dengan memulai melalui pengaturan -Xmx4G, lalu meningkatkan memori secara konservatif sesuai kebutuhan.
  • Jalankan aliran Anda dengan data representatif dan tekanan balik puncak dengan memulai melalui pengaturan -Xmx4G, lalu meningkatkan ukuran kluster secara konservatif sesuai kebutuhan.
  • Buat profil aplikasi saat aliran sedang berjalan dengan menggunakan alat seperti VisualVM dan YourKit.
  • Jika peningkatan konservatif dalam tumpukan tidak meningkatkan performa secara signifikan, pertimbangkan untuk mendesain ulang aliran, prosesor, dan aspek lain dari sistem Anda.
Parameter JVM tambahan

Tabel berikut mencantumkan opsi JVM tambahan. Ini juga memberikan nilai yang bekerja paling baik dalam pengujian awal. Pengujian mengamati aktivitas GC dan penggunaan memori serta menggunakan profil yang cermat.

Parameter Deskripsi Default JVM Rekomendasi
InitiatingHeapOccupancyPercent Jumlah tumpukan yang digunakan sebelum siklus penandaan dipicu. 45 35
ParallelGCThreads Jumlah utas yang digunakan GC. Nilai ini dibatasi untuk membatasi efek keseluruhan pada sistem. 5/8 dari jumlah vCPU 8
ConcGCThreads Jumlah utas GC untuk dijalankan secara paralel. Nilai ini ditingkatkan untuk memperhitungkan ParallelGCThreads yang dibatasi. 1/4 dari nilai ParallelGCThreads 4
G1ReservePercent Persentase memori cadangan untuk tetap bebas. Nilai ini ditingkatkan untuk menghindari kelelahan ruang, yang membantu menghindari GC penuh. 10 20
UseStringDeduplication Apakah akan mencoba mengidentifikasi dan menghapus duplikat referensi ke string yang identik. Mengaktifkan fitur ini dapat menghemat memori. - hadiah

Konfigurasikan pengaturan ini dengan menambahkan entri berikut ke NiFi bootstrap.conf:

java.arg.17=-XX:+UseStringDeduplication
java.arg.18=-XX:G1ReservePercent=20
java.arg.19=-XX:ParallelGCThreads=8
java.arg.20=-XX:ConcGCThreads=4
java.arg.21=-XX:InitiatingHeapOccupancyPercent=35

Zookeeper

Untuk meningkatkan toleransi kesalahan, jalankan ZooKeeper sebagai kluster. Ambil pendekatan ini meskipun sebagian besar penyebaran NiFi menempatkan beban yang relatif sederhana pada ZooKeeper. Aktifkan pengelompokan untuk ZooKeeper secara eksplisit. Secara default, ZooKeeper berjalan dalam mode server tunggal. Untuk informasi terperinci, lihat Penyiapan Kluster (Multi-Server) di Panduan Administrator ZooKeeper.

Kecuali untuk pengaturan pengklusteran, gunakan nilai default untuk konfigurasi ZooKeeper Anda.

Jika Anda memiliki kluster NiFi besar, Anda mungkin perlu menggunakan sejumlah besar server ZooKeeper. Untuk ukuran kluster yang lebih kecil, ukuran VM yang lebih kecil dan disk yang dikelola SSD Standar sudah cukup.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Materi dan rekomendasi dalam dokumen ini berasal dari beberapa sumber:

  • Percobaan
  • Praktik terbaik Azure
  • Praktik terbaik, dokumentasi, dan pengetahuan komunitas NiFi

Untuk informasi selengkapnya, lihat sumber daya berikut: