Cara sederhana untuk secara algoritmik mengidentifikasi lonjakan kesalahan yang direkam

Kami membutuhkan sistem peringatan dini. Saya berurusan dengan server yang diketahui memiliki masalah kinerja di bawah beban. Kesalahan dicatat dalam database bersama dengan stempel waktu. Ada beberapa langkah intervensi manual yang dapat diambil untuk mengurangi beban server, tetapi hanya jika seseorang mengetahui masalah ini ...

Dengan serangkaian waktu terjadinya kesalahan, bagaimana saya bisa mengidentifikasi awal lonjakan kesalahan (dalam waktu nyata)? Kami dapat menghitung secara berkala atau pada setiap kemunculan kesalahan.

Kami tidak peduli tentang kesalahan sesekali, tetapi tidak memiliki ambang tertentu. Saya bisa memberi tahu seseorang kapan saja, misalnya, tiga kesalahan dalam lima menit, tapi saya yakin ada cara yang lebih baik ...

Saya ingin dapat menyesuaikan sensitivitas algoritma berdasarkan umpan balik dari sysadmin. Untuk saat ini, mereka ingin itu cukup sensitif, meskipun kita tahu kita dapat mengharapkan beberapa hal positif yang salah.

Saya bukan ahli statistik, yang saya yakin sudah jelas, dan menerapkan ini harus relatif sederhana dengan alat yang ada: SQL Server dan ASP JScript old-school. Saya tidak mencari jawaban dalam kode, tetapi jika membutuhkan perangkat lunak tambahan, mungkin tidak akan bekerja untuk kita (meskipun saya menyambut solusi yang tidak praktis tetapi ideal sebagai komentar, untuk rasa ingin tahu saya sendiri).

Sudah 5 bulan sejak Anda mengajukan pertanyaan ini, dan mudah-mudahan Anda menemukan sesuatu. Saya akan membuat beberapa saran berbeda di sini, berharap Anda dapat menggunakannya di skenario lain.

Untuk kasus penggunaan Anda, saya tidak berpikir Anda perlu melihat algoritma deteksi lonjakan.

Jadi begini: Mari kita mulai dengan gambar kesalahan yang terjadi pada timeline:

Yang Anda inginkan adalah indikator numerik, "ukuran" seberapa cepat kesalahan terjadi. Dan ukuran ini harus sesuai dengan ambang batas - sysadmin Anda harus dapat menetapkan batas yang mengontrol dengan kesalahan sensitivitas apa yang berubah menjadi peringatan.

Ukur 1

Anda menyebutkan "paku", cara termudah untuk mendapatkan lonjakan adalah menggambar histogram setiap interval 20 menit:

Sysadmin Anda akan menetapkan sensitivitas berdasarkan ketinggian bar, yaitu kesalahan yang paling dapat ditoleransi dalam interval 20 menit.

(Pada titik ini Anda mungkin bertanya-tanya apakah panjang jendela 20 menit itu tidak dapat disesuaikan. Dapat, dan Anda dapat menganggap panjang jendela sebagai pendefinisian kata bersama dalam kesalahan frasa yang muncul bersama-sama .)

Apa masalah dengan metode ini untuk skenario khusus Anda? Nah, variabel Anda adalah bilangan bulat, mungkin kurang dari 3. Anda tidak akan menetapkan ambang ke 1, karena itu hanya berarti "setiap kesalahan adalah peringatan" yang tidak memerlukan algoritma. Jadi pilihan Anda untuk ambang batas akan menjadi 2 dan 3. Ini tidak memberikan sysadmin Anda banyak kontrol halus.

Ukur 2

Alih-alih menghitung kesalahan di jendela waktu, catat jumlah menit antara kesalahan saat ini dan terakhir. Ketika nilai ini menjadi terlalu kecil, itu berarti kesalahan Anda menjadi terlalu sering dan Anda perlu meningkatkan peringatan.

Sysadmin Anda mungkin akan menetapkan batas pada 10 (yaitu jika kesalahan terjadi kurang dari 10 menit, itu masalah) atau 20 menit. Mungkin 30 menit untuk sistem misi yang kurang kritis.

Ukuran ini memberikan lebih banyak fleksibilitas. Tidak seperti Measure 1, di mana ada set kecil nilai yang bisa Anda gunakan, sekarang Anda memiliki ukuran yang memberikan nilai 20-30 bagus. Karena itu sysadmin Anda akan memiliki lebih banyak ruang untuk fine-tuning.

Nasihat yang ramah

Ada cara lain untuk mendekati masalah ini. Daripada melihat frekuensi kesalahan, dimungkinkan untuk memprediksi kesalahan sebelum terjadi.

Anda menyebutkan bahwa perilaku ini terjadi pada satu server, yang diketahui memiliki masalah kinerja. Anda dapat memantau Indikator Kinerja Utama tertentu pada mesin itu, dan minta mereka memberi tahu Anda kapan kesalahan akan terjadi. Khususnya, Anda akan melihat penggunaan CPU, penggunaan memori, dan KPI yang berkaitan dengan Disk I / O. Jika penggunaan CPU Anda melampaui 80%, sistem akan melambat.

(Saya tahu Anda mengatakan Anda tidak ingin menginstal perangkat lunak apa pun, dan memang benar bahwa Anda dapat melakukan ini menggunakan PerfMon. Tetapi ada alat gratis di luar sana yang akan melakukan ini untuk Anda, seperti Nagios dan Zenoss .)

Dan untuk orang-orang yang datang ke sini berharap menemukan sesuatu tentang deteksi lonjakan dalam rangkaian waktu:

Deteksi Spike dalam Time-Series

$x_1, x_2,...$

$M_k = (1 - \alpha) M_{k-1} + \alpha x_k$

$\alpha$$x_k$

Jika nilai baru Anda telah bergerak terlalu jauh dari rata-rata bergerak, misalnya

$\frac{x_k - M_k}{M_k} > 20\%$

maka Anda memunculkan peringatan.

Rata-rata bergerak bagus saat bekerja dengan data waktu-nyata. Tapi misalkan Anda sudah memiliki banyak data dalam sebuah tabel, dan Anda hanya ingin menjalankan query SQL untuk menemukan paku.

Saya akan menyarankan:

1. Hitung nilai rata - rata deret waktu Anda
2. $\sigma$
3. $2\sigma$

Lebih banyak hal menyenangkan tentang seri waktu

1. Banyak seri waktu nyata menunjukkan perilaku siklik. Ada model yang disebut ARIMA yang membantu Anda mengekstrak siklus ini dari seri waktu Anda.

2. Rata-rata bergerak yang mempertimbangkan perilaku siklik: Holt dan Winters

+1 untuk kontrol proses Statistik, ada beberapa informasi berguna di sini di Deteksi Langkah .

Untuk SPC tidak terlalu sulit untuk menulis implementasi dari Aturan Listrik Barat atau Aturan Nelson .

Hanya membuat USP di SQL server yang akan iterate melalui kumpulan data dan ping setiap titik terhadap aturan menggunakan titik tetangganya. Mungkin jumlah kesalahan per jam (tergantung kebutuhan Anda).

Jenis ini berhubungan dengan pertanyaan yang saya posting di Stack Overflow beberapa waktu lalu (baru saja menulis jawaban cepat jika itu membantu): Grafik Kontrol Proses Statistik di SQL Server 2008 R2

Pencarian untuk algoritma deteksi online akan menjadi awal.

Informasi lebih lanjut terletak di stackoverflow: Puncak Dection dari sinyal yang diukur

Implementasi python dari rutin deteksi puncak naif dapat ditemukan di github

Anda mungkin ingin melihat kontrol proses statistik. Atau pemantauan deret waktu. Ada banyak pekerjaan dalam arah ini, dan jawaban yang optimal mungkin sangat tergantung pada apa yang sebenarnya Anda lakukan (apakah Anda perlu menyaring musiman musiman atau mingguan dalam beban sebelum mendeteksi anomali, dll.).