Elasticsearch:Konfigurasikan parameter YML

Catatan penggunaan

Ubah konfigurasi

1. Buka halaman detail kluster.

   1. Login 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. Login 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 performa. Aktifkan fitur ini hanya jika diperlukan. Untuk informasi lebih lanjut tentang parameter tersebut, lihat Configure audit logs. 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 Limitations. Untuk melihat log tersebut, Anda harus terlebih dahulu mengaktifkan Audit Log Indexing. Untuk informasi lebih lanjut, lihat Query logs. 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. Configure CORS access http.cors.enabled http.cors.allow-origin http.cors.max-age http.cors.allow-methods http.cors.allow-headers http.cors.allow-credentials Configure the remote reindex whitelist reindex.remote.whitelist Configure audit logs 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 LDAP feature 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 Configure queue size 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 Custom SQL plugin configuration 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. Configure pipeline (pre-processing) 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. Tidak seperti 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 Configure query result limit 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. Persist cluster.max_shards_per_node settings 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 berlaku bahkan setelah instans Elasticsearch direstart. Anda tidak perlu mengonfigurasi ulang parameter ini setelah restart. Disable monitoring data collection 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. Optimize numeric exact-match queries (reduce GC pressure) Parameter ini hanya didukung untuk Elasticsearch 7.10 dan versi setelahnya. Jika kluster Anda menjalankan banyak kueri pencocokan eksak (term atau terms) pada bidang numerik dan tekanan GC tinggi, Anda dapat mengatur search.numeric_exact_match_query_allow_docvalues ke true untuk mengaktifkan optimasi kueri berbasis BKD. Pencocokan eksak numerik kemudian dieksekusi pada doc_values, yang mengurangi tekanan GC. Contoh konfigurasi YML: search.numeric_exact_match_query_allow_docvalues: true Parameter ini juga mendukung konfigurasi dinamis. Anda dapat menjalankan perintah berikut di Kibana Dev Tools agar pengaturan berlaku tanpa me-restart kluster: PUT /_cluster/settings { "persistent": { "search.numeric_exact_match_query_allow_docvalues": true } } Configure HTTP compression Elasticsearch dapat mengompres respons HTTP untuk mengurangi jumlah data yang ditransmisikan melalui jaringan. Untuk mengaktifkan fitur ini, konfigurasikan http.compression dalam file YML. Contoh konfigurasi YML: http.compression: true Setelah fitur diaktifkan, tidak setiap permintaan menerima respons terkompresi. Elasticsearch hanya mengembalikan respons terkompresi ketika permintaan dari klien berisi header Accept-Encoding: gzip. Oleh karena itu, selain mengaktifkan parameter ini dalam file YML, pastikan klien Anda mengirim header permintaan ini. Configure the fielddata circuit breaker limit (indices.breaker.fielddata.limit) Parameter indices.breaker.fielddata.limit menentukan batas atas memori heap yang dapat digunakan oleh fielddata. Saat batas tercapai, permintaan memicu pemutus sirkuit untuk melindungi node. Penting Jika Anda mengatur batas pemutus sirkuit ini terlalu tinggi, fielddata dapat menggunakan lebih banyak memori heap, yang dapat menyebabkan error kehabisan memori (OOM) pada node dan memengaruhi stabilitas kluster. Sesuaikan batas ini dengan hati-hati.
   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 performa 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 Change modes.

   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 dalam skrip akses klien 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 restart. Selama restart, Anda dapat melihat progresnya di daftar Tasks. Setelah restart selesai, konfigurasi file YML berlaku.

Parameter yang tidak dapat diubah

Alibaba Cloud Elasticsearch hanya mendukung parameter YML yang tercantum dalam dokumentasi produk. Parameter berikut tidak dapat diubah.

Parameter discovery.zen.* biasanya tidak perlu disesuaikan. index.translog.flush_threshold_size adalah pengaturan tingkat indeks, bukan item konfigurasi YML tingkat kluster. Anda dapat mengonfigurasinya menggunakan pengaturan indeks.

Jika Anda mengirimkan parameter yang tidak didukung di bagian Other Configurations, sistem akan mengembalikan error yang menunjukkan bahwa konfigurasi YML tidak valid dan Anda harus memeriksa file konfigurasi YML (kode error: InvalidEsConfig).

Konfigurasikan akses CORS

Konfigurasikan daftar putih API Reindex

Untuk memastikan migrasi data aman antar kluster, Anda harus menambahkan alamat koneksi pribadi dan port kluster ES_2 ke daftar putih API Reindex 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 pengenal zona ketersediaan dari nama domain sebelum menambahkannya ke daftar putih API Reindex.

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

3. Dalam file YML untuk ES_1, konfigurasikan daftar putih API Reindex. 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 di atas.

Konfigurasikan log audit

Versi 7.x dan setelahnya

1. Buka panel YML File Configuration.

   Untuk informasi lebih lanjut, lihat Modify the configuration.

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, 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 Query logs. Fitur ini hanya tersedia di beberapa wilayah. Untuk informasi lebih lanjut, lihat Limitations.

Versi 5.x dan 6.x

1. Buka panel YML File Configuration.

   Untuk informasi lebih lanjut, lihat YML file configuration.

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 Limitations. 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 ketika jenis event tertentu, seperti authentication_failed, dipicu.

   Peringatan

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

3. Lihat log audit.

   Untuk kluster versi 5.x dan 6.x, saat logging 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: Konfigurasikan 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 jumlah replika 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, teruskan konfigurasi ini saat Anda mengaktifkan pengindeksan log audit (dengan mengatur xpack.security.audit.enabled ke true). Jika tidak, indeks log audit menggunakan pengaturan default number_of_shards: 5 dan number_of_replicas: 1.

Konfigurasikan 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 adalah salinan lengkap dari shard utama dan dapat menangani permintaan pencarian secara independen.

Bagaimana cara memeriksa apakah kompresi HTTP diaktifkan untuk kluster Elasticsearch saya?

Kebijakan keamanan mencegah konfigurasi detail kluster dibaca secara langsung. Anda dapat memeriksa nilai saat ini dari http.compression sendiri dengan salah satu cara berikut.

Metode 1: Kueri pengaturan kluster dengan menjalankan perintah curl berikut.

curl -u <user>:<password> -XGET "https://<your-es-endpoint>:9200/_cluster/settings?include_defaults=true&filter_path=defaults.http.compression"

Metode 2: Jalankan perintah berikut di Kibana Dev Tools.

GET /_cluster/settings?include_defaults=true&filter_path=defaults.http.compression

Interpretasikan hasil sebagai berikut: jika defaults.http.compression dalam respons adalah true, kompresi HTTP diaktifkan untuk kluster. Jika nilainya false, kompresi HTTP tidak diaktifkan. Untuk mengaktifkannya, konfigurasikan http.compression: true di bagian Other Configurations. Untuk informasi lebih lanjut, lihat bagian Modify the configuration dalam topik ini.