Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan Masalah Metrik
## Hasilnya termasuk "Lainnya," tetapi saya tidak memiliki ini sebagai dimensi
Ini berarti bahwa kueri menyertakan klausa **GROUP BY** yang menentukan kunci label yang tidak digunakan dalam beberapa metrik yang dikembalikan oleh kueri. Dalam hal ini, grup kosong yang disebut `Other` dikembalikan. Metrik yang tidak menyertakan kunci label tersebut mungkin merupakan metrik agregat yang mengembalikan nilai yang dikumpulkan di semua nilai kunci label tersebut.
Sebagai contoh, anggap kita memiliki kueri berikut:
```
SELECT AVG(Faults)
FROM MyCustomNamespace
GROUP BY Operation, ServiceName
```
Jika beberapa metrik yang dikembalikan tidak mencakup `ServiceName` sebagai dimensi, maka metrik tersebut ditampilkan memiliki `Other` sebagai nilai untuk `ServiceName`.
Untuk mencegah melihat "Lainnya" dalam hasil Anda, gunakan **SCHEMA** dalam klausa **FROM** Anda, seperti pada contoh berikut:
```
SELECT AVG(Faults)
FROM SCHEMA(MyCustomNamespace, Operation)
GROUP BY Operation, ServiceName
```
Ini membatasi hasil yang dikembalikan hanya pada metrik yang memiliki dimensi `Operation` dan dimensi `ServiceName`.
## Timestamp tertua dalam grafik saya memiliki nilai metrik yang lebih rendah daripada yang lain
CloudWatch Metrics Insights mendukung data historis hingga dua minggu. Ketika Anda membuat grafik dengan periode yang lebih lama dari satu menit, mungkin ada kasus di mana titik data tertua berbeda dengan nilai yang diharapkan. Ini karena kueri Wawasan CloudWatch Metrik hanya menampilkan data dalam periode retensi dua minggu. Dalam hal ini, titik data tertua dalam kueri hanya mengembalikan pengamatan yang telah diukur dalam batas dua minggu, alih-alih mengembalikan semua pengamatan dalam periode titik data tersebut.
## Nilai metrik yang tidak konsisten di periode waktu yang berbeda saat menggunakan kueri berbasis tag
Saat Anda menggunakan `WHERE` atau `GROUP BY` klausa dengan tag dalam kueri Wawasan CloudWatch Metrik, Anda mungkin melihat nilai metrik yang berbeda tergantung pada periode waktu yang dipilih. Misalnya, periode 6 jam mungkin menunjukkan nilai puncak 20, sedangkan periode 1 jam hanya menunjukkan 2 untuk jendela waktu yang sama.
Ini terjadi karena cap waktu tag disimpan dengan resolusi tingkat kedua, sedangkan titik data metrik disejajarkan dengan batas periode (misalnya, awal setiap menit atau jam). Untuk menentukan titik data mana yang cocok dengan rentang waktu tag CloudWatch , sesuaikan awal rentang dengan mengurangi satu periode. Dengan periode yang lebih besar, penyesuaian ini menciptakan kesenjangan yang lebih luas antara stempel waktu tag dan titik data yang disertakan paling awal, yang dapat menyebabkan titik data di dekat awal rentang dikecualikan.
Contoh berikut menunjukkan bagaimana hal ini mempengaruhi hasil query. Metrik memiliki dua nilai tag: `env=beta` (dari 00:00 hingga 01:30) dan `env=gamma` (dari 01:30 hingga 03:00). Setiap tag mencakup 90 menit data dengan SUM 270.
![\[Dua grafik CloudWatch metrik membandingkan hasil kueri berbasis tag dengan periode 1 menit dan 3 jam.\]](http://docs.aws.amazon.com/id_id/AmazonCloudWatch/latest/monitoring/images/metrics-insights-tag-alignment.png)
| **env = beta dengan periode 1 menit** | Statistik | Expected | Kembali | Perbedaan |
| --- | --- | --- | --- | --- |
| JUMLAH | 270 | 271 | \$11 |
| AVG | 3.0 | 3.0 | 0 |
| MIN | 1 | 1 | 0 |
| MAX | 5 | 5 | 0 |
| SAMPLE\$1COUNT | 90 | 91 | \$11 |
| **env = gamma dengan periode 1 menit** | Statistik | Expected | Kembali | Perbedaan |
| --- | --- | --- | --- | --- |
| JUMLAH | 270 | 275 | \$15 |
| AVG | 3.0 | 3.0 | 0 |
| MIN | 1 | 1 | 0 |
| MAX | 5 | 5 | 0 |
| SAMPLE\$1COUNT | 90 | 91 | \$11 |
Dengan periode 1 menit, penyesuaian penyelarasan kecil (1 menit), jadi hanya 1 titik data tambahan yang disertakan per tag. Dengan periode 3 jam, penyesuaian mencakup seluruh rentang kueri:
| **env = beta dengan periode 3 jam** | Statistik | Expected | Kembali | Perbedaan |
| --- | --- | --- | --- | --- |
| JUMLAH | 270 | 540 | \$1270 |
| AVG | 3.0 | 3.0 | 0 |
| MIN | 1 | 1 | 0 |
| MAX | 5 | 5 | 0 |
| SAMPLE\$1COUNT | 90 | 180 | \$190 |
| **env = gamma dengan periode 3 jam** | Statistik | Expected | Dikembalikan | Perbedaan |
| --- | --- | --- | --- | --- |
| JUMLAH | 270 | 540 | \$1270 |
| AVG | 3.0 | 3.0 | 0 |
| MIN | 1 | 1 | 0 |
| MAX | 5 | 5 | 0 |
| SAMPLE\$1COUNT | 90 | 180 | \$190 |
Dengan periode 3 jam, kedua tag mengembalikan seluruh kumpulan data (SUM=540, SAMPLE\$1COUNT=180) karena stempel waktu titik data agregat tunggal berada dalam kedua rentang yang disesuaikan. Batas tag dihapus secara efektif.
Untuk mengurangi dampak perilaku ini, cobalah pendekatan berikut:
+ **Gunakan periode agregasi yang lebih kecil.** Periode yang lebih kecil (seperti 1 menit atau 5 menit) lebih cocok dengan resolusi tingkat kedua dari stempel waktu tag, yang meminimalkan kesenjangan penyelarasan dan membuatnya lebih mungkin bahwa semua titik data yang relevan disertakan.
+ **Gunakan pemfilteran berbasis dimensi alih-alih tag.** Jika kasus penggunaan Anda mengizinkannya, filter berdasarkan dimensi daripada tag. Kueri berbasis dimensi tidak terpengaruh oleh perilaku ini. Misalnya, gunakan `WHERE InstanceId = 'i-1234567890abcdef0'` sebagai ganti dari `WHERE tag."my-tag" = 'my-value'`.
+ **Kueri pada perincian yang konsisten.** Saat membandingkan data metrik di jendela waktu yang berbeda, gunakan periode yang sama untuk menghindari perbedaan tak terduga yang disebabkan oleh penyesuaian penyelarasan.