クラウドネイティブゲートウェイの可観測性の包括的な実践

可観測性

可観測性とは、システム、アプリケーション、またはサービスの動作ステータス、パフォーマンス、動作を効果的に監視、理解、デバッグできる能力を指します。

システムアーキテクチャが単一アーキテクチャからクラスタアーキテクチャ、そしてマイクロサービスアーキテクチャへと進化するにつれて、ビジネスはより大規模かつ複雑になってきています。クラウドネイティブ時代の文脈では、マイクロサービス、サービスメッシュ、サーバーレスなどの新しいテクノロジーの出現により、ビジネスの複雑さは個人の限界を急速に超えており、可観測性は最新の分散型システムの設計と運用において重要な要素となっています。システムの重要性はますます高まっています。従来の監視および警告方法は、多くの場合、システムのいくつかの基本的な指標のみに焦点を当てており、より詳細な情報やコンテキストを無視しています。可観測性の目標は、包括的なデータの収集と分析を通じて、より深く包括的な洞察を提供し、運用と開発者がシステムの動作をより深く理解し、問題のトラブルシューティングを行い、パフォーマンスのボトルネックを予測し、障害に対応できるようにすることです。

ログ、メトリクス、分散トレースは、可観測性の 3 つの柱として知られています。

ロギング:ロギングは、システムの動作中に生成されるイベントと情報の記録です。アプリケーションログを記録することで、システムの動作状況やエラー、例外情報を把握でき、トラブルシューティングやシステム分析が容易になります。一般的なログシステムには、ELK (Elasticsearch、Logstash、Kibana) や Splunk などが含まれます。
メトリック:メトリックは、システムのさまざまな側面のパフォーマンスを測定するために使用されるメトリックです。インジケーターデータを収集および記録することで、CPU 使用率、メモリ使用量、リクエストの応答時間などを含むシステムの動作をリアルタイムで監視できます。一般的に使用されるインジケーターシステムには、Prometheus や InfluxDB などがあります。
分散トレーシング:分散トレーシングは、分散システムにおけるリクエストのパスとパフォーマンスを追跡および監視するために使用されるテクノロジーです。システム内の異なるコンポーネント間のリクエスト間で一意の識別子を渡すことにより、リクエストのプロセスと消費時間を追跡でき、システムパフォーマンスの分析と最適化に役立ちます。一般的な分散トレースシステムには、Zipkin や Apache Skywalking などがあります。

包括的かつ正確な可観測性を提供することで、システム開発および運用保守担当者は、より迅速に問題を発見し、システムの動作を理解し、対応する最適化と意思決定を行うことができるため、システムのパフォーマンス、安定性、信頼性が向上します。

クラウドネイティブゲートウェイ監視可能システム

MSE クラウドネイティブゲートウェイは、Alibaba Cloud の既存のクラウド製品 (ログサービス SLS、アプリケーションリアルタイム監視サービス ARMS) とオープンソースソフトウェアの優れたサポートに依存して、豊富な監視可能なシステムを構築し、ユーザーに強力なログ、監視、リンクを提供します。追跡およびアラーム機能は次のとおりです。

ゲートウェイの可観測性機能は、顧客が製品の信頼性エクスペリエンスを構築できるように支援し、顧客に障害を検出して特定する機能を提供し、障害の発生を減らし、障害の影響を軽減することに特化しています。ゲートウェイの監視およびアラーム管理機能に基づいて、障害を発見してタイムリーに顧客に通知することができ、監視とログに基づいて障害を迅速に特定でき、リンク追跡に基づいてすべてのリンク障害の根本原因のトラブルシューティングを行うことができます。リクエスト呼び出しに基づいて実現できます。

クラウドネイティブゲートウェイの観察可能な実践

プロセスの概要

この記事は、読者が障害検出と障害位置特定におけるゲートウェイの可観測性の機能を体験できるように、以下の図でマークされている機能モジュールから開始します。

全体的なプロセスを次の図に示します。

ユーザーはゲートウェイからアラームを受信します
ユーザーはプロメテウスの監視をチェックして、問題のあるルートとサービスを見つけます。
ユーザーは、SLS ログを表示して、より詳細なエラー情報を取得できます。
ユーザーはリンクを通じてトラブルシューティングの根本原因を追跡します

テスト環境アーキテクチャの概要

この記事では、ACK クラスターに一連の Springboot サービスをデプロイしますが、呼び出し関係は上図のようになり、Spring SVC 4-2 がクラッシュしました。ゲートウェイ経由で ACK クラスターにアクセスし、次のようにルートを作成します。

テストプロセス中、ゲートウェイは次の 3 つのリクエストを通じてアクセスされます。

通常のリクエストの場合、ゲートウェイは httpbin にルーティングします。
ゲートウェイで不正なリクエストが返されました。この記事では、ルートにヒットできないリクエストを使用しています。
上流サービスが不正なリクエストを返した後、ゲートウェイは Spring SVC 1 にルーティングします。

このとき、ゲートウェイのエラー率が大幅に増加します。

障害の発見と位置特定のプロセス

アラーム戦略により障害を迅速に発見

まず、ゲートウェイのアラームポリシーを構成し、ゲートウェイインスタンスの粒度でアラームルールと通知ポリシーを設定します。この記事では、電話やテキストメッセージなどに加えて電子メール通知を使用します。アラームポリシーの設定例を次の図に示します。

次の電子メールメッセージを通じて、ゲートウェイに障害があることがわかります。

Arms Prometheus を通じて問題を監視し、最初に特定します

次に、「ゲートウェイ監視分析」→「ビジネス監視」→「グローバルダッシュボード」のエラー情報概要セクションを確認してください。現在の監視情報は次のとおりです。

図の内容から以下の情報が得られます。

「ゲートウェイ詳細障害率」ダッシュボードでは、ゲートウェイの全体的な障害率がアップストリームサービスの障害率よりも高くなります。これは、一部のリクエストがゲートウェイでエラーコードを返し、一部のリクエストがアップストリームサービスでエラーコードを返すことを意味します。。
「ルート粒度障害率」ダッシュボードでは、ルート名が「spring」のルートのみの障害率が 0 ではないことがわかります。
「Upstream Service Granularity Failure Rate」ダッシュボードでは、サービス名「springboot-svc-1.app-system.svc.cluster.local」のサービス障害率のみが 0 ではないことがわかります。

図中の「ルーティングリクエスト失敗ランキング」または「上流サービスリクエスト失敗ランキング」のルート名またはサービス名をクリックすると、ルートまたはサービスの詳細情報が表示されます。

経路名「spring」の経路監視情報は以下の図のとおりです。

サービス名「springboot-svc-1.app-system.svc.cluster.local」のサービス監視情報は以下の図のようになります。

上の図は、誤ったルートとサービスによって返されたエラーコードが 5xx であることを示しています。この時点で、問題は最初に特定されています。上流サービス「springboot-svc-1.app-system.svc.cluster.local」が指摘していました。「春」というルートで「何かが間違っています。

ただし、解決する必要がある問題がまだ 2 つあります。

不正なリクエストがゲートウェイで返される原因は何ですか?
サービス「springboot-svc-1.app-system.svc.cluster.local」のエラーの原因は何ですか?

SLS ゲートウェイのログから詳細情報を取得する

次に、ゲートウェイログセンターの SLS ログからさらに詳細な情報を取得します。

まず、response_code をクリックすると、クエリリクエストが自動的に生成されます。この期間中のゲートウェイの応答コードは 200、404、500 の 3 つだけであることがわかります。ゲートウェイのトラブルシューティングページで、応答コードを入力して、エラーコードの考えられる原因を表示します。

404 応答コードが返されるのは、ルートがヒットしていないためであることがわかります。同様に、応答コードが 500 の場合、次の図に示すように、対応するルーティング名とサービス名が表示されます。

トラブルシューティングツールを使用すると、エラーの原因がバックエンドサービスであることがわかります。

これまでのところ、サービス「springboot-svc-1.app-system.svc.cluster.local」のエラーの根本原因は何なのかという疑問が 1 つだけ残っています。

Arms xtrace リンクトレースによるコールチェーンの分析

リンクトレーシングテクノロジの助けを借りて、より詳細なエラー情報を取得できます。簡単な構成だけで、ゲートウェイを Arms xtrace に接続できます。

ACK クラスター上の Java アプリケーションは、ドキュメント「Installing Probes for Container Services Kubernetes Edition Java Applications [1]」に従って構成されます。

SLS ログで不正なリクエストのトレース ID を見つけ、そのトレース ID に基づいてリンク追跡ページで対応する呼び出しリンクを検索して、呼び出しリンクエラーの根本原因を分析します。

リンクトレースの結果から判断すると、障害の根本原因は springboot-svc-4-2 サービスエラーであり、この時点で完全な障害の検出と障害の特定が完了しました。

要約する

クラウドネイティブゲートウェイの可観測性による障害発見と障害位置の実際のプロセスでは、最初にゲートウェイのアラームポリシーを通じて障害がユーザーに通知され、次にアームが提供するプロメテウス監視サービスを通じて障害のあるルートとサービスが最初に特定されました。 SLS ログサービスによって提供されるゲートウェイの構造化ログがクエリおよび分析され、いくつかのエラーがクライアントリクエストパスエラーによって引き起こされていることが判明しました。最後に、サービスコールリンクがリンクトレースによって分析され、サービスコールの根本原因が特定されました。障害が正常に特定されました。

関連リンク：

[1] Java アプリケーションのコンテナサービス Kubernetes バージョンのプローブをインストールする

https://help.aliyun.com/zh/arms/application-monitoring/getting-started/install-arms-agent-for-java-applications-deployed-in-ack?spm=a2c4g.11186623.0.i6#arms- cs-k8s-java

著者: ユウ・チェン

クリックして今すぐクラウド製品を無料で試し、クラウドでの実践的な取り組みを始めましょう!

元のリンク

この記事は Alibaba Cloud のオリジナルコンテンツであり、許可なく複製することはできません。