広告業務システムのデータ転送ステーション「ログセンター - リアルタイムサービスモニタリング」

広告業務システムのデータ転送ステーション「ログセンター - リアルタイムサービスモニタリング」

ログセンター

ログ センターは、広告リンク内のデータの転送ステーションです。フルリンク サービスの堅牢性をリアルタイムで監視し、決済、エクスポージャー、インタラクション、その他の監視とレポートをサポートします。バックリンクにおいて極めて重要な役割を果たします。

ログセンターには複数の機能モジュールが含まれており、その機能特性に応じて、リアルタイムサービス監視、監視[エクスポージャ/インタラクション/Win]レポート、転送決済の3種類に分類できます。

リアルタイムのサービス監視 - リンク前のログ分析

現在、ADX リンクには複数のマイクロサービス/モジュールが含まれています。各サービスのデータ量の問題、システム全体の堅牢性、ビジネスデータの成長ポイントの分析、細部に潜むさまざまなペインポイントの隠れた危険性などの問題を解決するために、前者のリンクは、トレース ログに基づいてメトリクスをリアルタイムで監視するために、収束および統合されたデータ インジケーターが形成されます。

もちろん、このモジュールの背後には、コスト/リソースの圧縮などの追加の要因があります。

ログ収束手段 - 「外科的開口部」

広告、レコメンデーション、検索の上位 3 つの複合ビジネスの「広告ビジネス システム詳細」のADX アーキテクチャ モジュール図によると、リンクにはフロントエンド、トラフィック エンジン、入札、ポートレート、配信などの5 つの主要なサービスが含まれていますエンジン... モジュール。
記事の最後にある公式アカウントに注目してください

では、これらのモジュールのログ データを統合し、統合されたログ トレースを形成するにはどうすればよいでしょうか?

監視システムの構築に慣れている学生は問題ないと思うかもしれませんが、古典的な EFK\Prometheus\Graphite などには成熟したホイールが多数あります。はい、よく知らない学生は、クラウド ネイティブ コミュニティの監視シリーズ「監視コンポーネントの比較」を参照すると簡単に理解できます。

Tao Liが最初だったので、ここに直接計画があります。

上記のデータフロー図では、5 つのモジュール/マイクロサービスが Docker ミラーリング方式に基づいて独立してデプロイされています [Docker 関連情報については、Docker エンジニアリング環境の構築と導入を参照してください]。ログ データは、次の形式で透過的に送信されます。同時に、ログデータはカップリング用の pvId /uuid の形式で透過的に送信されます。

結合により、pv 粒度のトレース ログが形成されます。現時点では、データ フローの前部に小さな開口部を開きます。これがデータを外部に流す唯一の方法です。

注: resp の形式は最適ではなく、コストは非常に低いですが、帯域幅と IO プレッシャーが発生しやすくなります。[ADX
システムは無視できますが、これはその特定の展開方法に関連しています。サービスのパフォーマンスを極限まで圧縮するために、各サービスは同じマシン上に展開されます (詳細については、次の記事を参照してください) ;
代替として、agent\SDK\Filebeat などの他の形式を使用できます。

臨床手術を行うのと同じように、喉の開口部からリンク全体のトレースデータが取得されます。ADX データの規模はビジネスの成長と正の相関があるため、トラフィックが 2 倍になるという特殊な状況を考慮する必要があることを意味します。したがって、ミドルウェアに依存すると、データを Kafka に注ぎ込み、それを下流の分析サービスと Hive ストレージに転送する、
「山を削り、谷を埋める」という奇跡的な効果が得られます。

• Hive ストレージが属する非同期リンクは、Flink\Spark などのデータ マイニング手法の介入を通じて OLAP 分析を実行し、ビジネス上の意思決定をさらに支援します。
• 分析サービスは同期リンクに属し、Graphite\Prometheus\Zabbix\Open-Falcon などのコンポーネントの優れたデータ収集、集約、視覚化およびその他の多次元機能により、ビジネスとサービスの両方をカバーするリアルタイム監視が構築されています。協力してビジネスの進歩を支援します。

メトリクスベースのログ分析 - Prometheus と Graphite

メトリクスはサービスの監視可能な方向の 3 つの要素の 1 つで、その他は Log\Trace です。[可観測性の方向性について詳しくは、Cloud Native Hot Topics｜可観測性とは]

まず、技術選定についてですが、なぜ数多くのコンポーネントの中から Prometheus と Graphite を選んだのかというと、主に以下のようなプロセスになります。

• 市場調査
  • 完全な調査方法とソリューションが必要であり、オープンソース製品や競合製品、あるいは業界の大手企業の設計なども可能です。
• 独自の条件と組み合わせて
  • 内面を徹底的に見つめ、自分の長所と短所を理解してください。研究結果を組み合わせて、最適なものを見つけてください
• 二次開発・カスタマイズ
  • 着地と同時に現状の計画の問題点を状況と合わせて検討し、補完開発や方向性開発を行う
• …
  記事末尾の公式アカウントにご注目ください

元のソリューションには Prometheus コンポーネントしかありませんでしたが、2 つの問題点がありました。[Prometheus コンポーネントの詳細については、「Prometheus?」を参照してください。古代ギリシャのタイタンの神？エイリアン？いいえ、新世代のエンタープライズ レベルの監視コンポーネント、Prometheus]

• Prometheus インジケーターのデータ精度は 100% ではありません
  • ここでの解決策は、Graphite + Prometheus デュアル モニタリング リンクを使用してデータ サポートを提供することです。もちろん、データの冗長性が伴いますが、コアインデックスはデュアルサンプリングの形式であり、通常のインデックスは Prometheus 独自のものです。
• Prometheus の再起動/停止メトリクスは、最初は 0 から計算されます。
  • ここではそれを回避するためにホットスタンバイ方式を採用しています。

監視サービスが自身を監視し、通常のサービスよりも堅牢である方法

監視サービスとしての主な責任は、他のサービスを監視することです。

この前提の下では、監視サービスには暗黙の要件があります。つまり、通常のサービスよりも堅牢である必要があります。オブジェクトサービスが停止される前に監視サービスが停止するとは言えません。

したがって、強力な高可用性を確保するために、監視サービスには、拡張性が高くパフォーマンスの高い一連のアーキテクチャ設計、柔軟で独立した拡張および縮小メカニズム、さらに 2 つのダウングレード スキームと一連のセルフサービス監視が備えられています。

拡張性とパフォーマンスに優れたアーキテクチャ設計

サービス注文インスタンスでは、オーケストレーションにマルチコルーチンの同時実行性が使用されます。データはメモリ チャネルに挿入され、複数のコルーチンが動的に同時に呼び出され、ビジネスの集計とデータ インジケーターの出力が実行されます。マシンの性能を活かしながらダイナミックな拡張特性を満たします。

信頼できる 2 セットのダウングレード スキーム

トラフィックのピーク時にサービスがビジネス データを継続的に出力できるようにするために、2 つのダウングレード スキームが設計されています。

• トラフィックサンプリング
  • 最大収容力では、80%、40%、20%、10%の勾配比サンプリングを一度に実行し、データ量がオーバーロードする場合は、2番目のプランに入ります。
• 大きくても小さくてもいけない
  • ファネル モデルを使用してトラフィックをフィルタリングすると、一部のコア データの通常の出力が保証されるだけであり、他のすべてのデータ タスクは放棄されます。

サービス自体を監視する

サービスが監視されている間、サービス データがクリーンで正しいことを確認するために、独自のサービス データ チェック ロジックを設計しました。

デュアルリンクモードについては前述しましたが、GraphtieとPrometheusの2つの異なるリンクデータを当てはめることで、サービス自体のデータ状況を判断することができます。

柔軟かつ自律的な伸縮機構

サービスは分散方式で展開され、サービス トラフィック開始しきい値、サービス終了失敗率、サービス終了 P90 しきい値の 3 つの指標の連携モードにより、拡張と縮小のタイミングのデータ ベースが提供されます。

• 冗長性: スタンバイ ノードと拡張ノードの間のマシン スケールの冗長性は約 1.05 です。

記事の最後にある公式アカウントに注目してください

形成監視効果

データ インジケーターは集約された後、データ ソース モードで Grafana コンポーネントに埋め込まれ、リアルタイムで多様な多次元の視覚化効果を提供します。[Grafana の詳細は 5 分で確認でき、Prometheus + Grafana に基づいたリアルタイム監視システムを構築できます]

サポートされているビジネス次元: 露出量/割合、材料充填量/割合、配信エンジンの候補タイプの量/割合...; サービス次元: QPS/失敗率/SLA/HttpCode 分布...

露光データ転送決済

暴露データは ADX のさらなる懸念事項であり、そのデータ フローは、収益に関わる通信と決済の重要な橋渡しとなっています。

---

続きの記事をご覧ください!

推奨書籍：
広告・レコメンド・検索の3大複合ビジネス「広告業務システム詳細」
広告業務システムの過去と未来の継承「メッセージセンター」
広告業務システムデータ転送ステーション「ログセンター - リアルタイムサービス監視」
広告ビジネスシステムのデータブリッジ - 「ログセンター - 露出データ転送と決済」広告ビジネスシステムのコアチャネル -
「ログセンター - S2S監視とレポート」広告ビジネスシステムの補助意思決定
- 「」広告ビジネスシステム「AB実験プラットフォーム」
フレームワークPrecipitation —— 「データ消費型サービスフレームワーク」のSmart Fuse
広告ビジネスシステム —— 「スマートフローコントロール」のアジャイルデリバリー
広告ビジネスシステム —— 「Dockerコンテナベースのデプロイメント」
広告ビジネスシステムの業務接続—「PDB – 広告配信[数量と価格]」

---

3 行のコードで実現 - リンク リストの反転...
Kafka の高スループット、高パフォーマンスのコア テクノロジと最適なアプリケーション シナリオ...
HTTPS がデータ送信のセキュリティを確保する方法 - TLS プロトコル...
リアルタイムの構築Prometheus + Grafana に基づく監視システムを 5 分で完了...