サーバーの1つで24時間年中無休で実行されるWindowsサービスがあります。
最近は外部の会社と繋がっていて、その会社はかなり落ち込んでいます。
このサービスのエラーログ内で最後の1分間に25個のエラーが発生したときに、基本的に監視するものを設定する必要があります。
テーブルを作成し、ログに記録されているときにこれらのエラーをテーブルに挿入してから、tsqlクエリを介して最後の1分間に25が発生したかどうかをチェックするものを設定する必要があると思いますか？（その後、電子メールを送信するか、サポートのためにダッシュボード監視ページを更新します）
本当に私の質問は、誰かがこれよりも良いアイデアを持っているかどうかです。過去に誰かがこれよりも良いことをしたに違いありません。ログから直接読み込もうとしたことは一度もないと思います。多分それはより良いルートでしょう。
どんなアイデアの方向性もこれに大いに感謝します。ありがとう。
Windowsサービスが定期的に呼び出す外部WebAPIにも同様の問題があります。
私の解決策は、NLogを使用してテキストログファイルにエラーを書き込み、サービス自体に失敗した失敗の数のカウンターを保持することでした。カウンターが構成可能なしきい値を超えた場合、エラーエントリではなくクリティカルエントリをNLogに書き込み、クリティカルイベントが発生したときに運用チームの何人かの人々が取得するエイリアスを電子メールで送信するようにNLogを構成します。
「直前の25エラー」セマンティクスを厳密に実装する必要がある場合は、メモリ内に制約された（最大25アイテムまでの）キューにエラーを書き込むことができます。キューの長さが25に達した場合は、キューの最初のアイテムが最後の1分以内にあるかどうかを確認してください。その場合は、重大なエラーをログに書き込みます。
ロギングは楽しいです。：/
基本的に、オプションは次のとおりです。
データベースサーバーにログインする-利点：他の場所から簡単に読み取ることができます。短所：データベースサーバーが必要です。プロジェクトにまだ含まれていない場合は、苦痛かもしれません。また、ネットワーク接続に問題がある場合、ロギングは失敗します。
イベントログに記録する-利点：ローカルでの書き込みが高速です。正しいユーザー権限でリモートで読み取ることができます。短所：これは多くのクエリを実行することになり、イベントログはそのために正確に作成されません。
ファイルにログを記録する-利点：書き込みが非常に高速です。短所：リモートコードにアクセスするには、多くの権限設定が必要です。破損/紛失/削除などの可能性があります。
System CenterOperationsManagerなどの追加のソフトウェアを使用します。利点：これはまさにそのために構築されたタイプのものです。短所：コスト/セットアップ。
それらは私の好みの順序です。