Object Storage Service (OSS) menyediakan metrik pemantauan yang komprehensif dan fitur pencatatan untuk membantu Anda memantau perilaku operasi program, dengan cepat mengidentifikasi potensi masalah, serta menentukan penyebab utama kegagalan. Hal ini secara signifikan meningkatkan efisiensi pemecahan masalah.
Topik ini menjelaskan cara menggunakan layanan pemantauan OSS, fitur pencatatan, dan alat pihak ketiga untuk memantau, mendiagnosis, dan memecahkan masalah saat menggunakan OSS untuk menyimpan data bisnis Anda. Layanan pemantauan OSS berfungsi untuk tujuan-tujuan berikut:
Memantau status operasi dan kinerja OSS secara real-time serta mengirimkan notifikasi peringatan.
Menyediakan metode dan alat yang efektif untuk mengidentifikasi masalah.
Memecahkan masalah berdasarkan panduan terkait.
Topik ini mencakup bagian-bagian berikut:
Layanan Pemantauan: menjelaskan cara menggunakan layanan pemantauan OSS untuk memantau status operasi dan kinerja OSS.
Pelacakan dan Diagnosis: menjelaskan cara menggunakan layanan pemantauan OSS dan fitur pencatatan untuk melacak dan mendiagnosis masalah.
Pemecahan Masalah: menjelaskan masalah umum dan solusi untuk masalah-masalah tersebut.
Layanan Pemantauan
Memantau Status Keseluruhan
Ketersediaan/Tingkat Permintaan Valid
Ketersediaan/Tingkat Permintaan Valid adalah metrik paling penting yang digunakan untuk menunjukkan stabilitas OSS dan penggunaan OSS. Persentase kurang dari 100% menunjukkan bahwa permintaan tertentu gagal.
Persentase kurang dari 100% dapat disebabkan oleh optimasi OSS seperti migrasi partisi untuk penyeimbangan beban. Dalam hal ini, SDK OSS menyediakan mekanisme ulang yang relevan untuk menangani permintaan error karena optimasi sementara ini. Dengan cara ini, bisnis Anda tidak terpengaruh.
Untuk menentukan jenis dan penyebab permintaan error serta memecahkan masalah, analisis permintaan berdasarkan detail status permintaan dan distribusi status permintaan di konsol Cloud Monitor.
Selain itu, dalam skenario bisnis tertentu, tingkat permintaan valid mungkin kurang dari 100%. Misalnya, Anda perlu mengirim permintaan untuk memeriksa apakah suatu objek ada sebelum mengelola objek dalam skenario tertentu. Jika objek tidak ada, kode status HTTP 404 dikembalikan ke klien, yang menghasilkan tingkat permintaan valid lebih rendah dari 100%.
Untuk bisnis yang memerlukan ketersediaan tinggi OSS, Anda dapat mengonfigurasi aturan peringatan yang dipicu ketika metrik turun di bawah nilai ambang batas.
Jumlah Total Permintaan/Jumlah Permintaan Valid
Metrik Jumlah Total Permintaan/Jumlah Permintaan Valid menunjukkan status operasi OSS dalam aspek jumlah permintaan. Jika jumlah permintaan valid lebih kecil daripada jumlah total permintaan, itu menunjukkan bahwa permintaan tertentu gagal.
Untuk memantau fluktuasi jumlah permintaan valid, terutama lonjakan dan penurunan, serta menganalisis penyebabnya, Anda dapat mengonfigurasi aturan peringatan untuk menerima notifikasi sesegera mungkin. Untuk informasi lebih lanjut, lihat Gunakan layanan peringatan.
Distribusi Status Permintaan
Ketika ketersediaan/tingkat permintaan valid kurang dari 100%, atau jumlah permintaan valid lebih kecil daripada jumlah total permintaan, Anda dapat melihat Distribusi Status Permintaan untuk menentukan jenis permintaan error. Untuk informasi lebih lanjut tentang Distribusi Status Permintaan, lihat Data Deret Waktu.
Memantau Status Permintaan
Detail Status Permintaan memantau berbagai jenis permintaan dan memberikan lebih banyak detail tentang pemantauan berdasarkan distribusi status permintaan.
Memantau Kinerja
Layanan pemantauan menyediakan metrik berikut untuk membantu Anda memantau kinerja OSS:
Latensi Rata-rata, yang mencakup latensi E2E rata-rata dan latensi server rata-rata
Metrik latensi menunjukkan jumlah waktu rata-rata dan maksimum yang diperlukan untuk memproses jenis permintaan tertentu yang dihasilkan dengan memanggil operasi API. Metrik latensi E2E menunjukkan jumlah waktu yang diperlukan untuk mentransmisikan permintaan antara klien dan server, yang mencakup jumlah waktu yang diperlukan untuk memproses, membaca, dan merespons permintaan, serta latensi jaringan dalam proses ini. Latensi server adalah jumlah waktu yang diperlukan untuk memproses permintaan di sisi server, yang tidak termasuk latensi jaringan selama komunikasi antara server dan klien. Oleh karena itu, ketika latensi E2E meningkat dan latensi server tetap stabil, wajar jika menentukan bahwa peningkatan latensi E2E disebabkan oleh kondisi jaringan yang buruk, yang mengecualikan kemungkinan kegagalan OSS.
Latensi Maksimum, yang mencakup latensi E2E maksimum dan latensi server maksimum
Kategori Permintaan Berhasil
Trafik
Metrik Trafik menunjukkan trafik yang digunakan oleh permintaan melalui Internet, permintaan melalui jaringan internal, permintaan balik ke asal CDN, dan tugas replikasi lintas wilayah (CRR). Layanan pemantauan menyediakan metrik trafik berdasarkan pengguna dan metrik trafik berdasarkan bucket.
OSS memantau metrik sebelumnya, kecuali trafik, berdasarkan jenis permintaan yang dikirim dengan memanggil operasi API berikut:
GetObject
HeadObject
PutObject
PostObject
AppendObject
UploadPart
UploadPartCopy
Selain itu, kategori permintaan berhasil juga mencakup permintaan yang dikirim dengan memanggil operasi API berikut:
DeleteObject
DeleteObjects
Untuk metrik yang menunjukkan kinerja OSS, Anda harus fokus pada fluktuasi abnormal mereka, seperti lonjakan dalam latensi rata-rata dan latensi tinggi yang berkepanjangan untuk permintaan. Anda dapat mengonfigurasi aturan peringatan untuk metrik kinerja sehingga notifikasi dikirim ketika aturan peringatan dipicu.
Memantau Item yang Dapat Ditagih
Layanan pemantauan OSS memungkinkan Anda memantau item yang dapat ditagih berikut: penggunaan penyimpanan, jumlah permintaan PUT dan GET, trafik arah keluar melalui Internet, yang tidak termasuk trafik arah keluar CRR atau trafik arah keluar CDN. Layanan pemantauan OSS tidak mendukung pengaturan peringatan untuk item yang dapat ditagih dan pembacaan OpenAPI.
Layanan pemantauan OSS mengumpulkan data pemantauan berdasarkan bucket setiap jam. Anda dapat melihat grafik bucket tertentu untuk mendapatkan tren data kontinu bucket. Anda dapat memprediksi tren penggunaan penyimpanan bisnis Anda dan biaya penyimpanan masa depan berdasarkan grafik pemantauan.
Layanan pemantauan OSS menyediakan statistik penggunaan sumber daya berdasarkan pengguna dan berdasarkan bucket per bulan. Penggunaan sumber daya OSS akun Alibaba Cloud atau bucket tertentu dihitung dan diperbarui setiap jam. Dengan cara ini, Anda dapat menghitung biaya penyimpanan Anda untuk bulan saat ini.
Untuk informasi lebih lanjut tentang item yang dapat ditagih dan metode penagihan OSS, lihat Billing overview.
CatatanStatistik yang diberikan oleh layanan pemantauan mungkin berbeda dari penggunaan aktual dalam tagihan. Anda akan dikenakan biaya berdasarkan penggunaan aktual dalam tagihan yang ditampilkan di konsol Biaya dan Pengeluaran.
Pelacakan dan Diagnosis
Diagnosis Masalah
Diagnosis Kinerja
Anda harus menentukan baseline kinerja aplikasi Anda berdasarkan persyaratan bisnis Anda. Masalah kinerja mungkin disebabkan oleh beban berlebih di OSS, konfigurasi TCP klien, dan hambatan lalu lintas dari jaringan.
Dengan cara ini, Anda dapat mengidentifikasi kemungkinan masalah berdasarkan metrik kinerja yang disediakan oleh layanan pemantauan. Kemudian, kueri log untuk detail lebih lanjut dan diagnosis lebih lanjut terhadap masalah tersebut.
Diagnosis Error
Aplikasi klien menerima pesan error dari server ketika terjadi kesalahan permintaan. Layanan pemantauan mencatat dan menampilkan permintaan error yang berbeda. Anda dapat memeriksa log server, klien, dan kondisi jaringan untuk mendapatkan detail tentang permintaan tertentu. Kode status HTTP dan kode error menunjukkan kemungkinan penyebab permintaan error.
Untuk informasi lebih lanjut tentang kode error, lihat Kode Error.
Gunakan Fitur Pencatatan untuk Mendiagnosis Masalah
OSS menyediakan fitur pencatatan yang dapat mencatat detail tentang permintaan.
Untuk informasi lebih lanjut tentang cara mengaktifkan dan menggunakan pencatatan, lihat Konfigurasi Pencatatan dan Pencatatan.
Gunakan Alat Log Jaringan
Dalam kasus tertentu, Anda mungkin perlu menggunakan alat log jaringan untuk menangkap lalu lintas antara klien dan server. Dengan cara ini, Anda dapat memperoleh data yang ditransmisikan dan informasi tentang kondisi jaringan. Misalnya, sebuah error dilaporkan untuk permintaan pengguna, tetapi tidak ada log yang dihasilkan untuk permintaan tersebut di server aplikasi. Dalam hal ini, periksa log OSS atau gunakan alat pemantauan jaringan untuk mengidentifikasi masalah. Salah satu alat yang sering digunakan adalah Wireshark, yang digunakan untuk melihat informasi paket rinci tentang berbagai protokol jaringan. Untuk informasi lebih lanjut, lihat Cara menginstal dan menggunakan Wireshark di Windows dan Gunakan WireShark.
Pelacakan dan Diagnosis E2E
Dalam kebanyakan kasus, permintaan dikirim dari klien ke OSS, dan server OSS memproses permintaan dan mengirim respons ke klien. Anda dapat menggunakan log klien, jaringan, dan server untuk memecahkan akar penyebab masalah. OSS menyediakan ID permintaan sebagai pengenal unik log. Selain itu, dengan menggunakan timestamp log, Anda dapat memperoleh informasi tentang peristiwa lain saat permintaan sedang diproses. Ini membantu Anda menganalisis dan menyelidiki penyebab masalah.
RequestID
OSS menetapkan ID permintaan unik untuk setiap permintaan. Di log yang berbeda, ID permintaan permintaan terdapat di bidang yang berbeda.
Di log OSS, ID permintaan berada di bidang Request ID.
Ketika Anda melacak data jaringan, seperti aliran data yang ditangkap oleh Wireshark, ID permintaan termasuk dalam respons sebagai header HTTP standar x-oss-request-id.
Di aplikasi klien, versi terbaru OSS SDK for Java menampilkan ID permintaan dalam respons. Anda dapat menggunakan metode getRequestId untuk memperoleh ID permintaan dari respons. Anda dapat memperoleh Request ID permintaan eksepsional dengan memanggil metode getRequestId operasi OSSException.
Timestamp
Anda dapat menggunakan timestamp log untuk mengkueri log. Perhatikan bahwa suatu peristiwa mungkin terjadi pada titik waktu yang berbeda di klien dan di server aplikasi. Oleh karena itu, timestamp log OSS dan log klien untuk suatu peristiwa mungkin berbeda. Saat Anda mengkueri log server berdasarkan timestamp log di klien, tambahkan 15 menit atau kurangi 15 menit dari timestamp.
Pemecahan Masalah
Masalah Terkait Kinerja
Latensi E2E Rata-rata Tinggi dan Latensi Server Rata-rata Rendah
Penyebab yang Mungkin:
Respons Lambat Aplikasi Klien
Koneksi dan thread yang tersedia terbatas.
Jalankan perintah terkait untuk memeriksa status koneksi sistem dan ubah jumlah core CPU.
Lihat hambatan sumber daya klien, tingkatkan jumlah thread konkuren secara tepat, dan optimalkan kode klien.
Sumber daya CPU, memori, atau bandwidth terbatas
Gunakan alat pemantauan untuk menentukan hambatan sumber daya dan optimalkan kode atau tingkatkan sumber daya.
Kondisi Jaringan Buruk
Gunakan Wireshark untuk menganalisis penyebab masalah jaringan.
Latensi E2E Rata-rata Rendah, Latensi Server Rata-rata Rendah, dan Latensi Permintaan Klien Tinggi
Untuk latensi permintaan klien tinggi, latensi tinggi kemungkinan besar terjadi sebelum permintaan tiba di server aplikasi. Oleh karena itu, kami sarankan Anda menganalisis mengapa permintaan dari klien tidak tiba di server.
Skenario berikut dapat menyebabkan latensi permintaan klien tinggi:
Koneksi dan thread yang tersedia terbatas.
Periksa status koneksi sistem dan ubah jumlah core CPU.
Lihat hambatan sumber daya klien, tingkatkan jumlah thread konkuren secara tepat, dan optimalkan kode klien.
Banyak upaya ulang terjadi untuk permintaan di klien
Periksa log di klien untuk menentukan penyebab upaya ulang dan gunakan Wireshark untuk mengidentifikasi masalah jaringan.
Periksa log klien untuk menentukan apakah upaya ulang dilakukan. Ambil OSS SDK for Java sebagai contoh. Anda dapat mengkueri prompt log level warn- atau info-: Jikalog serupa dicatat, upaya ulang mungkin terjadi di klien atau di server.
[Server]Tidak dapat mengeksekusi permintaan HTTP: atau [Client]Tidak dapat mengeksekusi permintaan HTTP:Ambil OSS SDK for Java sebagai contoh. Anda dapat mengkueri log berikut jika level log klien adalah debug. Jika log serupa dicatat, upaya ulang telah dilakukan.
Mengulang pada
Latensi Server Rata-rata Tinggi
Untuk latensi server rata-rata tinggi dalam unduhan dan unggahan, pertimbangkan penyebab yang mungkin berikut:
Sejumlah besar klien sering mengakses objek.
Lihat log OSS dan aktifkan CDN atau modifikasi daftar kontrol akses (ACL) bucket atau objek.
Masalah Internal OSS
Hubungi dukungan teknis dan berikan log klien untuk menyelesaikan masalah.
Error di Server Aplikasi
Peningkatan Sementara
Ubah kebijakan ulang klien dan gunakan mekanisme konsesi yang tepat.
Peningkatan Permanen
Hubungi dukungan teknis dan berikan log klien untuk menyelesaikan masalah.
Error Jaringan
Error jaringan terjadi ketika server gagal merespons permintaan karena koneksi antara server dan klien hilang saat server memproses permintaan. Dalam hal ini, kode status HTTP 499 dicatat untuk permintaan. Kode status HTTP 499 dikembalikan karena alasan berikut yang mungkin:
Sebelum server menerima permintaan untuk membaca dan menulis data, server memeriksa apakah koneksi telah dibuat. Jika tidak, kode status HTTP 499 dicatat untuk permintaan.
Kode status HTTP 499 dicatat untuk permintaan ketika server memproses permintaan tetapi klien menonaktifkan koneksi.
Error jaringan terjadi ketika klien membatalkan permintaan atau kehilangan koneksi saat permintaan sedang diproses. Jika klien membatalkan permintaan, Anda harus memeriksa kode aplikasi dan memperoleh mengapa dan kapan klien terputus dengan OSS. Jika klien kehilangan koneksi, Anda dapat menggunakan alat seperti Wireshark untuk mengidentifikasi penyebab yang mungkin.
Error Klien
Peningkatan Permintaan Error Otorisasi Klien
Ketika permintaan error otorisasi klien meningkat, atau aplikasi klien menerima sejumlah besar respons error kode status HTTP 403, pertimbangkan penyebab yang mungkin berikut:
Nama Domain Bucket Tidak Valid
Jika pengguna menggunakan domain tingkat ketiga atau domain tingkat dua untuk mengakses bucket, wilayah yang termasuk dalam nama domain mungkin berbeda dari wilayah tempat bucket berada. Misalnya, bucket yang diakses berada di wilayah China (Hangzhou), tetapi nama domain yang diakses adalah Bucket.oss-cn-shanghai.aliyuncs.com. Dalam hal ini, Anda harus memverifikasi wilayah tempat bucket berada dan mengakses nama domain yang benar.
Jika Anda menggunakan akselerasi CDN, nama domain bucket yang dipetakan ke CDN mungkin salah. Dalam hal ini, periksa apakah asalnya adalah domain tingkat tiga bucket.
Jika pengguna menggunakan klien JavaScript dan kode status HTTP 403 dikembalikan, periksa apakah Berbagi Sumber Daya Lintas Domain (CORS) dikonfigurasikan untuk browser web yang digunakan pengguna untuk mengakses bucket. Dalam hal ini, periksa dan modifikasi konfigurasi CORS bucket sehingga pengguna dapat menggunakan browser web untuk mengakses bucket. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan CORS, lihat CORS.
Kontrol Akses
Jika Anda menggunakan pasangan AccessKey akun Alibaba Cloud untuk mengakses bucket, periksa validitas pasangan AccessKey Anda.
Jika Anda menggunakan pasangan AccessKey pengguna RAM untuk mengakses bucket, periksa validitas atau otorisasi pasangan AccessKey.
Jika Anda menggunakan token sementara yang dihasilkan oleh Security Token Service (STS), periksa apakah token sementara telah kedaluwarsa. Jika token sementara telah kedaluwarsa, ajukan token baru.
Jika ACL dikonfigurasikan untuk bucket atau objek yang diakses, periksa apakah pengguna diizinkan melakukan operasi tertentu berdasarkan pengaturan ACL.
URL Kedaluwarsa
Jika kode status HTTP 403 dikembalikan ketika pengguna pihak ketiga mengakses bucket menggunakan URL bertanda tangan, penyebab yang paling mungkin adalah URL bertanda tangan telah kedaluwarsa.
Kode status HTTP 403 mungkin dikembalikan ketika pengguna RAM masuk ke alat OSS seperti ossftp, ossbrowser, dan konsol OSS. Dalam hal ini, periksa apakah pasangan AccessKey yang benar dimasukkan atau apakah pengguna memiliki izin untuk memanggil operasi GetService jika akun tersebut adalah pengguna RAM.
Peningkatan Jumlah Respons Error Kode Status HTTP 404 Terhadap Permintaan Klien
Respons error kode status HTTP 404 yang dikembalikan ke permintaan klien menunjukkan bahwa data yang diakses pengguna tidak ada. Jika jumlah respons error kode status HTTP 404 terhadap permintaan klien meningkat, pertimbangkan penyebab yang mungkin berikut:
Logika Bisnis Aplikasi. Misalnya, aplikasi memanggil metode doesObjectExist yang disediakan oleh OSS SDK for Java untuk memeriksa apakah objek ada sebelum melakukan operasi lebih lanjut. Jika objek tidak ada, nilai false dikembalikan ke klien dan kode status HTTP 404 dihasilkan di server. Dalam skenario ini, kode status HTTP 404 tidak menunjukkan error.
Objek yang diakses dihapus oleh aplikasi klien atau proses lain. Dalam hal ini, kueri log OSS objek yang diakses.
Penghapusan Berulang yang Disebabkan oleh Kegagalan Jaringan. Misalnya, klien memulai operasi untuk menghapus objek. Permintaan tiba di server, dan objek dihapus. Namun, respons tidak tiba di klien karena kegagalan jaringan. Akibatnya, klien mengirim permintaan lain untuk menghapus objek, dan kode status HTTP 404 dikembalikan. Dalam hal ini, Anda dapat mengkueri dan melihat log klien dan log OSS untuk menentukan penyebab kode status HTTP 404.
Kueri log klien dan periksa apakah permintaan berulang dikirim dari klien.
Kueri log OSS. Kemudian, periksa apakah dua operasi penghapusan diinisiasi pada objek dan kode status HTTP operasi pertama adalah 2xx.
Proporsi Permintaan Valid Rendah dan Permintaan Error Klien Tinggi
Proporsi permintaan valid adalah proporsi permintaan berhasil yang responsnya adalah kode status HTTP 2xx atau 3xx terhadap total permintaan. Permintaan yang responsnya adalah kode status HTTP 4xx atau 5xx dihitung sebagai permintaan gagal dan menurunkan proporsi permintaan valid. Permintaan error klien lainnya oleh pengguna merujuk pada permintaan error selain permintaan error server, permintaan error jaringan, permintaan error otorisasi klien, permintaan error sumber daya tidak ditemukan, dan permintaan error timeout klien. Respons terhadap permintaan error sebelumnya masing-masing adalah 5xx, 499, 403, 404, 408, atau 400 yang kode error OSS-nya adalah RequestTimeout.
Anda dapat mengkueri log OSS untuk menentukan jenis error. Kemudian, referensi kode error OSS dan pecahkan masalah dengan memodifikasi kode aplikasi. Untuk informasi lebih lanjut, lihat Kode Error.
Peningkatan Abnormal dalam Penggunaan Penyimpanan
Ketika penggunaan penyimpanan Anda meningkat secara dramatis, penyebabnya mungkin kegagalan operasi pembersihan. Pecahkan masalah dalam aspek-aspek berikut:
Aplikasi klien menggunakan proses tertentu untuk melakukan operasi pembersihan rutin untuk melepaskan penyimpanan. Lakukan langkah-langkah berikut:
Periksa apakah tingkat permintaan valid menurun karena kegagalan operasi pembersihan.
Tentukan apa yang secara spesifik menyebabkan tingkat permintaan valid menurun dan jenis permintaan error. Kemudian, peroleh detail tentang error dari log klien.
Aplikasi klien membersihkan penyimpanan bucket Anda dengan mengonfigurasi aturan siklus hidup. Untuk operasi pembersihan yang dipicu oleh aturan siklus hidup, Anda harus menggunakan konsol OSS atau memanggil operasi API untuk memeriksa apakah aturan siklus hidup dikonfigurasi dengan benar. Jika tidak, Anda dapat memodifikasi aturan siklus hidup di konsol OSS. Untuk memeriksa apakah aturan siklus hidup dimodifikasi, kueri log OSS. Jika aturan siklus hidup dikonfigurasi dengan benar tetapi tidak berlaku, hubungi dukungan teknis OSS untuk bantuan.
Masalah Layanan Penyimpanan Lainnya
Jika bagian pemecahan masalah dalam topik ini tidak dapat menyelesaikan masalah layanan penyimpanan Anda, gunakan metode berikut untuk mendiagnosis dan memecahkan masalah Anda:
Lihat layanan pemantauan OSS di konsol CloudMonitor dan periksa apakah baseline metrik telah berubah. Anda mungkin menentukan apakah masalah tersebut bersifat sementara atau permanen dan operasi penyimpanan mana yang terpengaruh oleh masalah ini.
Kueri log OSS untuk memperoleh semua error yang terjadi pada saat yang sama berdasarkan informasi pemantauan yang mungkin membantu Anda mengidentifikasi dan menyelesaikan masalah.
Jika log OSS di server tidak dapat memberikan informasi yang cukup untuk pemecahan masalah, gunakan log klien untuk menyelidiki aplikasi klien atau alat jaringan seperti Wireshark untuk menyelidiki kegagalan jaringan.