記録されたエラーの急増をアルゴリズムで識別する簡単な方法


29

早期警告システムが必要です。負荷がかかるとパフォーマンスの問題が発生することがわかっているサーバーを扱っています。エラーは、タイムスタンプとともにデータベースに記録されます。サーバーの負荷を軽減するために実行できる手動介入手順がいくつかありますが、誰かが問題を認識している場合のみです...

エラーが発生した一連の時間を考えると、エラーの急増の始まりを(リアルタイムで)どうやって特定できますか?定期的に、またはエラーが発生するたびに計算できます。

偶発的なエラーについては気にしませんが、特定のしきい値はありません。たとえば、5分間で3つのエラーが発生したときはいつでも誰かに通知できますが、もっと良い方法があるはずです...

sysadminsからのフィードバックに基づいてアルゴリズムの感度を調整できるようにしたいと思います。現時点では、ある程度の誤検知が予想されることはわかっていますが、彼らはかなり敏感であることを望んでいます。

私は統計学者ではありませんが、これは明らかであり、既存のツールであるSQL Serverと旧式のASP JScriptを使用してこれを実装するのは比較的簡単である必要があります。コードで答えを探しているわけではありませんが、追加のソフトウェアが必要な場合、おそらく機能しません(ただし、非現実的で理想的なソリューションをコメントとして歓迎しますが、私自身の好奇心のためです)。


1
これは人々にとって有用だったようで、タイトルはそのままにしておきますが、「スパイク」は誤解を招くと思います。実際に探していたのは、変曲点または相対的な増加です。
dbenton

回答:


44

この質問をしてから5か月が経ちました。ここでいくつかの異なる提案を行います。他のシナリオでそれらを使用することを期待しています。

ユースケースでは、スパイク検出アルゴリズムを調べる必要はないと思います。

だからここに行きます:タイムラインで発生するエラーの写真から始めましょう:

エラーグラフ

必要なのは、エラーが発生する速さの「尺度」である数値インジケータです。また、この方法はしきい値設定に適している必要があります。システム管理者は、どの感度エラーが警告に変わるを制御する制限を設定できる必要があります。

対策1

「スパイク」について言及しましたが、スパイクを取得する最も簡単な方法は、20分間隔でヒストグラムを描画することです。

エラーヒストグラム

システム管理者は、バーの高さに基づいて感度を設定します。つまり、20分間隔で許容できるほとんどのエラーです。

(この時点で、20分のウィンドウの長さを調整できないのではないかと思うかもしれません。ウィンドウの長さは、一緒に表示されるフレーズエラーで単語を一緒に定義すると考えることができます。)

特定のシナリオでこの方法の問題は何ですか?変数はおそらく3未満の整数です。しきい値を1に設定するのは、アルゴリズムを必要としない「すべてのエラーは警告」を意味するためです。したがって、しきい値の選択は2と3になります。これは、システム管理者にきめ細かな制御を提供しません。

対策2

時間枠でエラーをカウントする代わりに、現在のエラーと最後のエラーの間の分数を追跡します。この値が小さすぎると、エラーが頻繁に発生しているため、警告を発する必要があります。

時差

システム管理者は、おそらく制限を10(つまり、エラーが10分以内に発生している場合は問題)または20分に設定します。ミッションクリティカルではないシステムの場合は、おそらく30分です。

この方法により、柔軟性が向上します。使用できる値の小さなセットがあったメジャー1とは異なり、20〜30の適切な値を提供するメジャーができました。そのため、システム管理者は微調整の範囲が広がります。

フレンドリーアドバイス

この問題に対処する別の方法があります。エラーの頻度を調べるのではなく、エラーが発生する前に予測することが可能です。

この現象は、パフォーマンスの問題があることが知られている単一のサーバーで発生していると述べました。そのマシンの特定の重要業績評価指標を監視し、エラーが発生する時期を知らせることができます。具体的には、CPU使用率、メモリ使用率、およびディスクI / Oに関連するKPIを調べます。CPU使用率が80%を超えると、システムの速度が低下します。

(ソフトウェアをインストールしたくないと言ったことは知っていますが、PerfMonを使用してこれを実行できるのは事実です。しかし、NagiosZenossなど、これを行う無料のツールがあります。)

そして、時系列でスパイク検出について何かを見つけたいと思ってここに来た人々のために:

時系列でのスパイク検出

バツ1バツ2

Mk=1αMk1+αバツk

αバツk

たとえば、新しい値が移動平均から離れすぎている場合

バツkMkMk>20

その後、警告を発します。

移動平均は、リアルタイムデータを扱う場合に便利です。しかし、すでにテーブルに大量のデータがあり、それに対してSQLクエリを実行してスパイクを検出したいとします。

私はお勧めします:

  1. 時系列の平均値を計算する
  2. 標準偏差 計算するσ
  3. 2σ

時系列に関するより楽しいもの

  1. 多くの実世界の時系列は、周期的な動作を示します。時系列からこれらのサイクルを抽出するのに役立つARIMAというモデルがあります。

  2. 周期的な振る舞いを考慮した移動平均:Holt and Winters


徹底的かつ教育的な答えをありがとう。最終的に、各エラーをデータベースに記録し、最後のX(5分で解決)分のエラー数を返すストアドプロシージャを作成しました。その数がしきい値Yを超えていた場合、警告メールが送信されました。満足するまで実験によりしきい値を調整しました。私がそれをやり遂げている場合、エラー間の時間をカウントするというあなたの提案を取り入れて、粒度を大きくします。
dbenton

8
殿堂の答え、拍手。これに賛成するためだけにこのコミュニティに参加しました。
-wesanyer

3

統計的プロセス制御のための+1、ここでいくつかの有用な情報がステップ検出にあります。

SPCの場合、Western Electric RulesまたはNelson Rulesの実装を作成するのはそれほど難しくありません。

SQLサーバーでUSPを作成して、データセットを反復処理し、隣接するポイントを使用してルールに対して各ポイントをpingします。1時間ごとにエラーの数を合計することもできます(必要に応じて)。


この種の問題は、しばらく前にStack Overflowに投稿した質問に関連しています(役立つ場合は簡単な回答を書いただけです):SQL Server 2008 R2の統計的プロセス管理チャート


2

オンライン検出アルゴリズムの検索が始まりです。

stackoverflowにある詳細情報:測定信号のピーク検出

単純なピーク検出ルーチンのpython実装は、githubにあります。


私はオンライン検出アルゴリズムを検索し、ほとんどが私の頭上にある学術論文を見つけました。彼らは答えを保持するかもしれませんが、私の個人的な「単純な」テストに合格しません。間違っている場合は修正しますが、ピーク検出アルゴリズムを探しているとは思わない。エラーがピークに達した後、定義上、最悪の問題を改善する機会を逃したようです。「スパイク」の使用が混乱を招いた場合は申し訳ありません。エラーの継続的な増加を予測するか、大きなステップアップを特定する必要があると思います。
-dbenton

1

統計的なプロセス制御を見ることもできます。または時系列監視。この方向には多くの作業があり、最適な答えはおそらくあなたが何をしているかに大きく依存します(異常などを検出する前に、負荷の年間または毎週の季節性を除外する必要があります)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.