背景
最後のグループでの監視警報システムに関するいくつかの議論がありました！毎回印刷エラーログは、毎日のアラームが多数で、その結果、アラームにつながるため、一部の学生は偉大なアラーム音を受け取ります、貴重なアラームを見落とすことは簡単です、今のシステム・エラー・ログがあまりにも多く感じます。
ここでは、この議論のためのいくつかのアイデアがあります：
- のみ印刷する必要があり、ユーザー体験の感覚があるだけの場合には、慎重にエラーログに印刷され、コードの開発段階にする必要があります
- 人工知能の多数の方法を使用したデータは、警報を行うために警報を行うには、ノイズ低減アルゴリズムを装備します
上記の二つの考え方は、まず、開発者のための比較的高い需要、そして何度も、ユーザーエクスペリエンスの衆生かどうかを判断することは困難であり、二つ目は、業界では気持ちが不可能な、成熟したプログラムではありません。
私の考え
私たちの警報システムは、システムレベルに基づいているため、アラーム音が、私は、このような運用レベルで非常に良好な応答をタイムアウト呼び出し、特定のインターフェース呼び出し与えられている、などではなく、RPCなど、理解した理由、システムの健康、彼らは私たちは、システムの健全性の総合的な理解を持つことができないことを確認したときにアラームが生じ。私は、運用レベルではなく、監視や警報の層をすれば、状況ははるかに良いだろう、と思います。例えば、我々があれば、いくつかの比較を前年同期比秒あたりのメッセージ数を作成するには、その後、年を監視するために行われ、例えることができIMシステム、ありますいくつかの点で、メッセージの量が大幅に減少した後、警察を作成している、我々は警告を受けたときに、少なくとも、システムは、システムレベルのアラームと組み合わせ問題は、システムがすぐにどこに問題見つけることができますを確認する必要がありますA。
システムレベルの監視
システムレベルの監視、私は2つの状況に分けする必要があります理解してください。
- そのようなコーポレート・ガバナンスのサービスプラットフォームとして、自動監視を監視すべきRPCインターフェイスQPS、tp99およびその他のデータ
- このようなシステムのエラーなどデベロッパーズ・マニュアル、警告、エラーログを出力し、エラーの後、数アラームログに応じて
私はその後続け、それを判断することは困難であり、システムの最初のバージョンでは、それらの場所がエラーを戦う必要があり、システム・エラー・ログの並べ替えのために、それは長いプロセスであるべき、と思うし、唯一のオンラインおよび不合理ました調整。
ビジネスレベルの監視
運用レベルのモニタリング、二つの主な仕事があります。
- ビジネス指標を決定します
- レディ
定量化可能なビジネスメトリックを決定し、そのような広告システムの自然な流れ、およびその他の収益として、最も重要です