需要の背景
分散型の普及に伴い、システムの複雑さは徐々に増しており、異なるサービス間の相互作用により、パフォーマンスの位置付けに対するより高い要件が求められています。いずれかのノードに異常が発生すると、業務システムに損失が発生する可能性があります。リンク トレースには、優れた監視ツールが早急に必要です。
要件は次のとおりです
機能要件
- リンク追跡を要求し、障害を迅速に特定し、トラブルシューティング時間を短縮し、障害の範囲を判断します。
- リンクの各ステージの消費時間を視覚化し、パフォーマンス分析を実行して、ビジネスのボトルネックを排除します。
- サービスの依存関係を整理し、依存関係の合理性を最適化する
- システムインジケータ監視、スループット（TPS）、応答時間、エラー記録など
非機能要件:
プローブのパフォーマンスの消費: サービス コールの埋め込み自体がパフォーマンスの損失を引き起こすため、ビジネス システムのパフォーマンスに影響を与えるコンポーネントが必要になります 小規模なコードの侵入: ビジネス システムへの侵入を可能な限り最小限またはまったく行わない その他、ユーザーに対して透過的、
削減開発者の負担。
スカイウォーキング
- 序章
完全なリンク追跡ツール
使用方法は次のとおりです
ダッシュボード
ダッシュボードは Skywalking のホームページであり、サービス (APM)、データベース (データベース) などの指標を視覚化するための複数のダッシュボードを提供します。
APM
APM パネルは通常、グローバル (グローバル)、サービス (サービス)、インスタンス (インスタンス)、エンドポイント (API) の 4 つの次元に分かれており、フィルター機能を提供し、各ブロックにはいくつかのインジケーターが含まれています。
- グローバル指標:
1、サービス負荷：
1分あたりのサービスリクエスト
2. 遅いサービス:
応答が遅いサービス、応答時間、単位ミリ秒でソートされた上位 N
3、アンヘルスサービス（Apdex）：
Apdex パフォーマンス インデックス、つまりサービスの不健全な値。1 が満点です。Apdex は、設定されたしきい値と応答時間に基づいて総合的に考慮され、総応答に対する満足のいく応答時間と不満足な応答時間の比率です。平均応答時間などの従来の指標はすぐにバイアスがかかりやすくなるため、サービスに対するユーザーの満足度によって測定されます。
4、遅いエンドポイント：
遅いインターフェースの平均応答時間がミリ秒単位で並べ替えられます。
5、グローバル応答遅延：
応答時間のパーセンテージ、さまざまなパーセンテージの遅延時間、単位はミリ秒。パーセンタイル タグの意味。たとえば、p99 は 3500 ミリ秒です。これは、リクエストの 99% が 3500 ミリ秒より高速である必要があることを意味します。
6、グローバルヒートマップ：
サービス応答時間の熱分布グラフは、期間内のさまざまな応答時間の数に応じて色の濃さを示します。色が濃いほど、リクエストが多いことを示します。
- サービス（サービス）次元：**
サービス Apdex 番号:
Apdex パフォーマンス インジケーター
サービス Apdex 折れ線グラフ:
時間の経過に伴う Apdex スコア
サービスの平均応答時間:
サービスの平均応答時間
サービス応答時間のパーセンタイル:
応答遅延の割合
**成功率 (%)**数字:
リクエストの成功率
**成功率 (%) 折れ線グラフ: **一定期間にわたるリクエストの成功率
**サービス負荷 (CPM - 1 分あたりのコール数):
**1 分あたりのコール数
サービス負荷（CPM - 1分あたりの通話数）：
一定期間ごとの 1 分あたりの通話数
サービス インスタンスの負荷（CPM - 1 分あたりのコール数）：
インスタンスごとの 1 分あたりのリクエスト数
遅いサービスインスタンス：
各サービスインスタンスの平均遅延topN
サービスインスタンスの成功率：
サービスインスタンスのリクエスト成功率topN
- インスタンス (インスタンス) ディメンション:
- エンドポイント (API) ディメンション:
データベース:
トポロジー
トポロジ マップは、サービス間の依存関係を直感的に表示できるため、サービスを分類するのに非常に役立ちます。また、次の図に示すように、カスタム グループ化をサポートしています。ai-search、social-search、social -scan は、3 つのグループをカスタマイズします。サービス間の依存関係をトポロジ図を通じて直感的に示します。
さらに、トポロジ マップでは、開発フレームワーク タイプ、平均サービス応答時間、スループット、応答率、Apdex スコア、SLA 値などを含む、測定用のサービス運用情報も表示できます。
リンク追跡:
- データベース操作の詳細を表示します。
- Redis キャッシュ操作の詳細を表示します。
パフォーマンス分析：
Skywalking はパフォーマンス分析において非常に強力で、スタックベースの分析結果が提供されるため、開発者は呼び出しプロセスの各ステップで消費された時間を一目で確認できるため、目標を絞った方法で最適化できます。
パフォーマンス分析では、新しいタスクを作成することでさまざまなエンドポイントをサンプリングし、リンク追跡よりも多くのスレッド スタック情報、遅いメソッド プロンプトなど、より詳細なレポートを提供します。次に、パフォーマンス分析を実行する方法を紹介します。
- 新しいタスクの作成:
パフォーマンス分析モジュール -> 新しいタスク -> サービスの選択で、エンドポイントを入力し、時間を監視します。操作は次のとおりです。
リマインダー: 各サービスに対して同時に追加できるタスクは 1 つだけです。追加されたタスクは変更または削除できません。有効期限が切れた後にのみ自動的に削除できます。
- 実行リクエスト:
「/api/searchByWholeOcr」インターフェースに複数回アクセスし、このタスクを選択すると、以下の図に示すように、監視されたデータが表示されます。
注: 導入設定のため、複数のリクエストを連続して実行する必要があります。実行回数が少ない場合、サンプリングデータが表示されず、解析できない場合があります。
パフォーマンス分析：
上の図からわかるように、「/api/searchByWholeOcr」インターフェイスには 681 ミリ秒かかりました。詳細なスタック情報を分析すると、最も時間がかかる操作は SearchServiceImpl クラスのexecuteSearchRequest() メソッドであることがわかります。 563ms (主に ES を呼び出して全文検索を行うことによって) は、次の図に示すように有効になります。
最後に書きます
Skywaling は、特に運用環境において非常に優れたリンク追跡ツールであり、時間のかかるインターフェイスとリンク プロセスを特定する際に重要な補助的な役割を果たします。これを使用するには、少なくとも、問題を特定する方法を知るためにそれを理解する必要があります。実用品や乾物などを中心にシェアしていくアカウント「安銭魔法」です 丁寧にまとめられていて読者の役に立つと思ったら3リンクお願いします。より実用的な乾物が継続的に更新されています...
この記事はmdniceマルチプラットフォームによって公開されています