View a markdown version of this page

Alarm log - Amazon CloudWatch
Cara kerja Log AlarmSiklus hidup Kueri Terjadwal TerkelolaKonfigurasi Log AlarmKueri logEkspresi agregasiMulti-contributor alarmPerlakuan data yang hilangStatus evaluasiPembaruan alarmTindakan dan pemberitahuanPraktik terbaik dan pemecahan masalah

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Alarm log

Alarm Log memonitor hasil kueri CloudWatch Logs Insights yang berjalan sesuai jadwal menggunakan Kueri Terjadwal. Alarm menerapkan ekspresi agregasi ke hasil kueri untuk menghasilkan nilai numerik, dan ketika nilai agregat tersebut melanggar ambang batas yang dikonfigurasi, alarm beralih ke ALARM status dan menjalankan tindakan yang dikonfigurasi.

Tidak seperti alarm metrik yang memerlukan filter metrik sebagai langkah perantara, Alarm Log mengevaluasi langsung pada data log menggunakan bahasa kueri Logs Insights yang sama yang Anda gunakan untuk analisis ad-hoc.

Cara kerja Log Alarm

Langkah-langkah berikut menjelaskan cara kerja Log Alarm:

  1. Anda membuat Alarm Log dengan kueri, ekspresi agregasi, jadwal, dan ambang batas.

  2. CloudWatch secara otomatis membuat Ku AWS eri Terjadwal terkelola yang menjalankan kueri Anda pada jadwal yang ditentukan.

  3. Setiap eksekusi kueri menghasilkan hasil agregat (nilai tunggal atau beberapa nilai kontributor).

  4. CloudWatch mengevaluasi hasil agregat terhadap ambang batas Anda menggunakan M-out-of-N evaluasi pada eksekusi kueri terbaru.

  5. Jika ambang batas dilanggar, alarm beralih ke ALARM status dan menjalankan tindakan yang Anda konfigurasi (seperti pemberitahuan Amazon SNS).

catatan

Log Alarm mengevaluasi eksekusi kueri N terakhir. Alarm bertransisi ke ALARM saat M dari N eksekusi tersebut menembus ambang batas.

Untuk membuat Alarm Log, lihatBuat Alarm Log.

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:

  • Hal ini 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 Terjadwal yang AWS dikelola saat Anda menghapus alarm.

Konfigurasi Log Alarm

Alarm Log dikonfigurasi dengan parameter berikut:

  • QueryStringadalah kueri CloudWatch Logs Insights untuk dijalankan.

  • LogGroupIdentifiersadalah grup log untuk dikueri. Tentukan nama grup log atau ARN grup log.

  • ScheduledQueryRoleARNadalah ARN dari peran IAM yang memungkinkan CloudWatch Log menjalankan kueri terjadwal atas nama Anda.

  • AggregationExpressionmendefinisikan bagaimana hasil kueri digabungkan menjadi nilai numerik untuk evaluasi ambang batas.

  • ScheduleExpressionmenentukan seberapa sering kueri berjalan (misalnya,rate(5 minutes)).

  • StartTimeOffsetmendefinisikan jendela lookback dalam hitungan detik untuk setiap eksekusi kueri.

  • EndTimeOffsetmendefinisikan akhir rentang waktu kueri sebagai offset dalam detik dari waktu saat ini.

  • ComparisonOperatoradalah bagaimana hasil agregat dibandingkan dengan ambang batas. Nilai yang valid:GreaterThanThreshold,GreaterThanOrEqualToThreshold,LessThanThreshold,LessThanOrEqualToThreshold.

  • Ambang batas adalah nilai numerik untuk dibandingkan.

  • QueryResultsToEvaluateadalah jumlah eksekusi kueri terbaru untuk dievaluasi (N in M-out-of-N).

  • QueryResultsToAlarmadalah jumlah hasil pelanggaran yang diperlukan untuk memicu ALARM (M in M-out-of-N).

  • TreatMissingDatamendefinisikan bagaimana hasil kueri yang hilang diperlakukan selama evaluasi.

Untuk daftar lengkap parameter dan instruksi pembuatan, lihatBuat Alarm Log.

Kueri log

Kueri Log Alarm adalah kueri CloudWatch Logs Insights yang memilih dan memfilter data log untuk dievaluasi. Kueri berjalan pada grup log yang ditentukan LogGroupIdentifiers selama rentang waktu yang ditentukan oleh StartTimeOffset danEndTimeOffset.

Kueri menggunakan CloudWatch sintaks kueri Logs Insights. Untuk pedoman penulisan kueri yang efisien untuk Alarm Log, lihatPraktik terbaik dan pemecahan masalah.

Ekspresi agregasi

Ekspresi agregasi mendefinisikan bagaimana CloudWatch merangkum hasil kueri menjadi 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 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 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

Ketika Anda menyertakan by klausa dalam ekspresi agregasi Anda, alarm mengevaluasi setiap kombinasi unik dari nilai bidang (disebut kontributor) secara independen. Alarm beralih ke ALARM menyatakan jika ada kontributor yang melanggar ambang batas.

Misalnya, ekspresi berikut ini menghitung kesalahan berdasarkan nama layanan:

count(*) by serviceName

Setiap nilai unik dievaluasi serviceName secara independen terhadap ambang batas. Jika ada layanan yang melebihi ambang batas di M dari N eksekusi kueri, alarm memasuki ALARM status.

Batas berikut berlaku untuk alarm multi-kontributor:

  • Maksimal 5 bidang dalam by klausa.

  • Maksimum 500 hasil kontributor dikembalikan per eksekusi kueri.

  • Maksimal 100 kontributor dilacak dalam ALARM negara secara bersamaan.

Secara default, kontributor diurutkan berdasarkan abjad dan hanya 500 pertama yang dikembalikan per eksekusi kueri. Untuk mengurutkan kontributor berdasarkan nilai agregatnya, tent | sort asc ukan atau | sort desc dalam ekspresi agregasi Anda (misalnya,avg(latency) by serviceName | sort desc). Value-based penyortiran memastikan bahwa kontributor 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 yang melanggar). Tindakan OpsItem Manajer Sistem berjalan pada tingkat alarm.

catatan

Manajer Insiden Sistem dan tindakan investigasi tidak didukung untuk Alarm Log.

Jika kontributor menghilang dari hasil kueri (misalnya, sumber daya sementara dihentikan), kontributor tersebut beralih 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.

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 standarOK,, dan ALARM statusINSUFFICIENT_DATA, Log Alarm dapat melaporkan status evaluasi berikut di EvaluationState lapangan. Status ini memberikan konteks tambahan tentang mengapa alarm berada dalam keadaan saat ini.

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 beralih keINSUFFICIENT_DATA. Kami merekomendasikan pemantauan manual sampai masalah teratasi.
EVALUATION_ERROR Kesalahan konfigurasi klien mencegah evaluasi. Hal ini dapat terjadi karena izin yang tidak mencukupi, kueri yang tidak valid, atau ketika semua hasil kueri gagal. Alarm beralih 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 dari Alarm Log, alarm bertransisi INSUFFICIENT_DATA hingga titik data baru yang cukup dikumpulkan. Perubahan 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

  • Pem OpsItem buatan Manajer Sistem

Untuk matriks dukungan tindakan lengkap, lihatTindakan-tindakan alarm.

Ketika status Log Alarm bertransisi, pemberitahuan tindakan menyertakan informasi berikut:

  • Informasi perubahan konfigurasi alarm standar (nama alarm, deskripsi, detail konfigurasi).

  • Informasi perubahan status (status baru, alasan negara, stempel waktu).

  • Pemberitahuan email Amazon SNS juga menyertakan tautan mendalam ke konsol Log CloudWatch s Insights yang menunjukkan hasil kueri lengkap.

Contoh berikut menunjukkan pemberitahuan email Amazon SNS untuk Alarm Log nilai tunggal (tanpa BY klausa):

{
    "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 BY klausa). Setiap kontributor yang melanggar 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 meny ActionLogLineCount etel 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

Baris log hanya disertakan dalam notifikasi email Amazon SNS. Tindakan lambda tidak menyertakan baris log dalam payloadnya.

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, hasil total yang tersedia, dan batas ukuran muatan Amazon SNS.

Praktik terbaik dan pemecahan masalah

Praktik terbaik

Pengoptimalan kueri

  • Uji kueri secara manual di CloudWatch Logs Insights sebelum menggunakannya dalam 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.

Perencanaan jadwal

  • Pilih frekuensi jadwal yang memungkinkan kueri selesai sebelum eksekusi berikutnya. Untuk grup log volume tinggi, gunakan interval yang lebih lama (misalnya, 10 menit, bukan 5).

  • Perhitungkan keterlambatan penyerapan log saat pengaturan StartTimeOffset. Kesenjangan kecil antara EndTimeOffset dan waktu saat ini membantu menghindari evaluasi data yang tidak lengkap.

  • Sebarkan jadwal Log Alarm di seluruh akun Anda untuk menghindari mencapai batas konkurensi Kueri Terjadwal. Eksekusi kueri bersamaan di seluruh akun Anda tidak boleh melebihi 100. Pertimbangkan 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 ketika tidak ada log yang cocok.

  • Untuk sinyal berkelanjutan (seperti log lalu lintas), pertimbangkan pengaturan TreatMissingData breaching untuk mendeteksi kapan data log yang diharapkan berhenti tiba.

Multi-contributor desain

  • Pilih bidang yang berarti 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 banyak, persempit kueri Anda atau gunakan lebih sedikit bidang klausa BY.

  • Gunakan akh | sort desc iran atau | sort asc dalam ekspresi agregasi Anda untuk memprioritaskan nilai tertinggi atau terendah berdasarkan operator perbandingan Anda ketika batas kontributor 500 tercapai.

Pemecahan masalah

Alarm tetap di INSUFFICIENT_DATA

Kemungkinan penyebab Resolusi
Peran eksekusi kueri terjadwal tidak memiliki izin Verifikasi peran memilikilogs:StartQuery,, logs:StopQuerylogs:GetQueryResults, dan logs:DescribeLogGroups izin yang dicakup ke grup log yang benar.
Grup log tidak ada atau telah 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 di INSUFFICIENT_DATA sampai eksekusi kueri yang cukup selesai untuk memenuhi jendela evaluasi. M-out-of-N
Kueri terjadwal tidak berjalan Periksa Kueri Terjadwal yang AWS 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 Anda adalahavg(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. StartTimeOffsetdan EndTimeOffset tentukan jendela kueri relatif terhadap waktu eksekusi T — [T − StartTimeOffset, T − EndTimeOffset] — tetapi mereka tidak memperhitungkan penundaan konsumsi. Jika peristiwa masih dicerna untuk jendela yang Anda kueri, kueri akan berjalan sebelum tersedia dan melewatkannya.

Gunakan EndTimeOffset untuk menggeser jendela ke belakang cukup jauh sehingga konsumsi selesai untuk seluruh rentang.

Contoh: Misalkan log membutuhkan waktu hingga 2 menit untuk dapat dikueri setelah peristiwa terjadi.

  • StartTimeOffset=60, EndTimeOffset=0— jendela [T−60s, T]. Jendela berakhir pada waktu eksekusi, sehingga peristiwa terbaru belum tertelan dan terlewatkan.

  • StartTimeOffset=180, EndTimeOffset=120— jendela [T−180s, T−120s]. Jendela berakhir 2 menit di masa lalu, di mana semua peristiwa dicerna dan dapat dievaluasi.

Alarm menunjukkan EVALUATION_ERROR

Ini menunjukkan masalah konfigurasi klien. Periksa StateReason bidang untuk detailnya. Penyebab umum:

  • Sintaks kueri tidak valid atau cacat.

  • Izin tidak mencukupi 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 terus berlanjut 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.

Baris log tidak muncul di notifikasi

  • Veri ActionLogLineCount fikasi diatur ke nilai antara 1 dan 50.

  • Pastikan peran baris log memiliki logs:GetQueryResults izin yang dicakup ke grup log yang benar.

  • Baris log hanya disertakan dalam notifikasi email Amazon SNS. Jenis tindakan lain tidak menyertakan baris log.

  • Kueri yang menggunakan unmask() tidak dapat menyertakan baris log dalam notifikasi (ditolak pada waktu pembuatan).

Untuk praktik terbaik tambahan tentang pengoptimalan kueri, pemantauan, dan otorisasi, lihat Praktik terbaik Kueri Ter jadwal di Panduan Pengguna Amazon CloudWatch Log.