|
翻訳者 |ブガッティ 校正者 | Chonglou 当社のエンジニアリングチームの優れた点の一つは、困難な問題に対して型破りで創造的な解決策を見出す能力です。開発リーダーとして、私たちにはこれらのスキルを次世代の開発者に伝え、複雑なビジネス問題の深層に目を向け、オープンソースコミュニティの力を最大限に活用できるよう支援する責任があります。 Helios では、この考え方に基づき、最近、複雑なロジックを実績のあるオープンソース プロジェクト( Prometheus )に委任することにしました。私たちは、製品にアラート メカニズムを追加しようと努めていました。アラートは新しいものではありません。多くのソフトウェア製品が、システム/製品内のイベントをユーザーに通知するアラートを提供していますが、新しいものではないということは、課題がないということではありません。私たちは、 Prometheus (具体的には、内部管理のメンテナンスのオーバーヘッドを削減するために選択した AWS ホスト型 Prometheus )を使用してこの課題に対処しました。OpenTelemetryコレクター メトリックス パイプラインでは、すでに Prometheus を使用してアラート メカニズムを構築しており、ユーザーの製品ニーズを満たすと同時に、開発と保守にかかる時間と労力を大幅に節約しています。 この記事ではこのソリューションを紹介し、開発者の皆様が日々直面する課題について創造的に考えるきっかけになれば幸いです。私たちの経験を通して、オープンソースプロジェクトを活用することで、より効率的なソリューションを構築し、エンジニアリングチームが貴重な時間をより多くのビジネス課題の解決に費やせるようになることを願っています。 アラートメカニズムの構築：車輪の再発明は不要OpenTelemetry （ OTel ）は、開発者が分散アプリケーションからテレメトリデータを生成、収集、エクスポートするのに役立つオープンソースの可観測性フレームワークです。OTelで収集されるデータには、分散トラッキングデータ（ HTTPリクエスト、DBコール、各種通信インフラに送信されたメッセージなど）とメトリクス（ CPU使用率、メモリ消費量、 OOMイベントなど）といった様々なシグナルが含まれます。 私たちは、このデータと他のソースからのデータに基づいたアラートメカニズムの構築に着手しました。これにより、ユーザーはシステム内のイベントに基づいて条件を設定できるようになりました。例えば、 API障害、DBクエリの予想外の遅延、Lambdaエラー（OOM）などに関するアラートを受信でき、通知の粒度と頻度を希望に応じて設定できます。 前述のように、多くのソフトウェア製品では、アプリケーション内で発生するイベントやその他の重要なビジネスKPIについてユーザーが常に情報を入手できるように、アラートメカニズムを提供する必要があります。これは一般的な機能ですが、実装は依然として複雑です。 このソリューションによって以下の3 つの目標が達成されることを期待しています。 1.分散追跡データに基づいてアラートをシームレスに実装します(手間をかけずに! ) 2.すべてのコンテンツをOTel データ モデルにネイティブにします。 3.迅速な市場参入 そこで、オープンソースツールに目を向け、 PrometheusのAlerts Managerモジュールを活用しました。Prometheusは、アプリケーションとインフラストラクチャのパフォーマンスと健全性を追跡するために設計された、監視とアラートのためのオープンソースの業界標準です。Prometheusは様々なソースからメトリクスを収集し、データの分析と可視化のための柔軟なクエリ言語を提供します。OTelメトリクスを収集するための最も一般的なバックエンドの一つであり、私たちのバックエンドには既にメトリクス収集をサポートするPrometheusが搭載されていました。 私たちは、Prometheusのようなオープンソースツールに頼ってこの作業を行っています。なぜなら、こうしたソリューションは、長年にわたり、数多くのユースケースに対応するためにソリューションを微調整・修正してきた経験を持つ、多くの優秀で経験豊富な開発者によって構築されているからです。彼らは、現場で起こりうるあらゆる、あるいは少なくともほとんどの落とし穴に遭遇してきました。アラートメカニズムの設計は社内で議論され、Prometheusを使用するというアイデアは、チームメンバーの過去の経験に基づいて生まれました。 図 1.分散トレース データに基づいてアラートを設定する– Prometheus Alert Manager を使用。このタブはHelios Sandbox でアクセスできます。 図 2.この例では、 Prometheus で Helios Sandbox からのさまざまなアラートを構成する方法を示しています。 詳細な議論: アラートメカニズムをどのように構築するか?Prometheus を導入したので、アラート メカニズムの追加を始めました。まずはトレーシング アラート、もっと正確に言うとトレーシングの基本モジュールであるspan ( HTTP リクエストや DB クエリの結果など)から始めたいと考えていました。Prometheus はメトリックアラートを提供していますが、私たちにはトレーシング アラートが必要でした。トレーシングからのデータはそのままではPrometheusに届きません。データ モデルに変換する必要があります。そのため、Prometheus が実際に span アラートを発行するには、 span を取得してメトリックに変換し、それによってトリガーされるアラートを構成する必要がありました。トレーシング( span )がアラート条件( DB クエリに 5 秒以上かかるなど)に一致すると、span をPrometheusメトリックに変換します。 Prometheusモデルは私たちの目標と合致しています。各イベントについて、OTelから生データを取得し、それをPrometheusを通じてメトリックとしてフィードします。これにより、特定の運用エラーが5分以内に3回以上発生した場合、アラートを発動する必要があると判断できます。 私たちはそこで止まりませんでした。Heliosのユーザーにとっての大きなメリットは、分散トレースデータから単一のメトリックへ、そしてまたメトリックから特定のトレースへ移動できることです。これは、メトリックのコンテキストが維持されるためです。ユーザーはトレースベースのアラートを設定し、アラートからE2Eストリームに戻って迅速な根本原因分析を行うことができます。これにより、ユーザーはアプリケーションのパフォーマンスと健全性に関する究極の可視性を得ることができます。利用可能なコンテキスト（測定データに基づく）により、ユーザーはアプリケーションストリーム内の問題やボトルネックを容易に特定し、迅速なトラブルシューティングと平均解決時間（ MTTR ）の短縮を実現できます。 追跡ベースのアラート私たちのアラート メカニズムでは、サービスAからサービス B への失敗したHTTP リクエスト、特定のコレクションに対する MongoDB クエリに 500 ミリ秒以上かかる、Lambda 関数の呼び出しが失敗するなど、トレース データに基づいて定義できる動作に対してアラートを発行するように設計されたシステムを構築しました。 上記の各項目は、標準的なOtel属性（ HTTPステータスコード、スパン期間など）に基づくスパンフィルターとして記述できます。これらのフィルターに加えて、様々な集計ロジック（例：期間Y内に一致するスパンの数がXに達した場合など）をサポートしています。したがって、アラート定義は基本的にフィルターと集計ロジックの組み合わせになります。 実装は3 つの部分から構成されます。 1.アラートごとに一意のメトリックを定義します。 2.集約ロジックをPromQL クエリに変換し、アラート定義を使用して Prometheus Alert Manager を更新します。 3.アラーム フィルターに一致するSPANをPrometheus 時系列に継続的に変換します。これにより、アラーム集約定義に準拠し、アラームがトリガーされます。 私たちは、可能な限り OTel のネイティブ性を維持したいと考えており、次のようにOTel コレクターに基づくアラート パイプラインを構築しました。 1. Kafka レシーバーを使用して、 「ファーストライン」コレクター(クライアントのOTel SDKからデータを受信する)から送信された OTLP 形式のスパンを処理するアラート マッチャー コレクターを作成します。 2. カフカ 受信機は（追跡パイプラインの一部として）アラート マッチャーに接続されます。 プロセッサは、クライアントが Helios UI で構成したフィルターを読み込み、それに応じてスパンをフィルタリングする、私たちが構築したカスタム ハンドラーです。 3.関連するスパンをフィルタリングした後、それらをPrometheusにメトリックとしてエクスポートする必要があります。そのために、 Otelコレクターの比較的新しい機能であるコネクタを実装しました。このコネクタにより、異なるタイプのパイプライン（この場合はトラッキングとメトリック）を接続できます。スパンからメトリックへのコネクタは、一致する各スパンを以下のプロパティを持つメトリックに変換します。
4. Prometheus Remote Writer Exporter を使用して、マネージド AWS Prometheus にメトリクスをエクスポートします。 Prometheus はほぼ即座に効果を発揮しますが、 WSによって管理されるため、いくつかの詳細に注意する必要があります(たとえば、アラートを報告するにはSNS-SQS しか使用できません) 。 警告から根本原因までトレースベースのアラートは既にありますが、迅速な根本原因分析を確実に行うために、アラート発生時に完全なアプリケーションコンテキストも提供したいと考えています。アラート発生後、Prometheus にアラート定義の時系列（顧客IDとアラート定義IDの組み合わせ）をクエリし、アラートクエリのインスタンスとしてメトリクスのリストを取得します。各メトリクスには、一致するスパンとトレースIDがあります。たとえば、アラートが長時間実行される DBクエリ用に設定されている場合、サンプルトレースには、トレース全体に加えてクエリ自体が含まれます。 全体のメカニズムは次のようになります。 図3. Helios アラート メカニズム アーキテクチャ – クライアントの OpenTelemetry SDK レポートからSlack のアラートまで。 図4. Helios Alerts Collectorアーキテクチャ– トラッキングパイプラインからメトリクスパイプラインへの変換 Prometheusアラートをアプローチとして使用することの利点と欠点アラートメカニズムに対する私たちのアプローチは、OTelトラッキングデータをPrometheusメトリックに変換し、Prometheus Alert Managerを活用することです。これにより、独自のアラートバックエンドを実装する必要がなくなります。この方法のメリットとデメリットをいくつか見ていきましょう。 多くの利点があるにもかかわらず、オープンソース ツールやチームが制御できない外部コンポーネントを使用すると、本質的に「ブラックボックス」になるため、場合によっては問題が発生することがあります。また、 APIと統合メカニズムがアーキテクチャに適合しない場合は、さらに作業が必要になったり、完全にブロックされたりすることもあります。 例を見てみましょう。Prometheusでは、 API呼び出しを使ってYAML定義を更新し、アラートを設定できます。ただし、ここではAWSを使用しています... マネージドPrometheusでは、 AWS APIコールを介してこれらの定義を更新できますが、Prometheusを直接更新するのではなく、実際の更新は定期的な同期中に行われます。動作上の問題（最初の更新がまだ同期されていないためにアラート定義が更新されないなど）を防ぐには、更新をカプセル化する独自の定期同期メカニズムを実装する必要があります。このソリューションをゼロから構築した場合、このメカニズムを完全に制御でき、いつでも更新できます。しかし、 AWSマネージドPrometheusではこの制御ができないため、追加の同期メカニズムを構築する必要があります。 さらに、ソリューションの一部の機能を調整したい場合もあるでしょう。例えば、今回のケースでは、アラート送信時により詳細なデータを提供したい場合などです。これは面倒な作業になる可能性があります。例えば、受信時に直接トリガーされるアラート（ Prometheusによって報告されるアラートのペイロードの一部として）の一致するスパンIDを取得することは、デフォルトでは機能しないため、Prometheusに別のAPI呼び出しを送信してクエリを実行する必要があり、これによりわずかなオーバーヘッドが発生します。 これらの課題にもかかわらず、 Prometheusに依存せずにこの機能を自社で実装するのははるかに困難だと認識していました。アラートロジックをゼロから開発する場合、設計（異なるコンポーネントやストレージなど）、実装、そして場合によってはバグ修正とフィードバックの繰り返しが必要になるため、すぐに使えるソリューションを用意することで、開発時間を大幅に短縮できました。 機能豊富で成熟したオープンソースツールであるPrometheusのおかげで、私たちの不安は大幅に軽減されました。将来のユースケースもこのツールでサポートされることが分かっており、本番環境にも対応しており、多くのユーザーが微調整を加えてくれるでしょう。これは私たちにとって大きな安心感となり、時間の節約にもなります。将来私たちが思いつくアラートロジックは、Prometheusに既に実装されている可能性が高いからです。もし私たちが独自に構築しようとすれば、設計上の選択ミスによって設計を破棄したり、新しいユースケースに対応するためにひどいコードを書いたりすることになるかもしれません。 さらに、私たちのアプローチの利点の一つは、すべてのコンテンツをOTelデータモデルにネイティブ化することです。つまり、OTelコレクターは、スパム（失敗したHTTPリクエストなど）であろうとメトリック（高いCPU使用率など）であろうと、すべてのコンテンツをフィルタリング、処理、エクスポート、受信します。 結論はHeliosでのアラートメカニズムの開発は容易ではありませんが、創造的な思考とオープンソースのコラボレーションにより、効率的かつスムーズにタスクを達成しました。OTel と Prometheus を活用することで、安定したターンアラウンドタイムで洗練されたアラートメカニズムを実現しました。アラートとメトリクスを相関させる方法を発見したため、アラートを取得してメトリクスに変換する際に、アラートをビジネスロジックに再接続する方法が明確になりました。 この経験が、開発者の皆様がオープンソースを活用して複雑な問題を解決するきっかけとなるだけでなく、ユーザーの皆様にとっても貴重なパートナーとなることを願っています。イノベーションは重要ですが、イノベーションそのものだけでなく、ユーザーの皆様にも影響を与え、エクスペリエンスを向上させたいと考えています。皆様にもぜひご期待ください。 元のタイトル: OpenTelemetry トレースを Prometheus メトリックと組み合わせて強力なアラートメカニズムを構築する方法、著者: Ran Nozik |
