Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Alarm log
Alarm Log memantau hasil kueri Wawasan CloudWatch Log yang berjalan sesuai jadwal menggunakan [Kueri Terjadwal](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/ScheduledQueries.html). Alarm menerapkan ekspresi agregasi ke hasil kueri untuk menghasilkan nilai numerik, dan ketika nilai agregat tersebut melanggar ambang batas yang dikonfigurasi, alarm bertransisi ke `ALARM` status dan menjalankan tindakan yang dikonfigurasi.
Tidak seperti alarm metrik yang memerlukan filter metrik sebagai langkah perantara, Alarm Log mengevaluasi secara langsung pada data log menggunakan bahasa kueri Wawasan Log yang sama yang Anda gunakan untuk analisis ad-hoc.
## Cara kerja Alarm Log
Langkah-langkah berikut menjelaskan cara kerja Alarm Log:
1. Anda membuat Alarm Log dengan kueri, ekspresi agregasi, jadwal, dan ambang batas.
1. CloudWatch secara otomatis membuat Kueri AWS Terjadwal terkelola yang menjalankan kueri Anda pada jadwal yang ditentukan.
1. Setiap eksekusi query menghasilkan hasil agregat (nilai tunggal atau beberapa nilai kontributor).
1. CloudWatch mengevaluasi hasil agregat terhadap ambang batas Anda menggunakan M-out-of-N evaluasi pada eksekusi kueri terbaru.
1. Jika ambang batas dilanggar, alarm akan bertransisi ke `ALARM` status dan menjalankan tindakan yang dikonfigurasi (seperti notifikasi Amazon SNS).
**catatan**
Log Alarm mengevaluasi eksekusi kueri N terakhir. Alarm bertransisi ke `ALARM` saat M dari eksekusi N tersebut melanggar ambang batas.
Untuk membuat Alarm Log, lihat[Buat Alarm Log](Alarm-On-Logs.md#Create_Log_Alarm).
## Siklus hidup Kueri Terjadwal Terkelola
Saat Anda membuat Alarm Log, CloudWatch secara otomatis membuat Kueri AWS Terjadwal terkelola yang menjalankan kueri Anda pada jadwal yang ditentukan. Anda tidak perlu membuat Query Terjadwal secara terpisah.
Kueri AWS Terjadwal yang dikelola memiliki karakteristik sebagai berikut:
+ Itu terlihat di konsol CloudWatch Log di bawah Kueri Terjadwal.
+ Anda tidak dapat memodifikasinya secara langsung. Untuk mengubah kueri atau konfigurasinya, perbarui Alarm Log.
+ CloudWatch menghapus Kueri AWS Terjadwal yang dikelola saat Anda menghapus alarm.
## Konfigurasi Alarm Log
Alarm Log dikonfigurasi dengan parameter berikut:
+ **QueryString**adalah kueri Wawasan CloudWatch Log yang akan dijalankan.
+ **LogGroupIdentifiers**adalah grup log untuk kueri. Tentukan nama grup log atau ARN grup log.
+ **ScheduledQueryRoleARN**adalah ARN dari peran IAM yang memungkinkan CloudWatch Log menjalankan kueri terjadwal atas nama Anda.
+ **AggregationExpression**mendefinisikan bagaimana hasil kueri dikumpulkan ke dalam nilai numerik untuk evaluasi ambang batas.
+ **ScheduleExpression**mendefinisikan seberapa sering kueri berjalan (misalnya,`rate(5 minutes)`).
+ **StartTimeOffset**mendefinisikan jendela lookback dalam hitungan detik untuk setiap eksekusi kueri.
+ **EndTimeOffset**mendefinisikan akhir rentang waktu kueri sebagai offset dalam hitungan detik dari waktu saat ini.
+ **ComparisonOperator**adalah bagaimana hasil agregat dibandingkan dengan ambang batas. Nilai yang valid:`GreaterThanThreshold`,`GreaterThanOrEqualToThreshold`,`LessThanThreshold`,`LessThanOrEqualToThreshold`.
+ **Ambang batas** adalah nilai numerik untuk dibandingkan.
+ **QueryResultsToEvaluate**adalah jumlah eksekusi kueri terbaru untuk dievaluasi (N in M-out-of-N).
+ **QueryResultsToAlarm**adalah jumlah hasil pelanggaran yang diperlukan untuk memicu `ALARM` (M in M-out-of-N).
+ **TreatMissingData**mendefinisikan bagaimana hasil kueri yang hilang diperlakukan selama evaluasi.
Untuk daftar lengkap parameter dan instruksi pembuatan, lihat[Buat Alarm Log](Alarm-On-Logs.md#Create_Log_Alarm).
## Kueri log
Kueri Log Alarm adalah kueri Wawasan CloudWatch Log yang memilih dan memfilter data log untuk dievaluasi. Kueri berjalan pada grup log yang ditentukan dalam `LogGroupIdentifiers` rentang waktu yang ditentukan oleh `StartTimeOffset` dan`EndTimeOffset`.
Kueri menggunakan [sintaks kueri CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html). Untuk panduan menulis kueri yang efisien untuk Alarm Log, lihat. [Praktik terbaik dan pemecahan masalah](#log-alarm-best-practices)
## Ekspresi agregasi
Ekspresi agregasi mendefinisikan bagaimana CloudWatch merangkum hasil kueri ke dalam nilai numerik untuk evaluasi ambang batas. Ekspresi menggunakan sintaks yang sama dengan `stats` perintah di CloudWatch Logs Insights.
Sintaks untuk ekspresi agregasi adalah sebagai berikut:
```
statistic_func_expression [by field1, field2, ...] [| sort asc|desc]
```
Anda hanya dapat menentukan ekspresi agregasi tunggal. Tabel berikut mencantumkan fungsi agregasi yang didukung.
**Fungsi agregasi yang didukung**
| Fungsi | Deskripsi | Contoh |
| --- | --- | --- |
| count(\*) | Hitung semua baris log yang cocok. | count(\*) |
| avg(field) | Nilai rata-rata bidang yang ditentukan. | avg(duration) |
| sum(field) | Jumlah bidang yang ditentukan. | sum(bytesSent) |
| min(field) | Nilai minimum bidang yang ditentukan. | min(latency) |
| max(field) | Nilai maksimum dari bidang yang ditentukan. | max(latency) |
`bin()`Fungsi ini tidak didukung dalam `by` klausa ekspresi agregasi. Namun, Anda dapat menggunakan `bin()` dalam string kueri itu sendiri.
## Multi-contributor alarm
Saat Anda menyertakan `by` klausa dalam ekspresi agregasi, alarm mengevaluasi setiap kombinasi unik nilai bidang (disebut *kontributor*) secara independen. Alarm bertransisi ke `ALARM` menyatakan jika ada kontributor yang melanggar ambang batas.
Misalnya, kesalahan grup ekspresi berikut dihitung berdasarkan nama layanan:
```
count(*) by serviceName
```
Setiap nilai unik `serviceName` dievaluasi secara independen terhadap ambang batas. Jika ada layanan yang melebihi ambang batas dalam eksekusi kueri M dari N, alarm memasuki `ALARM` status.
Batasan berikut berlaku untuk alarm multi-kontributor:
+ Maksimal 5 bidang dalam `by` klausa.
+ Maksimum 500 hasil kontributor yang dikembalikan per eksekusi kueri.
+ Maksimum 100 kontributor dilacak dalam `ALARM` status secara bersamaan.
Secara default, kontributor diurutkan menurut abjad dan hanya 500 pertama yang dikembalikan per eksekusi kueri. Untuk mengurutkan kontributor berdasarkan nilai agregatnya, tentukan `| sort asc` atau `| sort desc` dalam ekspresi agregasi Anda (misalnya,). `avg(latency) by serviceName | sort desc` Value-based penyortiran memastikan bahwa kontributor yang paling signifikan dievaluasi terlebih dahulu ketika jumlah total melebihi 500.
Untuk alarm multi-kontributor, tindakan Amazon SNS dan Lambda berjalan di tingkat kontributor (sekali per kontributor pelanggaran). OpsItem Tindakan Systems Manager berjalan pada tingkat alarm.
**catatan**
Manajer Insiden Systems Manager dan tindakan investigasi tidak didukung untuk Alarm Log.
Jika kontributor menghilang dari hasil kueri (misalnya, sumber daya sementara dihentikan), kontributor itu bertransisi ke `OK` status terlepas dari pengaturan perlakuan data yang hilang.
## Perlakuan data yang hilang
Data yang hilang terjadi ketika eksekusi kueri terjadwal tidak menghasilkan nilai yang dapat dievaluasi terhadap ambang batas. Ini terjadi dalam kasus-kasus berikut:
**Tidak ada log yang ada** - Grup log tidak berisi peristiwa log dalam rentang waktu kueri.
**Kueri tidak mengembalikan hasil yang berlaku** — Log hadir tetapi ekspresi agregasi tidak dapat menghasilkan nilai. Ini terjadi ketika:
+ Hasil kueri yang cocok tidak ada sesuai filter kueri.
+ Bidang yang direferensikan dalam ekspresi agregasi tidak ada dalam hasil kueri. Misalnya, `count(error-codes)` di mana `error-codes` tidak ada dalam peristiwa log yang dikembalikan.
Perhatikan bahwa `count(*)` pada set hasil kosong mengembalikan 0, yang merupakan titik data yang valid dan tidak diperlakukan sebagai hilang.
Anda dapat mengonfigurasi bagaimana alarm memperlakukan data yang hilang menggunakan `TreatMissingData` parameter. Tabel berikut menjelaskan opsi yang tersedia.
**Opsi perawatan data yang hilang**
| Nilai | Perilaku |
| --- | --- |
| missing | Perlakukan titik data sebagai hilang. Ini adalah opsi default. |
| notBreaching | Perlakukan titik data yang hilang sebagai tidak melanggar ambang batas. |
| breaching | Perlakukan titik data yang hilang sebagai melanggar ambang batas. |
| ignore | Abaikan titik data yang hilang dan evaluasi hanya data yang tersedia. |
## Status evaluasi
Selain standar`OK`,, dan `INSUFFICIENT_DATA` status`ALARM`, Alarm Log dapat melaporkan status evaluasi berikut di `EvaluationState` lapangan. Negara-negara ini memberikan konteks tambahan tentang mengapa alarm dalam keadaan saat ini.
**Status evaluasi Alarm Log**
| Status | Deskripsi |
| --- | --- |
| EVALUATION\_FAILURE | Masalah CloudWatch layanan sementara mencegah evaluasi. Hal ini dapat terjadi ketika layanan mengalami masalah dalam mengevaluasi hasil kueri karena kesalahan layanan, atau ketika beberapa (tetapi tidak semua) hasil kueri gagal. Alarm bertransisi keINSUFFICIENT\_DATA. Kami merekomendasikan pemantauan manual sampai masalah teratasi. |
| EVALUATION\_ERROR | Kesalahan konfigurasi klien mencegah evaluasi. Hal ini dapat terjadi karena izin yang tidak memadai, kueri yang tidak valid, atau ketika semua hasil kueri gagal. Alarm bertransisi ke INSUFFICIENT\_DATA segera. Lihat StateReason bidang untuk detailnya. |
| PARTIAL\_DATA | Kueri mengembalikan maksimum 500 grup kontributor tetapi lebih cocok. Alarm mengevaluasi kontributor yang tersedia, tetapi hasilnya mungkin tidak lengkap. |
## Pembaruan alarm
Saat Anda memperbarui kueri, ekspresi agregasi, jadwal, atau grup log Alarm Log, alarm akan bertransisi `INSUFFICIENT_DATA` hingga titik data baru yang cukup dikumpulkan. Perubahan pada ambang batas atau M-out-of-N nilai tidak memicu reset ini.
## Tindakan dan pemberitahuan
Log Alarm mendukung tindakan berikut:
+ Notifikasi Amazon SNS
+ Pemanggilan fungsi Lambda
+ OpsItem Pembuatan Systems Manager
Untuk matriks dukungan tindakan lengkap, lihat[Tindakan-tindakan alarm](alarm-actions.md).
Saat status transisi Alarm Log, pemberitahuan tindakan menyertakan informasi berikut:
+ Informasi perubahan konfigurasi alarm standar (nama alarm, deskripsi, detail konfigurasi).
+ Informasi perubahan negara (status baru, alasan negara, stempel waktu).
+ Pemberitahuan email Amazon SNS juga menyertakan tautan dalam ke konsol Wawasan CloudWatch Log yang menunjukkan hasil kueri lengkap.
Contoh berikut menunjukkan notifikasi email Amazon SNS untuk Alarm Log bernilai tunggal (tanpa klausa): `BY`
```
{
"AlarmName": "HighErrorCount",
"NewStateValue": "ALARM",
"NewStateReason": "Threshold Crossed: 3 out of the last 5 query results [142.0 (10/06/26 12:15:00), 135.0 (10/06/26 12:10:00), 120.0 (10/06/26 12:05:00)] were greater than the threshold (100.0) (minimum 3 datapoints for OK -> ALARM transition).",
"NewStateReasonData": {
"version": "1.0",
"queryDate": "2026-06-10T12:15:30.000+0000",
"threshold": 100.0,
"queryResultsToEvaluate": 5,
"queryResultsToAlarm": 3,
"results": [
{
"queryResultId": "scheduled-query-execution-id-3",
"status": "COMPLETE",
"timestamp": "2026-06-10T12:15:00.000+0000",
"value": 142.0
}
// Additional results...
]
},
"StateChangeTime": "2026-06-10T12:15:30.000+0000",
"OldStateValue": "OK"
// Additional fields...
}
```
Contoh berikut menunjukkan pemberitahuan email Amazon SNS untuk Alarm Log multi-kontributor (dengan klausa). `BY` Setiap kontributor pelanggaran menghasilkan pemberitahuan terpisah:
```
{
"AlarmName": "EndpointLatency",
"NewStateValue": "ALARM",
"NewStateReason": "5 out of 10 contributors evaluated to ALARM",
"StateChangeTime": "2026-06-10T12:20:15.000+0000",
"OldStateValue": "OK",
"AlarmContributorId": "a1b2c3d4e5f6g7h8",
"AlarmContributorAttributes": {
"endpoint": "/api/orders"
}
// Additional fields...
}
```
### Termasuk baris log dalam notifikasi
Anda dapat secara opsional menyertakan baris log hasil kueri mentah dalam pemberitahuan alarm dengan menyetel `ActionLogLineCount` parameter ke nilai antara 1 dan 50. Ini adalah peristiwa log yang mendasari di mana ekspresi agregasi dievaluasi, bukan nilai agregat. Nilai defaultnya adalah 0, yang berarti tidak ada baris log yang disertakan.
**catatan**
Garis log hanya disertakan dalam pemberitahuan email Amazon SNS. Tindakan Lambda tidak menyertakan baris log dalam muatannya.
**penting**
Menyertakan baris log dalam notifikasi dapat mengekspos data sensitif dari log Anda di pesan Amazon SNS. Tinjau konten log Anda sebelum mengaktifkan fitur ini.
Untuk menyertakan baris log, peran baris log harus memiliki `logs:GetQueryResults` izin. Jumlah baris log yang disertakan dalam notifikasi dibatasi oleh jumlah yang diminta, total hasil yang tersedia, dan batas ukuran muatan Amazon SNS.
## Praktik terbaik dan pemecahan masalah
### Praktik terbaik
**Pengoptimalan kueri**
+ Uji kueri secara manual di Wawasan CloudWatch Log sebelum menggunakannya di Alarm Log untuk memverifikasi kinerja dan hasil yang diharapkan.
+ Gunakan perintah filter di awal kueri Anda untuk mengurangi volume data yang diproses.
+ Batasi rentang waktu kueri (StartTimeOffset) untuk menghindari batas waktu dengan grup log volume tinggi.
+ Gunakan indeks bidang untuk mengoptimalkan kinerja kueri.
**Jadwal perencanaan**
+ Pilih frekuensi jadwal yang memungkinkan kueri diselesaikan sebelum eksekusi berikutnya. Untuk grup log volume tinggi, gunakan interval yang lebih lama (misalnya, 10 menit, bukan 5).
+ Akun untuk penundaan konsumsi log saat pengaturan. StartTimeOffset Kesenjangan kecil antara EndTimeOffset dan waktu saat ini membantu menghindari evaluasi data yang tidak lengkap.
+ Sebarkan jadwal Alarm Log di seluruh akun Anda untuk menghindari mencapai batas konkurensi Kueri Terjadwal. Eksekusi kueri bersamaan di seluruh akun Anda tidak boleh melebihi 100. Faktor dalam kuota ini saat membuat beberapa Alarm Log dengan jadwal yang tumpang tindih.
**Penyetelan ambang batas**
+ Mulailah dengan nilai QueryResultsToEvaluate (N) yang lebih tinggi untuk mengurangi kebisingan alarm dari lonjakan sementara.
+ Untuk kejadian jarang (seperti kesalahan yang jarang terjadi), atur TreatMissingData `notBreaching` agar alarm tetap dalam keadaan OK saat tidak ada log yang cocok.
+ Untuk sinyal kontinu (seperti log lalu lintas), pertimbangkan pengaturan TreatMissingData `breaching` untuk mendeteksi kapan data log yang diharapkan berhenti tiba.
**Multi-contributor desain**
+ Pilih bidang yang bermakna untuk klausa BY yang mewakili sumber daya atau dimensi berbeda yang ingin Anda pantau secara independen.
+ Ketahuilah bahwa hanya 500 kontributor pertama yang dikembalikan per eksekusi kueri. Jika Anda mengharapkan lebih, persempit kueri Anda atau gunakan lebih sedikit bidang klausa BY.
+ Gunakan `| sort asc` akhiran `| sort desc` atau dalam ekspresi agregasi Anda untuk memprioritaskan nilai tertinggi atau terendah berdasarkan operator perbandingan Anda saat batas kontributor 500 tercapai.
### Pemecahan masalah
**Alarm tetap di INSUFFICIENT\_DATA**
| Kemungkinan penyebab | Resolusi |
| --- | --- |
| Peran eksekusi kueri terjadwal tidak memiliki izin | Verifikasi peran yang telah dicakup logs:StartQuery logs:StopQuerylogs:GetQueryResults,,, dan logs:DescribeLogGroups izin ke grup log yang benar. |
| Grup log tidak ada atau dihapus | Verifikasi ARN grup log dalam konfigurasi alarm sudah benar dan dapat diakses. |
| Alarm yang baru dibuat atau diperbarui | Setelah pembuatan atau pembaruan konfigurasi, alarm tetap berada di INSUFFICIENT\_DATA hingga eksekusi kueri yang cukup lengkap untuk memenuhi jendela evaluasi. M-out-of-N |
| Kueri terjadwal tidak berjalan | Periksa Kueri AWS Terjadwal yang dikelola di konsol CloudWatch Log untuk memverifikasi bahwa kueri tersebut dijalankan sesuai jadwal. |
| Bidang agregasi tidak ada dalam hasil kueri | Bidang yang direferensikan dalam ekspresi agregasi harus ada dalam hasil kueri. Misalnya, jika agregasi Andaavg(latency), pastikan kueri menghasilkan latency bidang. Jika bidang tidak ada, hasilnya diperlakukan sebagai data yang hilang. |
| Penundaan konsumsi log | Kueri terjadwal hanya dapat mengevaluasi peristiwa log yang telah dicerna pada saat dijalankan. `StartTimeOffset`dan `EndTimeOffset` menentukan jendela query relatif terhadap waktu eksekusi T — [T − StartTimeOffset, T − EndTimeOffset] — tetapi mereka tidak memperhitungkan keterlambatan konsumsi. Jika peristiwa masih dicerna untuk jendela yang Anda kueri, kueri berjalan sebelum tersedia dan melewatinya.
Gunakan `EndTimeOffset` untuk menggeser jendela ke belakang cukup jauh sehingga konsumsi selesai untuk seluruh rentang.
Contoh: Misalkan log membutuhkan waktu hingga 2 menit untuk menjadi dapat dikueri setelah peristiwa terjadi.[See the AWS documentation website for more details](http://docs.aws.amazon.com/id_id/AmazonCloudWatch/latest/monitoring/alarm-log.html) |
**Alarm menunjukkan EVALUATION\_ERROR**
Ini menunjukkan masalah konfigurasi klien. Periksa StateReason bidang untuk detailnya. Penyebab umum:
+ Sintaks kueri tidak valid atau cacat.
+ Izin tidak memadai pada peran eksekusi kueri terjadwal.
+ Semua eksekusi kueri gagal (misalnya, izin grup log dicabut).
**Alarm menunjukkan EVALUATION\_FAILURE**
Ini menunjukkan masalah CloudWatch layanan sementara. Alarm secara otomatis pulih ketika masalah teratasi. Jika bertahan lebih dari beberapa menit, periksa dasbor kesehatan CloudWatch layanan.
**Alarm menunjukkan PARTIAL\_DATA**
Kueri mengembalikan maksimum 500 grup kontributor tetapi lebih cocok. Alarm mengevaluasi kontributor yang tersedia, tetapi hasilnya mungkin tidak lengkap. Pertimbangkan untuk mempersempit kueri Anda atau mengurangi jumlah bidang klausa BY.
**Garis log tidak muncul di notifikasi**
+ Verifikasi `ActionLogLineCount` diatur ke nilai antara 1 dan 50.
+ Verifikasi bahwa peran baris log memiliki `logs:GetQueryResults` izin yang dicakup ke grup log yang benar.
+ Garis log hanya disertakan dalam pemberitahuan email Amazon SNS. Jenis tindakan lain tidak termasuk baris log.
+ Kueri yang menggunakan `unmask()` tidak dapat menyertakan baris log dalam pemberitahuan (ditolak pada waktu pembuatan).
Untuk praktik terbaik tambahan tentang pengoptimalan, pemantauan, dan otorisasi kueri, lihat [Praktik terbaik Kueri Terjadwal](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/scheduled-queries-best-practices.html) di *Panduan Pengguna CloudWatch Log Amazon*.