ビジネスより多くのセクターライン、任意のアプリケーションを実行しているラインは、さまざまな理由で問題となることがあります。例えば、運用レベル、先週より減少受注、流れの急激な低下、技術的な問題システムは、インタフェースの応答が遅く、ERRORが表示されます。カナダの運輸事業は、1つの明白な機能は、サービスの多くのサプライヤーに依存しているので、我々も異常である、というように、コール・プロバイダー・インターフェースに焦点を当てる必要があります。
大きなトラフィックの下、各事業ラインは、できるだけ早く警察によって発見することができます作成し、問題を解決するため、サービス業務システムの品質を向上させるために、我々は統一された監視警報システムを構築することを決めました。一方でシステムが異常なタイムリーなソリューションを初めてに発生することが判明している。一方で、できるだけ早期に、いくつかの潜在的な問題を見つけ、今、このようなシステムのビジネスロジックの通常動作に影響を与えませんが、いくつかは、より時間のかかる操作されていると長くしています速やかに治療しなければ、このような問題は、ビジネスの将来の発展に影響を与える可能性があります。
本論文では、位置決めスズメバチの巣大企業トラフィック監視警報システム、全体的なアーキテクチャの設計だけでなく、実践コースで着陸ピットステップでの経験のいくつかを説明しています。
アーキテクチャの設計と実装
私たちは、警報システムを監視する、主に以下の3つの機能があります。
1.共通のコンポーネント自動警報：一般に、統一制御フレームワークレベルを容易にするために、（などRPC、HTTPなど）ビジネス・システムを使用する各フレームアセンブリのデフォルトのアラームルールを作成します。
2.カスタムアラームサービス：埋没サービスインジケータによるサービスは、各特定のオペレーティング・システム・モジュールの状態を記録し、運用するためにカスタムフィールドを開発します。
3.問題を迅速に見つける：問題は、発見の目的ではない解決するための鍵です。私たちは、アラームメッセージの完了後に一目に、開発者がすぐに解決するために問題場所を、見つけることができるように、送信されることを願っています。
この文脈において、図警報センターと主要なプロセスの全体的なアーキテクチャは、以下のように：
縦方向のビューは、右サービスシステムで、カフカアラームセンターを残しています。
警報中心のアーキテクチャは3層に分割され、上層は主に問い合わせ、保守アラームログアラームルールを完了するために、Web管理ページで、中間層は、アラーム中心のコアであり、底部層は、データ層です。アクセス警報センターを実行するためにMES-クライアント・スターターのjarパッケージを介してサービスシステムと呼ばれます。
私たちは5つのモジュールに警報センターに作業することができます：
1.データ収集
私たちは、指標のいくつかは、システムが記録し、アップロードするために我々の注意を実行している収集システムの問題を報告する方法を見つけるためにインデックスを使用します。モードは、その上のログ、UDPをアップロードし、することができます。
まず、データ収集モジュール、我々は、ホイールを作成する繰り返しますが、（MESに直接基づいていないスズメバチの巣ビッグデータ分析ツールの内側に達成するために）、このための主な考慮事項いくつかの理由：データ分析とアラームのデータソースへの1つは似ています。2アラームにも簡単にアクセスでき、開発コストの多くを保存します。
それをキャプチャする必要があり、特定の指標は何ですか？単一の大型輸送ビジネスシナリオユーザーを要求するために、例えば、リンク全体HTTP要求を含むことができる、ダボコール、SQLオペレーションセンターはまた、検証、変換、割当ておよび他のセクターを含むことができます。上下セット、それはクラスやメソッドの多くが参加する、それは、収集を行うには、各メソッド呼び出し、クラスごとに不可能で呼び出し、時間のかかるだけでなく、意味がありません。
できるだけ多くを発見するためにコストを最小限にするために、我々は統合制御フレームワークレベルを達成するために使用するようにHTTP、SQL、RPCフレームワークダボとして、システムコンポーネントの一部である自動RBI共通のフレームワークを選択しました。
ビジネスのために、各事業の焦点のためのシステムインジケータが異なっています。別のビジネス開発者のためのさまざまな指標に焦点を当てる必要があり、そのような成功の支払いやその他の注文数として、APIの開発者は、さまざまなビジネスモジュールやシステムのその定義は、指標に焦点を当てる必要があります、手動で埋もれたシステムを介して提供することができます。
2.データストレージ
動的インデックスまでのデータ収集のために、私たちは主に二つの理由に基づいて、保存するためにElasticsearchを使用することにしました：
一つは、ダイナミックなフィールドが格納されます。各業務システムの問題の指標が異なっていてもよく、各ミドルウェアの焦点が異なるので、各フィールドの埋め込みどのフィールドタイプは、埋め込みストアに動的にフィールドを追加するデータベースを必要とする、予測不可能です。フィールドのタイプを定義する必要があり、データを自動的に追加することができるドットの埋め込み挿入全くElasticsearchありません。
第二に、それはデータの膨大な量の試練に耐えることができます。埋め込みポイントの複数を有することになる各成分を介してモニタに各ユーザ要求は、データの量が非常に大きいです。Elasticsearchは、データストレージの大容量をサポートすることができ、それは拡張性の良いレベルを持っています。
また、Elasticsearchも迅速な実行回数、合計、平均、他のタスクのための集計計算をサポートしています。
3.アラームルール
埋もれたデータを使用すると、アラームルールのセットを定義する必要がある次のステップは、我々はそれが予め設定した閾値を超えて確認するために、特定のチェックを定量化するためのデータの問題を懸念しています。これは、全体のアラーム中心的な問題の中で最も複雑で、最も核心です。
全体的なアーキテクチャ図に先立って、コア部は、定期的なタスクを実行することによって、システムの動作を駆動する「ルール実行エンジン」です。まず、実行エンジンが力のすべてのルールを照会し、次いで濾過し、重合がElasticsearchにルールの説明、及び、以前に比較して設定されたルールを用いて得られた閾値計算結果を重合させる最後にステップに従って計算される条件が送信された場合アラームメッセージ。
このプロセスは、いくつかの重要な技術のポイントが含まれます。
1）タイミングタスク
システムの可用性を確保するために、単一障害点を回避するためには、全体のアラーム監視システム障害を起こし、我々のサイクルのための「分」、一回毎分セットアラームルールを行いました。ここでは、簡単な操作でタスクを起動および停止、分散タスクスケジューリングのための弾性仕事です。
2）。「3段」アラームルール
私たちは、定義されたアラームルール「は、フィルタリング、集約、比較、」これらの三つの段階で達成します。例えば、サービスA埋没エラーログと想定されます。
app_name=B is_error=false warn_msg=aa datetime=2019-04-01 11:12:00
app_name=A is_error=false datetime=2019-04-02 12:12:00
app_name=A is_error=true error_msg=bb datetime=2019-04-02 15:12:00
app_name=A is_error=true error_msg=bb datetime=2019-04-02 16:12:09
次のようにアラームルールが定義されています。
-
フィルター：いくつかの条件によって設定されたデータを識別しようとしています。このような問題のために、フィルタ条件があってもよい：APP_NAME = A、is_error = TRUE 「2019-14-02 16時12分00秒」と「2019-14-02夜4時13分00秒」の間に、日時。
-
重合：ステップは、一意の値を与えるために、事前に定義されたタイプの重合数、平均、合計、最大などのデータセットを計算します。上記の問題のために、我々は、エラーが表示される計算することを選択した回数をカウントします。
-
比較：前のステップで得られた結果を、設定された閾値と比較されます。
いくつかの複雑なアラーム条件のために、このような故障率と言及した私たちのトップの流れの変動など、それを達成するためにどのようにすべきですか？
問題があると仮定：Aがサービスの失敗率が80％を超え、総要求量が100より大きい呼び出す場合、アラーム通知が送信されます。
失敗の数と合計数が前で呼ばれることもある一方で私たちは、数が実際に故障の総故障率によって分割されていることを知っている「フィルタ+重合」実際にはこの問題は、以下の式で記述することができるので、邪魔になります：
failedCount/totalCount>0.8&&totalCount>100
我々は次に、上記式のエンジン高速EL式が評価される使用、閾値比較で得られた結果を設定することができます。
3）自動的にデフォルトのアラームルールを作成し、
Redisの中にキャッシュしながら一般的に使用されるダボ、HTTPなどの複数のクラスやメソッドが関与するように、開発者は、管理インターフェースアラームルールを介して維持することができるため、アラームルールは、MySQLデータベースに格納されています。
ダボに例えば、ApplicationModelにダボを介してプロバイダと消費者の全てを取得する第一、情報及びルールは、これらのクラスおよびメソッド（ルールテンプレートは、情報を取り除くために、特定のクラス規則及び方法として理解することができる）の組み合わせをテンプレート、Aの作成この方法のルールの下でクラス。
たとえば：;偽の状態、アラームなどの10以上の数のBダボサービスコールインターフェース/列車/ grabTicket /分の範囲ダボインタフェース/順序/ 1秒以上、アラームの分平均応答時間当たりの外部に設けられたサービスをgetOrderById。
4.アラーム動作
アラームは、次の2つの方法アラームの動作を中心に発生することがトリガされた後、現在のルール：
-
Eメールアラーム：担当の異なる人々の開発を通じて、アラームの種類ごとに、初めてシステム異常の通知を関係者。
-
マイクロチャネルのアラーム：サプリメントとしてアラームメッセージ。
その後、我々は、開発者がすぐに新機能の研究開発に関わるそれほど苦労せずに、警察の問題の両方を識別することができるように、そのようなさまざまなレベルの問題のために異なるアラームモードを使用したとして、警察の戦術の挙動を改善していきます。
位置決め補助
開発者は迅速なツールを見つけやすくするために、我々はヒットサンプリング機能を設計し。
まず第一に、私はリンクの削減を達成するために、kibanaのビュー・ログに直接ジャンプするためのリンクを提供し、抽出されたtracer_idルールを打ちます。
第二に、開発者はまた、彼は注意を望んで自分のフィールドを設定することができ、その後、私はまた、抽出され、このフィールドの値よ、問題はあなたはそれがどこにあるか見て一目ことができます。
技術では、利用者がドル以上の中括弧内入力することができますヒットサンプリングフィールドを定義します。例えば、我々は特定のベンダーのインタフェース動作に焦点を当てるかもしれませんが、フィールドサンプリングは、図の上半分が低いヒットする可能性があります。警報メッセージは、以下に示されている開発者に送信された最終的なメッセージを交換することによって達成FreeMarkerの、ESに対応する値にクエリで抽出したフィールドの内部で、送信する必要がある場合、システム開発者は、迅速に場所問題を知っています。
段付ピット経験と進化の方向
大規模な輸送サービスの監視警報システムは、0-1からのプロセスでビルドし、開発プロセス全体にわたり、我々のような、多くの問題に遭遇しました：メモリ即座に再生、もっとゆっくりES、頻繁に全GC、以下の特定上記の点のために最適化された経験について話しています。
段付ピット
1.メモリはすぐに再生します
すべてのシステムは、それが限界に耐えなければならないので、それは、洪水時にダムを傍受することができます必要があります。
同じ警報センター、外受信カフカにおける最大のボトルネックポイントがログを埋没MES上を通過直面警報センター。初期の最後の行は、インスタント埋設ログにつながるため、業務システムの異常の大多数に一度登場し演奏システムメモリの問題が生じ、アラームセンターをヒット。
解決策は、各ノードの最大容量、優れたシステム保護を評価することです。この問題に対処するために、我々は、カフカがプルモデルを使用してメッセージを消費するので、そのようなRateLimiterグアバの使用など、引っ張って良いの速度を制御するだけで、制限方法を取ります：
messageHandler = (message) -> {
RateLimiter messageRateLimiter = RateLimiter.create(20000);
final double acquireTime = messageRateLimiter.acquire();
/**
save..
*/
}2. ESもっとゆっくり
MESは、より大きなログデータの移行を促進すると同時に、性能を保証するためには、高温と低温のポイントを持っているので、以下のように、我々は、アプリケーションの粒状性指数ES +月を作成しました：
3.頻繁にフル・GC
我们使用 Logback 作为日志框架，为了能够搜集到 ERROR 和 WARN 日志，自定义了一个 Appender。如果想搜集 Spring 容器启动之前（此时 TalarmLogbackAppender 还未初始化）的日志, Logback 的一个扩展 jar 包中的 DelegatingLogbackAppender 提供了一种缓存的方式，内存泄漏就出在这个缓存的地方。
正常情况系统启动起来之后，ApplicationContextHolder 中的 Spring 上下文不为空，会自动从缓存里面把日志取出来。但是如果因为种种原因没有初始化这个类 ApplicationContextHolder，日志会在缓存中越积越多，最终导致频繁的 Full GC。
解决办法：
1. 保证 ApplicationContextHolder 的初始化
2. DelegatingLogbackAppender 有三种模式：OFF SOFT ON ，如果需要打开，尽量使用 SOFT模式，这时候缓存被存储在一个由 SoftReference 包装的列表中，在系统内存不足的时候，可以被垃圾回收器回收掉。
近期规划
目前这个系统还有一些不完善的地方，也是未来的一些规划：
-
更易用：提供更多的使用帮助提示，帮助开发人员快速熟悉系统。
-
更多报警维度：目前支持 HTTP，SQL， Dubbo 组件的自动报警，后续会陆续支持 MQ，Redis 定时任务等等。
-
图形化展示：将埋点数据通过图形的方式展示出来，可以更直观地展示出系统的运行情况，同时也有助于开发人员对于系统阈值的设置。
小结
总结起来，大交通业务监控报警系统架构有以下几个特点：
-
支持灵活的报警规则配置，丰富的筛选逻辑
-
自动添加常用组件的报警，Dubbo、HTTP 自动接入报警
-
接入简单，接入 MES 的系统都可以快速接入使用
操作と生産ラインの維持管理は、主に3つのことを実行します。見つけて、問題を解決し、問題を特定します。、システムに異常が発生した場合に問題を特定、つまり、できるだけ早くシステムの担当者に通知します。見つけて、問題を解決し、より良い、より正確に、開発者のためのシステムを修復迅速に必要な情報を提供することです。
測位警報システムは、チェーンの最初のステップであるべきで、入口には、オンラインでの問題を解決することを意味します。データバックシステム（トレーサーリンクなど）、流通システム及びその他の有機タンデムの展開とコアデータを通じてつながる、大幅オンライン問題解決の効率を改善し、生産の護衛のためのより良いことができます。
何をするにしても、私たちの究極の目標は、サービスの質を向上させるために一つだけです。
著者：ソンチュンテスト、スズメバチの巣の大きなトラフィックプラットフォームシニアリサーチエンジニア。
（タイトル図出典：ネットワーク）
スズメバチの巣の技術を見て、あなたはより多くを知りたいです