この質問をしてから5か月が経ちました。ここでいくつかの異なる提案を行います。他のシナリオでそれらを使用することを期待しています。
ユースケースでは、スパイク検出アルゴリズムを調べる必要はないと思います。
だからここに行きます:タイムラインで発生するエラーの写真から始めましょう:
必要なのは、エラーが発生する速さの「尺度」である数値インジケータです。また、この方法はしきい値設定に適している必要があります。システム管理者は、どの感度エラーが警告に変わるかを制御する制限を設定できる必要があります。
対策1
「スパイク」について言及しましたが、スパイクを取得する最も簡単な方法は、20分間隔でヒストグラムを描画することです。
システム管理者は、バーの高さに基づいて感度を設定します。つまり、20分間隔で許容できるほとんどのエラーです。
(この時点で、20分のウィンドウの長さを調整できないのではないかと思うかもしれません。ウィンドウの長さは、一緒に表示されるフレーズエラーで単語を一緒に定義すると考えることができます。)
特定のシナリオでこの方法の問題は何ですか?変数はおそらく3未満の整数です。しきい値を1に設定するのは、アルゴリズムを必要としない「すべてのエラーは警告」を意味するためです。したがって、しきい値の選択は2と3になります。これは、システム管理者にきめ細かな制御を提供しません。
対策2
時間枠でエラーをカウントする代わりに、現在のエラーと最後のエラーの間の分数を追跡します。この値が小さすぎると、エラーが頻繁に発生しているため、警告を発する必要があります。
システム管理者は、おそらく制限を10(つまり、エラーが10分以内に発生している場合は問題)または20分に設定します。ミッションクリティカルではないシステムの場合は、おそらく30分です。
この方法により、柔軟性が向上します。使用できる値の小さなセットがあったメジャー1とは異なり、20〜30の適切な値を提供するメジャーができました。そのため、システム管理者は微調整の範囲が広がります。
フレンドリーアドバイス
この問題に対処する別の方法があります。エラーの頻度を調べるのではなく、エラーが発生する前に予測することが可能です。
この現象は、パフォーマンスの問題があることが知られている単一のサーバーで発生していると述べました。そのマシンの特定の重要業績評価指標を監視し、エラーが発生する時期を知らせることができます。具体的には、CPU使用率、メモリ使用率、およびディスクI / Oに関連するKPIを調べます。CPU使用率が80%を超えると、システムの速度が低下します。
(ソフトウェアをインストールしたくないと言ったことは知っていますが、PerfMonを使用してこれを実行できるのは事実です。しかし、NagiosやZenossなど、これを行う無料のツールがあります。)
そして、時系列でスパイク検出について何かを見つけたいと思ってここに来た人々のために:
時系列でのスパイク検出
バツ1、x2、。。。
Mk= (1 - α )Mk − 1+ α のxk
αバツk
たとえば、新しい値が移動平均から離れすぎている場合
バツk− MkMk> 20%
その後、警告を発します。
移動平均は、リアルタイムデータを扱う場合に便利です。しかし、すでにテーブルに大量のデータがあり、それに対してSQLクエリを実行してスパイクを検出したいとします。
私はお勧めします:
- 時系列の平均値を計算する
- 標準偏差 計算するσ
- 2つのσ
時系列に関するより楽しいもの
多くの実世界の時系列は、周期的な動作を示します。時系列からこれらのサイクルを抽出するのに役立つARIMAというモデルがあります。
周期的な振る舞いを考慮した移動平均:Holt and Winters