Layanan Log Sederhana mendukung pemantauan terkorelasi di beberapa set hasil kueri dan peringatan tanpa data untuk mendeteksi gangguan pengumpulan data.
Ketepatan waktu pemantauan
-
Cara kerja pemantauan
Sistem peringatan secara berkala mengeksekusi pernyataan kueri yang dikonfigurasi berdasarkan Check Frequency, menjalankannya terhadap data dalam rentang waktu tertentu, dan mengevaluasi hasilnya terhadap kondisi peringatan. Jika kondisi dievaluasi sebagai true, peringatan dipicu.
-
Analisis masalah ketepatan waktu
-
Latensi pengindeksan data: Terdapat penundaan antara saat data ditulis ke Layanan Log Sederhana dan saat data tersebut tersedia untuk dikueri. Bahkan penundaan singkat sekalipun menciptakan risiko kehilangan data dalam kueri.
Sebagai contoh, pemeriksaan peringatan dijalankan pada pukul 12:03:30. Kueri dikonfigurasi untuk rentang waktu relatif satu menit terakhir, dan Check Frequency diatur ke interval tetap 1 menit. Hal ini menetapkan rentang waktu kueri menjadi [12:02:30, 12:03:30). Entri log yang ditulis pada pukul 12:03:29 mungkin belum diindeks dan tersedia untuk dikueri pada pukul 12:03:30, sehingga dapat terlewat oleh kueri.
-
Akurasi kueri: Saat log dengan timestamp berbeda dalam menit yang sama ditulis secara batch, Layanan Log Sederhana mungkin mengindeks seluruh batch menggunakan timestamp dari log paling awal.
Sebagai contoh, pemeriksaan peringatan dijalankan pada pukul 12:03:30 dengan rentang waktu relatif satu menit, yaitu [12:02:30, 12:03:30). Misalkan beberapa entri log ditulis sebagai batch pada pukul 12:02:50, tetapi timestamp masing-masing adalah 12:02:20, 12:02:50, dan seterusnya. Seluruh batch tersebut mungkin diindeks dengan timestamp 12:02:20. Akibatnya, kueri yang menggunakan rentang waktu [12:02:30, 12:03:30) tidak akan menemukan log-log tersebut.
-
-
Rekomendasi untuk mengoptimalkan ketepatan waktu
-
Mengutamakan akurasi: Ikuti rekomendasi ini jika Anda memerlukan akurasi peringatan tinggi, tanpa peringatan duplikat atau terlewat.
-
Untuk mengatasi latensi pengindeksan data: Di kotak dialog Query Statistics, atur Query Time Range relatif yang berakhir sedikit di masa lalu. Sebagai contoh, atur Start At relatif ke 70 detik lalu dan End Time ke 10 detik lalu. Buffer 10 detik ini membantu mencegah kehilangan data akibat penundaan pengindeksan.
-
Untuk mengatasi ketidakakuratan kueri: Di kotak dialog Query Time Range, sesuaikan Query Time Range Anda ke jendela waktu tetap, seperti 1 Menit (Time Frame), 5 Menit (Time Frame), atau 1 Jam (Time Frame). Atur Check Frequency agar sesuai dengan jendela waktu yang dipilih, misalnya 1 menit, 5 menit, atau 1 jam.
-
-
Mengutamakan ketepatan waktu: Ikuti rekomendasi ini jika Anda memerlukan peringatan segera dan dapat mentolerir kemungkinan peringatan duplikat.
-
Untuk mengatasi latensi pengindeksan data: Di kotak dialog Query Statistics, di bawah Query Time Range, geser waktu Start At relatif lebih jauh ke masa lalu, misalnya ke 70 detik lalu (relatif).
-
Untuk mengatasi ketidakakuratan kueri: Di kotak dialog Query Statistics, pastikan Query Time Range cukup lebar untuk mencakup interval sebelumnya, misalnya dengan mengaturnya ke 90 detik relatif dan mengatur Check Frequency ke 1 menit.
-
-
Mengasosiasikan hasil kueri dan analisis
Sistem peringatan Layanan Log Sederhana memperlakukan hasil kueri sebagai set dan mendukung pemantauan terkorelasi di beberapa set.
Di halaman konfigurasi, setiap kueri diidentifikasi dengan angka (0, 1, atau 2) dan mencakup editor kueri serta pengaturan rentang waktu. Kueri yang berdekatan dihubungkan dengan daftar drop-down set operations. Anda dapat menggunakan tombol pengurutan untuk mengubah urutan atau menghapus kueri. Opsi Grouped Evaluation berada di bagian bawah.
-
Layanan Log Sederhana mendukung pemantauan terkorelasi hingga tiga set.
-
Secara default, 1.000 baris pertama dari hasil kueri digunakan untuk operasi set. Jika Anda menggunakan tiga kueri dan mengatur set operation ke nilai selain No Merge, hanya 100 baris pertama dari setiap kueri yang digunakan.
-
Jika Anda menggunakan tiga set, sistem pertama-tama melakukan operasi set pada dua set pertama, lalu melakukan operasi kedua pada hasil tersebut dan set ketiga. Contohnya:
-
Set A LEFT JOIN Set B LEFT JOIN Set C: Sistem pertama-tama melakukan LEFT JOIN pada Set A dan Set B, lalu menggabungkan hasil tersebut dengan Set C menggunakan LEFT JOIN lainnya.
-
Set A JOIN Set B INNER JOIN Set C: Sistem pertama-tama melakukan JOIN pada Set A dan Set B, lalu menggabungkan hasil tersebut dengan Set C menggunakan INNER JOIN.
-
Set A LEFT EXCLUDE JOIN Set B No Merge Set C: Sistem melakukan LEFT EXCLUDE JOIN pada Set A dan Set B, dan mengabaikan Set C.
-
Daftar drop-down set operations menyediakan sembilan opsi, yang dijelaskan dalam tabel berikut.
|
Set operations |
Ilustrasi |
Deskripsi |
|
|
Kedua set tidak diasosiasikan. Set A memberikan hasil kueri, sedangkan Set B hanya berfungsi sebagai sumber variabel untuk templat notifikasi peringatan. |
|
|
None |
Menggabungkan setiap baris dari Set A dengan setiap baris dari Set B. Operasi ini biasanya digunakan untuk memfilter data guna evaluasi. |
|
|
|
Menggabungkan data dari Set B ke baris yang sesuai di Set A, menyelaraskan baris berdasarkan nama field. |
|
|
|
Hanya mengembalikan baris dari Set A yang memiliki baris yang cocok di Set B. Ini secara efektif menggunakan Set B sebagai daftar putih untuk Set A. |
|
|
|
Memperkaya Set A dengan data yang cocok dari Set B. Dalam hal ini, Set B bertindak sebagai tabel dimensi untuk Set A. |
|
|
|
Memperkaya Set B dengan data yang cocok dari Set A. Dalam hal ini, Set A bertindak sebagai tabel dimensi untuk Set B. |
|
|
|
Menggabungkan semua baris dari Set A dan Set B, memperkaya baris yang cocok dengan data dari set lainnya. |
|
|
|
Hanya mengembalikan baris dari Set A yang tidak memiliki kecocokan di Set B. Ini secara efektif menggunakan Set B sebagai blacklist untuk Set A. |
|
|
|
Hanya mengembalikan baris dari Set B yang tidak memiliki kecocokan di Set A. Ini secara efektif menggunakan Set A sebagai blacklist untuk Set B. |
No merge
-
Kebutuhan
Pantau log akses NGINX. Jika jumlah error 5xx melebihi 500 dalam periode 15 menit, peringatan dipicu. Peringatan harus mencantumkan host spesifik yang mengembalikan error.
-
Konfigurasinya sebagai berikut: kueri untuk Query and Statistics 0 adalah
status > 500 | select count(1) as cnt, dan set operation diatur ke No merge. Kueri untuk Query and Statistics 1 adalahstatus > 500 | select host, count(1) as pv group by host order by pv desc limit 5. group evaluation diatur ke No Grouping, dan trigger condition diatur ke has data, dengan kondisicnt > 500. -
Hasil
-
Hasil Query and Statistics 0
Menghitung jumlah error 5xx dalam periode 15 menit.
cnt
1234
-
Hasil Query and Statistics 1
Mengidentifikasi 5 host teratas dengan jumlah error 5xx tertinggi dalam periode 15 menit dan jumlah error masing-masing.
host
pv
host1
60
host2
55
host3
47
host4
45
host5
30
-
Hasil operasi set
Ketika set operation diatur ke No merge, operasi set mengembalikan hasil Query and Statistics 0.
-
CROSS JOIN
-
Contoh 1
-
Kebutuhan
Pantau log akses dari Object Storage Service (OSS) dan Server Load Balancer (SLB). Peringatan dipicu jika jumlah gabungan error 4xx dari OSS dan error 5xx dari SLB melebihi 1.000 dalam periode 15 menit.
-
Konfigurasi: Kueri untuk Query Statement 0 adalah
status >= 400 and status < 500 | select count(1) as pv, dan Set Operations diatur ke CROSS JOIN. Kueri untuk Query Statement 1 adalahstatus >= 500 | select count(1) as pv. Untuk aturan peringatan, Group Evaluation diatur ke Ungrouped, dan Trigger Condition diatur ke Data exists dengan kondisi($0.pv + $1.pv) > 1000. -
Hasil
-
Hasil pernyataan kueri 0
Jumlah error 4xx dari OSS dalam periode 15 menit.
pv
890
-
Hasil pernyataan kueri 1
Jumlah error 5xx dari SLB dalam periode 15 menit.
pv
567
-
Hasil operasi set
Ketika Set Operations diatur ke CROSS JOIN, hasilnya sebagai berikut:
$0.pv
$1.pv
890
567
-
-
-
Contoh tambahan
-
Hasil pernyataan kueri 0
a
b
a1
b1
a2
b2
a5
b5
-
Hasil pernyataan kueri 1
a
c
a1
c1
a3
c3
-
Hasil operasi set
Ketika Set Operations diatur ke CROSS JOIN, hasilnya sebagai berikut:
$0.a
b
$1.a
c
a1
b1
a1
c1
a1
b1
a3
c3
a2
b2
a1
c1
a2
b2
a3
c3
a5
b5
a1
c1
a5
b5
a3
c3
-
Join
-
Contoh 1
-
Kebutuhan
Pantau log akses Nginx dari dua LogStore, satu di wilayah China (Beijing) dan yang lain di wilayah China (Shanghai). Peringatan dipicu jika jumlah total host dengan lebih dari 30 error 5xx di kedua LogStore melebihi 10 dalam interval 15 menit.
-
Konfigurasinya sebagai berikut: Untuk Query Statistics 0, pernyataan kuerinya adalah
status > 500 | select host, count(*) as pv group by host having pv > 30, dan Set Operation adalah JOIN. Untuk Query Statistics 1, pernyataan kuerinya adalahstatus > 500 | select host, count(*) as pv group by host having pv > 30, Group Evaluation adalah No Grouping, dan Trigger Condition adalah has specific number of results lebih besar dari 10. -
Hasil
-
Hasil Pernyataan Kueri 0
Kueri ini mengidentifikasi host dengan lebih dari 30 error 5xx dalam periode 15 menit dan mencantumkan jumlah error masing-masing.
Host
Pv
host1
60
host2
55
host3
47
host4
45
host5
31
-
Hasil Pernyataan Kueri 1
Kueri ini mengidentifikasi host dengan lebih dari 30 error 5xx dalam periode 15 menit dan mencantumkan jumlah error masing-masing.
Host
Pv
hosta
70
hostb
45
hostc
44
hostd
42
-
Hasil operasi set
Ketika Set Operations diatur ke JOIN, hasil gabungannya adalah:
Host
Pv
host1
60
host2
55
host3
47
host4
45
host5
31
hosta
70
hostb
45
hostc
44
hostd
42
-
-
-
Contoh lain
-
Jika field hasil dari dua Pernyataan Kueri tidak cocok, operasi JOIN mengisi field yang tidak cocok dengan None.
-
Hasil Pernyataan Kueri 0
A
B
a1
b1
a2
b2
-
Hasil Pernyataan Kueri 1
B
C
b1
c1
b2
c2
-
Hasil operasi set
A
B
C
a1
b1
None
a2
b2
None
None
b1
c1
None
b2
c2
-
-
Saat menggunakan tiga Pernyataan Kueri, sistem pertama-tama melakukan operasi set pada Pernyataan Kueri 0 dan Pernyataan Kueri 1, lalu menggabungkan hasil tersebut dengan hasil dari Pernyataan Kueri 2.
-
Hasil Pernyataan Kueri 0
A
B
a1
b1
a2
b2
-
Hasil Pernyataan Kueri 1
A
B
a1
b11
a2
b22
a3
b33
-
Hasil penggabungan Pernyataan Kueri 0 dan Pernyataan Kueri 1
Hasil operasi INNER JOIN dengan kondisi $0.a == $1.a adalah:
A
$0.b
$1.b
a1
b1
b11
a2
b2
b22
-
Hasil Pernyataan Kueri 2
A
B
a3
b333
a4
b444
-
Hasil operasi set akhir
Hasil akhir operasi JOIN adalah:
CatatanNilai dari field b dalam hasil Pernyataan Kueri 2 mengisi kolom $0.b dalam hasil akhir.
A
$0.b
$1.b
a1
b1
b11
a2
b2
b22
a3
b333
None
a4
b444
None
-
-
Inner join
-
Contoh 1
-
Kebutuhan
Pantau jumlah error 5xx di bucket tertentu. Picu peringatan jika jumlah error 5xx melebihi 1.000 dalam periode 15 menit. Untuk memenuhi kebutuhan ini, Anda harus menambahkan data resource untuk memelihara daftar putih bucket.
-
Konfigurasinya sebagai berikut: Pernyataan kueri untuk Query Statement 0 adalah
status >=500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000. Set Operations diatur ke INNER JOIN dengan kondisi join$0.bucket = $1.bucket. Untuk Query Statement 1, sumber data OSS (user.test) dipilih, yang menentukan bucket bucket_03, bucket_04, bucket_05, dan bucket_06. Group Evaluation diatur ke Ungrouped, dan Trigger Condition diatur ke Data exists. -
Hasil
-
Hasil Pernyataan Kueri 0
Mengidentifikasi bucket yang memiliki lebih dari 1.000 error 5xx dalam periode 15 menit.
Bucket
Pv
bucket_01
1600
bucket_02
1550
bucket_03
1470
bucket_04
1450
-
Hasil Pernyataan Kueri 1
Data resource untuk bucket.
Bucket
Description
bucket_03
for dev team
bucket_04
for test team
bucket_05
for service team
bucket_06
for support team
-
Hasil operasi set
Ketika Set Operation diatur ke INNER JOIN dengan kondisi $0.bucket == $1.bucket, hasil operasi set adalah sebagai berikut:
Bucket
Pv
Description
bucket_03
1470
for dev team
bucket_04
1450
for test team
-
-
-
Contoh 2
-
Kebutuhan
Dua logstore, satu di wilayah China (Beijing) dan satu di wilayah China (Shanghai), menyimpan log akses Nginx. Setiap 15 menit, sistem mengkueri klien dengan lebih dari 30 error 5xx. Sistem memicu peringatan jika error 5xx terjadi di kedua wilayah dan jumlah error di wilayah China (Beijing) lebih besar daripada di wilayah China (Shanghai).
-
Konfigurasinya sebagai berikut: Pernyataan kueri untuk Query Statement 0 adalah
status >= 500 | select client_ip, count(1) as pv group by client_ip having pv > 30. Set Operations diatur ke INNER JOIN dengan kondisi join$0.client_ip = $1.client_ipdan$0.pv > $1.pv. Pernyataan kueri untuk Query Statement 1 adalahstatus >= 500 | select client_ip, count(1) as pv group by client_ip having pv > 30. Group Evaluation diatur ke Ungrouped, dan Trigger Condition diatur ke Data exists. -
Hasil
-
Hasil Pernyataan Kueri 0
Mengidentifikasi klien di wilayah China (Beijing) yang memiliki lebih dari 30 error 5xx dalam periode 15 menit dan jumlah error masing-masing.
Client ip
Pv
192.0.2.4
60
192.0.2.5
55
192.0.2.6
47
192.0.2.7
45
192.0.2.8
31
-
Hasil Pernyataan Kueri 1
Mengidentifikasi klien di wilayah China (Shanghai) yang memiliki lebih dari 30 error 5xx dalam periode 15 menit dan jumlah error masing-masing.
Client ip
Pv
192.0.2.5
70
192.0.2.6
45
192.0.2.7
44
192.0.2.8
42
192.0.2.9
42
-
Hasil operasi set
Ketika Set Operations diatur ke INNER JOIN, $0.client_ip == $1.client_ip, dan $0.pv > $1.pv, hasil operasi set adalah sebagai berikut:
Client ip
Pv
192.0.2.6
47
192.0.2.7
45
-
-
-
Contoh lain
Jika set hasil dari dua pernyataan kueri berisi field dengan nama identik yang bukan kunci gabungan, sistem secara otomatis menambahkan awalan $0. dan $1. pada nama field tersebut dalam set hasil akhir.
-
Hasil Pernyataan Kueri 0
A
B
C
D
a1
b1
c1
d1
a2
b2
c2
d2
a3
b3
c3
d3
-
Hasil Pernyataan Kueri 1
A
B
C
a1
b11
c11
a2
b22
c22
-
Hasil operasi set
Ketika Set Operation adalah INNER JOIN dan $0.a == $1.a, hasil operasi set adalah sebagai berikut:
A
$0.b
$0.c
D
$1.b
$1.c
a1
b1
c1
d1
b11
c11
a2
b2
c2
d2
b22
c22
-
LEFT JOIN
-
Hasil pernyataan kueri 0
A
B
a1
b1
a2
b2
a3
b3
-
Hasil pernyataan kueri 1
A
B
C
a1
b11
c1
a2
b22
c2
-
Hasil operasi set
Ketika Set Operations diatur ke LEFT JOIN dengan kondisi join $0.a == $1.a, hasilnya sebagai berikut:
A
$0.b
$1.b
C
a1
b1
b11
c1
a2
b2
b22
c2
a3
b3
None
None
Right join
-
Hasil Kueri 0
a
b
c
a1
b11
c1
a2
b22
c2
-
Hasil Kueri 1
a
b
a1
b1
a2
b2
a3
b3
-
Hasil operasi set
Ketika Set Operations diatur ke RIGHT JOIN dengan kondisi $0.a == $1.a, hasilnya adalah:
a
$0.b
c
$1.b
a1
b11
c1
b1
a2
b22
c2
b2
a3
NULL
NULL
b3
Full join
-
Data sumber 0
a
b
c
a1
b1
c1
a2
b2
c2
a5
b5
c3
-
Data sumber 1
a
b
d
a1
b11
d1
a2
b22
d2
a3
b33
d3
-
Hasil operasi set
Ketika Anda mengatur parameter Set Operations ke FULL JOIN dengan kondisi join $0.a == $1.a, hasilnya sebagai berikut:
a
$0.b
c
$1.b
d
a1
b1
c1
b11
d1
a2
b2
c2
b22
d2
a5
b5
c3
None
None
a3
None
None
b33
d3
LEFT EXCLUDE JOIN
-
Kebutuhan
Pantau error 5xx untuk semua bucket, kecuali yang ada di daftar hitam. Peringatan dipicu jika jumlah error melebihi 1.000 dalam periode 15 menit. Untuk melakukan ini, gunakan data resource untuk memelihara daftar hitam bucket.
-
Konfigurasinya sebagai berikut: Kueri untuk Query Statement 0 adalah
status >=500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000. set operation diatur ke LEFT EXCLUDE JOIN dengan kondisi join$0.bucket = $1.bucket. Untuk Query Statement 1, sumber data OSS adalah (user.test) dan bucket-nya adalah bucket_03 dan bucket_04. Group Evaluation diatur ke Ungrouped, dan trigger condition diatur ke data exists. -
Hasil
-
Hasil Pernyataan Kueri 0
Mengidentifikasi bucket yang memiliki lebih dari 1.000 error 5xx dalam periode 15 menit.
Bucket
Pv
bucket_01
1060
bucket_02
1055
bucket_03
1047
bucket_04
1045
-
Hasil Pernyataan Kueri 1
Data resource untuk bucket.
Bucket
Description
bucket_03
for dev team
bucket_04
for test team
-
Hasil operasi set
Ketika set operation diatur ke LEFT EXCLUDE JOIN dengan kondisi $0.bucket = $1.bucket, hasilnya sebagai berikut:
Bucket
Pv
bucket_01
1060
bucket_02
1055
-
Right exclude join
-
Kebutuhan
Pantau error 5xx untuk semua bucket yang tidak ada di daftar hitam. Sistem memicu peringatan jika jumlah error melebihi 1.000 dalam periode 15 menit. Untuk melakukan ini, tambahkan data resource untuk memelihara daftar hitam bucket.
-
Konfigurasikan pengaturan sebagai berikut: untuk Query Statement 0, pilih sumber data OSS (user.test) dan tentukan bucket_03 dan bucket_04. Atur Set Operations ke RIGHT EXCLUDE JOIN, dengan kondisi join sebagai
$0.bucket = $1.bucket. Untuk Query Statement 1, atur pernyataan kueri kestatus > 500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000. Atur Group Evaluation ke No Grouping, dan atur Trigger Condition ke Data exists. -
Hasil
-
Hasil Pernyataan Kueri 0
Mengembalikan data resource untuk bucket yang ada di daftar hitam.
Bucket
Description
bucket_03
for dev team
bucket_04
for test team
-
Hasil Pernyataan Kueri 1
Mengembalikan bucket dengan lebih dari 1.000 error 5xx dalam periode 15 menit.
Bucket
Pv
bucket_01
60
bucket_02
55
bucket_03
47
bucket_04
45
-
Hasil operasi set
Ketika Set Operations diatur ke RIGHT EXCLUDE JOIN dengan kondisi join $0.bucket = $1.bucket, hasilnya sebagai berikut:
Bucket
Pv
bucket_01
60
bucket_02
55
-
Peringatan tanpa data
Peringatan tanpa data membantu mendeteksi kehilangan data yang tidak terdeteksi selama pengumpulan data. Sebagai contoh, Anda dapat membuat aturan peringatan untuk memantau pemanfaatan CPU setiap host dan menerima notifikasi peringatan jika salah satu kondisi berikut terpenuhi:
-
Pemanfaatan CPU melebihi 95%.
-
Tidak ada data yang dikembalikan dari kueri dan analisis.
Konfigurasikan aturan peringatan sebagai berikut:
-
Query statistics: Tentukan kueri untuk menghitung pemanfaatan CPU.
* | select promql_query_range('cpu_util') from metrics limit 1000 -
Trigger Condition: Data matches the expression, value>95, Severity: Medium
Jika field value dalam hasil kueri dan analisis melebihi 95, peringatan dengan tingkat keparahan menengah dipicu.
-
Threshold of Continuous Triggers: Jumlah kali berturut-turut kondisi pemicu harus terpenuhi untuk menghasilkan peringatan.
-
No-data alert: Aktifkan sakelar no-data alert, lalu atur tingkat keparahan dan anotasi.
Saat diaktifkan, peringatan dipicu jika kueri berturut-turut yang tidak mengembalikan data melebihi ambang batas pemicu berturut-turut.
Anda dapat mengatur tingkat keparahan dan anotasi terpisah untuk peringatan tanpa data.
Halaman dikonfigurasi sebagai berikut:
Untuk grouping evaluation, pilih Automatic by label. Di bagian Add annotation, atur judul ke ${alert_name} alert triggered dan deskripsi ke ${alert_name} alert triggered. Nonaktifkan automatic annotation dan recovery notification. Di advanced settings, atur continuous trigger threshold ke 1. Aktifkan no-data alert, dan atur severity-nya ke Medium, judul anotasinya ke ${alert_name}: No data, dan deskripsinya ke No data was returned when this alert rule was evaluated.







