はじめに

某SIerでKubernetesの監視について検証している @suzuyan です。
前回は初投稿の記事にて、Splunk IMを使いKubernetesのリソースを監視してみました。
今回の記事では、同じくSplunk社のSplunk APMを使ってKubernetes上のコンテナアプリケーションの監視(Tracing)を試してみたいと思います。

環境

Kubernetes: OpenShift 4.9.43 (Kubernetes v1.22.8)
AWS 上に構築
macOS Big Sur 11.6.6 (作業端末)

Splunk APM を使ってみる

文章で色々確認するのは大事ですが、実際に触ってみた方が理解も進みそうなので、さっそく監視設定を進めたいと思います。

Splunk Observability Cloud にログインする

アカウント作成の際に選択したリージョンによってサブドメインが異なります。
前回はus1でしたが、今回はAPACを選択したためjp0になっています。

Splunk Observability Cloudというのが前回の記事で利用したSplunk Infrastructure Monitoringや今回のSplunk APMなど、Splunkのクラウド監視製品の総称のようですね。前回の投稿から1年以上経過しており、ダッシュボードのUIもかなり変わったような気がします。

Splunk OpenTelemetry Collector のセットアップ

APMによるアプリケーションの監視を行うためには、Splunk OpenTelemetry Collectorを事前にセットアップしておく必要があります。
ダッシュボードよりData Setupを選択し、Kubernetesをクリックします。

1.Integration Summary
最下部のNextをクリックします。

2.Configure Integration
今回は以下のように入力して進めました。
Splunk access token: Default (デフォルトのまま)
Cluster Name: testcluster (任意のクラスタ名を入力)
Provider: Other (デフォルトのまま)
Distribution: RedHat OpenShift （今回OpenShiftのためRedHat OpenShiftを選択）
Add Gateway: No (デフォルトのまま)
Profiling: True (デフォルトのまま)

3.Install Integration
ここでhelmによるインストール手順が公開されます。お使いの作業端末にhelm3をインストールしておく必要があります。
Macであればbrewでインストール可能です。

Helmのリポジトリを追加します。

$ helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
"splunk-otel-collector-chart" has been added to your repositories

お決まりですが。リポジトリの最新情報を取得します。

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "splunk-otel-collector-chart" chart repository
Update Complete. ⎈Happy Helming!⎈

ACCESS TOKENの箇所はそれぞれの環境で異なります。Dの部分に表示されているコマンドをコピペすれば大丈夫です。
以下のコマンドを実行すると、DeploymentとDaemonSetが作成され、Podが生成されます。
Namespaceは必要に応じて-nオプションで指定します。

$ helm install --set cloudProvider=' ' --set distribution='openshift' --set splunkObservability.accessToken='<ACCESS TOKEN>' --set clusterName='testcluster' --set splunkObservability.realm='jp0' --set gateway.enabled='false' --generate-name splunk-otel-collector-chart/splunk-otel-collector --set splunkObservability.profilingEnabled='true'`
NAME: splunk-otel-collector-1659682227
LAST DEPLOYED: Fri Aug  5 06:50:29 2022
NAMESPACE: test-apm
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm jp0

Podの動作を確認してみます。DaemonSetで、ノード毎に1Podずつ、agentが配置されていることが分かります。

$ kubectl get pod
NAME                                                              READY   STATUS    RESTARTS      AGE
splunk-otel-collector-1659682227-agent-59l74                      1/1     Running   0             2d3h
splunk-otel-collector-1659682227-agent-9n2zk                      1/1     Running   0             2d3h
splunk-otel-collector-1659682227-agent-9wtbl                      1/1     Running   0             2d3h
splunk-otel-collector-1659682227-agent-dw6wz                      1/1     Running   0             2d3h
splunk-otel-collector-1659682227-agent-pjcbw                      1/1     Running   0             2d3h
splunk-otel-collector-1659682227-agent-z7nj4                      1/1     Running   0             2d3h
splunk-otel-collector-1659682227-k8s-cluster-receiver-589b94pv2   1/1     Running   0             2d3h

ブラウザに戻り、Nextをクリックし、4に進みます。

4.Review Inventory
これまでの設定がうまくいっていれば、この段階で対象のクラスタの情報が表示されます。

アプリケーションの監視設定 (Tracing)

既にKubernetesクラスタの情報を確認できますが、肝心のAPM Tracingを行うためにはコンテナ自体にTracingを行うための設定が必要です。

ダッシュボードに戻り、改めてData Setupをクリックします。
既に設定が完了した、Kubernetesのところにチェックマークが入っています。
Monitor applications をクリックします。

ここで様々なプログラミング言語が表示されますが、今回はJava (Provides Traces.)をクリックします。

1.Integration Summary
Nextをクリックします

2.Configure Integration
Service name: java-test-app (任意のサービス名を入力)
Collector endpoint: http://localhost:4317 (デフォルトのまま)
Environment: test (任意の環境名を入力)
AlwaysOn Profiling: No (デフォルトのまま)
Application metrics: No (デフォルトのまま)
Kubernetes: Yes (KubernetesのためYesにします)
Legacy Agent: No (デフォルトのまま)

3.Install Integration
正直、ここで表示される手順はかなり情報不足だと思います。

Aは既に実施したSplunk OpenTelemetry Collectorの導入に関する内容です。
Bはコンテナイメージに組み込むためのjarファイルのダウンロードです。
Cはコンテナをデプロイする際のDeploymentのyamlファイルの例です。
Dはコンテナで実行する必要があるコマンドです。

BからDでもう少し丁寧に解説されていると良いのですが。。。
このあたりの情報について、合わせて[1]を参照した方が分かりやすいです。
というより私は[1]がなければ、恐らくTracingの設定方法を理解できなかったかもしれません。
結論としては、A、BおよびDはDockerfileで、コンテナイメージを作成する際に必要になります。
今回は[1]に記載されている、コンテナイメージ
image: docker.io/astro7982/curlappstatic:lastest
を利用するため、A, B, Dの手順は割愛します。おそらく[1]の記事を書いた方が作成したコンテナイメージでしょうか。

Cを参考にして、Deploymentのyamlファイルを作成します。
service.name=, deployment.environment= には 2. Configure Integration で入力した値をそれぞれ記載する必要があります。

java-test-app.yaml

apiVersion: v1
kind: Pod
metadata:
  name: httpgooglechecker
spec:
  containers:
  - name: httpgooglechecker
    image: docker.io/astro7982/curlappstatic:lastest
    env:
    - name: SPLUNK_OTEL_AGENT
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: service.name=java-test-app,deployment.environment=test
    - name: SPLUNK_METRICS_ENDPOINT
      value: http://$(SPLUNK_OTEL_AGENT):9943
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: http://$(SPLUNK_OTEL_AGENT):4317
    command: ["/bin/sh"]
    args: ["run.sh"]

作成したyamlを使用してPodをデプロイします。

$ kubectl create -f java-test-app.yaml
pod/httpgooglechecker created

4.Review Inventory
今回の設定手順では、ここでは何も表示されませんでした。
設定自体は3のPodの作成まで実施すれば完了です。

Tracing の内容を確認する

下部の Explore Service Spans もしくは左メニューの APM をクリックします。
デプロイしたアプリケーションに関する概要情報が表示されます。

右メニューの Exprole をクリックします。
今回のアプリケーションに関する情報が表示されます。
www.google.com にcurlでHTTPリクエストするだけのシンプルなアプリケーションです。

< Overview をクリックして前の画面に戻ります。

続いて Traces をクリックします。
Tracingの状況が時系列で表示されます。一番上のTrace IDをクリックしてみます。

Trace ID毎にパフォーマンスを確認することができますね。これはパフォーマンスの分析に役立ちそうです。

今回は最低限の設定と、シンプルなサンプルアプリケーションを試しにデプロイしただけですが、Tracingとはどのようなものかを確認することができました。
多数のPodで構成される複雑なアプリケーションや、マイクロサービス化されたシステムで活用すれば、より効果的な監視を行えるのではないでしょうか。
次回は、マイクロサービスのサンプルアプリケーションを使用してTracingの素晴らしさを実感してみたいと思います！

References