Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memecahkan Masalah Layanan Amazon OpenSearch
Topik ini menjelaskan cara mengidentifikasi dan memecahkan masalah OpenSearch Layanan Amazon yang umum. Konsultasikan informasi di bagian ini sebelum menghubungi AWS Support
Tidak dapat mengakses OpenSearch Dasbor
Titik akhir OpenSearch Dasbor tidak mendukung permintaan yang ditandatangani. Jika kebijakan kontrol akses untuk domain Anda hanya memberikan akses ke peran IAM tertentu dan Anda belum mengonfigurasi autentikasi Amazon Cognito, Anda mungkin menerima kesalahan berikut saat mencoba mengakses Dasbor:
"User: anonymous is not authorized to perform: es:ESHttpGet"
Jika domain OpenSearch Layanan Anda menggunakan akses VPC, Anda mungkin tidak menerima kesalahan ini, tetapi permintaan tersebut mungkin habis. Untuk mempelajari selengkapnya tentang memperbaiki masalah ini dan berbagai opsi konfigurasi yang tersedia untuk Anda, lihat Mengontrol akses ke Dasbor , Tentang kebijakan akses pada VPC domain, dan Identity and Access Management di Amazon OpenSearch Service.
Tidak dapat mengakses domain VPC
Lihat Tentang kebijakan akses pada VPC domain dan Menguji VPC domain.
Klaster dalam status hanya-baca
Dibandingkan dengan versi Elasticsearch sebelumnya, OpenSearch dan Elasticsearch 7. x menggunakan sistem yang berbeda untuk koordinasi cluster. Dalam sistem baru ini, ketika klaster kehilangan kuorum, klaster ini tidak tersedia sampai Anda mengambil tindakan. Kehilangan kuorum dapat terjadi dalam dua bentuk:
-
Jika klaster Anda menggunakan simpul utama terdedikasi, kehilangan kuorum terjadi ketika setengah atau lebih dari klaster tidak tersedia.
-
Jika klaster Anda tidak menggunakan simpul utama terdedikasi, kehilangan kuorum terjadi ketika setengah atau lebih dari simpul data Anda tidak tersedia.
Jika kehilangan kuorum terjadi dan klaster Anda memiliki lebih dari satu node, OpenSearch Service mengembalikan kuorum dan menempatkan cluster ke status hanya-baca. Anda memiliki dua pilihan:
-
Menghapus status hanya-baca dan menggunakan klaster apa adanya.
Jika Anda lebih suka menggunakan klaster apa adanya, verifikasikan bahwa kesehatan klaster hijau menggunakan permintaan berikut:
GET _cat/health?v
Jika kesehatan klaster merah, kami sarankan memulihkan klaster dari snapshot. Anda juga dapat melihat Status klaster merah untuk langkah-langkah pemecahan masalah. Jika kesehatan klaster berwarna hijau, periksa apakah semua indeks yang diharapkan hadir menggunakan permintaan berikut:
GET _cat/indices?v
Kemudian jalankan beberapa pencarian untuk memverifikasi bahwa data yang diharapkan ada. Jika ada, Anda dapat menghapus status hanya-baca menggunakan permintaan berikut:
PUT _cluster/settings { "persistent": { "cluster.blocks.read_only": false } }
Jika kehilangan kuorum terjadi dan klaster Anda hanya memiliki satu node, OpenSearch Service menggantikan node dan tidak menempatkan cluster ke status read-only. Jika tidak, opsi Anda sama: menggunakan klaster apa adanya atau memulihkan dari snapshot.
Dalam kedua situasi tersebut, OpenSearch Layanan mengirimkan dua acara ke Anda AWS Health Dashboard
Status klaster merah
Status cluster merah berarti bahwa setidaknya satu pecahan primer dan replika tidak dialokasikan ke node. OpenSearch Layanan terus mencoba mengambil snapshot otomatis dari semua indeks terlepas dari statusnya, tetapi snapshot gagal saat status cluster merah tetap ada.
Penyebab paling umum dari status cluster merah adalah node cluster yang gagal dan OpenSearch proses mogok karena beban pemrosesan berat yang terus menerus.
catatan
OpenSearch Layanan menyimpan snapshot otomatis selama 14 hari terlepas dari status klaster. Oleh karena itu, jika status klaster merah tetap ada selama lebih dari dua minggu, snapshot otomatis terakhir yang sehat akan dihapus dan Anda bisa secara permanen kehilangan data klaster Anda. Jika domain OpenSearch Layanan Anda memasukkan status klaster merah, AWS Support dapat menghubungi Anda untuk menanyakan apakah Anda ingin mengatasi masalah itu sendiri atau Anda ingin tim dukungan membantu. Anda dapat mengatur CloudWatch alarm untuk memberi tahu Anda ketika status klaster merah terjadi.
Pada akhirnya, pecahan merah menyebabkan gugus merah, dan indeks merah menyebabkan pecahan merah. Untuk mengidentifikasi indeks yang menyebabkan status cluster merah, OpenSearch memiliki beberapa API yang bermanfaat.
-
GET /_cluster/allocation/explain
memilih serpihan pertama yang belum ditetapkan yang ditemukannya dan menjelaskan mengapa hal itu tidak dapat dialokasikan ke simpul:{ "index": "test4", "shard": 0, "primary": true, "current_state": "unassigned", "can_allocate": "no", "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes" }
-
GET /_cat/indices?v
menunjukkan status kesehatan, jumlah dokumen, dan penggunaan disk untuk setiap indeks:health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open test1 30h1EiMvS5uAFr2t5CEVoQ 5 0 820 0 14mb 14mb green open test2 sdIxs_WDT56afFGu5KPbFQ 1 0 0 0 233b 233b green open test3 GGRZp_TBRZuSaZpAGk2pmw 1 1 2 0 14.7kb 7.3kb red open test4 BJxfAErbTtu5HBjIXJV_7A 1 0 green open test5 _8C6MIXOSxCqVYicH3jsEA 1 0 7 0 24.3kb 24.3kb
Menghapus indeks merah adalah cara tercepat untuk memperbaiki status cluster merah. Bergantung pada alasan status klaster merah, Anda kemudian dapat menskalakan domain OpenSearch Layanan Anda untuk menggunakan jenis instans yang lebih besar, lebih banyak instance, atau lebih banyak penyimpanan berbasis EBS dan mencoba membuat ulang indeks yang bermasalah.
Jika menghapus indeks bermasalah tidak layak, Anda dapat memulihkan snapshot, menghapus dokumen dari indeks, mengubah pengaturan indeks, mengurangi jumlah replika, atau menghapus indeks lain untuk mengosongkan ruang disk. Langkah penting adalah menyelesaikan status klaster merah sebelum mengonfigurasi ulang domain OpenSearch Layanan Anda. Mengkonfigurasi ulang domain dengan status klaster merah dapat menambah masalah dan menyebabkan domain terjebak dalam status konfigurasi Memproses hingga Anda menyelesaikan status tersebut.
Remediasi otomatis cluster merah
Jika status klaster Anda terus menerus berwarna merah selama lebih dari satu jam, OpenSearch Service mencoba memperbaikinya secara otomatis dengan mengubah rute pecahan yang tidak terisi atau memulihkan dari snapshot sebelumnya.
Jika gagal memperbaiki satu atau lebih indeks merah dan status klaster tetap merah selama total 14 hari, OpenSearch Layanan mengambil tindakan lebih lanjut hanya jika klaster memenuhi setidaknya satu dari kriteria berikut:
-
Hanya memiliki satu zona ketersediaan
-
Tidak memiliki node master khusus
-
Berisi jenis instance burstable (T2 atau T3)
Pada saat ini, jika klaster Anda memenuhi salah satu kriteria ini, OpenSearch Layanan mengirimkan pemberitahuan harian selama 7 hari ke depan yang menjelaskan bahwa jika Anda tidak memperbaiki indeks ini, semua pecahan yang tidak ditetapkan akan dihapus. Jika status klaster Anda masih merah setelah 21 hari, OpenSearch Service menghapus pecahan yang tidak ditetapkan (penyimpanan dan komputasi) pada semua indeks merah. Anda menerima pemberitahuan di panel Pemberitahuan konsol OpenSearch Layanan untuk setiap peristiwa ini. Untuk informasi selengkapnya, lihat Acara kesehatan cluster.
Memulihkan dari beban pemrosesan berat yang terus menerus
Untuk menentukan apakah status klaster merah adalah karena beban pemrosesan berat yang terus menerus pada simpul data, pantau metrik klaster berikut.
Metrik terkait | Deskripsi | Pemulihan |
---|---|---|
JVM MemoryPressure |
Tentukan persentase tumpukan Java yang digunakan untuk semua simpul data dalam sebuah klaster. Lihat statistik Maksimum untuk metrik ini, dan cari penurunan tekanan memori yang semakin kecil karena kolektor sampah Java gagal untuk mendapatkan kembali memori yang memadai. Pola ini mungkin disebabkan oleh pengkuerian kompleks atau bidang data yang besar. Tipe instans x86 menggunakan pengumpul sampah Concurrent Mark Sweep (CMS), yang berjalan bersama thread aplikasi untuk membuat jeda tetap singkat. Jika CMS tidak dapat merebut kembali memori yang cukup selama pengumpulan normal, itu memicu pengumpulan sampah penuh, yang dapat menyebabkan jeda aplikasi yang lama dan berdampak pada stabilitas cluster. Jenis instance Graviton berbasis ARM menggunakan pengumpul sampah Garbage-First (G1), yang mirip dengan CMS, tetapi menggunakan jeda singkat tambahan dan defragmentasi tumpukan untuk lebih mengurangi kebutuhan pengumpulan sampah penuh. Dalam kedua kasus tersebut, jika penggunaan memori terus tumbuh melampaui apa yang dapat diambil kembali oleh pengumpul sampah selama pengumpulan sampah penuh, OpenSearch macet dengan kesalahan kehabisan memori. Pada semua jenis instance, aturan praktis yang baik adalah menjaga penggunaan di bawah 80%. API
|
Setel pemutus sirkuit memori untuk JVM. Untuk informasi selengkapnya, lihat JVM OutOfMemoryError. Jika masalah berlanjut, hapus indeks yang tidak perlu, kurangi jumlah atau kompleksitas permintaan ke domain, tambahkan instance, atau gunakan jenis instance yang lebih besar. |
CPUUtilization | Tentukan persentase sumber daya CPU yang digunakan untuk simpul data dalam sebuah klaster. Lihat statistik Maksimum untuk metrik ini, dan cari pola penggunaan tinggi yang berkelanjutan. | Tambahkan simpul data atau tingkatkan ukuran tipe instans dari simpul data yang ada. |
Node | Tentukan jumlah simpul dalam sebuah klaster. Lihat statistik Minimum untuk metrik ini. Nilai ini berfluktuasi ketika layanan men-deploy armada baru dari instans untuk klaster. | Tambahkan simpul data. |
Status klaster kuning
Status cluster kuning berarti pecahan utama untuk semua indeks dialokasikan ke node dalam cluster, tetapi pecahan replika untuk setidaknya satu indeks tidak. Cluster simpul tunggal selalu diinisialisasi dengan status klaster kuning karena tidak ada simpul lain yang dapat ditetapkan oleh OpenSearch Service sebagai replika. Untuk mencapai status klaster hijau, tingkatkan jumlah simpul Anda. Untuk informasi selengkapnya, lihat Mengukur domain OpenSearch Layanan Amazon.
Klaster multi-simpul mungkin secara singkat memiliki status klaster kuning setelah membuat indeks baru atau setelah kegagalan simpul. Status ini diselesaikan sendiri sebagai OpenSearch mereplikasi data di seluruh cluster. Kurangnya ruang disk juga dapat menyebabkan status klaster kuning; klaster hanya dapat mendistribusikan serpihan replika jika simpul memiliki ruang disk untuk mengakomodasinya.
ClusterBlockException
Anda mungkin menerima kesalahan ClusterBlockException
karena sebab-sebab berikut.
Kurangnya ruang penyimpanan yang tersedia
Jika satu atau lebih node di cluster Anda memiliki ruang penyimpanan kurang dari nilai minimum 1) 20% dari ruang penyimpanan yang tersedia, atau 2) 20 GiB ruang penyimpanan, operasi penulisan dasar seperti menambahkan dokumen dan membuat indeks dapat mulai gagal. Menghitung persyaratan penyimpananmemberikan ringkasan tentang bagaimana OpenSearch Layanan menggunakan ruang disk.
Untuk menghindari masalah, pantau FreeStorageSpace
metrik di konsol OpenSearch Layanan dan buat CloudWatch alarm untuk dipicu saat FreeStorageSpace
turun di bawah ambang batas tertentu. GET
/_cat/allocation?v
juga menyediakan ringkasan alokasi shard dan penggunaan disk yang berguna. Untuk mengatasi masalah yang terkait dengan kurangnya ruang penyimpanan, skala domain OpenSearch Layanan Anda untuk menggunakan jenis instans yang lebih besar, lebih banyak instance, atau lebih banyak penyimpanan berbasis EBS.
Tekanan memori JVM tinggi
Ketika MemoryPressure metrik JVM melebihi 92% selama 30 menit, OpenSearch Layanan memicu mekanisme perlindungan dan memblokir semua operasi penulisan untuk mencegah klaster mencapai status merah. Saat perlindungan aktif, operasi penulisan gagal dengan ClusterBlockException
kesalahan, indeks baru tidak dapat dibuat, dan IndexCreateBlockException
kesalahan dilemparkan.
Ketika MemoryPressure metrik JVM kembali ke 88% atau lebih rendah selama lima menit, perlindungan dinonaktifkan, dan operasi tulis ke cluster tidak diblokir.
Tekanan memori JVM yang tinggi dapat disebabkan oleh lonjakan jumlah permintaan ke cluster, alokasi pecahan yang tidak seimbang di seluruh node, terlalu banyak pecahan dalam cluster, data lapangan atau ledakan pemetaan indeks, atau jenis instance yang tidak dapat menangani beban masuk. Ini juga dapat disebabkan oleh penggunaan agregasi, wildcard, atau rentang waktu yang luas dalam kueri.
Untuk mengurangi lalu lintas ke cluster dan mengatasi masalah tekanan memori JVM yang tinggi, coba satu atau beberapa hal berikut:
-
Skala domain sehingga ukuran heap maksimum per node adalah 32 GB.
-
Kurangi jumlah pecahan dengan menghapus indeks lama atau tidak terpakai.
-
Hapus cache data dengan operasi
POST
API. Perhatikan bahwa membersihkan cache dapat mengganggu kueri yang sedang berlangsung.index-name
/_cache/clear?fielddata=true
Secara umum, untuk menghindari tekanan memori JVM yang tinggi di masa depan, ikuti praktik terbaik berikut:
-
Hindari agregasi pada bidang teks, atau ubah jenis pemetaan untuk indeks
Anda. keyword
-
Optimalkan permintaan pencarian dan pengindeksan dengan memilih jumlah pecahan yang benar.
-
Siapkan kebijakan Manajemen Negara Indeks (ISM) untuk menghapus indeks yang tidak digunakan secara teratur.
Kesalahan saat bermigrasi ke Multi-AZ dengan Siaga
Masalah berikut mungkin terjadi saat Anda memigrasikan domain yang ada ke Multi-AZ dengan standby.
Membuat indeks, templat indeks, atau kebijakan ISM selama migrasi dari domain tanpa siaga ke domain dengan siaga
Jika Anda membuat indeks saat memigrasikan domain dari Multi-AZ tanpa Standby ke dengan Standby, dan templat indeks atau kebijakan ISM tidak mengikuti pedoman penyalinan data yang disarankan, hal ini dapat menyebabkan inkonsistensi data dan migrasi mungkin gagal. Untuk menghindari situasi ini, buat indeks baru dengan jumlah salinan data (termasuk node primer dan replika) yang merupakan kelipatan dari tiga. Anda dapat memeriksa progres migrasi menggunakan API. DescribeDomainChangeProgress
Jika Anda menemukan kesalahan jumlah replika, perbaiki kesalahan, lalu hubungi AWS Support
Jumlah salinan data yang salah
Jika Anda tidak memiliki jumlah salinan data yang tepat di domain Anda, migrasi ke Multi-AZ dengan Siaga akan gagal.
JVM OutOfMemoryError
JVM OutOfMemoryError
biasanya berarti bahwa salah satu pemutus sirkuit JVM berikut tercapai.
Pemutus sirkuit | Deskripsi | Properti pengaturan klaster |
---|---|---|
Pemutus Induk | Total persentase memori tumpukan JVM yang diizinkan untuk semua pemutus sirkuit. Nilai default adalah 95%. | indices.breaker.total.limit |
Pemutus Data Bidang | Persentase memori tumpukan JVM yang diizinkan untuk memuat satu bidang data ke dalam memori. Nilai default adalah 40%. Jika Anda mengunggah data dengan bidang besar, Anda mungkin perlu menaikkan batas ini. | indices.breaker.fielddata.limit |
Pemutus Permintaan | Persentase memori tumpukan JVM yang diizinkan untuk struktur data yang digunakan untuk menanggapi permintaan layanan. Nilai defaultnya adalah 60%. Jika permintaan layanan Anda melibatkan penghitungan agregasi, Anda mungkin perlu menaikkan batas ini. | indices.breaker.request.limit |
Simpul klaster yang gagal
Instans Amazon EC2 mungkin mengalami penghentian tak terduga dan memulai ulang. Biasanya, OpenSearch Service me-restart node untuk Anda. Namun, mungkin saja satu atau lebih node dalam sebuah OpenSearch cluster tetap dalam kondisi gagal.
Untuk memeriksa kondisi ini, buka dasbor domain Anda di konsol OpenSearch Layanan. Buka tab Kesehatan cluster dan temukan metrik Total node. Lihat apakah jumlah simpul yang dilaporkan lebih sedikit dari jumlah yang Anda konfigurasikan untuk klaster Anda. Jika metrik menunjukkan bahwa satu atau lebih simpul mati selama lebih dari satu hari, hubungi AWS Support
Anda juga dapat mengatur CloudWatch alarm untuk memberi tahu Anda saat masalah ini terjadi.
catatan
Metrik Total node tidak akurat selama perubahan konfigurasi klaster Anda dan selama pemeliharaan rutin untuk layanan. Perilaku ini yang diharapkan. Metrik akan melaporkan jumlah simpul klaster yang benar dengan segera. Untuk mempelajari lebih lanjut, lihat Membuat perubahan konfigurasi di Amazon OpenSearch Service.
Untuk melindungi klaster Anda dari penghentian dan restart node yang tidak terduga, buat setidaknya satu replika untuk setiap indeks di domain Layanan Anda. OpenSearch
Melampaui batas serpihan maksimum
OpenSearch Begitu juga dengan 7. x versi Elasticsearch memiliki pengaturan default tidak lebih dari 1.000 pecahan per node. OpenSearch/Elasticsearch memunculkan kesalahan jika permintaan, seperti membuat indeks baru, akan menyebabkan Anda melebihi batas ini. Jika Anda mengalami kesalahan ini, Anda memiliki beberapa pilihan:
-
Tambahkan lebih banyak simpul data ke klaster.
-
Tingkatkan pengaturan
_cluster/settings/cluster.max_shards_per_node
. -
Gunakan API _shrink untuk mengurangi jumlah serpihan pada simpul.
Domain terjebak dalam status pemrosesan
Domain OpenSearch Layanan Anda memasuki status “Pemrosesan” saat berada di tengah perubahan konfigurasi. Saat Anda memulai perubahan konfigurasi, status domain berubah menjadi “Pemrosesan” sementara OpenSearch Layanan menciptakan lingkungan baru. Di lingkungan baru, OpenSearch Service meluncurkan satu set node baru yang berlaku (seperti data, master, atau UltraWarm). Setelah migrasi selesai, node yang lebih tua dihentikan.
Cluster dapat terjebak dalam status “Pemrosesan” jika salah satu dari situasi ini terjadi:
-
Satu set node data baru gagal diluncurkan.
-
Migrasi pecahan ke kumpulan node data baru tidak berhasil.
-
Pemeriksaan validasi gagal dengan kesalahan.
Untuk langkah-langkah resolusi terperinci dalam setiap situasi ini, lihat Mengapa domain OpenSearch Layanan Amazon saya terjebak dalam status “Pemrosesan”?
Keseimbangan burst EBS rendah
OpenSearch Layanan mengirimi Anda pemberitahuan konsol ketika saldo burst EBS pada salah satu volume Tujuan Umum (SSD) Anda di bawah 70%, dan pemberitahuan tindak lanjut jika saldo turun di bawah 20%. Untuk memperbaiki masalah ini, Anda dapat meningkatkan skala cluster Anda, atau mengurangi IOPS baca dan tulis sehingga saldo burst dapat dikreditkan. Saldo burst tetap pada 0 untuk domain dengan tipe volume gp3, dan domain dengan volume gp2 yang memiliki ukuran volume di atas 1000 GiB. Untuk informasi selengkapnya, lihat Volume SSD Tujuan Umum (gp2). Anda dapat memantau keseimbangan burst EBS dengan BurstBalance
CloudWatch metrik.
Tidak dapat mengaktifkan log audit
Anda mungkin mengalami kesalahan berikut saat mencoba mengaktifkan penerbitan log audit menggunakan konsol OpenSearch Layanan:
Kebijakan Akses Sumber Daya yang ditentukan untuk grup CloudWatch log Log tidak memberikan izin yang cukup bagi Amazon OpenSearch Service untuk membuat aliran log. Silakan periksa Kebijakan Akses Sumber Daya.
Jika Anda mengalami kesalahan ini, verifikasi bahwa elemen resource
dari kebijakan Anda menyertakan grup log ARN yang benar. Jika iya, lakukan langkah-langkah berikut:
-
Tunggu beberapa menit.
-
Segarkan halaman di peramban web Anda.
-
Pilih Pilih grup yang ada.
-
Untuk grup log yang ada, pilih grup log yang Anda buat sebelum menerima pesan galat.
-
Di bagian kebijakan akses, pilih Pilih kebijakan yang ada.
-
Untuk kebijakan yang ada, pilih kebijakan yang Anda buat sebelum menerima pesan galat.
-
Pilih Aktifkan.
Jika kesalahan berlanjut setelah mengulangi proses beberapa kali, hubungi Support AWS .
Tidak dapat menutup indeks
OpenSearch Layanan mendukung _close
Periksa lisensi klien
Distribusi default Logstash dan Beats mencakup pemeriksaan lisensi berpemilik dan gagal terhubung ke versi open source. OpenSearch Pastikan Anda menggunakan distribusi Apache 2.0 (OSS) dari klien ini dengan Layanan. OpenSearch
Permintaan throttling
Jika Anda menerima kesalahan 403 Request throttled due to too many requests
atau 429 Too Many Requests
terus-menerus, pertimbangkan untuk menskalakan secara vertikal. Amazon OpenSearch Service membatasi permintaan jika payload akan menyebabkan penggunaan memori melebihi ukuran maksimum heap Java.
Tidak dapat SSH ke simpul
Anda tidak dapat menggunakan SSH untuk mengakses salah satu node di OpenSearch cluster Anda, dan Anda tidak dapat langsung memodifikasiopensearch.yml
. Sebagai gantinya, gunakan konsol AWS CLI, atau SDK untuk mengonfigurasi domain Anda. Anda juga dapat menentukan beberapa pengaturan tingkat cluster menggunakan OpenSearch REST API. Untuk mempelajari selengkapnya, lihat Referensi API OpenSearch Layanan Amazon danOperasi yang didukung di Amazon OpenSearch Service.
Jika Anda membutuhkan lebih banyak wawasan tentang kinerja cluster, Anda dapat mempublikasikan log kesalahan dan memperlambat log CloudWatch.
Kesalahan snapshot “Tidak Valid untuk Kelas Penyimpanan Objek”
OpenSearch Snapshot layanan tidak mendukung kelas penyimpanan S3 Glacier. Anda mungkin mengalami kesalahan ini ketika Anda mencoba untuk membuat daftar snapshot jika bucket S3 Anda menyertakan aturan siklus hidup yang mentransisikan objek ke kelas penyimpanan S3 Glacier.
Jika Anda perlu memulihkan snapshot dari bucket, pulihkan objek dari S3 Glacier, salin objek ke bucket baru, dan daftarkan bucket baru sebagai repositori snapshot.
Header host tidak valid
OpenSearch Layanan mengharuskan klien menentukan Host
di header permintaan. Nilai Host
yang valid adalah titik akhir domain tanpa https://
, seperti:
Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com
Jika Anda menerima Invalid Host Header
kesalahan saat membuat permintaan, periksa apakah klien atau proxy Anda menyertakan titik akhir domain OpenSearch Layanan (dan bukan, misalnya, alamat IP-nya) di Host
header.
Tipe instans M3 tidak valid
OpenSearch Layanan tidak mendukung penambahan atau modifikasi instance M3 ke domain yang ada yang berjalan OpenSearch atau Elasticsearch versi 6.7 dan yang lebih baru. Anda dapat terus menggunakan instans M3 dengan Elasticsearch 6.5 dan yang lebih lama.
Sebaiknya pilih tipe instans yang lebih baru. Untuk domain yang berjalan OpenSearch atau Elasticsearch 6.7 atau yang lebih baru, pembatasan berikut berlaku:
-
Jika domain Anda yang ada tidak menggunakan instans M3, Anda tidak dapat lagi mengubahnya.
-
Jika Anda mengubah domain yang ada dari tipe instans M3 ke tipe instans lain, Anda tidak dapat beralih kembali.
Kueri panas berhenti berfungsi setelah mengaktifkan UltraWarm
Saat Anda mengaktifkan UltraWarm pada domain, jika tidak ada penggantian yang sudah ada sebelumnya ke search.max_buckets
pengaturan, OpenSearch Service secara otomatis menetapkan nilainya 10000
untuk mencegah kueri yang berat memori menjenuhkan node hangat. Jika kueri panas Anda menggunakan lebih dari 10.000 bucket, kueri tersebut mungkin berhenti berfungsi saat Anda mengaktifkan. UltraWarm
Karena Anda tidak dapat mengubah setelan ini karena sifat OpenSearch Layanan Amazon yang dikelola, Anda perlu membuka kasus dukungan untuk meningkatkan batas. Peningkatan batas tidak memerlukan langganan dukungan premium.
Tidak dapat menurunkan versi setelah peningkatan
Upgrade di tempat tidak dapat dibatalkan, tetapi jika Anda menghubungi AWS Support
Perlu ringkasan domain untuk semua Wilayah AWS
Skrip berikut menggunakan AWS CLI perintah mendeskripsikan wilayah Amazon EC2 untuk membuat daftar semua Wilayah di mana OpenSearch Layanan dapat tersedia. Kemudian ia menyerukan list-domain-namesuntuk setiap Wilayah:
for region in `aws ec2 describe-regions --output text | cut -f4` do echo "\nListing domains in region '$region':" aws opensearch list-domain-names --region $region --query 'DomainNames' done
Anda menerima output berikut untuk setiap Wilayah:
Listing domains in region:'us-west-2'...
[
{
"DomainName": "sample-domain"
}
]
Wilayah di mana OpenSearch Layanan tidak tersedia mengembalikan “Tidak dapat terhubung ke URL titik akhir.”
Kesalahan browser saat menggunakan OpenSearch Dasbor
Browser Anda membungkus pesan kesalahan layanan dalam objek respons HTTP saat Anda menggunakan Dasbor untuk melihat data di domain OpenSearch Layanan Anda. Anda dapat menggunakan alat developer yang umumnya tersedia di peramban web, seperti Mode Developer di Chrome, untuk melihat kesalahan layanan yang mendasarinya dan membantu upaya debugging Anda.
Untuk melihat kesalahan layanan di Chrome
-
Dari bilah menu atas Chrome, pilih Lihat, Pengembang, Alat Pengembang.
-
Pilih tab Jaringan.
-
Di kolom Status, pilih sesi HTTP apa pun dengan status 500.
Untuk melihat kesalahan layanan di Firefox
-
Dari menu, pilih Alat, Developer Web, Jaringan.
-
Pilih sesi HTTP apa pun dengan status 500.
-
Pilih tab Respons untuk melihat respons layanan.
Pecahan simpul dan kemiringan penyimpanan
Node shard skew adalah ketika satu atau lebih node dalam sebuah cluster memiliki pecahan yang jauh lebih banyak daripada node lainnya. Skew penyimpanan node adalah ketika satu atau lebih node dalam sebuah cluster memiliki storage (disk.indices
) secara signifikan lebih banyak daripada node lainnya. Meskipun kedua kondisi ini dapat terjadi sementara, seperti ketika domain telah menggantikan node dan masih mengalokasikan pecahan untuk itu, Anda harus mengatasinya jika tetap ada.
Untuk mengidentifikasi kedua jenis kemiringan, jalankan operasi _cat/allocationshards
respons: disk.indices
shards | disk.indices | disk.used | disk.avail | disk.total | disk.percent | host | ip | node
264
|465.3mb
|229.9mb
|1.4tb
|1.5tb
|0
|x.x.x.x
|x.x.x.x
|node1
115 | 7.9mb | 83.7mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node2264
|465.3mb
|235.3mb
|1.4tb
|1.5tb
|0
|x.x.x.x
|x.x.x.x
|node3
116 | 7.9mb | 82.8mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node4 115 | 8.4mb | 85mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node5
Sementara beberapa kemiringan penyimpanan adalah normal, apa pun yang lebih dari 10% dari rata-rata adalah signifikan. Ketika distribusi shard miring, penggunaan CPU, jaringan, dan bandwidth disk juga bisa menjadi miring. Karena lebih banyak data umumnya berarti lebih banyak operasi pengindeksan dan pencarian, node terberat juga cenderung menjadi node yang paling tegang sumber daya, sedangkan node yang lebih ringan mewakili kapasitas yang kurang dimanfaatkan.
Remediasi: Gunakan jumlah pecahan yang merupakan kelipatan dari jumlah node data untuk memastikan bahwa setiap indeks didistribusikan secara merata di seluruh node data.
Pecahan indeks dan kemiringan penyimpanan
Index shard skew adalah ketika satu atau lebih node memegang lebih banyak pecahan indeks daripada node lainnya. Kemiringan penyimpanan indeks adalah ketika satu atau lebih node menyimpan jumlah penyimpanan total indeks yang tidak proporsional.
Kemiringan indeks lebih sulit diidentifikasi daripada kemiringan simpul karena memerlukan beberapa manipulasi output API _cat/shards.
-
Kesalahan HTTP 429 terjadi pada subset node data
-
Indeks tidak merata atau operasi pencarian antrian di seluruh node data
-
Tumpukan JVM dan/atau pemanfaatan CPU yang tidak merata di seluruh node data
Remediasi: Gunakan jumlah pecahan yang merupakan kelipatan dari jumlah node data untuk memastikan bahwa setiap indeks didistribusikan secara merata di seluruh node data. Jika Anda masih melihat penyimpanan indeks atau shard miring, Anda mungkin perlu memaksa realokasi pecahan, yang terjadi dengan setiap penerapan biru/hijau domain Layanan Anda. OpenSearch
Operasi yang tidak sah setelah memilih akses VPC
Saat Anda membuat domain baru menggunakan konsol OpenSearch Layanan, Anda memiliki opsi untuk memilih VPC atau akses publik. Jika Anda memilih akses VPC, OpenSearch Layanan kueri untuk informasi VPC dan gagal jika Anda tidak memiliki izin yang tepat:
You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation
Untuk mengaktifkan kueri ini, Anda harus memiliki akses ke operasi ec2:DescribeVpcs
, ec2:DescribeSubnets
, dan ec2:DescribeSecurityGroups
. Persyaratan ini hanya untuk konsol. Jika Anda menggunakan AWS CLI untuk membuat dan mengonfigurasi domain dengan titik akhir VPC, Anda tidak memerlukan akses ke operasi tersebut.
Terjebak saat memuat setelah membuat domain VPC
Setelah membuat domain baru yang menggunakan akses VPC, Status konfigurasi domain mungkin tidak akan pernah mengalami kemajuan melampaui Pemuatan. Jika masalah ini terjadi, Anda mungkin telah menonaktifkan AWS Security Token Service (AWS STS) untuk Wilayah Anda.
Untuk menambahkan titik akhir VPC ke VPC Anda, OpenSearch Layanan perlu mengambil peran tersebut. AWSServiceRoleForAmazonOpenSearchService
Dengan demikian, AWS STS harus diaktifkan untuk membuat domain baru yang menggunakan akses VPC di Wilayah tertentu. Untuk mempelajari lebih lanjut tentang mengaktifkan dan menonaktifkan AWS STS, lihat Panduan Pengguna IAM.
Menolak permintaan ke OpenSearch API
Dengan diperkenalkannya kontrol akses berbasis tag untuk OpenSearch API, Anda mungkin mulai melihat kesalahan akses ditolak yang sebelumnya tidak Anda lihat. Ini mungkin karena satu atau beberapa kebijakan akses Anda berisi Deny
penggunaan ResourceTag
kondisi, dan kondisi tersebut sekarang sedang dihormati.
Misalnya, kebijakan berikut digunakan untuk hanya menolak akses ke CreateDomain
tindakan dari API konfigurasi, jika domain memiliki tagenvironment=production
. Meskipun daftar tindakan juga termasukESHttpPut
, pernyataan penolakan tidak berlaku untuk tindakan itu atau ESHttp*
tindakan lainnya.
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:CreateDomain", "es:ESHttpPut" ], "Effect": "Deny", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
Dengan dukungan tambahan tag untuk metode OpenSearch HTTP, kebijakan berbasis identitas IAM seperti di atas akan mengakibatkan pengguna terlampir ditolak akses ke tindakan. ESHttpPut
Sebelumnya, dengan tidak adanya validasi tag, pengguna terlampir masih dapat mengirim permintaan PUT.
Jika Anda mulai melihat kesalahan akses ditolak setelah memperbarui domain Anda ke perangkat lunak layanan R20220323 atau yang lebih baru, periksa kebijakan akses berbasis identitas Anda untuk melihat apakah ini masalahnya dan perbarui jika perlu untuk mengizinkan akses.
Tidak dapat terhubung dari Alpine Linux
Alpine Linux membatasi ukuran respons DNS ke 512 byte. Jika Anda mencoba untuk terhubung ke domain OpenSearch Layanan Anda dari Alpine Linux versi 3.18.0 atau lebih rendah, resolusi DNS dapat gagal jika domain berada dalam VPC dan memiliki lebih dari 20 node. Jika Anda menggunakan versi Alpine Linux yang lebih tinggi dari 3.18.0, Anda harus dapat menyelesaikan lebih dari 20 host. Untuk informasi selengkapnya, lihat catatan rilis Alpine Linux 3.18.0
Jika domain Anda berada dalam VPC, sebaiknya gunakan distribusi Linux lainnya, seperti Debian, Ubuntu, CentOS, Red Hat Enterprise Linux, atau Amazon Linux 2, untuk menghubungkannya.
Terlalu banyak permintaan untuk Search Backpressure
Kontrol penerimaan berbasis CPU adalah mekanisme penjaga gerbang yang secara proaktif membatasi jumlah permintaan ke node berdasarkan kapasitasnya saat ini, baik untuk peningkatan organik maupun lonjakan lalu lintas. Permintaan yang berlebihan mengembalikan kode status HTTP 429 “Terlalu Banyak Permintaan” setelah ditolak. Kesalahan ini menunjukkan sumber daya klaster yang tidak mencukupi, permintaan pencarian intensif sumber daya, atau lonjakan beban kerja yang tidak diinginkan.
Search Backpressure memberikan alasan penolakan, yang dapat membantu menyempurnakan permintaan pencarian intensif sumber daya. Untuk lonjakan lalu lintas, kami merekomendasikan percobaan ulang sisi klien dengan backoff dan jitter eksponensial.
Kesalahan sertifikat saat menggunakan SDK
Karena AWS SDK menggunakan sertifikat CA dari komputer Anda, perubahan pada sertifikat di AWS server dapat menyebabkan kegagalan koneksi saat Anda mencoba menggunakan SDK. Pesan kesalahan bervariasi, tetapi biasanya berisi teks berikut:
Failed to query OpenSearch
...
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Anda dapat mencegah kegagalan ini dengan menyimpan sertifikat CA dan sistem operasi komputer Anda up-to-date. Jika Anda mengalami masalah ini di lingkungan perusahaan dan tidak mengelola komputer Anda sendiri, Anda mungkin perlu meminta administrator untuk membantu proses pembaruan.
Daftar berikut menunjukkan sistem operasi minimum dan versi Java:
-
Versi Microsoft Windows yang memiliki pembaruan mulai Januari 2005 atau yang lebih baru yang sudah terinstal memuat setidaknya satu dari CA yang diperlukan dalam daftar kepercayaan mereka.
-
Mac OS X 10.4 dengan Java untuk Mac OS X 10.4 Release 5 (Februari 2007), Mac OS X 10.5 (Oktober 2007), dan versi lebih baru memuat setidaknya satu dari CA yang diperlukan dalam daftar kepercayaan mereka.
-
Red Hat Enterprise Linux 5 (Maret 2007), 6, dan 7 serta CentOS 5, 6, dan 7 semuanya berisi setidaknya satu dari CA yang diperlukan dalam daftar default CA tepercaya mereka.
-
Java 1.4.2_12 (Mei 2006), 5 Pembaruan 2 (Maret 2005), dan semua versi setelahnya, termasuk Java 6 (Desember 2006), 7, dan 8, memuat setidaknya satu dari CA yang diperlukan dalam daftar default CA tepercaya mereka.
Ketiga otoritas sertifikasi (CA) adalah:
-
Amazon Root CA 1
-
Starfield Services Root Certificate Authority - G2
-
Starfield Class 2 Certification Authority
Sertifikat root dari dua otoritas pertama tersedia dari Amazon Trust Services
catatan
Saat ini, domain OpenSearch Layanan di Wilayah us-east-1 menggunakan sertifikat dari otoritas yang berbeda. Kami berencana untuk memperbarui Wilayah untuk menggunakan otoritas sertifikat baru ini dalam waktu dekat.