Splunk APMのTag Spotlightで爆速トラブルシューティング

# はじめに

オブザーバビリティ力を高めるには高カーディナリティ、大量のディメンションを元に切り分けできる能力が必要です。
※色々すっとばして言っちゃいましたが詳細は[オブザーバビリティ・エンジニアリング](https://amzn.asia/d/iYEnQnC)参照。

そのためには、アプリにカスタムでタグを埋め込むのはいいけれど、それをうまく使いこなせるバックエンドが必要です。
Splunk Observability CloudのAPMではどうなのか見てみました。

# Splunk Observability CloudのAPMでMicroserviceを可視化

とりあえずGoogle謹製の[マイクロサービスデモ](https://github.com/GoogleCloudPlatform/microservices-demo)のトレースを取得しAPMで見てみます。
※これも色々すっとばしてしまいましたが、そのうちSplunk Observability Cloudでの計装方法も記事にしようと思います。OpenTelemetry使います。

こんな感じでサービスマップが自動生成され、エラーが発生しているサービス（ここでは`paymentservice`）が赤く表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/7ce0dd8e-097c-0719-db82-3e76265a6619.png)

凡例はこんな感じ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/5518b56c-e7c6-e813-6668-b66a237127c3.png)

リクエスト数、レイテンシーと、表面的なErrorだけじゃなくてRoot Errorも検出してくれるようです。視覚的に分かりやすいですね。

じゃあ`paymentservice`で何が起きてるか見てみましょう。

Tag Spotlightを使うといい感じです。


# Tag Spotlightによるタグを活用した問題の切り分け

Tag Spotlightとはtag情報を元にエラー発生状況、レイテンシーを解析する機能です。

https://docs.splunk.com/Observability/apm/span-tags/tag-spotlight.html


Request/Errorの状況を色々なtagでのカットで見えてますね。インフラレイヤーであればKubernetes Nodeなど、アプリレイヤーであればEndpointなどです。テナントIDなどカスタムTagも分析対象にできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/435bcc82-8e14-50a7-fe7e-90f98433e0c0.png)

このtagの中からエラーに寄与してそうなものをざっと見ていきます。Tagの値の内`Err`数がおかしいものですね。
システムが壊れるのは大抵変更したときなのでバージョン情報はまず真っ先に見るべきtagでしょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/069f3fce-d4c2-735e-1881-a2ce46fe4742.png)
おっと！

このサービスでは2種類のバージョンが動いています。そのうち、新しいバージョン（v350.10）では`Req`が296件に対して全て`Err`が出ています。一つ前のバージョン（v350.9）では`Req`が37件で、`Err`が0件です。
バージョンが原因であることは確定的に明らかです。
もちろん他のTagも念のため見てもよいです。

じゃあどんなエラーが出ているのか？

エラーが出ているバージョンで絞って

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/117dc1b9-0e49-d196-2ee7-c2d89a7e0413.png)

関連するトレースを見てみます。ちなみにSplunk Observability Cloudはサンプリングしないのであらゆるリクエストを分析できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/74a277c3-6025-8ea2-8ae9-1c2595eb410d.png)

# トレース（分散トレーシング）で原因調査

トレースが見えました。分散トレーシングにより各サービスのスパンがまとまっています。
やはりpaymentserviceでエラーが出ていますね。何度かリトライして成功しているということが見れます。恐らくLBで新バージョンへ振り分けられた通信がエラー⇒リトライして、最終的に旧バージョンに振り分けられ成功しているのでしょう（Span内のバージョン情報を見れば仮説が正しいか分かります）。
なかなか検出しにくい事象です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/5ec60fc6-6028-685d-1819-8d9a8431bbfb.png)

詳細を見てみると`Invalid request`が出ています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/709a96c3-965c-b242-413d-6ab0dbfc0f1e.png)

いいところまで来ました。アプリがこけている訳ではなくリクエストに問題があるようです。
※アプリがこけるとスタックトレースが出力されたりします。

次の疑問は当然「なんで`Invalid request`が出てるの？」です。

下の方に`Logs for trace`というのが出てますね。
APMはトレース、スパンとログを紐づけることもできますので、それが自動的に検出されているようです。
見てみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1218403/6215aa2c-c26f-e8e2-b6cb-0ebb227d4fc8.png)

`Failed payment processing through ButtercupPayments: Invalid API Token (test-20e26e90-356b-432e-a2c6-956fc03f5609)`だそうです。
テストで使っていたAPI Tokenを間違って本番にリリースしちゃった系の障害ですね。

さくっと直してしまいましょう。
ついでに類似事象が起きないようにCI/CDプロセスでチェックするようにできればパーフェクトです。

# まとめ

SplunkのAPMを使ってサービスマップでエラーが出ているサービスの当たりを付け、Tag Spotlightで問題を切り分け、問題のあるトランザクションに対してトレース、ログでエラーの根本原因を探ってみました。

問題が起きているサービスが分かったのはいいけど、原因の切り分けが簡単にできないと手探りで試行錯誤せざるを得ないので、Tag Spotlightは非常に重要な機能だと思います。
視覚的でクリック数も少なく分析できるなという印象です。

Microserviceだと複雑だし何が起きるか分からないので、このようにバックエンド側でできる限りトラブルシューティングをサポートしてくれるような仕組みがあるとありがたいですね。