このワークショップの目的は、Splunk Observability Cloud プラットフォームの以下のコンポーネントを設定するための基本的な手順を説明することです
また、サンプルJavaアプリケーション（Spring PetClinic）のクローン（ダウンロード）方法、およびアプリケーションのコンパイル、パッケージ化、実行方法についても説明します。
アプリケーションが起動して実行されると、Splunk APM 製品で使用されるJava 2.x向けの自動ディスカバリーおよび設定機能により、メトリクス、トレース、ログが即座に表示されるようになります。
その後、Splunk OpenTelemetry Javascript Libraries (RUM) を使用してPetClinicのエンドユーザーインターフェース（アプリケーションがレンダリングするHTMLページ）を計装します。これにより、エンドユーザーが実行するすべてのクリックやページ読み込みに対してRUMトレースが生成されます。
最後に、PetClinicアプリケーションログへのトレースメタデータの自動インジェクションによって生成されたログを確認します。
2222 へのアウトバウンドSSHアクセス8083 へのアウトバウンドHTTPアクセスbash シェルおよび vi/vim エディタの基本的な知識
Splunk OpenTelemetry Collectorは、インフラストラクチャとアプリケーションの計装における中核コンポーネントです。その役割は以下のデータを収集して送信することです
Splunk IMワークショップを完了している場合は、続行する前にKubernetesで実行中のCollectorを削除してください。以下のコマンドを実行して削除できます
EC2インスタンスには、古いバージョンのCollectorがすでにインストールされている場合があります。Collectorをアンインストールするには、以下のコマンドを実行してください
インスタンスが正しく設定されていることを確認するために、このワークショップに必要な環境変数が正しく設定されているか確認する必要があります。ターミナルで以下のコマンドを実行してください
出力で、以下のすべての環境変数が存在し、値が設定されていることを確認してください。不足している場合は、インストラクターに連絡してください
これでCollectorのインストールに進むことができます。インストールスクリプトには、いくつかの追加パラメータが渡されます
--with-instrumentation - SplunkディストリビューションのOpenTelemetry Javaからエージェントをインストールします。これにより、PetClinic Javaアプリケーションの起動時に自動的にロードされます。設定は不要です！--deployment-environment - リソース属性 deployment.environment を指定された値に設定します。これはUIでビューをフィルタリングするために使用されます。--enable-profiler - Javaアプリケーションのプロファイラを有効にします。これによりアプリケーションのCPUプロファイルが生成されます。--enable-profiler-memory - Javaアプリケーションのプロファイラを有効にします。これによりアプリケーションのメモリプロファイルが生成されます。--enable-metrics - Micrometerメトリクスのエクスポートを有効にします--hec-token - Collectorが使用するHECトークンを設定します--hec-url - Collectorが使用するHEC URLを設定します次に、Collectorにパッチを適用して、AWSインスタンスIDではなくインスタンスのホスト名を公開するようにします。これにより、UIでのデータのフィルタリングが容易になります
agent_config.yaml にパッチを適用したら、Collectorを再起動する必要があります
インストールが完了したら、Hosts with agent installed ダッシュボードに移動して、ホストからのデータを確認できます。Dashboards → Hosts with agent installed の順に移動してください。
ダッシュボードフィルタを使用して host.name を選択し、ワークショップインスタンスのホスト名を入力または選択してください（これはターミナルセッションのコマンドプロンプトから取得できます）。ホストのデータが流れていることを確認したら、APMコンポーネントの作業を開始する準備が整いました。
APMをセットアップするために最初に必要なのは…そう、アプリケーションです。この演習では、Spring PetClinicアプリケーションを使用します。これは、Springフレームワーク（Springboot）で構築された非常に人気のあるサンプルJavaアプリケーションです。
まず、PetClinicのGitHubリポジトリをクローンし、その後アプリケーションのコンパイル、ビルド、パッケージ化、テストを行います
spring-petclinic ディレクトリに移動します
Dockerを使用して、PetClinicが使用するMySQLデータベースを起動します
次に、PetClinicアプリケーションにシンプルなトラフィックを生成するLocustを実行する別のコンテナを起動します。Locustは、Webアプリケーションにトラフィックを生成するために使用できるシンプルな負荷テストツールです。
次に、maven を使用してPetClinicをコンパイル、ビルド、パッケージ化します
初回実行時は数分かかり、アプリケーションをコンパイルする前に多くの依存関係をダウンロードします。以降のビルドはより高速になります。
ビルドが完了したら、実行しているインスタンスのパブリックIPアドレスを取得する必要があります。以下のコマンドを実行して取得できます
IPアドレスが返されます。アプリケーションが実行されていることを確認するために必要になるので、このIPアドレスをメモしておいてください。
Real User Monitoring (RUM) の計装では、ページにOpenTelemetry Javascriptスニペット https://github.com/signalfx/splunk-otel-js-web を追加します。ウィザードを使用して Data Management → Add Integration → RUM Instrumentation → Browser Instrumentation の順に進みます。
インストラクターがドロップダウンから使用するトークンを指示します。Next をクリックしてください。以下の形式で App name と Environment を入力します
<INSTANCE>-petclinic-service - <INSTANCE> を先ほどメモした値に置き換えてください。<INSTANCE>-petclinic-env - <INSTANCE> を先ほどメモした値に置き換えてください。ウィザードは、ページの <head> セクションの先頭に配置する必要があるHTMLコードスニペットを表示します。以下は例です（このスニペットは使用せず、ウィザードが生成したものを使用してください）
Spring PetClinicアプリケーションは、アプリケーションのすべてのページで再利用される単一のHTMLページを「レイアウト」ページとして使用しています。Splunk RUM計装ライブラリを挿入するには、すべてのページで自動的に読み込まれるため、この場所が最適です。
それでは、レイアウトページを編集しましょう
次に、上記で生成したスニペットをページの <head> セクションに挿入します。コメントは含めず、ソースURLの <version> を latest に置き換えてください
コード変更が完了したら、アプリケーションを再ビルドして再度実行する必要があります。maven コマンドを実行してPetClinicをコンパイル/ビルド/パッケージ化します
次に、ブラウザを使用してアプリケーション http://<IP_ADDRESS>:8083 にアクセスし、実際のユーザートラフィックを生成します。
RUMで、上記のRUMスニペットで定義された環境にフィルタリングし、ダッシュボードをクリックして開きます。
RUMトレースをドリルダウンすると、スパン内にAPMへのリンクが表示されます。トレースIDをクリックすると、現在のRUMトレースに対応するAPMトレースに移動します。
以下のコマンドでアプリケーションを起動できます。mysql プロファイルをアプリケーションに渡していることに注目してください。これにより、先ほど起動したMySQLデータベースを使用するようアプリケーションに指示します。また、otel.service.name と otel.resource.attributes をインスタンス名を使用した論理名に設定しています。これらはUIでのフィルタリングにも使用されます
http://<IP_ADDRESS>:8083（<IP_ADDRESS> を先ほど取得したIPアドレスに置き換えてください）にアクセスして、アプリケーションが実行されていることを確認できます。
Collectorをインストールした際、AlwaysOn Profiling と Metrics を有効にするように設定しました。これにより、CollectorはアプリケーションのCPUおよびメモリプロファイルを自動的に生成し、Splunk Observability Cloudに送信します。
PetClinicアプリケーションを起動すると、Collectorがアプリケーションを自動的に検出し、トレースとプロファイリングのために計装するのが確認できます。
Splunk APM UIにアクセスして、アプリケーションコンポーネント、トレース、プロファイリング、DB Queryパフォーマンス、メトリクスを確認できます。左側のメニューから APM をクリックし、Environment ドロップダウンをクリックして、ご自身の環境（例：<INSTANCE>-petclinic、<INSTANCE> は先ほどメモした値に置き換えてください）を選択します。
検証が完了したら、Ctrl-c を押してアプリケーションを停止できます。
リソース属性は、報告されるすべてのスパンに追加できます。例えば version=0.314 のように指定します。カンマ区切りのリソース属性リストも定義できます（例：key1=val1,key2=val2）。
新しいリソース属性を使用してPetClinicを再度起動しましょう。実行コマンドにリソース属性を追加すると、Collectorのインストール時に定義された内容が上書きされることに注意してください。新しいリソース属性 version=0.314 を追加しましょう
Splunk APM UIに戻り、最近のトレースをドリルダウンすると、スパン内に新しい version 属性が表示されます。
Splunk Log Observerコンポーネントでは、Splunk OpenTelemetry CollectorがSpring PetClinicアプリケーションからログを自動的に収集し、OTLPエクスポーターを使用してSplunk Observability Cloudに送信します。その際、ログイベントに trace_id、span_id、トレースフラグを付与します。
Log Observerは、アプリケーションとインフラストラクチャからのログをリアルタイムで表示します。ログの検索、フィルタリング、分析を行って、問題のトラブルシューティングや環境の監視が可能です。
PetClinic Webアプリケーションに戻り、Error リンクを数回クリックしてください。これにより、PetClinicアプリケーションログにいくつかのログメッセージが生成されます。
左側のメニューから Log Observer をクリックし、Index が splunk4rookies-workshop に設定されていることを確認してください。
次に、Add Filter をクリックし、フィールド service.name を検索して、値 <INSTANCE>-petclinic-service を選択し、=（include）をクリックします。これで、PetClinicアプリケーションからのログメッセージのみが表示されるはずです。
PetClinicアプリケーションの Error リンクをクリックして生成されたログエントリの1つを選択してください。ログメッセージと、ログメッセージに自動的にインジェクションされたトレースメタデータが表示されます。また、APMとInfrastructureのRelated Contentが利用可能であることにも注目してください。
これでワークショップは終了です。多くの内容をカバーしました。この時点で、メトリクス、トレース（APMとRUM）、ログ、データベースクエリパフォーマンス、コードプロファイリングがSplunk Observability Cloudに報告されているはずです。しかも、PetClinicアプリケーションのコードを変更することなく実現できました（RUMを除く）。
おめでとうございます！
このワークショップの目的は、Java向けのSplunk 自動ディスカバリーおよび設定機能を紹介することです。
ワークショップのシナリオは、Kubernetesにシンプルな（計装されていない）Javaマイクロサービスアプリケーションをインストールすることで作成されます。
既存のJavaベースのデプロイメント向けに自動ディスカバリー機能付きのSplunk OpenTelemetry Collectorをインストールする簡単な手順に従うことで、メトリクス、トレース、ログを Splunk Observability Cloud に送信することがいかに簡単かを確認できます。
このワークショップでは、以下のコンポーネントをカバーします
Splunk Synthetics は少し寂しそうですが、他のワークショップでカバーしています
Spring PetClinic Javaアプリケーションは、フロントエンドとバックエンドのサービスで構成されるシンプルなマイクロサービスアプリケーションです。フロントエンドサービスは、バックエンドサービスと対話するためのWebインターフェースを提供するSpring Bootアプリケーションです。バックエンドサービスは、MySQLデータベースと対話するためのRESTful APIを提供するSpring Bootアプリケーションです。
このワークショップを終えるころには、Kubernetesで実行されるJavaベースのアプリケーション向けの自動ディスカバリーおよび設定を有効にする方法をより深く理解できるようになります。
以下の図は、Splunk OpenTelemetry Operatorと自動ディスカバリーおよび設定を有効にした状態でKubernetes上で実行されるSpring PetClinic Javaアプリケーションのアーキテクチャを詳しく示しています。
Josh Voravong が作成したサンプルに基づいています。
インストラクターが、このワークショップで使用するインスタンスのログイン情報を提供します。
インスタンスに初めてログインすると、以下のようなSplunkロゴが表示されます。ワークショップインスタンスへの接続に問題がある場合は、インストラクターにお問い合わせください。
インスタンスが正しく設定されていることを確認するために、このワークショップに必要な環境変数が正しく設定されているか確認する必要があります。ターミナルで以下のスクリプトを実行し、環境変数が存在し、実際の有効な値が設定されていることを確認してください
INSTANCE 環境変数の値をメモしておいてください。後で Splunk Observability Cloud でデータをフィルタリングする際に使用します。
このワークショップでは、上記の環境変数がすべて必要です。値が不足しているものがある場合は、インストラクターに連絡してください。
この EC2 インスタンスを使用して以前に Splunk Observability ワークショップを完了している場合は、 既存の Splunk OpenTelemetry Collector のインストールが削除されていることを確認する必要があります。 これは以下のコマンドを実行することで行えます
オブザーバビリティシグナル（メトリクス、トレース、ログ）を Splunk Observability Cloud に送信するには、KubernetesクラスターにSplunk OpenTelemetry Collectorをデプロイする必要があります。
このワークショップでは、Splunk OpenTelemetry Collector Helm Chartを使用します。まず、Helm chartリポジトリをHelmに追加し、helm repo update を実行して最新バージョンを確認します
Splunk Observability Cloud では、Kubernetes上でのOpenTelemetry Collectorのセットアップを案内するUIウィザードが提供されていますが、時間の都合上、以下のHelm installコマンドを使用します。自動ディスカバリーおよび設定とコードプロファイリング用のオペレーターを有効にするための追加パラメータが設定されています。
--set="operator.enabled=true" - 自動ディスカバリーおよび設定を処理するためのOpenTelemetryオペレーターをインストールします。--set="splunkObservability.profilingEnabled=true" - オペレーター経由でコードプロファイリングを有効にします。Collectorをインストールするには、以下のコマンドを実行してください。これを編集しないでください
続行する前に、Podが Running として報告されていることを確認してください（通常約30秒かかります）。
Splunk OpenTelemetry Collectorからエラーが報告されていないことを確認してください（ctrl + c で終了）。または、インストール済みの素晴らしい k9s ターミナルUIを使用するとボーナスポイントです！
OpenTelemetry Collector のインストールでエラーが発生した場合は、 以下のコマンドでインストールを削除してやり直すことができます
アプリケーションの最初のデプロイメントでは、ビルド済みのコンテナを使用して、観測を開始したいKubernetesで実行される通常のJavaマイクロサービスベースのアプリケーションという基本シナリオを作成します。それでは、アプリケーションをデプロイしましょう
この時点で、Podが実行されていることを確認してデプロイメントを検証できます。コンテナのダウンロードと起動が必要なため、数分かかる場合があります。
kubectl get pods の出力が、上記のOutputタブに示されている出力と一致することを確認してください。すべてのサービスが Running と表示されていることを確認してください（または k9s を使用してステータスを継続的に監視できます）。
アプリケーションをテストするには、インスタンスのパブリックIPアドレスを取得する必要があります。以下のコマンドを実行して取得できます
http://<IP_ADDRESS>:81（<IP_ADDRESS> を上記で取得したIPアドレスに置き換えてください）にアクセスして、アプリケーションが実行されていることを確認してください。PetClinicアプリケーションが実行されているのが確認できるはずです。アプリケーションはポート 80 と 443 でも実行されているので、これらを使用するか、ポート 81 に到達できない場合はそちらを使用してください。
All Owners (1) タブと Veterinarians (2) タブにアクセスして、各ページに名前のリストが表示されることを確認し、アプリケーションが正しく動作していることを確認してください。
インストールが完了したら、Splunk Observability Cloud にログインして、Kubernetesクラスターからメトリクスが流れてきていることを確認できます。
左側のメニューから Infrastructure をクリックし、Kubernetes を選択してから、Kubernetes nodes タイルを選択します。
Kubernetes nodes の概要画面に入ったら、Time フィルタを -1h から過去15分 (-15m) に変更して最新のデータに焦点を当て、次に Table を選択してメトリクスを報告しているすべてのノードをリスト表示します。
次に、Refine by: パネルで Cluster name を選択し、リストからご自身のクラスターを選択します。
特定のクラスターを識別するには、セットアップ中に実行したシェルスクリプト出力の INSTANCE 値を使用してください。この一意の識別子により、リスト内の他のノードの中からワークショップクラスターを見つけることができます。
これにより、ご自身のクラスターのノードのみを表示するようにリストがフィルタリングされます。
K8s node logs ビューに切り替えて、ノードからのログを確認します。
このセクションでは、Kubernetes上で実行されているJavaサービスに対して自動検出と設定を有効化します。これにより、OpenTelemetry CollectorがPodアノテーションを検索し、JavaアプリケーションにSplunk OpenTelemetry Javaエージェントで計装を行う必要があることを示します。これにより、クラスター上で実行されているJavaサービスからトレース、スパン、およびプロファイリングデータを取得できるようになります。
自動検出と設定は、コード変更や再コンパイルを必要とせずにアプリケーションからトレース、スパン、およびプロファイリングデータを取得するように設計されていることを理解することが重要です。
これはAPMを始めるための優れた方法ですが、手動計装の代替ではありません。手動計装では、カスタムスパン、タグ、ログをアプリケーションに追加でき、トレースにより多くのコンテキストと詳細を提供できます。
Javaアプリケーションの場合、OpenTelemetry Collectorは instrumentation.opentelemetry.io/inject-java というアノテーションを検索します。
このアノテーションの値は true に設定するか、OpenTelemetry Collectorの namespace/daemonset（例：default/splunk-otel-collector）に設定できます。これにより、名前空間をまたいで動作することができ、このワークショップではこれを使用します。
Podが自動的にトレースを送信するようにしたい場合は、以下に示すように deployment.yaml にアノテーションを追加できます。これにより、初期デプロイメント時に計装ライブラリが追加されます。時間を節約するために、以下のPodに対してこれを実施済みです
自動検出と設定を構成するには、デプロイメントに計装アノテーションを追加するためのパッチを適用する必要があります。パッチが適用されると、OpenTelemetry Collectorが自動検出と設定ライブラリを注入し、Podが再起動されてトレースとプロファイリングデータの送信が開始されます。まず、以下を実行して api-gateway に splunk-otel-java イメージがないことを確認します
次に、デプロイメントにアノテーションを追加して、すべてのサービスのJava自動検出と設定を有効にします。以下のコマンドは、すべてのデプロイメントにパッチを適用します。これにより、OpenTelemetry Operatorが splunk-otel-java イメージをPodに注入します
config-server、discovery-server、admin-serverについては、すでにパッチが適用されているため変更はありません。
api-gateway Podのコンテナイメージを再度確認するには、以下のコマンドを実行します
api-gateway に新しいイメージが追加され、ghcr.io から splunk-otel-java がプルされます（注：2つの api-gateway コンテナが表示される場合、元のコンテナがまだ終了処理中の可能性があるため、数秒待ってください）。
Splunk Observability CloudのKubernetes Navigatorに戻ります。数分後、Podがオペレーターによって再起動され、自動検出と設定コンテナが追加されることが確認できます。以下のスクリーンショットのような表示になります
Kubernetes NavigatorでPodが緑色になるまで待ってから、次のセクションに進んでください。
左側のメニューでAPMをクリックして、新しく計装されたサービスからのトレースによって生成されたデータを確認します。
ドロップダウンボックスでEnvironmentフィルター (1) をワークショップインスタンスの名前に変更します。
これは**<INSTANCE>-workshopになります。ここでINSTANCE**は、先ほど実行したシェルスクリプトの値です。これのみが選択されていることを確認してください。
Service Map (2) ペインをクリックして、次のセクションの準備をします。
前のセクションで見てきたように、サービスで自動検出と設定を有効にすると、トレースがSplunk Observability Cloudに送信されます。
これらのトレースにより、Splunkは自動的にService MapsとRED Metricsを生成します。これらは、サービスの動作とサービス間の相互作用を理解するための最初のステップです。
次のセクションでは、トレース自体と、コードに触れることなくサービスの動作を理解するのに役立つ情報を詳しく見ていきます。
上記のマップは、すべてのサービス間のすべての相互作用を示しています。PetClinic Microserviceアプリケーションが起動して完全に同期するまで数分かかるため、マップはまだ中間状態にある可能性があります。時間フィルタを**-2mと入力してカスタム時間の2分に減らすと役立ちます。画面右上のRefreshボタン(1)**をクリックできます。赤い円で示される初期起動関連のエラーは最終的に消えます。
次に、各サービスで利用可能なメトリクスを調べるために、リクエスト、エラー、期間（RED）メトリクスダッシュボードを見てみましょう。
この演習では、サービスオペレーションが高いレイテンシやエラーを示している場合に使用する一般的なシナリオを使用します。
依存関係マップでcustomers-serviceをクリックし、Servicesドロップダウンボックス**(1)で customers-service が選択されていることを確認します。次に、サービス名に隣接するOperationsドロップダウン(2)**から GET /owners を選択します。
これにより、以下に示すように GET /owners でフィルタリングされたワークフローが表示されます
トレースを選択するには、Service Requests & Errors チャート**(1)**の線を選択します。関連するトレースの選択肢が表示されます。
関連するトレースのリストが表示されたら、青い**(2)** Trace ID Linkをクリックします。選択するトレースがServicesカラムに記載されている3つのサービスと同じものであることを確認してください。
これにより、ウォーターフォールビューで選択されたトレースが表示されます
ここにはいくつかのセクションがあります
スパンを調べる際、トレーシングの上で自動検出と設定を使用すると、コード変更なしで得られるいくつかの標準機能を見てみましょう
まず、Waterfall Paneで、以下のスクリーンショットに示すように customers-service:SELECT petclinic または類似のスパンが選択されていることを確認してください
10x をクリックすると、すべてのスパンが順番に表示されるように表示/非表示を切り替えることができます。mysql:petclinic SELECT petclinic **(2)**への呼び出しです。db.statement タグ**(3)**が含まれています。このタグは、このスパン中に実行されたデータベース呼び出しで使用されるDBクエリステートメントを保持します。これはDB-Query Performance機能で使用されます。DB-Query Performanceについては次のセクションで見ていきます。customer-service:GET /owners スパンに対して18個のコールスタックがあることがわかります。(4)次のセクションでプロファイリングを見ていきます。
Splunk APMは、エンジニアに1つの集中ビューでサービスパフォーマンスの深い理解を提供するService Centric Viewsを提供します。すべてのサービスにわたって、エンジニアはサービスの基盤となるインフラストラクチャからのエラーやボトルネックを迅速に特定し、新しいデプロイによるパフォーマンス低下を特定し、すべてのサードパーティ依存関係の健全性を可視化できます。
api-gateway のこのダッシュボードを表示するには、左側のメニューからAPMをクリックし、リストの api-gateway サービスをクリックします。これにより、Service Centric Viewダッシュボードが表示されます
インストルメントされた各サービスで利用可能なこのビューは、Service metrics、Error breakdown、Runtime metrics (Java)、Infrastructure metricsの概要を提供します。
前の章で見てきたように、APMを使用して、コードに触れることなく、さまざまなサービス間のインタラクションをトレースすることができ、問題をより迅速に特定できます。
トレーシングに加えて、automatic discovery and configurationは、問題をさらに迅速に発見するのに役立つ追加機能を最初から提供します。このセクションでは、そのうちの2つを見ていきます
Always-on ProfilingまたはDatabase Query Performanceについてさらに深く学びたい場合は、Debug Problems in Microservicesという別のNinja Workshopがありますので、そちらをご覧ください。
先ほどHelmチャートを使用してSplunk Distribution of the OpenTelemetry Collectorをインストールした際、AlwaysOn ProfilingとMetricsを有効にするように設定しました。これにより、OpenTelemetry JavaはアプリケーションのCPUとメモリのプロファイリングを自動的に生成し、Splunk Observability Cloudに送信します。
PetClinicアプリケーションをデプロイしてアノテーションを設定すると、collectorは自動的にアプリケーションを検出し、トレースとプロファイリングのためにインストルメントします。これを確認するために、次のスクリプトを実行して、インストルメントしているJavaコンテナの1つの起動ログを調べることができます
ログには、Javaの自動検出と設定によって取得されたフラグが表示されます
com.splunk.opentelemetry.profiler.ConfigurationLogger によって書き込まれたセクション、つまりProfiling Configurationです。splunk.profiler.directory など、制御できるさまざまな設定を確認できます。これは、エージェントがSplunkに送信する前にコールスタックを書き込む場所です。（これは、コンテナの設定方法によって異なる場合があります。）
変更したいもう1つのパラメータは splunk.profiler.call.stack.interval です。これは、システムがCPU Stack traceをキャプチャする頻度です。Pet Clinicアプリケーションのような短いスパンがある場合は、このインターバル設定を短くすることをお勧めします。デモアプリケーションでは、デフォルトのインターバル値を変更しなかったため、スパンに常にCPU Call Stackが関連付けられているとは限りません。
これらのパラメータを設定する方法はこちらで確認できます。以下の例では、deployment.yaml でコールスタックのより高い収集レートを設定する方法を示しています。これは、JAVA_OPTIONS configセクションでこの値を設定することで行います。
APM WaterfallビューでオリジナルのTrace & Span (1)（または類似のもの）を選択し、右側のペインから**Memory Stack Traces (2)**を選択してください
ペインにMemory Stack Trace Flame Graph **(3)**が表示されます。スクロールするか、ペインの右側をドラッグして拡大できます。
AlwaysOn Profilingは、アプリケーションのコードのスナップショット、つまりスタックトレースを常に取得しています。何千ものスタックトレースを読まなければならないことを想像してみてください！それは現実的ではありません。これを支援するために、AlwaysOn Profilingはプロファイリングデータを集約して要約し、Flame Graphと呼ばれるビューでCall Stacksを探索する便利な方法を提供します。これは、アプリケーションからキャプチャされたすべてのスタックトレースの要約を表します。Flame Graphを使用して、パフォーマンスの問題を引き起こしている可能性のあるコードの行を発見し、コードに加えた変更が意図した効果を持っているかどうかを確認できます。
Always-on Profilingをさらに詳しく調べるには、Memory Stack Tracesの下のProfiling Paneで上の画像で参照されているSpan **(3)**を選択してください。これにより、Always-on Profilingのメイン画面が開き、Memoryビューがあらかじめ選択されています
Heap Memoryのモニター、Memory Allocation Rate や Garbage Collecting Metricsなどの Application Activity を確認できます。さらなる調査のために、UIではスタックトレースをクリックして、呼び出された関数と、フレームチャートから関連する行を確認できます。これを使用して、コーディングプラットフォームで実際のコードの行を表示できます（もちろん、お好みのコーディングプラットフォームによって異なります）。
Database Query Performanceを使用すると、Splunk APMで直接、データベースクエリがサービスの可用性に与える影響をモニターできます。これにより、データベースをインストルメントすることなく、長時間実行されるクエリ、最適化されていないクエリ、または重いクエリを迅速に特定し、それらが引き起こしている可能性のある問題を軽減できます。
データベースクエリのパフォーマンスを確認するには、ブラウザで戻るか、メニューバーのAPMセクションに移動してAPMのService Mapページに移動し、Service Mapタイルをクリックします。
Dependency mapで推論されたデータベースサービス mysql:petclinic Inferred Database serverを選択し (1)、次に右側のペインをスクロールしてDatabase Query Performance Pane **(2)**を見つけます。
マップで選択したサービスが実際に（推論された）データベースサーバーである場合、このペインには期間に基づく上位90%（P90）のデータベースコールが表示されます。db-queryパフォーマンス機能をさらに詳しく調べるには、ペインの上部にあるDatabase Query Performanceという単語のどこかをクリックします。
これにより、DB-query Performanceの概要画面が表示されます
デフォルトでは、Splunk APMインストルメンテーションはデータベースクエリをサニタイズして、db.statements からシークレットや個人を特定できる情報（PII）などの機密データを削除またはマスクします。データベースクエリの正規化をオフにする方法はこちらで確認できます。
この画面には、Splunk Observability Cloudに送信されたTraces & Spansに基づいて、アプリケーションからデータベースに対して実行されたすべてのDatabase queries **(1)**が表示されます。時間ブロック間で比較したり、Total Time、P90 Latency & Requests **(2)**でソートしたりできることに注意してください。
リスト内の各Database queryについて、時間ウィンドウ中の最高レイテンシ、コールの総数、および1秒あたりのリクエスト数 **(3)**が表示されます。これにより、クエリを最適化できる場所を特定できます。
右側のペイン **(5)**の2つのチャートを使用して、Database Callsを含むトレースを選択できます。Tag Spotlightペイン **(6)**を使用して、エンドポイントやタグに基づいて、データベースコールに関連するタグを確認します。
クエリの詳細ビューを表示する必要がある場合
特定のQuery **(1)**をクリックします。これにより、Query Details pane **(2)**が開き、より詳細な調査に使用できます。
この時点まで、コード変更は一切なく、トレーシング、プロファイリング、データベースクエリパフォーマンスのデータがSplunk Observability Cloudに送信されています。
次に、Splunk Log Observer を使用してSpring PetClinicアプリケーションからログデータを取得します。
Splunk OpenTelemetry Collector は、Spring PetClinicアプリケーションからログを自動的に収集し、OTLPエクスポーターを使用してSplunk Observability Cloudに送信します。その際、ログイベントには trace_id、span_id、トレースフラグが付与されます。
Splunk Log Observer を使用してログを表示し、ログ情報をサービスやトレースと自動的に関連付けます。
この機能は Related Content と呼ばれています。
ログを表示するには、左側のメニューで 
Log Observer をクリックします。Log Observerに入ったら、フィルターバーの Index が splunk4rookies-workshop に設定されていることを確認してください。(1)
次に、Add Filter をクリックし、Fields (2) オプションを使用して deployment.environment フィールド (3) を検索します。ドロップダウンリストから、あなたのワークショップインスタンスを選択し (4)、= (含める) をクリックします。これで、PetClinicアプリケーションからのログメッセージのみが表示されます。
次に、service.name フィールドを検索し、値 customers-service を選択して = (含める) をクリックします。これがフィルターバー (1) に表示されます。次に、Run Search ボタン (2) をクリックします。
これによりログエントリがリフレッシュされ、customers-service からのエントリのみが表示されるように絞り込まれます。
“Saving pet” で始まるエントリ (1) をクリックします。サイドペーンが開き、関連するトレースIDやスパンID (2) を含む詳細情報を確認できます。
下部のペインには、関連するコンテンツが表示されます。以下のスクリーンショットでは、APMがこのログ行に関連するトレースを見つけたことがわかります (1):
Trace for 960432ac9f16b98be84618778905af50 (2) をクリックすると、このログ行が生成された特定のトレースのAPMウォーターフォールに移動します:
ログに関する Related Content ペーンが表示されていることに注意してください (1)。これをクリックすると、Log Observerに戻り、このトレースの一部であるすべてのログ行が表示されます。
アプリケーションにReal User Monitoring (RUM) インストルメンテーションを有効にするには、コードベースにOpen Telemetry Javascript https://github.com/signalfx/splunk-otel-js-web スニペットを追加する必要があります。
Spring PetClinicアプリケーションは、アプリケーションのすべてのビューで再利用される単一の index HTMLページを使用しています。これは、Splunk RUMインストルメンテーションライブラリを挿入するのに最適な場所です。すべてのページで自動的に読み込まれるためです。
api-gateway サービスはすでにインストルメンテーションを実行しており、RUMトレースをSplunk Observability Cloudに送信しています。次のセクションでデータを確認します。
スニペットを確認したい場合は、ブラウザでページを右クリックして View Page Source を選択することで、ページソースを表示できます。
左側のメニューで RUM をクリックして、RUMの簡単な概要ツアーを始めましょう。次に、Environment フィルター (1) をドロップダウンボックスから変更し、ワークショップインスタンスの名前 <INSTANCE>-workshop (1) を選択します (ここで INSTANCE は、以前に実行したシェルスクリプトの値です)。これのみが選択されていることを確認してください。
次に、App (2) ドロップダウンボックスをアプリの名前に変更します。これは <INSTANCE>-store になります。
Environment と App を選択すると、アプリケーションのRUMステータスを示す概要ページが表示されます。(Summary Dashboardが単一行の数値だけの場合は、縮小表示になっています。アプリケーション名の前にある > (1) をクリックして展開できます)。JavaScriptエラーが発生した場合は、以下のように表示されます:
続けるには、青いリンク (ワークショップ名) をクリックして詳細ページに移動します。これにより、UX Metrics、Front-end Health、Back-end Health、Custom Eventsによるインタラクションの内訳が表示され、過去のメトリクス (デフォルトでは1時間) と比較される新しいダッシュボードビューが表示されます。
通常、最初のチャートには1つの線のみがあります。Petclinicショップに関連するリンクをクリックしてください。
この例では http://198.19.249.202:81 です:
これにより、Tag Spotlightページに移動します。
TAG Spotlightビューでは、RUMデータに関連付けられたすべてのタグが表示されます。タグは、データを識別するために使用されるキーバリューペアです。この場合、タグはOpenTelemetryインストルメンテーションによって自動的に生成されます。タグは、データをフィルタリングし、チャートやテーブルを作成するために使用されます。Tag Spotlightビューでは、動作の傾向を検出し、ユーザーセッションにドリルダウンできます。
User Sessions (1) をクリックすると、タイムウィンドウ中に発生したユーザーセッションのリストが表示されます。
セッションの1つを見たいので、Duration (2) をクリックして期間でソートし、長いものの1つのリンク (3) をクリックしてください:
RUMトレースウォーターフォールを見ています。これは、ユーザーがpetclinicアプリケーションのページにアクセスしたときに、ユーザーデバイス上で何が起こったかを示します。
ウォーターフォールを下にスクロールして、右側の #!/owners/details セグメント (1) を見つけてクリックすると、Vetsリクエストの処理中に発生したアクションのリストが表示されます。HTTPリクエストには、リターンコードの前に青い APM リンクがあることに注意してください。1つを選択し、APMリンクをクリックします。これにより、KubernetesでホストされているこのバックエンドサービスコールのAPM情報が表示されます。
リクエストで何が起こったかを確認するためにドリルダウンしたい場合は、Trace IDのURLをクリックしてください。
これにより、RUMからのリクエストに関連するトレースが表示されます:
サービスへのエントリーポイントに RUM (1) 関連コンテンツリンクが追加されており、バックエンドサービスで何が起こったかを確認した後、RUMセッションに戻ることができるようになっていることがわかります。
おめでとうございます。Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry ワークショップを完了しました。
今日、既存のKubernetes上のJavaアプリケーションにトレース、コードプロファイリング、データベースクエリパフォーマンスを追加することがいかに簡単かを学びました。
Automatic Discovery and Configuration を使用して、コードや設定に一切触れることなく、アプリケーションとインフラストラクチャの可観測性を即座に向上させました。
また、シンプルな設定変更により、さらに多くの可観測性 (logging や RUM) をアプリケーションに追加して、エンドツーエンドの可観測性を提供できることも学びました。
