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 OpenSearch Dasbor, Tentang kebijakan akses pada domain VPC, dan Identity and Access Management di Amazon OpenSearch Service.

Tidak dapat mengakses domain VPC

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

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.

• Kembalikan indeks cluster atau individu dari snapshot.

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. Yang pertama memberitahu Anda tentang hilangnya kuorum. Yang kedua terjadi setelah OpenSearch Layanan berhasil mengembalikan kuorum. Untuk informasi selengkapnya tentang menggunakan AWS Health Dashboard, lihat Panduan AWS Health Pengguna.

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 _nodes/stats/jvm menawarkan ringkasan statistik JVM yang berguna, penggunaan kolam memori, dan informasi pengumpulan sampah: GET domain-endpoint/_nodes/stats/jvm?pretty	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?vjuga 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 index-name/_cache/clear?fielddata=true API. Perhatikan bahwa membersihkan cache dapat mengganggu kueri yang sedang berlangsung.

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 untuk mencoba lagi migrasi.

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:

1. Tunggu beberapa menit.

2. Segarkan halaman di peramban web Anda.

3. Pilih Pilih grup yang ada.

4. Untuk grup log yang ada, pilih grup log yang Anda buat sebelum menerima pesan galat.

5. Di bagian kebijakan akses, pilih Pilih kebijakan yang ada.

6. Untuk kebijakan yang ada, pilih kebijakan yang Anda buat sebelum menerima pesan galat.

7. Pilih Aktifkan.

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

Tidak dapat menutup indeks

OpenSearch Layanan mendukung _closeAPI 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 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, mereka dapat membantu Anda memulihkan snapshot pra-peningkatan otomatis pada domain baru. Misalnya, jika Anda memutakhirkan domain dari Elasticsearch 5.6 ke 6.4, AWS Support dapat membantu 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 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

1. Dari bilah menu atas Chrome, pilih Lihat, Pengembang, Alat Pengembang.

2. Pilih tab Jaringan.

3. Di kolom Status, pilih sesi HTTP apa pun dengan status 500.

Untuk melihat kesalahan layanan di Firefox

1. Dari menu, pilih Alat, Developer Web, Jaringan.

2. Pilih sesi HTTP apa pun dengan status 500.

3. 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/allocation API dan bandingkan entri dan entri dalam shards 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  | 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 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. Selidiki kemiringan indeks jika ada beberapa indikasi kemiringan dalam metrik cluster atau node. Berikut ini adalah indikasi umum dari kemiringan indeks:

• 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, tetapi menjaga komputer Anda up-to-date adalah solusi yang lebih mudah. Untuk mempelajari lebih lanjut tentang sertifikat yang disediakan ACM, lihat AWS Certificate Manager FAQ.

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.