Elasticsearch:Konfigurasi parameter YML

Catatan penggunaan

Ubah konfigurasi

1. Buka halaman detail kluster.

   1. Masuk ke Konsol Alibaba Cloud Elasticsearch.
   2. Pada panel navigasi kiri, klik Elasticsearch Clusters.
   3. Pada bilah navigasi atas, pilih kelompok sumber daya dan wilayah. Pada halaman Clusters, klik ID kluster yang diinginkan.
   4. Pada panel navigasi kiri halaman yang muncul, klik

2. Buka halaman konfigurasi file YML.

3. Pada panel navigasi kiri, klik Configuration and Management > Cluster Configuration.

4. Pada halaman ES Cluster Configuration, klik Modify Configuration di sebelah kanan YML File Configuration.

5. Pada kotak dialog YML File Configuration, konfigurasikan parameter yang diperlukan.

   Catatan

   Untuk melihat isi elasticsearch.yml, buka Konsol Kibana dan jalankan perintah GET _cluster/settings?include_defaults.

   Parameter	Deskripsi
   Auto Indexing	Menentukan apakah akan secara otomatis membuat indeks saat dokumen dikirim ke indeks yang tidak ada. Ini sesuai dengan pengaturan action.auto_create_index dalam file YML. Nilai default-nya adalah false. Alibaba Cloud Elasticsearch menonaktifkan pembuatan indeks otomatis secara default. Anda dapat mengaktifkannya dengan salah satu cara berikut: Penting Indeks yang dibuat secara otomatis mungkin tidak memenuhi kebutuhan Anda. Evaluasi dampaknya sebelum mengaktifkan fitur ini. Aktifkan pengaturan ini di Cluster Configuration di konsol. Ini merupakan perubahan statis yang memicu restart kluster. Aktifkan secara dinamis tanpa restart. Masuk ke Konsol Kibana dan gunakan salah satu perintah berikut untuk mengizinkan pembuatan indeks otomatis: Izinkan pembuatan otomatis untuk semua indeks PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "true" } } } Penting Perintah ini mengizinkan pembuatan otomatis semua indeks. Untuk menonaktifkan fitur ini, ubah true menjadi false. Izinkan pembuatan otomatis hanya untuk indeks tertentu. Contoh berikut hanya mengizinkan indeks sistem dibuat secara otomatis: PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "+.*,-*" } } }
   Index Deletion	Menentukan apakah Anda harus secara eksplisit menyebutkan nama indeks untuk menghapusnya. Jika Anda memilih Allow Wildcards, Anda dapat menggunakan wildcard untuk menghapus indeks secara massal. Indeks yang dihapus tidak dapat dipulihkan. Gunakan pengaturan ini dengan hati-hati. Ini sesuai dengan pengaturan action.destructive_requires_name dalam file YML. Nilai default-nya adalah true.
   Audit Log Indexing	Jika diaktifkan, sistem mencatat log audit untuk operasi seperti create, delete, update, dan query pada kluster Elasticsearch. Log audit mengonsumsi ruang disk dan dapat memengaruhi kinerja. Aktifkan fitur ini hanya jika diperlukan. Untuk informasi lebih lanjut tentang parameter, lihat Konfigurasi log audit. Penting Untuk Elasticsearch 7.x dan versi setelahnya, Anda dapat melihat log audit di konsol. Fitur ini hanya tersedia di beberapa wilayah. Untuk informasi lebih lanjut, lihat Batasan. Untuk melihat log, Anda harus terlebih dahulu mengaktifkan Audit Log Indexing. Untuk informasi lebih lanjut, lihat Kueri log. Untuk versi lainnya, lihat log audit di dalam kluster. Misalnya, Anda dapat mengkueri indeks yang namanya diawali dengan .security_audit_log-* di Konsol Kibana. Ini sesuai dengan pengaturan xpack.security.audit.enabled dalam file YML. Nilai default-nya adalah false.
   Watcher	Jika diaktifkan, Anda dapat menggunakan fitur Watcher dari X-Pack. Bersihkan secara berkala indeks .watcher-history* untuk mencegahnya mengonsumsi ruang disk berlebihan. Ini sesuai dengan pengaturan xpack.watcher.enabled dalam file YML. Nilai default-nya adalah false.
   Other Configurations	Parameter berikut juga didukung. Kecuali dinyatakan lain, konfigurasi ini kompatibel dengan Elasticsearch 5.x, 6.x, dan 7.x secara default. Konfigurasi akses CORS http.cors.enabled http.cors.allow-origin http.cors.max-age http.cors.allow-methods http.cors.allow-headers http.cors.allow-credentials Konfigurasi daftar putih reindex jarak jauh reindex.remote.whitelist Konfigurasi log audit Versi Elasticsearch 7.x dan 8.x hanya mendukung parameter xpack.security.audit.logfile.events.include. Versi 5.x dan 6.x mendukung parameter berikut: xpack.watcher.enabled xpack.notification xpack.security.audit.enabled xpack.security.audit.index.bulk_size xpack.security.audit.index.flush_interval xpack.security.audit.index.rollover xpack.security.audit.index.events.include xpack.security.audit.index.events.exclude xpack.security.audit.index.events.emit_request_body xpack.security.audit.index.settings.index Fitur LDAP Semua versi kecuali 5.x mendukung hal berikut: xpack.security.authc.realms.ldap1 xpack.security.authc.realms.active_directory1 xpack.security.authc.realms.pki1 xpack.security.authc.realms.saml1 xpack.security.authc.realms.kerberos1 xpack.security.authc.token.enabled Konfigurasi ukuran antrian thread_pool.bulk.queue_size (untuk versi 5.x dan 6.x) thread_pool.write.queue_size (untuk versi 6.x, 7.x, dan 8.x) thread_pool.search.queue_size Konfigurasi plugin SQL kustom xpack.sql.enabled Secara default, kluster Elasticsearch mengaktifkan plugin SQL bawaan di X-Pack. Jika Anda ingin mengunggah plugin SQL kustom, atur xpack.sql.enabled ke false. Konfigurasi pipeline (pra-pemrosesan) index.default_pipeline: Menentukan pipeline ingest default untuk suatu indeks. Pipeline ini dijalankan sebelum pipeline apa pun yang ditentukan dalam permintaan indeks individual, memproses dokumen sebelum ditulis ke indeks. index.final_pipeline: Menentukan pipeline ingest akhir untuk suatu indeks. Pipeline ini dijalankan setelah semua pipeline lain, termasuk default_pipeline, selesai dijalankan. Berbeda dengan default_pipeline, final_pipeline hanya dipicu selama penulisan dokumen awal. Secara default, operasi pembaruan tidak memicu final_pipeline. Untuk memaksa final_pipeline dijalankan selama operasi pembaruan, atur doc_as_upsert ke true. Contoh konfigurasi YML: index.default_pipeline: my_pipeline index.final_pipeline: my_final_pipeline Konfigurasi batas hasil kueri index.max_result_window: Mengontrol jumlah maksimum hasil yang dapat dikembalikan oleh parameter from + size dalam kueri. Untuk Elasticsearch 7.4.0 dan versi setelahnya, nilai default-nya adalah 10000. Anda dapat mengubah nilai ini (hingga 100000) dengan menjalankan perintah REST API berikut: PUT /<index_name>/_settings { "index": { "max_result_window": 100000 } } Penting Mengatur max_result_window ke nilai besar meningkatkan beban memori dan CPU. Untuk skenario paginasi dalam, gunakan scroll API atau search_after alih-alih menaikkan nilai ini. Pertahankan pengaturan cluster.max_shards_per_node Parameter cluster.max_shards_per_node membatasi jumlah maksimum shard (termasuk shard utama dan shard replika) per node data. Anda dapat mengubah parameter ini dengan menjalankan perintah berikut di Kibana Dev Tools: PUT /_cluster/settings { "persistent": { "cluster.max_shards_per_node": 3000 } } Kata kunci persistent berarti perubahan ini disimpan ke konfigurasi kluster dan tetap efektif bahkan setelah instans Elasticsearch direstart. Anda tidak perlu mengonfigurasi ulang parameter ini setelah restart. Nonaktifkan pengumpulan data pemantauan Jika kluster Anda tidak memiliki kueri aktif tetapi penggunaan memori tetap tinggi, Anda dapat menonaktifkan pengumpulan data pemantauan untuk mengurangi penggunaan memori. Jalankan perintah berikut di Kibana Dev Tools: PUT _cluster/settings { "persistent": { "xpack.monitoring.collection.indices": "*,-.*" } } Penting Setelah Anda menonaktifkan pengumpulan data pemantauan, halaman Monitoring di Kibana tidak lagi menampilkan informasi pemantauan indeks. Untuk melihat status indeks, jalankan perintah GET _cat/indices sebagai gantinya.
   Forced Update	Mengontrol apakah perubahan konfigurasi YML dipaksakan. Nilai yang valid: Close: Perubahan tidak dipaksakan. Anda dapat memilih mode perubahan (perubahan in-place atau perubahan blue-green) sesuai kebutuhan. Sistem memeriksa kesehatan kluster, seperti ketersediaan node dan status alokasi shard, untuk memastikan perubahan aman. Enable: Perubahan dipaksakan. Sistem mengabaikan status kesehatan kluster, seperti kegagalan node atau shard yang tidak ditugaskan, yang berpotensi menyebabkan ketidakstabilan selama fase restart.
   Update Mode	Menentukan cara menerapkan perubahan ke file YML. Nilai yang valid: Catatan Anda hanya dapat mengonfigurasi parameter Forced Update ketika parameter Close diatur ke Close. In-place Update (Default): Sistem melakukan perubahan bergulir pada node yang perlu diperbarui. Data tidak disalin selama perubahan, dan durasi tidak dipengaruhi oleh volume data. Namun, metode ini dapat memengaruhi kinerja kluster. Blue-green Update: Sistem menambahkan jumlah node baru yang sama, menyalin data, lalu beralih ke node baru secara mulus. Proses ini lebih lancar tetapi memakan waktu lebih lama, dan alamat IP node berubah. Untuk informasi lebih lanjut tentang mode perubahan, lihat Mode perubahan.

   Penting

   • Mengonfigurasi file YML memicu restart bergulir kluster. Jika indeks dalam kluster memiliki replika dan beban kluster normal (utilisasi CPU sekitar 60%, penggunaan memori heap sekitar 50%, dan load_1m lebih rendah dari jumlah core CPU), layanan biasanya tetap tersedia selama restart. Durasi restart bergantung pada ukuran kluster, volume data, dan beban. Lakukan operasi ini selama jam sepi.

   • Jika beban kluster tinggi, indeks tidak memiliki replika, dan workload Anda melibatkan banyak permintaan tulis atau kueri, timeout akses sesekali dapat terjadi selama perubahan kluster. Konfigurasikan mekanisme retry di skrip akses client Anda untuk meminimalkan dampak pada layanan Anda.

   • Jika perubahan blue-green sedang berlangsung untuk konfigurasi YML kluster (seperti scaling up atau down) dan status kluster adalah Updating, hanya perubahan in-place yang didukung untuk perubahan tambahan. Anda dapat melihat riwayat perubahan untuk memeriksa apakah perubahan blue-green sedang berlangsung untuk konfigurasi YML.

6. Pilih This operation will restart the cluster. Continue? dan klik OK.

   Setelah Anda mengonfirmasi, kluster Elasticsearch akan direstart. Selama restart, Anda dapat melihat progresnya di daftar Tasks. Setelah restart selesai, konfigurasi file YML berlaku.

Konfigurasi akses CORS

Konfigurasi daftar putih Reindex API

Untuk memastikan migrasi data antar kluster yang aman, Anda harus menambahkan alamat koneksi pribadi dan port kluster ES_2 ke daftar putih Reindex API kluster ES_1.

1. Buka halaman Security untuk ES_1 dan klik Edit di sebelah Configure Private Connection. Di panel samping Configure Private Connection, klik Endpoint ID yang dituju.

   Untuk menambahkan koneksi baru, klik + Add Private Connection di bagian bawah panel samping Configure instance private connection.

2. Di konsol VPC, pada tab Endpoint Connections, klik ikon di sebelah ID endpoint untuk melihat nama domain-nya.

   Penting

   Anda harus menghapus identifikasi zona ketersediaan dari nama domain sebelum menambahkannya ke daftar putih Reindex API.

   Misalnya, jika nama domain lengkapnya adalah "ep-bp1****************-cn-hangzhou-i.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com", hapus identifikasi zona ketersediaan "-cn-hangzhou-i" untuk mendapatkan nama domain akhir: "ep-bp1bp1****************.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com".

3. Di file YML untuk ES_1, konfigurasikan daftar putih Reindex API. Entri daftar putih harus berupa nama domain dan port endpoint.

   reindex:
     remote:
       whitelist: >-
         ep-bp1bp1****************.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com:9200

   Pada halaman ES cluster configuration, klik Modify configuration di sebelah kanan YML configuration. Di editor YAML Other configure pada panel, tambahkan konfigurasi daftar putih tersebut.

Konfigurasi log audit

Versi 7.x dan setelahnya

1. Buka panel YML File Configuration.

   Untuk informasi lebih lanjut, lihat Ubah konfigurasi.

2. Di bagian Audit Log Indexing, pilih Enable untuk mengaktifkan log audit.

3. Sesuaikan konfigurasi log audit.

   Setelah Anda mengaktifkan log audit, Anda dapat mengonfigurasi parameter xpack.security.audit.logfile.events.include di Other Configurations. Contoh:

   xpack:
     security:
       audit:
         logfile:
           events:
             include: >-
               access_denied,anonymous_access_denied,authentication_failed,connection_denied,tampered_request,run_as_denied,run_as_granted

   Penting

   • Untuk kluster versi 7.x dan setelahnya, Anda hanya dapat mengonfigurasi parameter xpack.security.audit.logfile.events.include.

   • Secara default, konfigurasi log audit hanya mencatat log untuk permintaan yang ditolak atau gagal. Untuk mendapatkan log permintaan yang berhasil, tambahkan event access_granted. Hal ini menyimpan semua informasi akses ke disk, yang dapat menyebabkan penggunaan disk tinggi. Setelah troubleshooting selesai, nonaktifkan fitur log audit.

4. Lihat log audit.

   Untuk kluster versi 7.x dan setelahnya, setelah Anda mengaktifkan Audit Log Indexing, Anda dapat melihat log audit di halaman View Logs di konsol. Untuk informasi lebih lanjut, lihat Kueri log. Fitur ini hanya tersedia di beberapa wilayah. Untuk informasi lebih lanjut, lihat Batasan.

Versi 5.x dan 6.x

1. Buka panel YML File Configuration.

   Untuk informasi lebih lanjut, lihat Konfigurasi file YML.

2. Di bagian Audit Log Indexing, pilih Enable untuk mengaktifkan log audit.

   Berikut adalah konfigurasi default untuk pengindeksan log audit. Anda dapat menyesuaikannya sesuai kebutuhan bisnis Anda.

   xpack.security.audit.index.bulk_size: 5000
   xpack.security.audit.index.events.emit_request_body: false
   xpack.security.audit.index.events.exclude: run_as_denied,anonymous_access_denied,realm_authentication_failed,access_denied,connection_denied
   xpack.security.audit.index.events.include: authentication_failed,access_granted,tampered_request,connection_granted,run_as_granted
   xpack.security.audit.index.flush_interval: 180s
   xpack.security.audit.index.rollover: hourly
   xpack.security.audit.index.settings.index.number_of_replicas: 1
   xpack.security.audit.index.settings.index.number_of_shards: 10

   Parameter	Default	Deskripsi
   xpack.security.audit.index.bulk_size	1000	Jumlah event audit yang ditulis ke indeks log audit dalam satu permintaan batch.
   xpack.security.audit.index.flush_interval	1s	Frekuensi event yang dibuffer di-flush ke indeks.
   xpack.security.audit.index.rollover	daily	Frekuensi pembuatan indeks baru melalui rollover. Nilai yang valid adalah hourly, daily, weekly, atau monthly.
   xpack.security.audit.logfile.events.include	access_denied,anonymous_access_denied,authentication_failed, connection_denied,tampered_request,run_as_denied,run_as_granted	Jenis event log audit yang dikumpulkan. Fitur ini hanya tersedia di beberapa wilayah. Untuk informasi lebih lanjut, lihat Batasan. Untuk daftar lengkap jenis event, lihat Audit event types (7.x).
   xpack.security.audit.index.events.include	access_denied, access_granted, anonymous_access_denied, authentication_failed, connection_denied, tampered_request, run_as_denied, run_as_granted	Jenis event log audit yang ditulis ke indeks. Parameter ini hanya didukung untuk kluster versi 5.x dan 6.x. Untuk daftar lengkap jenis event, lihat Audit event types (6.x).
   xpack.security.audit.index.events.exclude	null (tidak ada event yang dikecualikan secara default)	Event log audit yang dikecualikan dari indeks.
   xpack.security.audit.index.events.emit_request_body	false	Menentukan apakah akan mengabaikan atau menyertakan badan permintaan yang dikirim melalui REST saat jenis event tertentu, seperti authentication_failed, dipicu.

   Peringatan

   Jika log audit berisi informasi badan permintaan, data sensitif mungkin terekspos dalam file log.

3. Lihat log audit.

   Untuk kluster versi 5.x dan 6.x, saat pencatatan log audit diaktifkan, log audit ditulis ke kluster Elasticsearch dalam indeks yang namanya diawali dengan .security_audit_log-*. Oleh karena itu, Anda dapat melihat log audit di indeks yang diawali dengan .security_audit_log-* di Konsol Kibana.

   Penting

   Indeks log audit mengonsumsi ruang penyimpanan kluster. Elasticsearch tidak secara otomatis menghapus atau meng-expire-nya, sehingga Anda harus menghapus indeks log audit lama secara manual.

4. Opsional: Konfigurasi shard untuk indeks log audit.

   Untuk kluster versi 5.x dan 6.x, Anda dapat mengonfigurasi shard untuk indeks log audit menggunakan xpack.security.audit.index.settings. Konfigurasi berikut mengatur jumlah shard utama dan replika masing-masing menjadi 1.

   xpack.security.audit.index.settings:
     index:
       number_of_shards: 1
       number_of_replicas: 1

   Catatan

   Jika Anda ingin indeks log audit dibuat dengan parameter yang Anda berikan, terapkan konfigurasi ini saat Anda mengaktifkan pengindeksan log audit (dengan mengatur xpack.security.audit.enabled ke true). Jika tidak, indeks log audit akan menggunakan pengaturan default number_of_shards: 5 dan number_of_replicas: 1.

Konfigurasi ukuran antrian

FAQ

Bagaimana cara mengonfigurasi mode satu primary banyak replica untuk Elasticsearch?

Untuk mengonfigurasi indeks dengan satu shard utama dan beberapa replika, tentukan parameter number_of_shards dan number_of_replicas saat membuat indeks. Contoh berikut membuat indeks dengan 1 shard utama dan 2 replika:

PUT /<index_name>
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 2
  }
}

Konfigurasi ini cocok untuk skenario yang memerlukan satu shard utama dengan beberapa replika untuk meningkatkan redundansi data dan skalabilitas baca. Setiap replika merupakan salinan lengkap dari shard utama dan dapat menangani permintaan pencarian secara independen.