Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Mengotomatiskan analisis log dengan kueri terjadwal Kueri terjadwal memungkinkan Anda mengotomatiskan eksekusi kueri Wawasan CloudWatch Log pada jadwal reguler. Alih-alih menjalankan kueri secara manual untuk menganalisis data log Anda, Anda dapat mengonfigurasi kueri terjadwal agar berjalan secara otomatis dan memberikan hasil ke tujuan seperti bucket Amazon S3 atau bus acara Amazon. EventBridge Otomatisasi ini sangat ideal untuk menghasilkan laporan rutin, memantau tren, atau memicu proses hilir berdasarkan hasil analisis log. Kueri terjadwal mendukung ketiga bahasa kueri yang tersedia di Wawasan CloudWatch Log: + [**Bahasa kueri Wawasan Log (Wawasan Log QL)**](CWL_AnalyzeLogData_LogsInsights.md) + [**OpenSearch Service Piped Processing Language (PPL)**](CWL_AnalyzeLogData_PPL.md) + [**OpenSearch Layanan Structured Query Language (SQL)**](CWL_AnalyzeLogData_SQL.md) **Topics** + [Memahami konsep kueri terjadwal](scheduled-queries-concepts.md) + [Referensi ekspresi jadwal](scheduled-queries-schedule-reference.md) + [Praktik terbaik](scheduled-queries-best-practices.md) + [Memulai dengan kueri terjadwal](scheduled-queries-getting-started.md) + [Mengkonfigurasi tujuan S3 untuk kueri terjadwal](scheduled-queries-s3-destination.md) + [Memecahkan masalah kueri terjadwal](scheduled-queries-troubleshooting.md) # Memahami konsep kueri terjadwal Sebelum membuat kueri terjadwal, pahami konsep-konsep kunci ini yang memengaruhi cara kueri Anda berjalan dan di mana hasil dikirimkan. ## Pemisahan peran IAM Kueri terjadwal memerlukan dua peran IAM terpisah: satu untuk mengeksekusi kueri dan satu lagi untuk memberikan hasil ke bus acara Amazon S3 atau Amazon. EventBridge Memahami mengapa pemisahan ini ada membantu Anda mengonfigurasi izin dengan benar dan menggunakan manfaat keamanan dan operasional yang diberikannya. Arsitektur dua peran membagi tanggung jawab antara akses data dan pengiriman data. Peran eksekusi kueri mengakses data log Anda dan menjalankan kueri, sementara peran pengiriman tujuan menulis hasil ke tujuan yang Anda pilih. Pemisahan ini mengikuti prinsip hak istimewa terkecil—setiap peran hanya memiliki izin yang dibutuhkan untuk fungsi spesifiknya. **Peran eksekusi kueri** Memungkinkan CloudWatch CloudWatch Log menjalankan kueri Wawasan Log atas nama Anda. Peran ini memerlukan izin untuk mengakses grup log Anda dan menjalankan kueri, tetapi tidak memerlukan akses ke sumber daya tujuan. Izin yang diperlukan: + `logs:StartQuery` + `logs:StopQuery` + `logs:GetQueryResults` + `logs:DescribeLogGroups` + `logs:Unmask`jika data buka kedok diperlukan **Untuk grup log terenkripsi KMS: `kms:Decrypt` dan `kms:DescribeKey` izin untuk kunci KMS yang digunakan untuk mengenkripsi grup log**. Izin ini perlu ditambahkan juga. **Persyaratan hubungan kepercayaan:** Peran eksekusi kueri harus menyertakan kebijakan kepercayaan yang memungkinkan layanan CloudWatch Log (`logs.amazonaws.com`) untuk mengambil peran tersebut. Tanpa hubungan kepercayaan ini, kueri terjadwal akan gagal dengan kesalahan izin. Contoh kebijakan kepercayaan untuk peran eksekusi kueri: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "logs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Contoh kebijakan izin untuk peran eksekusi kueri: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:StartQuery", "logs:StopQuery", "logs:GetQueryResults", "logs:DescribeLogGroups" ], "Resource": "*" } ] } ``` **Peran pengiriman tujuan** Memungkinkan CloudWatch Log untuk mengirimkan hasil kueri ke tujuan yang Anda pilih. Peran ini hanya memerlukan izin untuk layanan tujuan tertentu, mengikuti prinsip hak istimewa paling sedikit. Izin yang diperlukan bervariasi menurut jenis tujuan. **Persyaratan hubungan kepercayaan:** Peran pengiriman tujuan juga harus menyertakan kebijakan kepercayaan yang memungkinkan layanan CloudWatch Log (`logs.amazonaws.com`) untuk mengambil peran tersebut. Contoh kebijakan izin untuk peran pengiriman tujuan S3: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::your-scheduled-query-results-bucket/*" } ] } ``` Pemisahan ini memberikan manfaat praktis untuk operasi Anda. Dari perspektif keamanan, jika Anda perlu mengubah tempat hasil dikirimkan, Anda hanya mengubah peran pengiriman tujuan tanpa mengubah izin eksekusi kueri. Untuk kepatuhan dan audit, Anda dapat dengan jelas melacak peran mana yang mengakses data log sensitif dan peran mana yang ditulis ke sistem eksternal. Ini memudahkan untuk menunjukkan bahwa infrastruktur analisis log Anda mengikuti praktik terbaik keamanan. ## Penggunaan lintas wilayah dan lintas akun Kueri terjadwal dibuat di wilayah tertentu dan berjalan di wilayah tersebut. Namun, Anda dapat menanyakan grup log dan memberikan hasil di seluruh wilayah dan akun. Anda perlu menyiapkan satu atau beberapa AWS akun sebagai *akun pemantauan* dan menautkannya dengan beberapa *akun sumber*. Akun pemantauan adalah AWS akun pusat yang dapat melihat dan berinteraksi dengan data observabilitas yang dihasilkan dari akun sumber. Akun sumber adalah AWS akun individu yang menghasilkan data observabilitas untuk sumber daya yang berada di dalamnya. Akun sumber membagikan data observabilitas mereka dengan akun pemantauan. Jadi, Anda dapat mengatur kueri terjadwal dari akun pemantauan menggunakan grup log dari semua akun yang ditautkan. **Menanyakan grup log lintas wilayah** Kueri terjadwal Anda dapat mengakses grup log di wilayah mana pun. Tentukan grup log menggunakan format ARN lengkapnya:. `arn:aws:logs:region:account-id:log-group:log-group-name` Kebutuhan peran eksekusi kueri `logs:StartQuery` dan `logs:GetQueryResults` izin untuk grup log di semua wilayah target. **penting** Saat menanyakan grup log atau memberikan hasil di seluruh wilayah, data log melintasi batas regional. Pertimbangkan hal berikut: **Persyaratan residensi data** - Pastikan transfer data lintas wilayah sesuai dengan kebijakan tata kelola data organisasi Anda dan persyaratan peraturan **Biaya transfer data** - Transfer data lintas wilayah menimbulkan biaya tambahan **Latensi jaringan** - Kueri yang mengakses grup log di wilayah yang jauh mungkin mengalami latensi yang lebih tinggi Untuk kinerja optimal dan efisiensi biaya, buat kueri terjadwal di wilayah yang sama dengan grup log utama Anda. **Pendekatan alternatif:** Gunakan [sentralisasi CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs_Centralization.html) untuk mereplikasi data log dari beberapa akun dan wilayah menjadi akun pemantauan pusat. Ini memungkinkan Anda membuat kueri terjadwal di satu wilayah yang mengakses semua log terpusat Anda, menghindari kueri lintas wilayah, dan menyederhanakan pengelolaan izin IAM. ## Menjadwalkan ekspresi dan penanganan zona waktu Jadwal yang Anda tentukan menentukan kapan kueri Anda berjalan dan seberapa sering dijalankan. Memilih ekspresi jadwal yang tepat memengaruhi saat Anda menerima hasil dan berapa banyak data yang Anda kueri. Memahami jenis ekspresi membantu Anda memilih antara kesederhanaan dan presisi. Ekspresi cron memberikan kontrol yang tepat atas waktu, memungkinkan Anda menentukan waktu yang tepat, hari dalam seminggu, atau hari dalam sebulan. Gunakan ekspresi cron saat Anda membutuhkan kueri untuk dijalankan pada jam kerja tertentu atau sejajar dengan jadwal operasional. Di konsol Anda juga dapat menjadwalkan kueri menggunakan opsi kalender mudah. **Ekspresi Cron** Jalankan kueri pada waktu tertentu. Format: `cron(minute hour day-of-month month day-of-week year)`. Contoh: + `cron(0 9 * * ? *)`- Setiap hari pukul 09.00 UTC + `cron(0 18 ? * MON-FRI *)`- Hari kerja pukul 6:00 PM UTC + `cron(0 0 1 * ? *)`- Hari pertama setiap bulan pada tengah malam UTC + `cron(0 12 ? * SUN *)`- Setiap Minggu siang UTC + `cron(30 8 1 1 ? *)`- 1 Januari pukul 8:30 UTC Semua kueri terjadwal berjalan di UTC, terlepas dari zona waktu lokal Anda atau di mana AWS sumber daya Anda berada. Ini sangat penting ketika Anda menjadwalkan kueri untuk jam kerja atau analisis sensitif waktu. Misalnya, jika bisnis Anda beroperasi di Waktu Timur AS dan Anda menginginkan laporan harian pada pukul 9 pagi ET, Anda perlu memperhitungkan offset UTC (14:00 UTC selama waktu musim panas, 13:00 UTC sebaliknya). Rencanakan ekspresi jadwal Anda dengan mempertimbangkan UTC untuk memastikan kueri berjalan pada waktu yang ditentukan. ## Memilih bahasa kueri Kueri terjadwal mendukung tiga bahasa kueri yang berbeda, dan pilihan Anda memengaruhi cara Anda menulis kueri dan seberapa mudah tim Anda dapat mempertahankannya. Bahasa yang tepat tergantung pada persyaratan analisis Anda dan keterampilan tim Anda yang ada. Jika Anda terutama memfilter dan menggabungkan data log, CloudWatch Logs Insights Query Language menawarkan sintaks yang paling mudah. Untuk transformasi data yang kompleks di mana Anda perlu membentuk kembali atau memperkaya data melalui beberapa langkah, pendekatan pipeline PPL membuat logika lebih mudah diikuti. Ketika Anda perlu melakukan gabungan atau agregasi kompleks yang mirip dengan operasi database, SQL menyediakan sintaks akrab yang dapat diadopsi oleh tim berpengalaman database dengan cepat. **CloudWatch Bahasa Kueri Wawasan Log (CWLI)** Dibuat khusus untuk analisis log dengan sintaks intuitif. Terbaik untuk: + Analisis dan penyaringan log berbasis teks + Agregasi dan statistik deret waktu + Tim baru untuk analisis log **OpenSearch Service Piped Processing Language (PPL)** Bahasa kueri berbasis pipeline dengan kemampuan transformasi data yang kuat. Terbaik untuk: + Transformasi dan pengayaan data yang kompleks + Alur kerja pemrosesan data multi-langkah + Tim yang akrab dengan pemrosesan berbasis pipa **OpenSearch Layanan Structured Query Language (SQL)** Sintaks SQL standar untuk kueri gaya database yang sudah dikenal. Terbaik untuk: + Kompleks bergabung dan agregasi + Intelijen bisnis dan pelaporan + Tim dengan pengalaman SQL yang kuat ## Pemilihan tujuan dan kasus penggunaan Di mana Anda mengirim hasil kueri menentukan apa yang dapat Anda lakukan dengan mereka. Pilihan ini membentuk seluruh alur kerja hilir Anda—apakah Anda sedang membangun analitik jangka panjang, memicu respons otomatis, atau keduanya. Memahami kekuatan setiap jenis tujuan membantu Anda merancang arsitektur yang tepat untuk kasus penggunaan Anda. Tujuan Amazon S3 dioptimalkan untuk penyimpanan dan pemrosesan batch. Saat Anda perlu menyimpan hasil kueri selama berbulan-bulan atau bertahun-tahun, menganalisis tren dari waktu ke waktu, atau memasukkan data ke dalam platform analitik, Amazon S3 menyediakan penyimpanan hemat biaya dengan retensi tak terbatas. EventBridge tujuan dioptimalkan untuk otomatisasi waktu nyata. Ketika hasil kueri harus memicu tindakan segera—seperti mengirim peringatan, memulai alur kerja, atau memperbarui sistem— EventBridge memberikan hasil sebagai peristiwa yang dapat ditanggapi oleh aplikasi Anda secara instan. Secara default, semua peristiwa penyelesaian kueri secara otomatis dikirim sebagai peristiwa ke bus peristiwa default, memungkinkan integrasi dengan sistem pemrosesan hilir, fungsi Lambda, atau arsitektur berbasis peristiwa lainnya. Hasil hanya dipublikasikan ke tujuan ketika kueri dijalankan dengan sukses. **Tujuan Amazon S3** Simpan hasil kueri sebagai file JSON untuk retensi jangka panjang dan pemrosesan batch. Terbaik untuk: + Analisis historis dan pengarsipan data + Integrasi dengan data lake dan platform analitik + Persyaratan kepatuhan dan audit + Penyimpanan hemat biaya dari set hasil besar **EventBridge destinasi** Kirim hasil kueri sebagai acara untuk pemrosesan dan otomatisasi waktu nyata. Anda dapat mengambil hasil kueri menggunakan QueryID yang dikirim dalam acara hingga 30 hari hanya karena kami menyimpan hasil selama 30 hari. Terbaik untuk: + Memicu respons otomatis terhadap hasil kueri + Integrasi dengan alur kerja tanpa server dan fungsi Lambda + Sistem peringatan dan notifikasi waktu nyata + Arsitektur dan layanan mikro yang digerakkan oleh acara ## Format dan struktur hasil kueri Untuk tujuan Amazon S3 - Hasil kueri dikirimkan dalam format JSON dengan struktur yang sama dengan respons API. GetQueryResults Untuk Amazon, EventBridge memahami format hasil kueri terjadwal membantu Anda merancang alur kerja pemrosesan dan integrasi hilir. Hasil kueri disampaikan dalam format JSON dengan struktur berikut: ``` { "version": "0", "id": "be72061b-eca2-e068-a7e1-83e01d6fe807", "detail-type": "Scheduled Query Completed", "source": "aws.logs", "account": "123456789012", "time": "2025-11-18T11:31:48Z", "region": "us-east-1", "resources": [ "arn:aws:logs:us-east-1:123456789012:scheduled-query:477b4380-b098-474e-9c5e-e10a8cc2e6e7" ], "detail": { "queryId": "2038fd57-ab4f-4018-bb2f-61d363f4a004", "queryString": "fields @timestamp, @message, @logStream, @log\n| sort @timestamp desc\n| limit 10000", "logGroupIdentifiers": [ "/aws/lambda/my-function" ], "status": "Complete", "startTime": 1763465460, "statistics": { "recordsMatched": 0, "recordsScanned": 0, "estimatedRecordsSkipped": 0, "bytesScanned": 0, "estimatedBytesSkipped": 0, "logGroupsScanned": 1 } } } ``` Elemen kunci meliputi: + `statistics`- Metrik kinerja kueri termasuk catatan yang cocok, dipindai, byte diproses, dan diperkirakan data yang dilewati + `startTime`- Saat eksekusi kueri dimulai (stempel waktu Unix) + `queryString`- Kueri aktual yang dieksekusi + `queryId`- ID kueri dari kueri yang menggunakan hasil mana yang dapat diambil + `logGroupIdentifiers`- Daftar grup log yang ditanyakan + `status`- Status eksekusi kueri (Lengkap, Gagal, dll.) # Referensi ekspresi jadwal Gunakan tabel referensi ini untuk membuat ekspresi jadwal untuk kueri terjadwal Anda. Format waktunya adalah UTC. **Sintaks ekspresi cron** Format: `cron(minute hour day-of-month month day-of-week year)` | Kasus Penggunaan | Ekspresi Cron | Deskripsi | Gunakan Kapan | | --- | --- | --- | --- | | Jadwal Harian | cron(0 9 \$1 \$1 ? \$1) | Setiap hari pukul 09.00 UTC | Laporan harian | | | cron(0 \$1/6 \$1 \$1 ? \$1) | Setiap 6 jam (00:00, 06:00, 12:00, 18:00 UTC) | Pemantauan yang sering | | | cron(30 2 \$1 \$1 ? \$1) | Setiap hari pukul 02:30 UTC | Analisis di luar puncak | | Jam Kerja | cron(0 9-17 ? \$1 MON-FRI \$1) | Setiap jam dari jam 9 pagi sampai jam 5 sore, Senin sampai Jumat UTC | Pemantauan bisnis | | | cron(0 18 ? \$1 MON-FRI \$1) | Hari kerja pukul 6:00 PM UTC | Akhir hari kerja | | | cron(0 8,12,17 ? \$1 MON-FRI \$1) | 8 pagi, siang, dan 5 sore pada hari kerja UTC | Waktu bisnis utama | | Jadwal Mingguan | cron(0 12 ? \$1 SUN \$1) | Setiap hari Minggu di siang hari UTC | Ringkasan mingguan | | | cron(0 9 ? \$1 MON \$1) | Setiap Senin pukul 9:00 UTC | Laporan awal minggu | | | cron(0 23 ? \$1 FRI \$1) | Setiap Jumat pukul 11:00 WIB UTC | Pembersihan akhir minggu | | Jadwal Bulanan | cron(0 0 1 \$1 ? \$1) | Hari pertama setiap bulan di tengah malam UTC | Laporan bulanan | | | cron(0 9 L \$1 ? \$1) | Hari terakhir setiap bulan pukul 9:00 UTC | Pemrosesan akhir bulan | | | cron(0 10 1 1,4,7,10 ? \$1) | Hari pertama setiap kuartal pukul 10:00 UTC | Analisis triwulanan | | Frekuensi Tinggi | cron(\$1/15 \$1 \$1 \$1 ? \$1) | Setiap 15 menit | Pemantauan waktu nyata | | | cron(0,30 \$1 \$1 \$1 ? \$1) | Setiap 30 menit (pukul 00 dan:30) | Pemeriksaan yang sering | | | cron(0 \$1/2 \$1 \$1 ? \$1) | Setiap 2 jam | Interval reguler | | Kasus Khusus | cron(30 8 1 1 ? \$1) | 1 Januari pukul 8:30 UTC | Laporan tahunan | | | cron(0 6 \$1 \$1 SAT,SUN \$1) | Akhir pekan pukul 6:00 UTC | Pemrosesan akhir pekan | | | cron(0 0 ? \$1 MON\$11 \$1) | Senin pertama setiap bulan di tengah malam UTC | Perencanaan bulanan | **Referensi bidang ekspresi cron** | Bidang | Nilai | Wildcard | Contoh | | --- | --- | --- | --- | | Menit (1) | 0-59 | \$1 , - / | 0(atas jam), \$1/15 (setiap 15 menit), 0,30 (dua kali per jam) | | Jam (2) | 0-23 | \$1 , - / | 9(9 AM), \$1/2 (setiap 2 jam), 9-17 (jam kerja) | | Day-of-month (3) | 1-31, L, W | \$1 , - / ? | 1(Hari pertama), L (hari terakhir), ? (saat menggunakan day-of-week) | | Bulan (4) | 1-12 atau JAN-DES | \$1 , - / | 1(Januari),JAN, 1,4,7,10 (triwulanan) | | Day-of-week (5) | 1-7 atau MGG-SBT | \$1 , - / ? \$1 L | MON-FRI(hari kerja),SUN, MON\$11 (Senin 1) | | Tahun (6) | 1970-2199 | \$1 , - / | \$1(setiap tahun), 2024 (tahun tertentu), 2024-2026 (kisaran) | **Karakter wildcard dan ekspresi khusus** **`*` (tanda bintang)** Cocokkan semua nilai di lapangan. Contoh: `*` di bidang jam berarti setiap jam. **`?`(tanda tanya)** Tidak ada nilai spesifik. Gunakan di day-of-month atau day-of-week ketika yang lain ditentukan. Contoh: Gunakan `?` day-of-month saat menentukan `MON-FRI` di day-of-week. **`-` (dasbor)** Rentang nilai. Contoh: `MON-FRI` (Senin sampai Jumat), `9-17` (9 pagi sampai jam 5 sore). **`,`(koma)** Beberapa nilai spesifik. Contoh: `MON,WED,FRI` (Senin, Rabu, Jumat), `8,12,17` (8 pagi, siang, 5 sore). **`/`(tebasan)** Nilai langkah atau kenaikan. Contoh: `0/15` dalam menit berarti setiap 15 menit dimulai pada menit 0 (0, 15, 30, 45). `*/2`dalam jam berarti setiap 2 jam. **`L`(terakhir)** Hari terakhir bulan atau kejadian terakhir hari kerja. Contoh: `L` day-of-month artinya hari terakhir dalam sebulan. `FRIL`berarti Jumat terakhir bulan. **`W`(hari kerja)** Hari kerja terdekat. Contoh: `15W` berarti hari kerja terdekat hingga tanggal 15 setiap bulan. **`#`(kejadian ke-n)** Ke-n terjadinya hari kerja dalam sebulan. Contoh: `MON#1` berarti Senin pertama setiap bulan, `FRI#2` berarti Jumat kedua setiap bulan. **Pola umum dan praktik terbaik** + **Untuk aplikasi bisnis:** Gunakan `MON-FRI` dan jam kerja (misalnya,`9-17`) untuk menghindari menjalankan kueri selama akhir pekan atau di luar jam kerja. + **Untuk pemantauan frekuensi tinggi:** Gunakan kenaikan seperti `*/15` (setiap 15 menit) tetapi perhatikan batas konkurensi kueri. + **Untuk efisiensi sumber daya:** Jadwalkan kueri intensif sumber daya selama jam-jam di luar sibuk menggunakan waktu pagi seperti UTC. `2-6` + **Untuk laporan bulanan:** Gunakan `L` untuk hari terakhir bulan atau tanggal tertentu seperti `1` untuk hari pertama untuk memastikan waktu yang konsisten. # Praktik terbaik Ikuti praktik terbaik ini untuk memastikan operasi kueri terjadwal yang andal dan efisien: **Pengoptimalan kueri** + Uji kueri secara manual sebelum penjadwalan untuk memverifikasi kinerja dan hasil + Gunakan indeks filter di awal kueri Anda untuk mengurangi pemrosesan data + Batasi rentang waktu untuk menghindari batas waktu dengan grup log volume tinggi + Pertimbangkan kompleksitas kueri dan batas waktu eksekusi **Jadwal perencanaan** + Hindari eksekusi yang tumpang tindih dengan memastikan kueri selesai sebelum jadwal berjalan berikutnya + Pertimbangkan penundaan konsumsi log saat mengatur rentang waktu + Gunakan ekspresi cron untuk waktu tertentu + Sebarkan jadwal untuk memastikan Anda tidak mencapai batas konkurensi kueri **Pemantauan dan pemeliharaan** + Memantau riwayat eksekusi secara teratur untuk mengidentifikasi kegagalan atau masalah kinerja + Meninjau dan memperbarui peran IAM secara berkala untuk menjaga keamanan + Uji aksesibilitas tujuan sebelum menerapkan ke produksi **Otorisasi** + Semua kueri terjadwal APIs untuk mengotorisasi sumber daya kueri terjadwal dan bukan pada sumber daya yang diperlukan dalam input seperti grup log. Siapkan kebijakan IAM yang sesuai + Mengelola otorisasi grup log menggunakan peran eksekusi yang diteruskan di APIs # Memulai dengan kueri terjadwal Saat membuat kueri terjadwal, Anda akan mengonfigurasi beberapa komponen utama yang menentukan cara kueri Anda berjalan dan di mana hasil dikirim. Memahami komponen-komponen ini akan membantu Anda mengatur analisis log otomatis yang efektif. Setiap kueri terjadwal terdiri dari komponen kunci berikut: **Konfigurasi kueri** String kueri CloudWatch Logs Insights, grup log target, dan bahasa kueri yang akan digunakan untuk analisis. **Ekspresi jadwal** Ekspresi cron atau kalender frekuensi yang menentukan kapan kueri berjalan. Anda dapat menentukan pengaturan zona waktu untuk memastikan kueri berjalan pada waktu lokal yang benar. Konsol menampilkan deskripsi jadwal Anda yang dapat dibaca manusia, seperti “Jalankan kueri setiap hari Selasa pukul 15:10 untuk rentang waktu 5 menit, efektif segera, di UTC, hingga tanpa batas waktu.” **Rentang waktu** Periode lookback untuk setiap eksekusi kueri, ditentukan oleh waktu mulai offset dari waktu eksekusi. Ini menentukan berapa banyak data historis yang akan dianalisis setiap eksekusi kueri. **Pratinjau jadwal eksekusi** Konsol menunjukkan tiga kueri terjadwal berikutnya berjalan dengan tanggal dan waktu yang tepat (misalnya, 2025/10/28 15:10, UTC; 2025/11/04 15:10, UTC; 2025/11/11 15:10, UTC), membantu Anda memverifikasi bahwa jadwal dikonfigurasi dengan benar. **Tujuan** Di mana hasil kueri dikirim setelah eksekusi berhasil. Tujuan yang didukung termasuk bucket Amazon S3 dan secara default metadata hasil dikirim ke bus acara default. **Peran eksekusi** Peran IAM yang diasumsikan CloudWatch Log untuk mengeksekusi kueri dan memberikan hasil ke tujuan yang ditentukan. Sebelum membuat kueri terjadwal, pastikan Anda memiliki izin dan sumber daya yang diperlukan yang dikonfigurasi. # Membuat kueri terjadwal Buat kueri terjadwal yang secara otomatis menjalankan kueri Wawasan CloudWatch Log dan memberikan hasil ke tujuan yang Anda pilih. ## Prasyarat Sebelum membuat kueri terjadwal, pastikan Anda memiliki yang berikut: + **Grup log** - Satu atau beberapa grup log yang berisi data yang ingin Anda analisis + **Eksekusi peran IAM - Peran** IAM dengan izin berikut: + `logs:StartQuery`- Izin untuk memulai CloudWatch kueri Wawasan Log + `logs:GetQueryResults`- Izin untuk mengambil hasil kueri + `logs:DescribeLogGroups`- Izin untuk mengakses informasi grup log. Ini hanya diperlukan untuk grup log berbasis awalan untuk penemuan grup log + **Izin tujuan - Izin** IAM tambahan untuk tujuan yang Anda pilih: + Untuk tujuan Amazon S3: `s3:PutObject` + **Untuk AWS CLI dan penggunaan API** - AWS Kredensi yang dikonfigurasi dengan izin untuk memanggil Log CloudWatch APIs Untuk contoh kebijakan IAM yang mendetail, lihat[Manajemen identitas dan akses untuk Amazon CloudWatch Logs](auth-and-access-control-cwl.md). Juga perlu dicatat Anda hanya dapat memiliki 1000 kueri terjadwal per akun. ------ #### [ Console ] **Untuk membuat kueri terjadwal (konsol)** 1. Buka konsol CloudWatch Log di [https://us-east-1.console.aws.amazon.com/cloudwatch/rumah? region=us-east-1](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:logs-insights) \$1 logsV2: logs-wawasan. 1. Di panel navigasi, pilih ** Wawasan Logs**. 1. Pilih **Buat kueri terjadwal**. 1. Di bagian **Definisi kueri**: 1. Untuk **bahasa Kueri**, pilih bahasa kueri yang akan digunakan dari daftar. 1. Untuk **string Kueri**, masukkan kueri Wawasan CloudWatch Log Anda di kotak. 1. Untuk **grup Log**, pilih grup log untuk kueri dari daftar. 1. Di bagian **Pengaturan jadwal**: 1. Untuk **ekspresi Jadwal**, konfigurasikan saat kueri berjalan. Pilih dari opsi yang telah ditentukan atau masukkan ekspresi cron kustom. 1. Untuk **Efektif saat pembuatan**, tentukan kapan jadwal menjadi aktif. Pilih untuk segera memulai atau pada tanggal dan waktu tertentu menggunakan YYYY/MM/DD format. 1. Untuk **Rentang waktu**, tentukan periode lookback untuk setiap eksekusi kueri. Masukkan durasi dalam menit yang menentukan seberapa jauh dari waktu eksekusi ke kueri. 1. Untuk **Lanjutkan tanpa batas waktu**, tentukan kapan jadwal berakhir. Pilih untuk menjalankan tanpa batas waktu atau sampai tanggal dan waktu tertentu menggunakan YYYY/MM/DD format. 1. Konsol menampilkan tiga kueri terjadwal berikutnya berdasarkan konfigurasi Anda, menunjukkan tanggal dan waktu yang tepat di UTC saat kueri akan dijalankan. 1. Dalam **hasil kueri Posting ke S3 - bagian opsional** (jika menggunakan tujuan S3): 1. Untuk **bucket S3**, pilih **Akun ini** jika bucket tujuan berada di AWS akun yang sama, atau pilih **Akun lain** jika bucket berada di AWS akun yang berbeda dan berikan ID akun pemilik ember sebagai input. 1. Untuk **URI Amazon S3**, masukkan bucket Amazon S3 dan awalan tempat hasil akan disimpan (misalnya,). `s3://my-bucket/query-results/` Jika Anda memilih **Akun ini**, Anda dapat memilih **Jelajahi Amazon S3** untuk menavigasi dan memilih lokasi Amazon S3 yang ada. 1. (Opsional) Untuk **ARN kunci KMS**, masukkan ARN kunci yang AWS KMS dikelola pelanggan untuk mengenkripsi hasil kueri menggunakan SSE-KMS. Kuncinya harus berada di AWS Wilayah yang sama dengan bucket Amazon S3 tujuan. 1. Dalam **peran IAM untuk memposting hasil kueri ke bagian Amazon** S3, pilih salah satu opsi berikut: 1. Pilih **Buat otomatis peran baru dengan izin default** untuk secara otomatis menyiapkan peran IAM dengan izin yang diperlukan untuk CloudWatch Log untuk mengirimkan hasil kueri ke Amazon S3. 1. Pilih **Gunakan peran yang ada untuk memilih peran** IAM yang ada dengan kebijakan yang diperlukan untuk CloudWatch Log untuk mengirimkan hasil kueri ke Amazon S3. Gunakan bidang pencarian untuk menemukan dan memilih peran IAM yang sesuai dari daftar. 1. Di **peran IAM untuk bagian eksekusi kueri terjadwal**, pilih salah satu opsi berikut: 1. Pilih **Auto-create peran baru dengan izin default** untuk secara otomatis mengatur peran IAM dengan izin yang diperlukan untuk CloudWatch Log untuk menjalankan kueri terjadwal. 1. Pilih **Gunakan peran yang ada untuk memilih peran** IAM yang ada dengan kebijakan yang diperlukan untuk CloudWatch Log untuk menjalankan kueri terjadwal. Gunakan bidang pencarian untuk menemukan dan memilih peran IAM yang sesuai dari daftar. 1. Pilih **Buat jadwal** untuk membuat kueri terjadwal. ------ #### [ AWS CLI ] **Untuk membuat query terjadwal (AWS CLI)** + Gunakan `create-scheduled-query` perintah untuk membuat kueri terjadwal baru: ``` aws logs create-scheduled-query \ --name "ErrorAnalysisQuery" \ --query-language "CWLI" \ --query-string "fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)" \ --schedule-expression "cron(8 * * * ? *)" \ --execution-role-arn "arn:aws:iam::123456789012:role/CloudWatchLogsScheduledQueryRole" \ --log-group-identifiers "/aws/lambda/my-function" "/aws/apigateway/my-api" \ --state "ENABLED" ``` ------ #### [ API ] **Untuk membuat kueri terjadwal (API)** + Gunakan `CreateScheduledQuery` tindakan untuk membuat kueri terjadwal baru. Contoh berikut membuat kueri terjadwal yang berjalan setiap jam: ``` { "name": "ErrorAnalysisQuery", "queryLanguage": "CWLI", "queryString": "fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)", "scheduleExpression": "cron(8 * * * ? *)", "executionRoleArn": "arn:aws:iam::123456789012:role/CloudWatchLogsScheduledQueryRole", "logGroupIdentifiers": ["/aws/lambda/my-function", "/aws/apigateway/my-api"], "state": "ENABLED" } ``` ------ Setelah membuat kueri terjadwal, Anda dapat melihat dan mengelolanya dari halaman **Kueri terjadwal** dan menggunakan ListScheduledQueries API, yang menampilkan semua kueri terjadwal dengan nama, tanggal pembuatan, status proses terakhir, waktu pemicu terakhir, dan frekuensi pengulangan. # Melihat dan mengelola kueri terjadwal Informasi berikut tersedia untuk setiap kueri: **Nama** Nama unik yang Anda tetapkan untuk kueri terjadwal. Pilih nama untuk melihat konfigurasi terperinci dan riwayat eksekusi. **Tanggal pembuatan** Tanggal ketika kueri terjadwal dibuat, ditampilkan dalam YYYY-MM-DD format. **Status Last Run** Status eksekusi dari kueri terbaru yang dijalankan. Nilai yang mungkin termasuk: + **Selesai** - Kueri berhasil dieksekusi dan hasilnya dikirim ke semua tujuan yang dikonfigurasi. + **Gagal** - Eksekusi kueri atau pengiriman hasil gagal. Periksa riwayat eksekusi untuk detail kesalahan. + Kueri **Tidak Valid - Kueri** tidak valid dan memiliki masalah sintaksis + **Timeout** - Kueri telah habis waktunya. Waktu kueri habis secara otomatis setelah 60 menit **Waktu terakhir dipicu** Tanggal dan waktu ketika kueri terakhir dieksekusi, ditampilkan dalam format YYYY-MM-DD HH: MM: SS. Menampilkan **Tidak Pernah** jika kueri belum berjalan. **Mengulangi setiap** Frekuensi jadwal untuk kueri. Menampilkan **Kustom** untuk kueri menggunakan ekspresi cron atau deskripsi frekuensi tertentu untuk jadwal yang lebih sederhana. Halaman **kueri terjadwal** memberikan ikhtisar semua kueri terjadwal Anda, menunjukkan status saat ini dan riwayat eksekusi sehingga Anda dapat melihat, memantau, dan mengelola semua kueri terjadwal Anda dari lokasi terpusat. Gunakan informasi ini untuk memantau kinerja kueri, mengidentifikasi masalah, dan mengelola alur kerja analisis log otomatis Anda. ------ #### [ Console ] **Untuk melihat kueri terjadwal (konsol)** 1. Buka konsol CloudWatch Log di [https://us-east-1.console.aws.amazon.com/cloudwatch/rumah? region=us-east-1](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:logs-insights) \$1 logsV2: logs-wawasan. 1. Di konsol CloudWatch Log, pilih **Kueri terjadwal**, **Lihat kueri terjadwal**. ------ #### [ AWS CLI ] **Untuk membuat daftar kueri terjadwal ()AWS CLI** + Gunakan `list-scheduled-queries` perintah untuk membuat daftar semua kueri terjadwal: ``` aws logs list-scheduled-queries --max-results 10 ``` ------ #### [ API ] **Untuk membuat daftar kueri terjadwal (API)** + Gunakan `ListScheduledQueries` tindakan untuk mengambil semua kueri terjadwal: ``` { "maxResults": 10 } ``` ------ Header halaman **kueri terjadwal** menunjukkan jumlah total kueri terjadwal di akun Anda, membantu Anda melacak penggunaan dan mengelola alur kerja analisis log otomatis Anda secara efektif. # Melihat riwayat eksekusi kueri terjadwal Gunakan riwayat eksekusi untuk memantau kinerja kueri terjadwal Anda dan memecahkan masalah apa pun dengan eksekusi kueri atau pengiriman hasil. Riwayat eksekusi menunjukkan status setiap kueri yang dijalankan, termasuk eksekusi yang berhasil, kegagalan, dan hasil pemrosesan tujuan. Anda dapat menggunakan informasi ini untuk mengidentifikasi pola, mendiagnosis masalah, dan memverifikasi bahwa kueri Anda berjalan seperti yang diharapkan. ------ #### [ Console ] **Untuk melihat riwayat eksekusi (konsol)** 1. Di konsol CloudWatch Log, pilih **Kueri terjadwal**, **Lihat kueri terjadwal**. 1. Pilih kueri terjadwal yang ingin Anda periksa. 1. Pilih tab **Riwayat eksekusi**. ------ #### [ AWS CLI ] **Untuk melihat riwayat eksekusi (AWS CLI)** 1. Gunakan `get-scheduled-query-history` perintah untuk mengambil riwayat eksekusi untuk kueri terjadwal: ``` aws logs get-scheduled-query-history \ --identifier "DailyErrorMonitoring" \ --start-time 1743379200 \ --end-time 1743465600 \ --max-results 10 ``` 1. Untuk memfilter berdasarkan status eksekusi, tambahkan `--execution-statuses` parameter: ``` aws logs get-scheduled-query-history \ --identifier "DailyErrorMonitoring" \ --start-time 1743379200 \ --end-time 1743465600 \ --max-results 1 \ --execution-statuses "SUCCEEDED" ``` ------ #### [ API ] **Untuk melihat riwayat eksekusi (API)** + Gunakan `GetScheduledQueryHistory` tindakan untuk mengambil riwayat eksekusi: ``` { "identifier": "DailyErrorMonitoring", "startTime": 1743379200, "endTime": 1743465600, "maxResults": 10, "executionStatuses": ["SUCCEEDED", "FAILED"] } ``` ------ Riwayat eksekusi menampilkan: + **Status eksekusi** - Berjalan, Selesai, Gagal, Batas Waktu, atau InvalidQuery + **Waktu yang dipicu** - Saat kueri dijalankan + **Tujuan** - Status pemrosesan untuk setiap tujuan yang dikonfigurasi termasuk S3 dan EventBridge + **Pesan galat** - Detail tentang kegagalan dalam eksekusi kueri atau pemrosesan tujuan # Memperbarui kueri terjadwal Ubah konfigurasi kueri terjadwal Anda untuk mengubah string kueri, jadwal, tujuan, atau peran eksekusi saat persyaratan Anda berkembang. Anda dapat memperbarui aspek apa pun dari kueri terjadwal, termasuk string kueri, ekspresi jadwal, tujuan, dan peran eksekusi. Perubahan segera berlaku untuk eksekusi di masa depan. ------ #### [ Console ] **Untuk memperbarui kueri terjadwal (konsol)** 1. Di konsol CloudWatch Log, pilih **Kueri terjadwal**, **Lihat kueri terjadwal**. 1. Pilih kueri terjadwal yang ingin Anda perbarui. 1. Pilih **Edit**. 1. Ubah konfigurasi sesuai kebutuhan. 1. Pilih **Simpan perubahan**. ------ #### [ AWS CLI ] **Untuk memperbarui kueri terjadwal (AWS CLI)** + Gunakan `update-scheduled-query` perintah untuk memodifikasi kueri terjadwal yang ada: ``` aws logs update-scheduled-query \ --identifier "arn:aws:logs:us-east-1:111122223333:scheduled-query:5e0c0228-1c29-4d26-904f-59f1f1ba3c8f" \ --description "Monitor for ERROR level logs daily" \ --query-language "LogsQL" \ --query-string "fields @timestamp, @message | filter @message like /ERROR/" \ --log-group-identifiers "/aws/lambda/my-function-1" "/aws/lambda/my-function-2" ``` ------ #### [ API ] **Untuk memperbarui kueri terjadwal (API)** 1. Gunakan `UpdateScheduledQuery` tindakan untuk mengubah konfigurasi kueri terjadwal: ``` { "identifier": "arn:aws:logs:us-east-1:111122223333:scheduled-query:5e0c0228-1c29-4d26-904f-59f1f1ba3c8f", "queryString": "fields @timestamp, @message | filter @message like /WARNING|ERROR/ | stats count() by bin(5m)", "scheduleExpression": "cron(0 */2 * * ? *)", "state": "ENABLED" } ``` 1. Untuk memperbarui beberapa parameter konfigurasi sekaligus: ``` { "identifier": "arn:aws:logs:us-east-1:111122223333:scheduled-query:5e0c0228-1c29-4d26-904f-59f1f1ba3c8f", "queryString": "fields @timestamp, @message, @level | filter @level = 'ERROR'", "scheduleExpression": "cron(0 8,12,16 * * ? *)", "executionRoleArn": "arn:aws:iam::111122223333:role/UpdatedScheduledQueryRole", "logGroupIdentifiers": ["/aws/lambda/my-function", "/aws/lambda/another-function"], "destinationConfiguration": { "s3Configuration": { "destinationIdentifier": "s3://111122223333-sqn-results-bucket/processed-results", "roleArn": "arn:aws:iam::111122223333:role/Admin" } } } ``` ------ # Mengkonfigurasi tujuan S3 untuk kueri terjadwal Konfigurasikan Amazon S3 sebagai tujuan untuk menyimpan hasil kueri terjadwal Anda sebagai file JSON untuk retensi dan analisis jangka panjang. Saat menggunakan Amazon S3 sebagai tujuan, hasil kueri disimpan sebagai file JSON di bucket dan awalan yang ditentukan. Opsi ini sangat ideal untuk pengarsipan hasil, melakukan analisis batch, atau mengintegrasikan dengan AWS layanan lain yang memproses data S3. Anda dapat mengirimkan hasil kueri ke bucket Amazon S3 di AWS akun yang sama dengan kueri terjadwal atau ke bucket di akun lain AWS . Anda juga dapat mengenkripsi hasil kueri secara opsional menggunakan AWS KMS kunci terkelola pelanggan (SSE-KMS). ## Memberikan hasil ke bucket Amazon S3 di akun yang sama Jika bucket Amazon S3 tujuan berada di AWS akun yang sama dengan kueri terjadwal, Anda dapat menelusuri dan memilih bucket langsung dari konsol. **Untuk mengonfigurasi tujuan Amazon S3 akun yang sama (konsol)** 1. Di bagian **Posting hasil kueri ke S3**, untuk **bucket S3**, pilih Akun **ini**. 1. Untuk **URI Amazon S3**, masukkan bucket Amazon S3 dan awalan tempat hasil akan disimpan (misalnya`s3://my-bucket/query-results/`,), atau pilih Jelajahi **Amazon S3 untuk menavigasi dan memilih lokasi Amazon** S3 yang ada. 1. (Opsional) Untuk mengenkripsi hasil dengan AWS KMS kunci yang dikelola pelanggan, masukkan ARN kunci di bidang AWS KMS ARN kunci **KMS**. Kuncinya harus berada di AWS Wilayah yang sama dengan bucket Amazon S3 tujuan. Jika Anda tidak menentukan AWS KMS kunci, setelan enkripsi default bucket akan berlaku. 1. Di **peran IAM untuk memposting hasil kueri ke Amazon** S3, **pilih Buat otomatis peran baru dengan izin default** untuk secara otomatis menyiapkan izin yang diperlukan, atau **pilih Gunakan peran yang ada untuk memilih peran IAM yang ada** dengan kebijakan yang diperlukan. Peran IAM pengiriman tujuan memerlukan izin berikut: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/prefix/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" } } } ] } ``` ## Memberikan hasil ke bucket Amazon S3 di akun lain Anda dapat mengirimkan hasil kueri terjadwal ke bucket Amazon S3 di akun lain AWS . Saat menggunakan bucket lintas akun, Anda harus memberikan URI Amazon S3 dan ID akun akun pemilik ember. **Untuk mengonfigurasi tujuan Amazon S3 lintas akun (konsol)** 1. Di bagian **Posting hasil kueri ke S3**, untuk **bucket S3**, pilih **Akun lain** dan berikan ID akun akun pemilik ember sebagai input. 1. Untuk URI **Amazon S3, masukkan URI** Amazon S3 lengkap dari bucket tujuan dan awalan di akun lain (misalnya,). `s3://cross-account-bucket/query-results/` 1. (Opsional) Untuk mengenkripsi hasil dengan AWS KMS kunci yang dikelola pelanggan, masukkan ARN kunci di bidang AWS KMS ARN kunci **KMS**. Kuncinya harus berada di AWS Wilayah yang sama dengan bucket Amazon S3 tujuan. 1. Di **peran IAM untuk memposting hasil kueri ke Amazon** S3, **pilih Buat otomatis peran baru dengan izin default** untuk secara otomatis menyiapkan izin yang diperlukan, atau **pilih Gunakan peran yang ada untuk memilih peran IAM yang ada** dengan kebijakan yang diperlukan. Pengiriman lintas akun memerlukan izin di kedua sisi. Peran IAM pengiriman tujuan di akun sumber memerlukan izin berikut: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::cross-account-bucket/prefix/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "123456789012" } } } ] } ``` Kebijakan bucket Amazon S3 di akun tujuan harus memberikan izin peran IAM akun sumber untuk menulis objek: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowScheduledQueryRolePutObject", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/my-s3-delivery-role" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::cross-account-bucket/prefix/*" } ] } ``` ## Mengenkripsi hasil dengan kunci yang dikelola pelanggan AWS KMS Anda dapat menentukan AWS KMS kunci terkelola pelanggan secara opsional untuk mengenkripsi hasil kueri yang dikirimkan ke Amazon S3 menggunakan SSE-KMS. AWS KMS Kuncinya bisa di akun yang sama dengan kueri terjadwal atau di akun yang berbeda. Saat Anda menentukan AWS KMS kunci, kueri terjadwal menggunakan kunci tersebut untuk mengenkripsi hasil melalui SSE-KMS. Jika Anda tidak menentukan AWS KMS kunci, setelan enkripsi default bucket akan berlaku. Jika bucket dikonfigurasi dengan enkripsi SSE-KMS default menggunakan kunci terkelola pelanggan, peran IAM pengiriman tujuan harus tetap memiliki `kms:GenerateDataKey` izin pada kunci tersebut. Peran IAM pengiriman tujuan memerlukan `kms:GenerateDataKey` izin pada AWS KMS kunci. Contoh berikut menunjukkan izin yang diperlukan untuk tujuan Amazon S3 dengan kunci yang dikelola pelanggan AWS KMS : ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/prefix/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" } } }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id", "Condition": { "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::my-bucket*" } } } ] } ``` Jika AWS KMS kunci berada di akun yang berbeda dari peran IAM pengiriman tujuan, kebijakan AWS KMS kunci di akun pemilik kunci harus secara eksplisit memberikan akses peran: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowScheduledQueryRoleToEncrypt", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/my-s3-delivery-role" }, "Action": "kms:GenerateDataKey", "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::my-bucket*" } } } ] } ``` **catatan** Ketika peran IAM AWS KMS kunci dan pengiriman tujuan berada di akun yang sama, kebijakan identitas IAM saja sudah cukup jika kebijakan AWS KMS kunci menyertakan pernyataan root “Aktifkan kebijakan IAM” default. Pemberian kebijakan AWS KMS kunci eksplisit hanya diperlukan jika kebijakan kunci tidak didelegasikan ke IAM. Peran IAM untuk memposting hasil kueri ke Amazon S3 harus dikonfigurasi secara terpisah dari peran IAM untuk eksekusi kueri terjadwal. Pemisahan ini memungkinkan kontrol akses berbutir halus, di mana peran eksekusi dapat menjalankan kueri sementara peran Amazon S3 secara khusus menangani pengiriman hasil. Kedua peran harus menyertakan kebijakan kepercayaan yang memungkinkan layanan CloudWatch Log (`logs.amazonaws.com`) untuk mengambil peran. # Memecahkan masalah kueri terjadwal Gunakan topik pemecahan masalah ini untuk menyelesaikan masalah umum dengan kueri terjadwal. ## Eksekusi kueri gagal dengan kesalahan izin Mengatasi kesalahan izin yang mencegah kueri terjadwal mengeksekusi atau mengirimkan hasil ke tujuan. Kesalahan izin terjadi ketika peran eksekusi tidak memiliki izin yang diperlukan untuk membaca dari grup log atau menulis ke sumber daya tujuan. **Untuk mengatasi kesalahan izin** 1. Verifikasi bahwa peran eksekusi memiliki `logs:StartQuery``logs:GetQueryResults`,, dan `logs:DescribeLogGroups` izin untuk grup log target. 1. Pastikan peran eksekusi memiliki izin menulis untuk sumber daya tujuan (seperti `s3:PutObject` untuk bucket S3). 1. Periksa apakah kebijakan kepercayaan memungkinkan CloudWatch Log untuk mengambil peran eksekusi. Peran harus mempercayai prinsipal layanan log (`logs.amazonaws.com`) dalam kebijakan kepercayaannya. Penyebab umum termasuk izin IAM yang hilang, sumber daya yang salah ARNs dalam kebijakan, atau masalah konfigurasi kebijakan kepercayaan. Untuk mencegah kesalahan izin, gunakan prinsip hak istimewa paling sedikit saat membuat peran eksekusi dan izin uji sebelum menerapkan kueri terjadwal ke produksi. ## Waktu kueri habis Mengatasi kesalahan batas waktu yang terjadi ketika kueri terjadwal melebihi batas waktu eksekusi maksimum. Batas waktu kueri terjadi ketika kueri membutuhkan waktu lebih dari 60 menit untuk memproses rentang data yang ditentukan, seringkali karena kumpulan data besar atau logika kueri yang kompleks. **Untuk mengatasi kesalahan batas waktu** 1. Kurangi rentang waktu dengan mengurangi offset waktu mulai untuk memproses lebih sedikit data per eksekusi. 1. Optimalkan kueri dengan menambahkan filter di awal kueri untuk mengurangi jumlah data yang diproses. Gunakan indeks filter untuk mengurangi ukuran pemindaian data. 1. Pertimbangkan untuk memecah kueri kompleks menjadi kueri yang lebih sederhana dan lebih terfokus. Penyebab umum termasuk menanyakan rentang waktu yang besar, memproses grup log volume tinggi, atau menggunakan agregasi kompleks tanpa penyaringan yang tepat. Untuk mencegah batas waktu, uji kueri secara manual di Wawasan CloudWatch Log dengan volume data yang diharapkan dan optimalkan kinerja sebelum penjadwalan. ## Pemrosesan tujuan gagal Mengatasi kegagalan yang terjadi saat hasil kueri terjadwal tidak dapat dikirimkan ke tujuan yang dikonfigurasi. Kegagalan pemrosesan tujuan terjadi ketika bucket Amazon S3 target atau bus EventBridge acara tidak dapat diakses atau tidak dikonfigurasi dengan benar. **Untuk mengatasi kegagalan di mana hasil kueri tidak dipublikasikan ke tujuan** 1. Verifikasi bahwa bucket Amazon S3 yang ditentukan ada dan dapat diakses. 1. Periksa konfigurasi tujuan untuk benar URIs. 1. Pastikan peran eksekusi memiliki izin yang diperlukan untuk menulis ke tujuan. Penyebab umum termasuk sumber daya tujuan yang dihapus atau diganti namanya, tujuan yang salah URIs, atau masalah konektivitas jaringan. Untuk mencegah kegagalan tujuan, validasi konfigurasi tujuan secara teratur dan pantau ketersediaan sumber daya tujuan. ## Kesalahan kueri tidak valid Mengatasi kesalahan sintaks dan logika dalam string kueri terjadwal yang mencegah eksekusi berhasil. Kesalahan kueri tidak valid terjadi ketika string kueri berisi kesalahan sintaks, mereferensikan bidang yang tidak ada, atau menggunakan fitur bahasa kueri yang tidak didukung. **Untuk mengatasi kesalahan kueri yang tidak valid** 1. Uji kueri Anda secara manual di Wawasan CloudWatch Log untuk memverifikasi sintaks dan logika. 1. Periksa apakah semua bidang log yang direferensikan ada di grup log target Anda. 1. Verifikasi bahwa fitur bahasa kueri yang Anda gunakan didukung untuk kueri terjadwal. Penyebab umum termasuk kesalahan ketik dalam nama bidang, sintaks kueri yang salah, atau menggunakan fitur kueri yang tidak didukung dalam lingkungan eksekusi terjadwal. Untuk mencegah kesalahan kueri yang tidak valid, selalu uji kueri secara interaktif sebelum menjadwalkan dan gunakan fitur penemuan bidang untuk memverifikasi nama bidang. ## Kesalahan Konkurensi Kueri Ada beberapa poin penting yang disebutkan di bawah ini untuk diingat ketika kesalahan konkurensi dilihat sebagai kueri terjadwal menggunakan kuota yang sama dengan kueri wawasan Cloudwatch Logs. Disarankan untuk menyebarkan jadwal Anda untuk menghindari mencapai batas konkurensi. + **Kuota:** Anda dapat menjalankan hingga 100 kueri Wawasan CloudWatch Log bersamaan per akun. AWS + **Dasbor:** Kueri yang ditambahkan ke CloudWatch dasbor juga dihitung terhadap batas konkurensi ini, karena dijalankan saat dasbor dimuat atau di-refresh. + **OpenSearch Layanan PPL/SQL:** Anda dapat menjalankan hingga 15 kueri OpenSearch PPL atau SQL bersamaan per akun. OpenSearch AWS + **Kueri lintas akun:** Kuota konkurensi berlaku untuk kueri tunggal dan lintas akun. Saat menggunakan observabilitas CloudWatch lintas akun, kueri yang dimulai dalam akun pemantauan terhadap akun sumber tertaut juga dihitung terhadap batas konkurensi akun pemantauan. + **Grup Log Akses Jarang:** Untuk grup log di kelas log akses yang jarang, jumlah maksimum kueri Wawasan Log bersamaan dibatasi hingga lima.