はじめに
オブザーバビリティ力を高めるには高カーディナリティ、大量のディメンションを元に切り分けできる能力が必要です。
※色々すっとばして言っちゃいましたが詳細はオブザーバビリティ・エンジニアリング参照。
そのためには、アプリにカスタムでタグを埋め込むのはいいけれど、それをうまく使いこなせるバックエンドが必要です。
Splunk Observability CloudのAPMではどうなのか見てみました。
Splunk Observability CloudのAPMでMicroserviceを可視化
とりあえずGoogle謹製のマイクロサービスデモのトレースを取得しAPMで見てみます。
※これも色々すっとばしてしまいましたが、そのうちSplunk Observability Cloudでの計装方法も記事にしようと思います。OpenTelemetry使います。
こんな感じでサービスマップが自動生成され、エラーが発生しているサービス（ここではpaymentservice）が赤く表示されます。
凡例はこんな感じ。
リクエスト数、レイテンシーと、表面的なErrorだけじゃなくてRoot Errorも検出してくれるようです。視覚的に分かりやすいですね。
じゃあpaymentserviceで何が起きてるか見てみましょう。
Tag Spotlightを使うといい感じです。
Tag Spotlightによるタグを活用した問題の切り分け
Tag Spotlightとはtag情報を元にエラー発生状況、レイテンシーを解析する機能です。
Request/Errorの状況を色々なtagでのカットで見えてますね。インフラレイヤーであればKubernetes Nodeなど、アプリレイヤーであればEndpointなどです。テナントIDなどカスタムTagも分析対象にできます。
このtagの中からエラーに寄与してそうなものをざっと見ていきます。Tagの値の内Err数がおかしいものですね。
システムが壊れるのは大抵変更したときなのでバージョン情報はまず真っ先に見るべきtagでしょう。
おっと！
このサービスでは2種類のバージョンが動いています。そのうち、新しいバージョン（v350.10）ではReqが296件に対して全てErrが出ています。一つ前のバージョン（v350.9）ではReqが37件で、Errが0件です。
バージョンが原因であることは確定的に明らかです。
もちろん他のTagも念のため見てもよいです。
じゃあどんなエラーが出ているのか？
エラーが出ているバージョンで絞って
関連するトレースを見てみます。ちなみにSplunk Observability Cloudはサンプリングしないのであらゆるリクエストを分析できます。
トレース（分散トレーシング）で原因調査
トレースが見えました。分散トレーシングにより各サービスのスパンがまとまっています。
やはりpaymentserviceでエラーが出ていますね。何度かリトライして成功しているということが見れます。恐らくLBで新バージョンへ振り分けられた通信がエラー⇒リトライして、最終的に旧バージョンに振り分けられ成功しているのでしょう（Span内のバージョン情報を見れば仮説が正しいか分かります）。
なかなか検出しにくい事象です。
詳細を見てみるとInvalid requestが出ています。
いいところまで来ました。アプリがこけている訳ではなくリクエストに問題があるようです。
※アプリがこけるとスタックトレースが出力されたりします。
次の疑問は当然「なんでInvalid requestが出てるの？」です。
下の方にLogs for traceというのが出てますね。
APMはトレース、スパンとログを紐づけることもできますので、それが自動的に検出されているようです。
見てみましょう。
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だと複雑だし何が起きるか分からないので、このようにバックエンド側でできる限りトラブルシューティングをサポートしてくれるような仕組みがあるとありがたいですね。