Untuk kemampuan serupa dengan Amazon Timestream LiveAnalytics, pertimbangkan Amazon Timestream untuk InfluxDB. Ini menawarkan konsumsi data yang disederhanakan dan waktu respons kueri milidetik satu digit untuk analitik waktu nyata. Pelajari lebih lanjut [di sini](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemantauan dan Pengoptimalan Konfigurasi untuk Timestream untuk InfluxDB 2
## Ikhtisar
Pemantauan dan pengoptimalan konfigurasi yang efektif sangat penting untuk menjaga kinerja, keandalan, dan efisiensi biaya yang optimal dalam Timestream Anda untuk penyebaran InfluxDB. Panduan ini memberikan panduan komprehensif tentang CloudWatch metrik, ambang kinerja, dan strategi penyetelan konfigurasi untuk membantu Anda mengelola instans InfluxDB secara proaktif.
## CloudWatch Referensi Metrik
Amazon CloudWatch menyediakan metrik terperinci untuk memantau Timestream Anda untuk instans InfluxDB. Memahami metrik ini dan ambang batasnya sangat penting untuk menjaga kesehatan dan kinerja sistem.
### Metrik Pemanfaatan Sumber Daya
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | Persentase CPU yang digunakan | Persen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | Persentase memori yang digunakan | Persen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | Jumlah memori heap yang digunakan | Byte | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | Alokasi memori aktif saat ini | Byte | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | Persentase ruang disk yang digunakan | Persen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metrik Operasi I/O
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | Jumlah operasi baca per detik | Hitungan/Detik | Pertahankan ≥ 30% ruang kepala di bawah IOPS yang disediakanContoh: 12K IOPS → pertahankan < 8,400 IOPS total |
| WriteOpsPerSec | DbInstanceName | Jumlah operasi tulis per detik | Hitungan/Detik | Pertahankan ≥ 30% ruang kepala di bawah IOPS yang disediakanContoh: 12K IOPS → pertahankan < 8,400 IOPS total |
| Jumlah IOps PerSec | DbInstanceName | Total I/O operasi per detik (baca\$1tulis) | Hitungan/Detik | Pertahankan ≥ 30% ruang kepala di bawah IOPS yang disediakanMemantau terhadap kemampuan kelas instance |
### Metrik Throughput
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | Data membaca throughput | Byte/Detik | Pantau terhadap batas throughput penyimpanan |
| WriteThroughput | DbInstanceName | Throughput penulisan data | Byte/Detik | Pantau terhadap batas throughput penyimpanan |
### Metrik Kinerja API
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| APIRequestTarif | DbInstanceName, Titik Akhir, Status | Nilai permintaan API ke titik akhir tertentu dengan kode status (2xx, 4xx, 5xx) | Hitungan/Detik | Tingkat kesalahan: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, Titik Akhir, Status | Volume tanggapan kueri berdasarkan titik akhir dan kode status | Byte | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metrik Eksekusi Kueri
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName, Hasil | Jumlah total permintaan kueri berdasarkan jenis hasil (sukses, runtime\$1error, compile\$1error, queue\$1error) | Hitungan | Tingkat keberhasilan: > 99% Tingkat kesalahan: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metrik Organisasi Data
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang Kritis |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName, Ember | Jumlah deret waktu unik dalam ember | Hitungan | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | Jumlah total ember dalam instance | Hitungan | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### Metrik Sistem Kesehatan
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | Waktu mesin InfluxDB telah berjalan | Detik | Pantau untuk restart yang tidak terdugaPeringatan: Uptime disetel ulang secara tak terduga |
| WriteTimeouts | DbInstanceName | Jumlah operasi tulis yang habis waktunya | Hitungan | Peringatan: > 0,1% dari operasi tulisKritis: Meningkatnya tren |
### Metrik Manajemen Tugas
| CloudWatch Nama Metrik | Dimensi | Deskripsi | Unit | Ambang yang Direkomendasikan |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | Jumlah pekerja tugas aktif | Hitungan | Pantau terhadap batas pekerja tugas yang dikonfigurasiPeringatan: Secara konsisten maksimal |
| TaskExecutionFailures | DbInstanceName | Jumlah eksekusi tugas yang gagal | Hitungan | Peringatan: > 1% dari eksekusi tugasKritis: Meningkatkan tingkat kegagalan |
### Memahami Hubungan Metrik Kunci
#### IOPS dan Hubungan Throughput
**Aturan Headroom 30%:** Selalu pertahankan setidaknya **30% ruang kepala** antara operasi berkelanjutan Anda per detik dan IOPS yang Anda berikan. Ini menyediakan buffer untuk:
+ Operasi pemadatan (dapat melonjak IOPS secara signifikan)
+ Setiap database restart untuk berjalan dengan lancar
+ Kueri meledak selama penggunaan puncak
+ Tulis lonjakan dari konsumsi batch
+ Operasi pemeliharaan indeks
**Contoh Perhitungan:**
+ IOPS yang disediakan: 12.000
+ Target IOPS Berkelanjutan Maksimum (Total IOpsPerSec): 8.400 (pemanfaatan 70%)
+ Ruang Kepala Cadangan: 3.600 IOPS (30%)
Jika Total IOps PerSec secara konsisten melebihi 8.400: → Tingkatkan tingkat penyimpanan atau optimalkan beban kerja
**Formula Pemantauan:**
Pemanfaatan IOPS% = (ReadOpsPerSec \$1 WriteOpsPerSec)/IOPS yang Disediakan × 100
+ Target: Jaga Pemanfaatan IOPS < 70%
+ Peringatan: Pemanfaatan IOPS > 70%
+ Kritis: Pemanfaatan IOPS> 90%
### Memahami Dampak Kinerja Kardinalitas Seri
Kardinalitas seri memiliki efek perkalian pada sumber daya sistem:
| **Hitungan Seri** | **Dampak Memori** | **Dampak Kinerja Kueri** | **Dampak Ukuran Indeks** | **Rekomendasi** |
| --- | --- | --- | --- | --- |
| < 100K | Minimal | Dapat diabaikan | Kecil | Konfigurasi standar |
| 100K - 1M | Sedang | 10-20% lebih lambat | Sedang | Setel pengaturan cache |
| 1M - 5M | Signifikan | 30-50% lebih lambat | Besar | Diperlukan optimasi agresif |
| 5M - 10M | Tinggi | 50-70% lebih lambat | Sangat Besar | Penyetelan maksimum, pertimbangkan desain ulang |
| > 10M | Parah | 70% \$1 lebih lambat | Berlebihan | Migrasi ke InfluxDB 3.0 |
**Mengapa 10M adalah Ambang Kritis:**
+ Arsitektur InfluxDB 2.x menggunakan pengindeksan dalam memori
+ Di luar seri 10M, operasi indeks menjadi sangat mahal
+ Kebutuhan memori tumbuh secara non-linier
+ Overhead perencanaan kueri meningkat secara dramatis
+ InfluxDB 3.0 menggunakan mesin penyimpanan kolumnar yang dirancang untuk kardinalitas tinggi
## Ukuran Instans dan Pedoman Kinerja
Tabel berikut memberikan panduan tentang ukuran instans yang sesuai berdasarkan kardinalitas seri dan karakteristik beban kerja Anda:
| **Jumlah Seri Maks** | **Menulis (baris/detik)** | **Membaca (pertanyaan/detik)** | **Instance yang Direkomendasikan** | **Jenis Penyimpanan** | **Kasus Penggunaan** |
| --- | --- | --- | --- | --- | --- |
| < 100K | \$1 50.000 | < 10 | db.influx.large | Influx IO Termasuk 3K | Penerapan kecil, pengembangan, pengujian |
| < 1M | \$1 150.000 | < 25 | db.influx.2xlarge | Influx IO Termasuk 3K | Beban kerja produksi kecil hingga menengah |
| \$1 1M | \$1 200.000 | \$1 25 | db.influx.4xlarge | Influx IO Termasuk 3K | Beban kerja produksi sedang |
| < 5M | \$1 250.000 | \$135 | db.influx.4xlarge | Influx IO Termasuk 12K | Beban kerja produksi besar |
| <10M | \$1 500.000 | \$150 | db.influx.8xlarge | Influx IO Termasuk 12K | Beban kerja produksi yang sangat besar |
| \$1 10M | < 750.000 | < 100 | db.influx.12xlarge | Influx IO Termasuk 12K | Kapasitas maksimum InfluxDB 2.x |
| > 10M | N/A | N/A | Migrasi ke InfluxDB 3.0 | N/A | Di luar jangkauan optimal InfluxDB 2.x |
## Optimasi Konfigurasi menurut Metrik
### Pemanfaatan CPU Tinggi (CPUUtilization > 70%)
**Gejala:**
+ **CPUUtilization**> 70% berkelanjutan
+ **QueryRequestsTotal**(volume tinggi atau kueri lambat)
+ **ActiveTaskWorkers**(beban tugas tinggi)
**Penyesuaian Konfigurasi:**
**Prioritas 1: Kontrol Konkurensi Kueri**
+ query-concurrency: Setel ke 50-75% dari jumlah vCPU
+ Contoh: 8 vCPU instance → query-concurrency = 4-6
**Prioritas 2: Batasi Kompleksitas Kueri**
+ influxql-max-select-series: 10000 (mencegah kueri tak terbatas)
+ influxql-max-select-point: 100000000
+ query-queue-size: 2048 (mencegah penumpukan antrian)
**Prioritas 3: Aktifkan Analisis Kueri**
+ flux-log-enabled: TRUE (sementara untuk debugging)
+ log-level: info (atau debug untuk analisis terperinci)
**Pertimbangan Penting:**
Mengurangi `query-concurrency` akan membatasi jumlah kueri yang dapat dijalankan secara bersamaan, yang dapat meningkatkan kueri antrian dan menyebabkan latensi kueri yang lebih tinggi selama periode puncak. Pengguna mungkin mengalami pemuatan dasbor yang lebih lambat atau melaporkan batas waktu jika permintaan kueri melebihi batas konkurensi yang dikurangi.
**Menyetel batas perlindungan (`influxql-max-select-series`,`influxql-max-select-point`) akan menyebabkan kueri yang melebihi ambang batas ini gagal dengan **compile\$1error** atau runtime\$1error di. **QueryRequestsTotal**** Meskipun ini melindungi sistem dari kehabisan sumber daya, ini dapat merusak kueri yang ada yang sebelumnya berfungsi.
**Praktik Terbaik:** Sebelum menerapkan perubahan ini, analisis pola kueri Anda menggunakan **QueryResponseVolume**dan **QueryRequestsTotal**metrik. Identifikasi dan optimalkan kueri yang paling mahal terlebih dahulu - cari kueri tanpa filter rentang waktu, kueri yang mencakup seri kardinalitas tinggi, atau kueri yang meminta titik data yang berlebihan. Mengoptimalkan kueri di tingkat aplikasi selalu lebih baik daripada memaksakan batas keras yang dapat merusak fungsionalitas.
**Tindakan Perangkat Keras:**
+ Skala ke kelas instance berikutnya dengan lebih banyak v CPUs
+ Tinjau pola kueri untuk peluang pengoptimalan
### Pemanfaatan Memori Tinggi (MemoryUtilization > 70%)
**Gejala:**
+ **MemoryUtilization**> 70% berkelanjutan
+ **HeapMemoryUsage**tren ke atas
+ **ActiveMemoryAllocation**menunjukkan paku
+ **SeriesCardinality**(kardinalitas tinggi meningkatkan penggunaan memori)
**Penyesuaian Konfigurasi:**
**Prioritas 1: Kurangi Memori Cache**
+ storage-cache-max-memory-ukuran: Setel ke 10-15% dari total RAM
+ Contoh: 32GB RAM → 3.355.443.200 hingga 5.033.164.800 byte
+ storage-cache-snapshot-memory-ukuran: 26.214,400 (25MB)
**Prioritas 2: Batasi Memori Kueri**
+ query-memory-bytes: Setel ke 60-70% dari total RAM
+ query-max-memory-bytes: Sama seperti query-memory-bytes
+ query-initial-memory-bytes: 10% dari query-memory-bytes
**Prioritas 3: Optimalkan Cache Seri**
+ storage-series-id-set-ukuran cache: Kurangi jika kardinalitas tinggi
+ Memori tinggi: 100-200
+ Normal: 500-1000
**Pertimbangan Penting:**
Sementara perubahan ini akan mengurangi tekanan memori, mereka akan memiliki dampak negatif langsung pada kinerja aplikasi. Mengurangi `storage-cache-max-memory-size` berarti lebih sedikit data yang di-cache dalam memori, memaksa lebih banyak pembacaan disk dan meningkatkan latensi kueri - Anda mungkin akan melihat **ReadOpsPerSec**peningkatan dan waktu **QueryResponseVolume**respons menurun.
Pembatasan `query-memory-bytes` akan menyebabkan kueri intensif memori gagal dengan **runtime\$1error** di **QueryRequestsTotal**, terutama kueri yang menggabungkan kumpulan data besar atau mengembalikan set hasil yang substansif. Pengguna mungkin mengalami kesalahan “kehabisan memori” untuk kueri yang sebelumnya berhasil.
Mengurangi `storage-series-id-set-cache-size` menurunkan kinerja untuk kueri terhadap data kardinalitas tinggi, karena sistem harus menghitung ulang hasil seri lebih sering daripada mengambilnya dari cache. Ini terutama memengaruhi dasbor yang berulang kali menanyakan kombinasi seri yang sama.
**Praktik Terbaik:** Sebelum menerapkan perubahan restriktif ini, analisis pola kueri Anda dan optimalkan terlebih dahulu:
+ Tinjau **QueryResponseVolume**untuk mengidentifikasi kueri yang mengembalikan data yang berlebihan
+ Gunakan **QueryRequestsTotal**untuk menemukan kueri yang sering dijalankan yang dapat mengambil manfaat dari pengoptimalan
+ Tambahkan filter rentang waktu untuk mengurangi pemindaian data ke apa yang diperlukan untuk beban kerja Anda
+ Menerapkan caching hasil kueri di tingkat aplikasi
+ Pertimbangkan pra-agregasi data menggunakan tugas downsampling
+ Tinjau **SeriesCardinality**dan optimalkan model data Anda untuk mengurangi tag yang tidak perlu
Pengoptimalan kueri harus selalu menjadi pendekatan pertama Anda - pembatasan konfigurasi harus menjadi pilihan terakhir ketika pengoptimalan tidak cukup.
**Tindakan Perangkat Keras:**
+ Tingkatkan ukuran instans untuk lebih banyak RAM
### Pemanfaatan Penyimpanan Tinggi (DiskUtilization > 70%)
**CloudWatch Metrik untuk Memantau:**
+ **DiskUtilization**> 70%
+ **WriteThroughput**pola
+ **TotalBuckets**(banyak ember bertambah overhead)
**Penyesuaian Konfigurasi:**
**Prioritas 1: Periksa Konfigurasi Logging**
+ log-level: Pastikan disetel ke “info” (bukan “debug”)
+ flux-log-enabled: Setel ke FALSE kecuali secara aktif men-debug
**Prioritas 2: Retensi Agresif**
+ storage-retention-check-interval: 15m0s (pembersihan lebih sering)
**Prioritas 3: Optimalkan Pemadatan**
+ storage-compact-full-write-durasi-dingin: 2h0m0s (lebih sering)
+ storage-cache-snapshot-write-durasi-dingin: 5m0s
**Prioritas 4: Kurangi Ukuran Indeks**
+ storage-max-index-log-file-size: 524.288 (512KB untuk pemadatan lebih cepat)
**Pertimbangan Penting:**
**Langkah Pertama Kritis - Periksa Konfigurasi Logging Anda:** Sebelum membuat perubahan lain, verifikasi pengaturan logging Anda. Pencatatan **debug dan log kueri Flux dapat menghabiskan ruang disk sebanyak atau lebih banyak daripada data deret waktu Anda yang sebenarnya**, dan ini adalah salah satu penyebab paling umum dari kelelahan penyimpanan yang tidak terduga.
**Dampak Penebangan:**
+ `log-level: debug`menghasilkan log yang sangat bertele-tele, berpotensi ratusan MB per jam
+ `flux-log-enabled: TRUE`mencatat setiap eksekusi kueri Flux dengan detail lengkap, membuat file log besar
+ Log ini terakumulasi dengan cepat dan sering diabaikan selama perencanaan kapasitas
+ File log dapat mengisi ruang disk lebih cepat daripada konsumsi data, terutama pada instance yang lebih kecil
+ Tidak seperti data deret waktu, log disimpan dalam penyimpanan lokal selama 24 jam sebelum penghapusan
**Tindakan Segera jika Log Besar:**
1. Set `log-level: info` (dari debug)
1. Set `flux-log-enabled: FALSE`
1. Pantau **DiskUtilization**untuk perbaikan segera
**Trade-off Konfigurasi Pemadatan:**
Perubahan konfigurasi ini dirancang khusus untuk beban kerja dengan **throughput konsumsi tinggi dan jendela retensi pendek** di mana penggunaan disk berfluktuasi secara substansif. Mereka memaksa mesin pemadatan untuk bekerja lebih agresif, yang hanya bermanfaat dalam skenario tertentu.
**Trade-off Kritis:** Meningkatkan frekuensi pemadatan akan secara signifikan meningkatkan konsumsi sumber daya:
+ **CPUUtilization**akan meningkat karena operasi pemadatan mengkonsumsi siklus CPU
+ **MemoryUtilization**akan meningkat selama pemadatan karena data dimuat dan diproses
+ **WriteOpsPerSec**dan **WriteThroughput**akan melonjak selama jendela pemadatan, berpotensi melebihi ruang kepala IOPS 30% Anda
+ **WriteTimeouts**dapat meningkat jika pemadatan I/O bersaing dengan penulisan aplikasi
Perubahan ini dapat menciptakan masalah kinerja cascading di mana pemadatan agresif mengkonsumsi sumber daya yang diperlukan untuk operasi kueri dan penulisan, menurunkan kinerja sistem secara keseluruhan bahkan sambil mengurangi penggunaan disk.
**Praktik Terbaik:** Sebelum menyesuaikan pengaturan pemadatan, fokuslah pada data dan manajemen logging:
1. **Periksa Logging Pertama (Masalah Paling Umum):** Verifikasi log-level adalah “info” dan flux-log-enabled FALSE
1. **Tinjau Model Data Anda:** Apakah Anda menulis data yang sebenarnya tidak Anda butuhkan? Bisakah Anda mengurangi pengukuran atau granularitas bidang?
1. **Optimalkan Kebijakan Retensi:** Periksa **TotalBuckets**dan tinjau setelan retensi untuk setiap bucket
1. **Memantau Dampak Pemadatan:** Garis dasar Anda **CPUUtilization**, **MemoryUtilization**, dan sebelum perubahan **WriteOpsPerSec**
**Pendekatan Alternatif:**
+ Meningkatkan kapasitas penyimpanan (seringkali lebih sederhana dan lebih hemat biaya)
+ Menerapkan strategi downsampling atau agregasi data
+ Konsolidasikan ember (kurangi **TotalBuckets**) untuk mengurangi overhead
+ Meninjau dan menegakkan kebijakan retensi secara lebih ketat
Hanya terapkan pengaturan pemadatan agresif jika Anda telah mengoptimalkan manajemen data dan mengonfirmasi instans Anda memiliki CPU, memori, dan ruang kepala IOPS yang cukup untuk menangani peningkatan beban.
**Tindakan Perangkat Keras:**
+ Meningkatkan kapasitas penyimpanan
### Pemanfaatan IOPS Tinggi (ReadIOPS/WriteIOPS/TotalOperationsPerSecond> 70% dari yang disediakan)
**CloudWatch Metrik untuk Memantau:**
+ **ReadOpsPerSec**\$1 **WriteOpsPerSec**= **Jumlah IOps PerSec**
+ **ReadThroughput** dan **WriteThroughput**
+ Bandingkan dengan IOPS yang disediakan (3K, 12K, atau 16K)
**Penyesuaian Konfigurasi:**
**Prioritas 1: Kontrol Pemadatan I/O**
+ storage-max-concurrent-compactions: 2-3 (batasi pemadatan bersamaan)
+ storage-compact-throughput-burst: Sesuaikan berdasarkan kemampuan disk
+ 3K IOPS: 25.165.824 (24MB/s)
+ 12K IOPS: 50.331.648 (48MB/s)
**Prioritas 2: Optimalkan Operasi Tulis**
+ storage-wal-max-concurrent-menulis: 8-12
+ storage-wal-max-write-keterlambatan: 5m0s
**Prioritas 3: Sesuaikan Waktu Snapshot**
+ storage-cache-snapshot-write-durasi dingin: 15m0s (lebih jarang)
+ storage-compact-full-write-durasi dingin: 6h0m0s (lebih jarang)
**Pertimbangan Penting:**
Perubahan ini menciptakan trade-off yang signifikan antara I/O pemanfaatan dan kinerja sistem:
**Membatasi Pemadatan I/O:**
+ Mengurangi `storage-max-concurrent-compactions` akan memperlambat operasi pemadatan, menyebabkan file TSM menumpuk dan meningkat **DiskUtilization**lebih cepat
+ Lebih rendah `storage-compact-throughput-burst` memperpanjang durasi pemadatan, menjaga pemadat tetap aktif lebih lama dan berpotensi memblokir operasi lain
+ Pemadatan yang lebih lambat berarti kinerja kueri menurun seiring waktu karena mesin penyimpanan harus membaca dari lebih banyak file TSM yang lebih kecil daripada yang terkonsolidasi
+ Anda mungkin melihat tingkat **QueryRequestsTotal**runtime\$1error meningkat karena batas waktu kueri sambil menunggu I/O
**Mengurangi Frekuensi Snapshot:**
+ Meningkat `storage-cache-snapshot-write-cold-duration` dan `storage-compact-full-write-cold-duration` berarti data tetap berada di log write-ahead (WAL) lebih lama
+ Ini meningkat **MemoryUtilization**karena lebih banyak data disimpan dalam cache sebelum dibuang ke disk
+ Risiko kehilangan data sedikit meningkat jika instance crash sebelum data cache dipertahankan
+ Waktu pemulihan setelah restart meningkat karena lebih banyak data WAL harus diputar ulang
**Tulis Operasi Tuning:**
+ Mengurangi `storage-wal-max-concurrent-writes` akan membuat serialisasi operasi penulisan lebih banyak, berpotensi meningkat **WriteTimeouts**selama periode throughput tinggi
+ Meningkatnya `storage-wal-max-write-delay` berarti menulis mungkin menunggu lebih lama sebelum ditolak, yang dapat menutupi masalah kapasitas tetapi membuat pengguna frustrasi dengan respons yang lambat
**Praktik Terbaik:** Pemanfaatan IOPS yang tinggi biasanya menunjukkan bahwa Anda telah melampaui tingkat penyimpanan Anda daripada masalah konfigurasi. Sebelum membatasi I/O, analyze I/O pola dan mengoptimalkan sebelum membatasi.
**Tindakan Perangkat Keras:**
+ Tingkatkan ke tingkat penyimpanan IOPS yang lebih tinggi (3K → 12K)
+ Pastikan 30% headroom IOPS dipertahankan
### Kardinalitas Seri Tinggi (SeriesCardinality > 1M)
**CloudWatch Metrik untuk Memantau:**
+ **SeriesCardinality**per ember dan total
+ **MemoryUtilization**(meningkat dengan kardinalitas)
+ **CPUUtilization**(overhead perencanaan kueri)
+ **QueryRequestsTotal**(tingkat runtime\$1error dapat meningkat)
**Penyesuaian Konfigurasi:**
**Prioritas 1: Optimalkan Penanganan Seri**
+ storage-series-id-set-ukuran cache: 1000-2000 (meningkatkan cache)
+ storage-series-file-max-concurrent-snapshot-compactions: 4-8
**Prioritas 2: Tetapkan Batas Perlindungan**
+ influxql-max-select-series: 10000 (mencegah kueri pelarian)
+ influxql-max-select-buckets: 1000
**Prioritas 3: Optimalkan Operasi Indeks**
+ storage-max-index-log-ukuran file: 2.097.152 (2MB)
**Pertimbangan Penting:**
Kardinalitas seri tinggi pada dasarnya adalah masalah pemodelan data, bukan masalah konfigurasi. Perubahan konfigurasi hanya dapat mengurangi gejala - mereka tidak dapat menyelesaikan masalah yang mendasarinya.
**Konfigurasi Trade-off:**
Peningkatan `storage-series-id-set-cache-size` akan meningkatkan kinerja kueri dengan caching seri pencarian, tetapi dengan biaya peningkatan. **MemoryUtilization** Setiap entri cache menghabiskan memori, dan dengan jutaan seri, ini bisa sangat besar. Pantau **HeapMemoryUsage**dan **ActiveMemoryAllocation**setelah melakukan perubahan ini.
Menyetel batas perlindungan (`influxql-max-select-series`,`influxql-max-select-buckets`) akan menyebabkan kueri yang sah gagal dengan **compile\$1error **QueryRequestsTotal****jika melebihi ambang batas ini. Dasbor yang sebelumnya berfungsi dapat rusak, dan pengguna perlu memodifikasi kueri mereka. Ini sangat bermasalah untuk:
+ Memantau dasbor yang terkumpul di banyak host/layanan
+ Kueri analitik yang perlu membandingkan beberapa entitas
+ Peringatan kueri yang mengevaluasi kondisi di seluruh armada
Menyesuaikan `storage-max-index-log-file-size` dengan nilai yang lebih kecil meningkatkan frekuensi pemadatan indeks, yang meningkat **CPUUtilization**dan **WriteOpsPerSec**saat sistem melakukan pemeliharaan indeks yang lebih sering.
**Pemahaman Kritis:**
Ketika **SeriesCardinality**melebihi 5M, Anda mendekati batas arsitektur InfluxDB 2.x. Pada seri 10M\$1, kinerja menurun secara eksponensial terlepas dari konfigurasi:
+ Perencanaan kueri menjadi sangat mahal (tinggi) **CPUUtilization**
+ Kebutuhan memori tumbuh secara non-linier (tinggi) **MemoryUtilization**
+ Operasi indeks mendominasi I/O (**ReadOpsPerSec**, **WriteOpsPerSec**)
+ **QueryRequestsTotal**tingkat runtime\$1error meningkat karena batas waktu kueri atau memori knalpot
**Praktik Terbaik:** Perubahan konfigurasi adalah alat bantu pita sementara. Anda harus mengatasi akar penyebabnya:
1. **Analisis Model Data Anda:**
+ Tinjau **SeriesCardinality**per ember untuk mengidentifikasi area masalah
+ Identifikasi tag mana yang memiliki jumlah nilai unik yang tinggi
+ Cari nilai tag tak terbatas (UUIDs, stempel waktu, pengguna, sesi) IDs IDs
+ Temukan tag yang seharusnya berupa bidang
**Tindakan Model Data:**
+ Tinjau desain tag untuk mengurangi kardinalitas yang tidak perlu
+ Pertimbangkan untuk mengkonsolidasikan seri serupa
+ **Jika > seri 10M:** Rencanakan migrasi ke InfluxDB 3.0
### Masalah Kinerja Kueri
**CloudWatch Metrik untuk Memantau:**
+ **QueryRequestsTotal**berdasarkan jenis hasil (sukses, runtime\$1error, compile\$1error, queue\$1error)
+ **APIRequestNilai** dengan Status = 500 atau Status = 499
+ **QueryResponseVolume**(tanggapan besar menunjukkan pertanyaan mahal)
**Penyesuaian Konfigurasi:**
**Prioritas 1: Meningkatkan Sumber Daya Kueri**
+ query-concurrency: Meningkat menjadi 75% dari v CPUs
+ query-memory-bytes: Alokasikan 70% dari total RAM
+ query-queue-size: 4096
**Prioritas 2: Optimalkan Eksekusi Kueri**
+ storage-series-id-set-ukuran cache: 1000 (meningkat untuk caching yang lebih baik)
+ http-read-timeout: 60-an (mencegah batas waktu prematur)
**Prioritas 3: Tetapkan Batas yang Wajar**
+ influxql-max-select-point: 100000000
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
**Pertimbangan Penting:**
Meningkatkan sumber daya kueri menciptakan persaingan sumber daya dan potensi ketidakstabilan sistem:
**Pertukaran Alokasi Sumber Daya:**
Peningkatan `query-concurrency` memungkinkan lebih banyak kueri untuk berjalan secara bersamaan, tetapi setiap kueri bersaing untuk CPU dan memori:
+ **CPUUtilization**akan meningkat, berpotensi mencapai saturasi selama periode kueri puncak
+ **MemoryUtilization**akan meningkat karena lebih banyak kueri mengalokasikan memori secara bersamaan
+ Jika Anda meningkatkan konkurensi tanpa sumber daya yang memadai, semua kueri melambat, bukan hanya beberapa antrian
+ Risiko kegagalan cascading jika kueri bersamaan menghabiskan sumber daya yang tersedia
Mengalokasikan lebih banyak `query-memory-bytes` berarti lebih sedikit memori yang tersedia untuk caching dan operasi lainnya:
+ **HeapMemoryUsage**akan meningkat
+ `storage-cache-max-memory-size`mungkin perlu dikurangi untuk mengkompensasi
+ Lebih sedikit klik cache berarti kinerja kueri yang lebih tinggi **ReadOpsPerSec**dan lebih lambat
+ Sistem menjadi lebih rentan terhadap kelelahan memori jika kueri menggunakan alokasi penuh mereka
Peningkatan `query-queue-size` hanya menunda masalah - itu tidak menyelesaikan masalah kapasitas:
+ Kueri menunggu lebih lama dalam antrian, meningkatkan latensi end-to-end
+ Pengguna menganggap sistem lebih lambat meskipun throughput mungkin tidak berubah
+ Antrian besar dapat menutupi masalah kapasitas yang mendasarinya
+ **QueryRequestsTotal**tingkat queue\$1error menurun, tetapi pengalaman pengguna mungkin tidak membaik
Peningkatan `http-read-timeout` mencegah pembatalan kueri prematur, tetapi:
+ Kueri yang berjalan lama menghabiskan sumber daya lebih lama, mengurangi kapasitas untuk kueri lain
+ Pengguna menunggu lebih lama sebelum menerima kesalahan batas waktu
+ Dapat menyembunyikan kueri yang tidak efisien yang harus dioptimalkan
+ Dapat menyebabkan kehabisan sumber daya jika banyak kueri lambat menumpuk
**Praktik Terbaik:** Masalah kinerja kueri biasanya disebabkan oleh kueri yang tidak efisien, bukan sumber daya yang tidak mencukupi. Sebelum meningkatkan alokasi sumber daya:
1. **Menganalisis Pola Kueri:**
+ Tinjau **QueryResponseVolume**untuk mengidentifikasi kueri yang mengembalikan data berlebihan (> 1MB)
+ Periksa pola **QueryRequestsTotal**runtime\$1error - apa yang menyebabkan kegagalan?
+ Cari **APIRequestRate** with Status=499 (batas waktu klien) - kueri terlalu lambat
+ Identifikasi kueri mahal yang sering dieksekusi
1. **Optimalkan Kueri Pertama:**
Kueri Umum Anti-pola:
+ Filter rentang waktu yang hilang → Tambahkan batas waktu eksplisit
+ Menanyakan semua seri → Tambahkan filter tag tertentu
+ Jendela agregasi berlebihan → Gunakan interval yang sesuai
+ Bidang yang tidak perlu di SELECT → Minta hanya data yang diperlukan
+ Tidak ada klausul LIMIT → Tambahkan batas yang wajar
1. **Solusi Tingkat Aplikasi:**
+ Menerapkan caching hasil kueri (Redis, Memcached)
+ Gunakan tugas untuk pra-agregat pola umum
+ Tambahkan pagination untuk set hasil besar
+ Menerapkan pembatasan tingkat kueri per pengguna/dasbor
+ Gunakan data downsampled untuk kueri historis
1. **Verifikasi Ketersediaan Sumber Daya:**
+ Periksa **CPUUtilization**- jika sudah > 70%, meningkatkan konkurensi akan memperburuk keadaan
+ Periksa **MemoryUtilization**- jika sudah > 70%, mengalokasikan lebih banyak memori kueri akan menyebabkan OOM
+ Verifikasi **Total IOps PerSec** memiliki 30% headroom sebelum meningkatkan beban kueri
**Pendekatan yang Direkomendasikan:**
1. Mulailah dengan mengoptimalkan 10 kueri termahal teratas (oleh) **QueryResponseVolume**
1. Menerapkan caching hasil kueri di tingkat aplikasi
1. Hanya tingkatkan alokasi sumber daya jika kueri dioptimalkan dan metrik menampilkan headroom
1. Skala ke kelas instance yang lebih besar jika beban kerja melebihi kapasitas saat ini
**Tindakan Perangkat Keras:**
+ Skala kapasitas komputasi Anda, kueri mendapat manfaat dari daya pemrosesan ekstra (v) CPUs
#### RegEx Perangkap Kinerja dalam Kueri Flux
Saat memfilter data di Flux, hindari menggunakan ekspresi reguler untuk kecocokan persis atau pencocokan pola sederhana, karena ini akan menimbulkan penalti kinerja yang signifikan. RegEx operasi di Flux **berulir tunggal dan melewati indeks TSM** **yang mendasarinya sepenuhnya.** Alih-alih memanfaatkan indeks tag InfluxDB yang dioptimalkan untuk pencarian cepat, RegEx filter memaksa mesin kueri untuk mengambil semua seri yang cocok dari penyimpanan dan melakukan perbandingan teks secara berurutan terhadap setiap nilai. Ini menjadi sangat bermasalah ketika:
+ **Memfilter pada nilai tag yang tepat** - Gunakan operator kesetaraan (`==`) atau `contains()` fungsi alih-alih RegEx pola seperti `/^exact_value$/`
+ **Mencocokkan beberapa nilai tertentu** - Gunakan `in` operator dengan larik nilai daripada pola pergantian seperti `/(value1|value2|value3)/`
+ **Awalan sederhana atau pencocokan akhiran** - Pertimbangkan untuk menggunakan `strings.hasPrefix()` atau `strings.hasSuffix()` fungsi, yang lebih efisien daripada jangkar RegEx
Untuk skenario yang membutuhkan beberapa kecocokan pola, restrukturisasi kueri Anda untuk menggunakan beberapa predikat filter yang dikombinasikan dengan operator logis, atau pra-filter menggunakan kesetaraan tag sebelum menerapkan operasi string yang lebih kompleks. Cadangan RegEx khusus untuk kasus yang membutuhkan pencocokan pola sebenarnya yang tidak dapat diekspresikan melalui operator perbandingan yang lebih sederhana.
### Tulis Masalah Kinerja
**CloudWatch Metrik untuk Memantau:**
+ **WriteTimeouts**(peningkatan jumlah)
+ **WriteOpsPerSec** dan **WriteThroughput**
+ **APIRequestNilai** dengan Status = 500 untuk menulis titik akhir
+ **QueryRequestsTotal**dengan result=runtime\$1error selama penulisan
**Penyesuaian Konfigurasi:**
**Prioritas 1: Optimalkan WAL Menulis**
+ storage-wal-max-concurrent-menulis: 12-16
+ storage-wal-max-write-keterlambatan: 10m0s
+ http-write-timeout: 60-an
**Prioritas 2: Optimalkan Snapshot Cache**
+ storage-cache-snapshot-memory-ukuran: 52.428.800 (50MB)
+ storage-cache-snapshot-write-durasi-dingin: 10m0s
**Prioritas 3: Validasi Bidang Kontrol**
+ storage-no-validate-field-size: TRUE (jika sumber data dipercaya)
**Pertimbangan Penting:**
Penyetelan kinerja tulis melibatkan pertukaran yang cermat antara throughput, keandalan, dan konsumsi sumber daya:
**Trade-off Konfigurasi WAL:**
Peningkatan `storage-wal-max-concurrent-writes` memungkinkan lebih banyak operasi penulisan paralel, tetapi:
+ **CPUUtilization**meningkat karena lebih banyak utas tulis bersaing untuk CPU
+ **MemoryUtilization**meningkat karena lebih banyak data disangga dalam memori sebelum WAL flush
+ **WriteOpsPerSec**akan melonjak, berpotensi melebihi ruang kepala IOPS 30% Anda
+ Peningkatan pertengkaran untuk disk sebenarnya I/O dapat memperlambat penulisan individu
+ Jika Anda melebihi I/O kapasitas disk, **WriteTimeouts**dapat meningkat daripada menurun
Meningkat `storage-wal-max-write-delay` berarti menulis menunggu lebih lama sebelum waktu habis:
+ Masker masalah kapasitas dengan membuat penulisan menunggu alih-alih gagal dengan cepat
+ Pengguna mengalami waktu respons tulis yang lebih lambat bahkan ketika penulisan akhirnya berhasil
+ Dapat menyebabkan penumpukan antrian tulis dan tekanan memori
+ Tidak benar-benar meningkatkan kapasitas - hanya menunda batas waktu
Meningkatkan kesalahan batas waktu penundaan yang `http-write-timeout` serupa:
+ Memungkinkan penulisan batch yang lebih besar untuk diselesaikan
+ Tetapi juga memungkinkan penulisan lambat untuk mengkonsumsi sumber daya lebih lama
+ Dapat menyembunyikan masalah kinerja yang mendasarinya
+ Dapat menyebabkan kelelahan sumber daya jika banyak penulisan lambat menumpuk
**Trade-off Cache Snapshot:**
Meningkat `storage-cache-snapshot-memory-size` berarti lebih banyak data terakumulasi dalam memori sebelum pembilasan:
+ **MemoryUtilization**meningkat secara signifikan
+ Risiko kehilangan data meningkat jika instance crash sebelum snapshot
+ Snapshot yang lebih besar membutuhkan waktu lebih lama untuk ditulis, menciptakan lonjakan yang lebih besar **WriteOpsPerSec**
+ Dapat meningkatkan throughput tulis dengan mengumpulkan lebih banyak data, tetapi dengan mengorbankan memori dan keandalan
Meningkatkan jepretan `storage-cache-snapshot-write-cold-duration` penundaan:
+ Lebih lanjut meningkat **MemoryUtilization**karena data tetap dalam cache lebih lama
+ Meningkatkan jendela risiko kehilangan data
+ Mengurangi **WriteOpsPerSec**frekuensi tetapi menciptakan lonjakan yang lebih besar saat snapshot terjadi
+ Waktu pemulihan setelah restart meningkat karena lebih banyak WAL harus diputar ulang
**Trade-off Validasi Bidang:**
Pengaturan `storage-no-validate-field-size: TRUE` menonaktifkan validasi ukuran bidang:
+ Meningkatkan throughput penulisan dengan melewatkan pemeriksaan validasi
+ **Risiko Kritis:** Memungkinkan data yang salah bentuk atau berbahaya ditulis
+ Dapat menyebabkan kerusakan data jika penulisan berisi ukuran bidang yang tidak valid
+ Membuat masalah data debugging jauh lebih sulit
+ **Gunakan hanya jika Anda memiliki kontrol penuh dan kepercayaan atas sumber data Anda**
**Praktik Terbaik:** Masalah kinerja tulis biasanya menunjukkan batas kapasitas atau pola penulisan yang tidak efisien. Sebelum menyetel konfigurasi:
1. **Analisis Pola Tulis:**
+ Ulasan **WriteThroughput**dan **WriteOpsPerSec**tren
+ Periksa **WriteTimeouts**korelasi dengan beban tulis
+ **APIRequestTingkat** Monitor untuk menulis titik akhir berdasarkan kode status
+ Identifikasi ukuran dan frekuensi batch tulis
1. **Optimalkan Operasi Tulis Pertama:**
Tulis Umum Anti-pola:
+ Menulis poin individu → Batch menulis (5.000-10.000 poin)
+ Terlalu sering menulis → Buffer dan batch
+ Penulisan sinkron → Terapkan antrian tulis async
+ Semburan tulis tanpa batas → Menerapkan pembatasan laju
+ Menulis presisi yang tidak perlu → Stempel waktu bundar dengan tepat
1. **Verifikasi I/O Kapasitas:**
+ Periksa **Total IOps PerSec** - jika sudah > 70%, meningkatkan konkurensi WAL akan memperburuk keadaan
+ Tinjau **WriteOpsPerSec**selama periode puncak
+ Pastikan ruang kepala IOPS 30% ada sebelum menyetel pengaturan tulis
+ Pertimbangkan apakah 3K IOPS cukup atau jika tingkat 12K IOPS diperlukan
1. **Perbaikan Tingkat Aplikasi:**
+ Terapkan buffering tulis dengan ukuran batch yang dapat dikonfigurasi
+ Tambahkan logika coba lagi tulis dengan backoff eksponensial
+ Gunakan operasi tulis asinkron
+ Menerapkan pembatasan laju tulis selama periode puncak
+ Pantau kedalaman antrian tulis dan terapkan tekanan balik
**Pendekatan yang Direkomendasikan:**
1. Mulailah dengan mengoptimalkan ukuran batch tulis di tingkat aplikasi (bertujuan untuk 5.000-10.000 poin per batch)
1. Menerapkan operasi buffering tulis dan async
1. Verifikasi **Total IOps PerSec** memiliki ruang kepala yang memadai
1. Tingkatkan ke tingkat penyimpanan berikutnya (3K IOPS → 12K IOPS → 16K IOPS) jika secara konsisten di atas 70% pemanfaatan
1. Hanya atur pengaturan WAL jika penulisan dioptimalkan dan I/O kapasitasnya memadai
1. **Jangan pernah** menonaktifkan validasi bidang kecuali Anda memiliki kontrol penuh atas sumber data
**Tindakan Perangkat Keras:**
+ Tingkatkan ke penyimpanan IOPS yang lebih tinggi (3K → 12K → 16K)
+ Pastikan I/O headroom memadai
+ Skala ke kelas instance yang lebih besar jika CPU atau memori dibatasi
## Memantau Praktik Terbaik
### CloudWatch Konfigurasi Alarm
**Alarm Kritis (Diperlukan Tindakan Segera):**
**CPUUtilization:**
+ Ambang batas: > 90% selama 5 menit
+ Tindakan: Menerapkan langkah-langkah remediasi lalu lintas atau Penskalaan Komputasi
**MemoryUtilization:**
+ Ambang batas: > 90% selama 5 menit
+ Tindakan: Menerapkan langkah-langkah remediasi lalu lintas atau Penskalaan Komputasi
**DiskUtilization:**
+ Ambang batas: > 85%
+ Tindakan: Cobalah untuk mengosongkan ruang dengan menghapus bucket lama, memperbarui konfigurasi retensi atau Storage Scaling
**Jumlah IOpsPerSec:**
+ Ambang batas: > 90% dari yang disediakan selama 10 menit
+ Tindakan: Menerapkan langkah-langkah remediasi lalu lintas atau Meningkatkan IOPS
**SeriesCardinality:**
+ Ambang: > 10.000.000
+ Tindakan: Tinjau model Data Anda, jika tidak ada perubahan yang memungkinkan, jelajahi migrasi ke InfluxDB 3 atau pisahkan data Anda
**EngineUptime:**
+ Ambang batas: Reset tak terduga (< 300 detik)
+ Tindakan: Periksa apakah itu bertepatan dengan jendela pemeliharaan, jika tidak membuat tiket ke dukungan Timestream.
**Alarm Peringatan (Diperlukan Investigasi):**
**CPUUtilization:**
+ Ambang batas: > 70% selama 15 menit
+ Tindakan: meninjau perubahan beban kerja atau lalu lintas
**MemoryUtilization:**
+ Ambang batas: > 70% selama 15 menit
+ Tindakan: meninjau perubahan beban kerja atau lalu lintas
**DiskUtilization:**
+ Ambang batas: > 70%
+ Tindakan: Meninjau kebijakan retensi
**Jumlah IOpsPerSec:**
+ Ambang batas: > 70% dari yang disediakan selama 15 menit
+ Tindakan: meninjau perubahan beban kerja atau lalu lintas
**QueryRequestsTotal (runtime\$1error):**
+ Ambang batas: > 1% dari total kueri
+ Tindakan: meninjau perubahan beban kerja atau lalu lintas
**WriteTimeouts:**
+ Ambang: > 1% dari operasi tulis
+ Tindakan: meninjau perubahan beban kerja atau lalu lintas
**SeriesCardinality:**
+ Ambang: > 5.000.000
+ Tindakan: Tinjau optimasi model data
### Daftar Periksa Pemantauan Proaktif
**Setiap hari:**
+ APIRequestTingkat Tinjauan untuk lonjakan kesalahan (400, 404, 499, 500)
+ Periksa tingkat QueryRequestsTotal runtime\$1error dan queue\$1error
+ Verifikasi WriteTimeouts jumlah minimal
+ Periksa alarm kritis apa pun
+ Verifikasi EngineUptime (tidak ada restart yang tidak terduga)
**Mingguan:**
+ Ulasan CPUUtilization, MemoryUtilization, dan DiskUtilization tren
+ Menganalisis QueryRequestsTotal pola berdasarkan jenis hasil
+ Periksa tingkat SeriesCardinality pertumbuhan per ember
+ Tinjau Tren IOps PerSec pemanfaatan total
+ Verifikasi parameter konfigurasi optimal
+ TaskExecutionFailures Pola ulasan
**Bulanan:**
+ Tinjauan perencanaan kapasitas (proyek 3-6 bulan ke depan)
+ Bandingkan metrik saat ini dengan tabel ukuran
+ Meninjau dan mengoptimalkan kebijakan retensi
+ Menganalisis pola kueri dari APIRequest Rate dan QueryResponseVolume
+ Tinjauan SeriesCardinality dan efisiensi model data
+ Menilai kebutuhan misalnya penskalaan atau perubahan konfigurasi
+ Tinjau TotalBuckets dan peluang konsolidasi
## Panduan Pemecahan Masalah
### Skenario: Degradasi Kinerja Mendadak
**Langkah Investigasi:**
**Periksa Perubahan Terbaru:**
+ Modifikasi parameter konfigurasi di Konsol AWS Manajemen
+ Perubahan penerapan aplikasi
+ Perubahan pola kueri
+ Modifikasi model data
+ Perubahan infrastruktur (tipe instance, penyimpanan)
**Tinjau CloudWatch Metrik:**
+ **Lonjakan CPU?** → Periksa CPUUtilization, QueryRequestsTotal
+ **Tekanan memori?** → Periksa MemoryUtilization, HeapMemoryUsage, ActiveMemoryAllocation
+ **Saturasi IOPS?** → Periksa Total IOpsPerSec, ReadOpsPerSec, WriteOpsPerSec
+ **Seri kardinalitas melompat?** → Periksa SeriesCardinality pertumbuhan
+ **Tingkat kesalahan meningkat?** → Periksa QueryRequestsTotal (runtime\$1error), APIRequest Nilai (Status = 500)
+ **Restart yang tidak terduga?** → Periksa EngineUptime
**Aktifkan Pencatatan Terperinci:**
Perubahan konfigurasi:
+ tingkat log: debug
+ flux-log-enabled: BENAR
Monitor selama 1-2 jam, lalu tinjau log
Kembali ke tingkat log: info setelah penyelidikan
**Langkah Resolusi:**
+ Menerapkan perubahan konfigurasi yang sesuai berdasarkan temuan
+ Skala sumber daya jika batas tercapai
+ Optimalkan kueri atau model data jika diperlukan
+ Menerapkan pembatasan laju jika beban tiba-tiba meningkat
### Skenario: Kelelahan Memori
**Gejala:**
+ MemoryUtilization > 90%
+ HeapMemoryUsage mendekati maksimum
+ QueryRequestsTotal menampilkan runtime\$1error (kehabisan memori)
+ APIRequestNilai yang menunjukkan Status = 500
**Langkah Resolusi:**
Tindakan Segera (jika kritis):
1. Mulai ulang instance untuk menghapus memori (jika aman untuk melakukannya)
1. Mengurangi query-concurrency untuk sementara
1. Hilangkan kueri yang berjalan lama jika memungkinkan
Perubahan Konfigurasi:
**Prioritas 1: Kurangi Memori Cache**
+ storage-cache-max-memory-ukuran: Kurangi hingga 10% dari RAM
+ Contoh: 32GB → 3.355.443.200 byte
+ storage-cache-snapshot-memory-ukuran: 26.214,400 (25MB)
**Prioritas 2: Batasi Memori Kueri**
+ query-memory-bytes: Setel ke 60% dari total RAM
+ query-max-memory-bytes: Pertandingan query-memory-bytes
+ query-initial-memory-bytes: 10% dari query-memory-bytes
**Prioritas 3: Tetapkan Batas Perlindungan**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ query-concurrency: Kurangi hingga 50% dari v CPUs
**Solusi Jangka Panjang:**
+ Optimalkan model data untuk mengurangi **SeriesCardinality**
+ Menerapkan batas ukuran hasil kueri di tingkat aplikasi
+ Tambahkan penegakan batas waktu kueri
+ Tinjau pertanyaan yang paling umum untuk memastikan ini mengikuti praktik terbaik yang disebutkan di bagian [Masalah Kinerja Kueri](#query-performance-issues)
### Skenario: Dampak Kardinalitas Seri Tinggi
**Tinjau CloudWatch metrik:**
+ **SeriesCardinality**> 5M
+ **MemoryUtilization**tinggi
+ **QueryRequestsTotal**menunjukkan peningkatan runtime\$1error
+ **CPUUtilization**meningkat karena overhead perencanaan kueri
**Langkah Investigasi:**
**Menganalisis Pertumbuhan Kardinalitas:**
+ SeriesCardinality tingkat pertumbuhan (harian/mingguan)
+ Proyeksi ke ambang 10M
+ Identifikasi sumber kardinalitas tinggi
+ Tinjau desain dan penggunaan tag
**Menilai Dampak Kinerja:**
+ Bandingkan tingkat **QueryRequestsTotal**keberhasilan peningkatan before/after kardinalitas
+ **MemoryUtilization**Korelasi ulasan
+ Periksa **CPUUtilization**pola
+ Menganalisis **QueryResponseVolume**tren
**Identifikasi Sumber Kardinalitas:**
Tinjau model data:
+ Ember mana yang paling tinggi? SeriesCardinality
+ Tag mana yang memiliki jumlah nilai unik yang tinggi?
+ Apakah ada tag yang tidak perlu?
+ Apakah nilai tag tidak terbatas (UUIDs, stempel waktu, dll.)?
**Tinjau Konfigurasi Saat Ini:**
Periksa parameter pengoptimalan:
+ storage-series-id-set-cache-size: Nilai saat ini?
+ influxql-max-select-series: Apakah itu membatasi kueri pelarian?
+ storage-max-index-log-file-size: Sesuai untuk kardinalitas?
**Langkah Resolusi:**
Perubahan Konfigurasi Segera:
**Prioritas 1: Optimalkan Penanganan Seri**
+ storage-series-id-set-ukuran cache: 1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6-8
+ storage-max-index-log-ukuran file: 2.097.152 (2MB)
**Prioritas 2: Tetapkan Batas Perlindungan**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ query-concurrency: Kurangi jika memori dibatasi
**Prioritas 3: Meningkatkan Sumber Daya**
+ Skala ke tingkat instance berikutnya
+ Meningkatkan alokasi memori
+ Pertimbangkan tingkat penyimpanan 12K IOPS
**Perencanaan Migrasi (jika > seri 10M):**
+ **InfluxDB 3.0 menawarkan kinerja kardinalitas tinggi yang unggul**
+ Rencanakan jadwal migrasi (2-3 bulan)
+ Uji dengan subset data terlebih dahulu
+ Mempersiapkan aplikasi untuk migrasi
+ InfluxDB 3.0 menggunakan penyimpanan kolumnar yang dioptimalkan untuk miliaran seri
### Skenario: Penumpukan Antrian Kueri
**Tinjau CloudWatch metrik:**
+ **QueryRequestsTotal**dengan result=queue\$1error meningkat (kueri ditolak)
+ **APIRequestNilai** dengan Status = 429 atau Status = 503 (layanan banyak permintaan) unavailable/too
+ **CPUUtilization**dapat meningkat (> 70%) yang menunjukkan saturasi sumber daya
+ **MemoryUtilization**mungkin tinggi (> 70%) membatasi kapasitas kueri
+ **QueryResponseVolume**menunjukkan ukuran respons yang besar (kueri mengambil sumber daya yang berlebihan)
**Langkah Investigasi:**
**Analisis Metrik Antrian dan Konkurensi:**
+ Tinjau **QueryRequestsTotal**rincian berdasarkan jenis hasil:
+ Jumlah queue\$1error yang tinggi menunjukkan kueri ditolak
+ Bandingkan tingkat keberhasilan dengan baseline - apakah itu menurun?
+ Periksa peningkatan runtime\$1error (kueri gagal setelah memulai)
+ Pola **APIRequestTingkat** Monitor:
+ Cari Status = 429 (terlalu banyak permintaan) atau Status = 503 (layanan tidak tersedia)
+ Identifikasi titik akhir mana yang mengalami penolakan
+ Periksa tren tingkat permintaan dari waktu ke waktu
**Tinjau Pemanfaatan Sumber Daya:**
+ **CPUUtilization**selama periode antrian tinggi:
+ Jika > 70%, kueri terikat CPU dan tidak dapat dijalankan lebih cepat
+ Jika < 50%, batas antrian mungkin terlalu ketat
+ **MemoryUtilization**korelasi:
+ Memori tinggi mungkin membatasi konkurensi kueri
+ Periksa **HeapMemoryUsage**dan **ActiveMemoryAllocation**untuk tekanan memori
+ IOpsPerSecPola **total**:
+ Tinggi I/O mungkin memperlambat eksekusi kueri
+ Periksa apakah kueri terikat I/O
**Identifikasi Pola Kueri:**
+ Ulasan **QueryResponseVolume**:
+ Apakah kueri mengembalikan data yang berlebihan (> 1MB)?
+ Identifikasi titik akhir dengan volume respons terbesar
+ Cari pola dalam kueri mahal
+ Menganalisis **QueryRequestsTotal**tingkat:
+ Berapa tingkat kueri per detik?
+ Apakah ada pola burst atau beban tinggi yang berkelanjutan?
+ Bandingkan dengan kapasitas instance dari tabel ukuran
+ Periksa **APIRequestTingkat** berdasarkan titik akhir:
+ Titik akhir kueri mana yang memiliki lalu lintas tertinggi?
+ Apakah ada kueri duplikat atau berlebihan?
**Periksa Ketersediaan Sumber Daya:**
+ Bandingkan metrik saat ini dengan rekomendasi tabel ukuran:
+ **SeriesCardinality**vs. kapasitas kelas instance
+ Tingkat kueri vs. kueri yang direkomendasikan per detik
+ **CPUUtilization**dan ruang **MemoryUtilization**kepala
+ Verifikasi kapasitas IOPS:
+ **Total IOps PerSec** harus memiliki 30% headroom
+ Periksa apakah kueri sedang menunggu pada disk I/O
**Langkah Resolusi:**
Perubahan Konfigurasi:
**Prioritas 1: Meningkatkan Kapasitas Antrian**
+ query-queue-size: 4096 (dari default 1024)
**Prioritas 2: Meningkatkan Konkurensi (jika sumber daya memungkinkan)**
+ query-concurrency: Meningkat menjadi 75% dari v CPUs
+ Contoh: 16 vCPU → query-concurrency = 12
+ Verifikasi CPUUtilization tetap < 80% setelah perubahan
+ Verifikasi MemoryUtilization tetap < 80% setelah perubahan
**Prioritas 3: Optimalkan Eksekusi Kueri**
+ query-memory-bytes: Pastikan alokasi yang memadai
+ storage-series-id-set-ukuran cache: 1000-1500
+ http-read-timeout: 120s (mencegah batas waktu prematur)
**Prioritas 4: Tetapkan Batas Perlindungan**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
**Solusi Tingkat Aplikasi:**
+ **Menerapkan caching hasil kueri** (Redis, Memcached)
+ Hasil cache untuk kueri yang sering dieksekusi
+ Tetapkan sesuai TTLs berdasarkan persyaratan kesegaran data
+ Memantau laju hit cache
+ **Gunakan kueri berkelanjutan** untuk melakukan pra-agregasi pola umum
+ Pra-hitung agregasi umum
+ Kueri data pra-agregat alih-alih data mentah
+ **Tambahkan pagination** untuk set hasil besar
+ Batasi ukuran kueri awal
+ Muat data tambahan sesuai permintaan
+ **Menerapkan pembatasan tingkat kueri** per pengguna/dasbor
+ Mencegah pengguna tunggal dari kewalahan sistem
+ Tetapkan kuota penggunaan wajar
+ **Gunakan data downsampled untuk kueri historis**
+ Kueri data resolusi rendah untuk rentang waktu yang lebih lama
+ Cadangan kueri resolusi penuh untuk data terbaru
**Keputusan Penskalaan:**
+ Jika CPUUtilization > 70% berkelanjutan: Skala ke instance yang lebih besar
+ Jika MemoryUtilization > 70% berkelanjutan: Skala ke instance yang dioptimalkan untuk memori
+ Jika tingkat kueri melebihi kapasitas instans: Skala ke tingkat berikutnya per tabel ukuran