メインコンテンツへスキップ
ランタンホーム

Splunk Lantern
  • CXone Expertによる機械翻訳

マイクロサービスにおける問題のデバッグ

  1. 最後の更新
    2025年3月11日
  2. PDFとして保存

エンジニアリングチームは、収益を生み出すマイクロサービスベースのアプリケーションの効果的な開発とパフォーマンスを確保する必要があります。計画的または計画外の変更によって問題が発生した場合、これらのチームはそれが重要な顧客セグメントのエクスペリエンスやその他の主要なビジネス指標にどのように影響するかを知る必要がありますが、ほとんどの場合、監視ソリューションではそのような可視性を提供できません。その結果、問題を特定して修正することは、時間がかかり困難なプロセスになります。

エンジニアは、平均レイテンシやエラー総数など、集約されたテレメトリに頼ることがよくあります。集約されたテレメトリでは、重要な顧客セグメントに特有のパフォーマンス問題は、アプリケーションの他の部分から流入する大量のデータに埋もれてしまいます。たとえば、全体の平均レイテンシーは許容できるかもしれませんが、組織が iOS アプリからのレイテンシーを気にしていて、そのレイテンシーが高い場合、問題は平均化されてしまうため、SRE はこの問題に気づきません。

さらに、集約されたテレメトリデータとそれぞれのアラートは、多くの場合、アプリケーションのゴールデンシグナル（遅延、トラフィック、エラー、飽和など）またはインフラストラクチャメトリクス（メモリやCPU使用率など）にのみ関連付けられます。テレメトリデータを主要なビジネス指標に結び付けなければ、アラートに優先順位を付けるのは非常に困難です。

どうすればできる Splunk platform 、 Splunk Infrastructure Monitoring 、および Splunk Application Performance Monitoring マイクロサービスの問題のデバッグを手伝ってくれる?

サービスの問題に関する詳細で正確なアラートを受け取る

開発者は、サービス内の問題の検出と切り分けを改善するために、カスタムメトリクスを設定することがよくあります。指標が詳細できめ細かくなればなるほど、開発者が問題を理解しやすくなります。詳細なメトリクスを大規模に扱うことは困難です。Splunk ソフトウェアのメトリクスエンジンは、大規模なデプロイメント向けにゼロから設計されています。開発者は以下を使用できます。 SignalFlow 受信するアラートが正確であることを確認するために、独自のアラートをプログラムし、騒々しいビジネス変動からのシグナルをスムーズ化できます。と SLO モニタリング これにより、開発者は自社のサービスが SLA に違反するリスクにさらされた場合に、よりプロアクティブなアラートを受け取ることができます。

主要ワークフローのパフォーマンスを監視

と ビジネスワークフロー エンジニアは、チェックアウト、ログインなど、バックエンドで実行される主要な機能に合わせて、マイクロサービスを自由に組み合わせてグループ化できます。ワークフローが作成されると、エンジニアはサービスマップをフィルタリングしてそのワークフローのパフォーマンスを表示し、パフォーマンスが低下した場合はアラートを設定できます。

問題の原因となっているアプリケーション、インフラストラクチャ、またはビジネスロジックを特定

OpenTelemetry を使用すれば、エンジニアは自分のサービスに任意のタグ (場所、コードバージョン、Kubernetes クラスタなどのビジネス属性またはロジック属性に関連する) をコーディングできます。ポイント・アンド・クリックのインターフェースを使うと、そのタグを使ってトラフィックをフィルタリングしたり、表示したりできます。 Tag Spotlight これにより、共通の属性に基づいてさまざまなトレースがグループ化されます。次に、視覚的に表現して、各トレースグループのエラーとレイテンシーを示します。このグローバルビューにより、エンジニアは問題のあるトレースに共通する部分をすぐに特定できるため、問題の原因をより簡単に特定できます。

エンジニアが顧客からの苦情など、特定の問題を他の情報源から知った場合、次のことが可能になります。 トレースアナライザー すべてのトレースからその問題に関連するトレースだけを検索し、ウォーターフォールビューを掘り下げて問題をより深く理解します。

サービスごとに統一されたテレメトリと可視性を実現

Splunk Observability Cloud サービス内の問題をデバッグするのに必要なすべてのテレメトリデータをまとめます。Splunk には、インフラストラクチャダッシュボードに加えて、すぐに使用できる RED メトリクス (レート、エラー、期間) が用意されています。各サービスについて、 サービス中心のビュー には、エンジニアがその特定のサービスに必要なすべての関連パフォーマンスデータが含まれた、すぐに使えるダッシュボードが用意されています。

それ以上に、 関連コンテンツ コンテキストを維持したまま、さまざまなテレメトリタイプをワンクリックで切り替えることができます。たとえば、トレースを表示する場合、関連コンテンツはそのトレースに関連するすべてのログを表示し、スパンを表示すると、関連コンテンツにはそのスパンを実行している Kubernetes ノードのメトリックが表示されます。

サービス内の根本原因を正確に診断

を通じて Splunk Infrastructure Monitoring エンジニアは、インフラストラクチャ (ホストのメモリ不足など) やネットワークが原因で発生する問題を理解できます。その一環として、 Kubernetes ナビゲーター Kubernetes クラスタ、ポッド、およびホストのパフォーマンスが低下する原因となるように設計されています。

の範囲内 ウォーターフォールビュー エンジニアは、上流と下流のサービスが自社のサービスに及ぼす影響を理解でき、データベースクエリのパフォーマンスが低いことも特定できます。そして、 AlwaysOn Profiling コードの各行がどれだけのメモリと CPU を消費しているか (Java、.NET、Node.js) を確認して、問題のあるコードを特定できます。

からのログを使用する Splunk platform 高度なトラブルシューティングのユースケース用

Splunk ログオブザーバーコネクトは、関連するログを以下から自動的に取得します。 Splunk platform エンジニアリングチームが 1 つのベンダーに 1 回ログを送信するだけで、そのログを複数のユースケースに使用できるようになります。ダッシュボードのログは、表示しているメトリクス、インフラストラクチャ、トレースのコンテキストに応じたログをチームに提供し、問題の根本原因を簡単に理解できるようにします。

前回の楽器

各ベンダーが独自のインストルメンテーションを必要とするため、開発者はオブザーバビリティベンダーの変更をためらうことがよくあります。 オープンテレメトリ はインストルメンテーションのデファクト・オープン・スタンダードであり、 Splunk Observability Cloud オープンテレメトリーネイティブです。と Splunk Observability Cloud 開発者は、OpenTelemetry でコードをインストルメントした後は、ツールを変更したり、新しいアプリケーションを構築したりするときに、再インストゥルメントする必要なく、データを任意のオブザーバビリティベンダーに送信できるので安心できます。

アーキテクチャに関係なく、アプリケーションを包括的に把握できます

一部のビジネストランザクションはマイクロサービスと3層アプリケーションの組み合わせに依存していますが、ほとんどのオブザーバビリティツールはどちらか一方のアーキテクチャに最適化されています。そのため、このような環境で問題のトラブルシューティングを行うには、多くのメンタルコンテキストの切り替えが必要になります。は Splunk platform Splunk ログオブザーバーコネクトとともに、以下のコンテキストを共有できます。 Splunk Observability Cloud (マイクロサービス向けに最適化) と Splunk AppDynamics (3 層アプリケーション向けに最適化) により、開発者は単一のソリューションでマイクロサービスと 3 層アプリケーションの両方にまたがる問題をデバッグできます。

ユースケースガイダンス