Pemecahan Masalah OpenSearch Layanan Amazon

Topik ini menjelaskan cara mengidentifikasi dan memecahkan masalah umum OpenSearch Layanan Amazon. 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 otentikasi Amazon Cognito, Anda mungkin menerima kesalahan berikut saat mencoba mengakses Dasbor:

"User: anonymous is not authorized to perform: es:ESHttpGet"

Jika domain OpenSearch Layanan menggunakan akses VPC, Anda mungkin tidak menerima kesalahan ini, tetapi permintaan mungkin habis waktu. Untuk mempelajari selengkapnya tentang memperbaiki masalah ini dan berbagai opsi konfigurasi yang tersedia untuk Anda, lihat Mengontrol akses ke Dasbor, Tentang kebijakan akses pada domain VPC, dan Identity and Access Management di Amazon OpenSearch Service.

Untuk daftar masalah yang lebih luas yang dapat membuat OpenSearch Dasbor tidak tersedia, bersama dengan langkah-langkah untuk menyelesaikannya, lihatMemecahkan Masalah Dasbor OpenSearch.

Tidak dapat mengakses domain VPC

Lihat Tentang kebijakan akses pada domain VPC dan Menguji domain VPC.

Lalu lintas keluar dari domain VPC

Jika Anda mengaktifkan egress melalui VPC di domain dan integrasi keluar mulai gagal, periksa hal berikut:

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 kehilangan kuorum terjadi dan cluster Anda memiliki lebih dari satu node, OpenSearch Layanan mengembalikan kuorum dan menempatkan cluster ke status read-only. Anda memiliki dua pilihan:

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 cluster 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 cluster 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, OpenSearch Layanan mengirimkan dua peristiwa ke Anda Dasbor Health. Yang pertama memberitahu Anda tentang hilangnya kuorum. Yang kedua terjadi setelah OpenSearch Layanan berhasil memulihkan kuorum. Untuk informasi selengkapnya tentang penggunaan Dasbor Health, lihat Panduan AWS Health Pengguna.

Status klaster merah

Status cluster merah berarti bahwa setidaknya satu pecahan utama 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.

Pada akhirnya, pecahan merah menyebabkan cluster merah, dan indeks merah menyebabkan pecahan merah. Untuk mengidentifikasi indeks yang menyebabkan status cluster merah, OpenSearch memiliki beberapa API yang bermanfaat.

Menghapus indeks merah adalah cara tercepat untuk memperbaiki status cluster merah. Bergantung pada alasan status cluster merah, Anda dapat menskalakan domain OpenSearch Layanan untuk menggunakan jenis instans yang lebih besar, lebih banyak instans, atau lebih banyak EBS-based penyimpanan dan mencoba membuat ulang indeks yang bermasalah.

Jika menghapus indeks bermasalah tidak memungkinkan, 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 cluster 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 cluster Anda terus berwarna merah selama lebih dari satu jam, OpenSearch Layanan mencoba memperbaikinya secara otomatis dengan mengubah rute pecahan yang tidak terisi atau memulihkan dari snapshot sebelumnya.

Jika gagal memperbaiki satu atau beberapa indeks merah dan status cluster tetap merah selama total 14 hari, OpenSearch Layanan mengambil tindakan lebih lanjut hanya jika cluster memenuhi setidaknya salah satu kriteria berikut:

Saat ini, jika cluster Anda memenuhi salah satu kriteria ini, OpenSearch Layanan mengirimi Anda pemberitahuan harian selama 7 hari ke depan menjelaskan bahwa jika Anda tidak memperbaiki indeks ini, semua pecahan yang tidak ditetapkan akan dihapus. Jika status cluster Anda masih merah setelah 21 hari, OpenSearch Layanan menghapus pecahan yang tidak ditetapkan (penyimpanan dan komputasi) pada semua indeks merah. Anda menerima pemberitahuan di panel Notifikasi OpenSearch pada konsol 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.

GET domain-endpoint/_nodes/stats/jvm?pretty

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. Single-nodecluster selalu diinisialisasi dengan status cluster kuning karena tidak ada node lain di mana OpenSearch Layanan dapat menetapkan replika. Untuk mencapai status klaster hijau, tingkatkan jumlah simpul Anda. Untuk informasi selengkapnya, lihat Mengatur ukuran domain OpenSearch Layanan Amazon.

Multi-node cluster mungkin secara singkat memiliki status cluster kuning setelah membuat indeks baru atau setelah kegagalan node. Status ini diselesaikan sendiri saat merep OpenSearch likasi 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% 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 memicu saat FreeStorageSpace turun di bawah ambang batas tertentu. GET /_cat/allocation?vjuga memberikan ringkasan yang berguna tentang alokasi shard dan penggunaan disk. Untuk mengatasi masalah yang terkait dengan kurangnya ruang penyimpanan, skala domain OpenSearch Layanan Anda untuk menggunakan jenis instans yang lebih besar, lebih banyak instans, atau lebih banyak EBS-based penyimpanan.

Tekanan memori JVM tinggi

Ketika JVMMemoryPressure metrik melebihi 92% selama 30 menit, OpenSearch Layanan memicu mekanisme perlindungan dan memblokir semua operasi penulisan untuk mencegah cluster mencapai status merah. Saat perlindungan aktif, operasi tulis gagal dengan ClusterBlockException kesalahan, indeks baru tidak dapat dibuat, dan IndexCreateBlockException kesalahan dilemparkan.

Ketika JVMMemoryPressure metrik kembali ke 88% atau lebih rendah selama lima menit, perlindungan dinonaktifkan, dan operasi penulisan 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. Hal ini juga dapat disebabkan oleh penggunaan agregasi, wildcard, atau rentang waktu yang luas dalam kueri.

Untuk mengurangi lalu lintas ke cluster dan menyelesaikan masalah tekanan memori JVM yang tinggi, coba satu atau beberapa hal berikut:

Secara umum, untuk menghindari tekanan memori JVM yang tinggi di masa depan, ikuti praktik terbaik berikut:

Kesalahan saat bermigrasi ke Multi-AZ dengan Standby

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 standby ke domain dengan standby

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 utama dan replika) yang kelipatan dari tiga. Anda dapat memeriksa kemajuan migrasi menggunakan DescribeDomainChangeProgress API. Jika Anda mengalami kesalahan penghitungan replika, perbaiki kesalahan dan kemudian hubungi AWS Dukungan untuk mencoba kembali migrasi.

Jumlah salinan data yang salah

Jika Anda tidak memiliki jumlah salinan data yang tepat di domain Anda, migrasi ke Multi-AZ dengan Standby akan gagal.

JVM OutOfMemoryError

JVM OutOfMemoryError biasanya berarti bahwa salah satu pemutus sirkuit JVM berikut tercapai.

Simpul klaster yang gagal

Instans Amazon EC2 mungkin mengalami penghentian tak terduga dan memulai ulang. Biasanya, OpenSearch Layanan memulai ulang node untuk Anda. Namun, ada kemungkinan satu atau lebih node dalam 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 ketika masalah ini terjadi.

Untuk melindungi cluster Anda dari penghentian dan restart node yang tidak terduga, buat setidaknya satu replika untuk setiap indeks di domain OpenSearch Layanan Anda.

Melampaui batas serpihan maksimum

OpenSearch Serta 7. x versi Elasticsearch memiliki pengaturan default tidak lebih dari 1.000 pecahan per node. OpenSearch/Elasticsearchmemunculkan kesalahan jika permintaan, seperti membuat indeks baru, akan menyebabkan Anda melebihi batas ini. Jika Anda mengalami kesalahan ini, Anda memiliki beberapa pilihan:

Domain terjebak dalam keadaan 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 Layanan meluncurkan kumpulan node baru yang berlaku (seperti data, master, atau UltraWarm). Setelah migrasi selesai, node yang lebih lama dihentikan.

Cluster dapat macet dalam status “Pemrosesan” jika salah satu dari situasi ini terjadi:

Untuk langkah penyelesaian terperinci dalam setiap situasi ini, lihat Mengapa domain OpenSearch Layanan Amazon saya terjebak dalam status “Pemrosesan”? .

Saldo 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 di 0 untuk domain dengan tipe volume gp3, dan domain dengan volume gp2 yang memiliki ukuran volume di atas 1000 GiB. Untuk informasi selengkapnya, lihat General Purpose SSD Volume (gp2). Anda dapat memantau burst balance EBS dengan BurstBalance CloudWatch metrik.

Metrik EBS meningkat selama pengubahan ukuran volume

Saat memodifikasi ukuran volume Amazon Elastic Block Store, Anda mungkin mengamati peningkatan sementara dalam berbagai metrik EBS sepertiWrite Throughput,, Write Throughput Micro burstingDisk Queue Depth, danIOPS. Ini adalah perilaku yang diharapkan selama operasi pengubahan ukuran dan biasanya berlangsung beberapa detik. Durasi dapat bervariasi, bagaimanapun, berdasarkan ukuran volume yang dimodifikasi.

Untuk menghindari masalah latensi dan penolakan permintaan, lakukan perubahan ukuran volume EBS hanya ketika cluster sehat dan lalu lintas jaringan rendah.

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 memadai bagi OpenSearch Layanan Amazon 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:

Jika kesalahan berlanjut setelah mengulangi proses beberapa kali, hubungi AWS Dukungan.

Tidak dapat menutup indeks

OpenSearch Layanan mendukung _close API hanya untuk OpenSearch dan Elasticsearch versi 7.4 dan yang lebih baru. Jika Anda menggunakan versi yang lebih lama dan memulihkan indeks dari snapshot, Anda dapat menghapus indeks yang ada (sebelum atau setelah mengindeks ulang itu).

Periksa lisensi klien

Distribusi default Logstash dan Beats termasuk pemeriksaan lisensi eksklusif dan gagal terhubung ke versi open source. OpenSearch Pastikan Anda menggunakan distribusi Apache 2.0 (OSS) dari klien ini dengan OpenSearch Layanan.

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 muatan 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 memodifikasi secara langsungopensearch.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 Refer OpenSearch ensi API Layanan Amazon danOperasi yang didukung di OpenSearch Layanan Amazon.

Jika Anda memerlukan wawasan lebih lanjut tentang kinerja cluster, Anda dapat mempublikasikan log kesalahan dan log lambat ke CloudWatch.

Kesalahan snapshot “Tidak Valid untuk Kelas Penyimpanan Objek”

OpenSearch Snapshot layanan tidak mendukung kelas penyimpanan Amazon Glacier. Anda mungkin mengalami kesalahan ini saat mencoba membuat daftar snapshot jika bucket S3 Anda menyertakan aturan siklus hidup yang mentransisi objek ke kelas penyimpanan Amazon Glacier.

Jika Anda perlu mengembalikan snapshot dari bucket, pulihkan objek dari Amazon 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 menjalankan OpenSearch atau Elasticsearch 6.7 atau yang lebih baru, batasan berikut berlaku:

Kueri panas berhenti bekerja setelah mengaktifkan UltraWarm

Saat Anda mengaktifkan UltraWarm pada domain, jika tidak ada penggantian yang sudah ada sebelumnya pada search.max_buckets pengaturan, OpenSearch Layanan secara otomatis menetapkan nilai untuk mencegah kueri yang banyak 10000 memori menjenuhkan node hangat. Jika kueri populer Anda menggunakan lebih dari 10.000 bucket, kueri tersebut mungkin berhenti berfungsi saat Anda mengaktifkannya UltraWarm.

Karena Anda tidak dapat mengubah pengaturan ini karena sifat Amazon OpenSearch Service yang dikelola, Anda perlu membuka kasus dukungan untuk meningkatkan batas. Peningkatan batas tidak memerlukan langganan dukungan premium.

Tidak dapat menurunkan versi setelah peningkatan

In-place upgrade tidak dapat diubah, tetapi jika Anda menghubungi AWS Dukungan, mereka dapat membantu Anda memulihkan snapshot pra-upgrade otomatis pada domain baru. Misalnya, jika Anda memutakhirkan domain dari Elasticsearch 5.6 ke 6.4, AWS Dukungan dapat membantu Anda memulihkan snapshot pra-upgrade pada domain Elasticsearch 5.6 baru. Jika Anda mengambil snapshot manual dari domain asli, Anda dapat melakukan langkah itu sendiri.

Perlu ringkasan domain untuk semua Wilayah AWS

Skrip berikut menggunakan AWS CLI perintah Amazon EC2 describe-regions untuk membuat daftar semua Wilayah di mana OpenSearch Layanan dapat tersedia. Kemudian ia memanggil nam a-nama daftar untuk 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.

Pecahan simpul dan kemiringan penyimpanan

Skew shard simpul adalah ketika satu atau lebih node dalam cluster memiliki lebih banyak pecahan secara signifikan daripada node lainnya. S kew penyimpanan node adalah ketika satu atau lebih node dalam cluster memiliki penyimpanan (disk.indices) yang jauh 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/allocation API dan bandingkan disk.indices entri shards dan dalam respons:

 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  | node2
    264    |      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 normal, apa pun di atas 10% dari rata-rata adalah signifikan. Ketika distribusi pecahan miring, penggunaan bandwidth CPU, jaringan, dan disk juga bisa menjadi miring. Karena lebih banyak data umumnya berarti lebih banyak pengindeksan dan operasi 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 simpul data untuk memastikan bahwa setiap indeks didistribusikan secara merata di seluruh node data.

Pecahan indeks dan kemiringan penyimpanan

Skew pecahan indeks adalah ketika satu atau lebih node menyimpan lebih banyak pecahan indeks daripada node lainnya. Kem iringan 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 _cat/shards API. Selidiki kemiringan indeks jika ada beberapa indikasi kemiringan dalam metrik cluster atau node. Berikut ini adalah indikasi umum dari kemiringan indeks:

Remediasi: Gunakan jumlah pecahan yang merupakan kelipatan dari jumlah simpul data untuk memastikan bahwa setiap indeks didistribusikan secara merata di seluruh node data. Jika Anda masih melihat penyimpanan indeks atau miring pecahan, Anda mungkin perlu memaksa realokasi pecahan, yang terjadi dengan setiap blue/green pener apan 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 akan menanyakan 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 menon aktifkan AWS Security Token Service (AWS STS) untuk Wilayah Anda.

Untuk menambahkan titik akhir VPC ke VPC Anda, OpenSearch Layanan harus mengambil peran tersebut. AWSServiceRoleForAmazonOpenSearchService Dengan demikian, AWS STS harus diaktifkan untuk membuat domain baru yang menggunakan akses VPC di Wilayah tertentu. Untuk mempelajari selengkapnya tentang mengaktifkan dan menonaktifkan AWS STS, lihat Panduan https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html Pengguna IAM.

Permintaan yang ditolak ke OpenSearch API

Dengan diperkenalkannya kontrol akses berbasis tag untuk OpenSearch API, Anda mungkin mulai melihat kesalahan akses ditolak di tempat yang sebelumnya tidak Anda lihat. Ini mungkin karena satu atau lebih kebijakan akses Anda berisi Deny penggunaan ResourceTag kondisi tersebut, 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.

Dengan dukungan tambahan tag untuk metode OpenSearch HTTP, kebijakan berbasis identitas IAM seperti di atas akan mengakibatkan pengguna terlampir ditolak akses ke tindakan tersebut. 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 menyambung ke domain OpenSearch Layanan dari Alpine Linux versi 3.18.0 atau lebih rendah, resolusi DNS dapat gagal jika domain berada di 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

CPU-based kontrol penerimaan adalah mekanisme gatekeeper yang secara proaktif membatasi jumlah permintaan ke node berdasarkan kapasitasnya saat ini, baik untuk peningkatan organik maupun lonjakan lalu lintas. Permintaan berlebihan mengembalikan kode status HTTP 429 “Terlalu Banyak Permintaan” setelah penolakan. Kesalahan ini menunjukkan sumber daya cluster 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 selalu memperbarui sertifikat CA dan sistem operasi komputer Anda. 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:

Ketiga otoritas sertifikasi (CA) adalah:

Sertifikat root dari dua otoritas pertama tersedia dari Amazon Trust Services, tetapi selalu memperbarui komputer Anda adalah solusi yang lebih mudah. Untuk mempelajari lebih lanjut tentang ACM-provided sertifikat, lihat AWS Certificate Manager FAQ.

Instalasi plugin kustom gagal karena kompatibilitas versi

Masalah: Instalasi plugin gagal karena ketidakcocokan versi antara plugin dan OpenSearch instance yang sedang berjalan. Sistem mengembalikan kesalahan berikut:

PluginValidationFailureReason : The provided plugin could not be loaded.

Penyebab: Plugin dikompilasi untuk OpenSearch ${MAJOR}. ${MINOR}.{PATCH}, tetapi lingkungan Anda menjalankan OpenSearch ${MAJOR}. $ {MINOR} 0. OpenSearch membutuhkan pencocokan versi yang tepat antara plugin dan OpenSearch instalasi inti untuk alasan stabilitas dan keamanan.

Kemungkinan perbaikan: Bangun plugin dengan OpenSearch versi ${MAJOR}. $ {MINOR} .0 agar sesuai dengan versi cluster Anda.