はじめに
某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 で入力した値をそれぞれ記載する必要があります。
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