はじめに

Splunk Observability CloudのAPMにはBusiness Workflow（ビジネスワークフロー）という機能があります。
アプリから得られたトレースにビジネス上の意味付けを与えられる機能で、良機能だと思うのでご紹介します。

トレース分析の課題

とりあえずGoogleのECサイトのデモであるMicroservice DemoをAPMのService Map機能で可視化してみます。
全トランザクションを元にサービス間の関連性がマップとして作成されます。

トレースも全量見れます。

さて、ここで気になることとして、どのトレースが重要かであるかです。
全てのトレースが等しく重要な訳ではなく、優先度を付けなければ効率的なモニタリング、アクションが取れなくなります。
ECサイトであれば例えば以下が実行された際のトレースが特に重要と考えられ、エラー率やレイテンシーを測定したいでしょう。また、その中でも無料会員よりも有料会員が重要とするケースもあります。
（このようなビジネス上重要なユーザーアクションをクリティカルユーザージャーニーとも呼んだりします）

ログイン
商品サーチ
商品購入アクション

Business Workflow

Business Workflowはそのようなトレースを抽出し、観測できる機能です
それでは設定方法と活用方法を見ていきましょう。

設定方法

以下種類の設定が可能です。

特定のサービスを経過したトレース
例：「paymentservice」（支払い）を経過したトレース
特定のサービスのTag別のトレース
例：「paymentservice」を経過しTenant Levelが「Gold」であるトレース
または一つのサービス内で複数の処理を行っているモノリシックなアプリの場合は例えば「Operation」みたいなTagで処理内容（商品検索、購入など）を出力するようにすれば、その処理ごとに抽出可能になります。
Global Tag別のトレース

1. 特定のサービスを経過したトレース

Business Workflowの設定画面はSetting > Business Workflowです。

Rule Typeに「Service」、Target Serviceに例えば「paymentservice」を指定し、Source of Workflow Nameに「Matched service:endpoint」を指定します。設定はこれだけです。

設定後、トレースが取得できるまで待ちます。Service MapでWorkflowを絞り込んでみましょう。するとpaymentserviceを経過したトレースに限定したMapを見ることができます。これで支払いアクションを取ったユーザーはどのようなサービスを使用しているか分かります。

トレースも見てみましょう。同様にpaymentserviceを経過したトレースだけに絞り込まれています。

2. 特定のサービスのTag別のトレース

Business Workflow作成に戻ります。Target Serviceに「paymentservice」を指定するところまでは同じで、Source of Workflow Nameに「Tag value」を指定します。そしてBusiness Workflow化したいTagを選択します。ここで選択できるTagはpaymentserviceのスパンに含まれるTagです。
例えばtenant.level（カスタムタグでGold、Silver、Bronzeの値を持つ）を取っているとしたら会員グレード別の分析ができます。

Service MapでWorkflow: goldが生成されているので選択すると、同様にpaymentを実行したgoldユーザーのトレースで絞り込まれます。

トレースも同様です。

3. Global Tag別のトレース

Rule Typeに「Global Tag」を選択することでGlobalでインデックス化したTag（詳細割愛）を元にBusiness Workflow化することができます。

以降はこれまでと同じです。

利用方法

ここまでの使い方は実はアドホックでフィルタをすることでも可能です。
Business Workflowの利点は定点観測、アラート、トラブルシューティングが容易になるところです。

SLIダッシュボード

Business WorkflowのRED（Request、Error、Duration）に関するダッシュボードが用意されています。任意のBusiness Workflowをフィルタに指定できます。

問題が起きた時、いつから何が悪化しているか簡単に確認できますね。

Detector

エラーとレイテンシーに対してDetector（アラート定義）を仕込むことができます。
Detectorについてはこちら：

Detector定義画面でBusiness Workflowが選択可能です。（ダッシュボードの🔔アイコンから遷移すれば既に設定済み）
検出方法はStatic Threshold、Sudden Change、Historical Anomary（Durationのみ）が選べます。

これにより、特に注意すべきBusiness Workflowで異常が発生した（今回の例であれば支払いの過程でエラー発生 or レイテンシーが急増した、またはSLOを違反しそうになっている）場合にアラートを通知し、アクションに移せます。

トラブルシューティング

アラートを受け取ったメンバーはとりあえずダッシュボードで状況把握し、次に根本原因調査です。なんと対象のBusiness Workflowのトレースも絞り込みは一瞬で、その中でレイテンシーの高いトレースや、エラーの発生しているトレースもフィルタをかけられるので、どれかピックアップして確認します。

ちなみにSplunk Observability Cloudはサンプリングしませんので「サンプリング対象外だったらから調べられなかった」ということはないです。

対象トレースのスパン分析はこんな感じ。どのサービスでどれだけ処理時間を要していて、どこでどんなエラーがでているか一目瞭然です。

あるいはAPMのTag Spotlight機能を使って問題の切り分けをしてあげてもよいです。
Tag Spotlightについてはこちら：

各Tagについて値ごとのエラー発生状況やレイテンシーが確認し、問題のある条件を切り分けできます。

まとめ

Splunk Observability CloudのAPMにはBusiness Workflow機能の概要と使い方を見てきました。
ビジネス上重要なトレースを特定⇒観測⇒アラート⇒トラブルシューティングの流れがキレイにできそうであるという印象です。