🤖

SplunkのSynthetic Monitoringで外形監視してみる

2023/04/21に公開

Splunk

外形監視

tech

はじめに

Splunk Observability CloudにはSynthetic Monitoring（外形監視と言ったり合成監視と言ったり）があります。
お手軽にユーザーエクスペリエンスの監視ができるので具体的な使い方を解説したいと思います。

Synthetic Monitoring

製品情報

ドキュメント

Splunk側で持っているグローバルの監視拠点（もちろん日本もあり）から定期的に対象サイト、APIに対してテストを実行し、想定通りの結果が得られたか、エラー・レイテンシーはどうかなどをチェックする機能です。

以下のテスト方法があります。

Browser Test
ユーザージャーニーのシナリオを組んでテスト実行します。ECサイトであればログイン⇒商品検索⇒購入など。実行結果は動画で確認できますし、Core Web Vitals（Webページのパフォーマンスとユーザーエクスペリエンス）も計測できます。
Uptime Test
単純にTCP、HTTPを送信しエラー・レイテンシーを計測します。
API Test
APIに対してリクエストを発行し、レスポンス内容やエラー・レイテンシーを計測できます。ステップを組んで認証⇒リクエストも可能です。

それぞれの設定方法を見ていきたいと思います。

Browser Test

テスト対象サイト

さすがにどこかのサイトに仕掛けるのははばかられるのでデモサイトを立ち上げて試します。

こちらを使わせてもらいます。靴下のショッピングサイトのデモで、ログイン、カート、チェックアウト機能などがあります。

Kubernetesでこんな感じで立ち上げ。

git clone https://github.com/microservices-demo/microservices-demo.git
cd microservices-demo/deploy/kubernetes/
sed -i 's/image: mongo/image: mongo:5.0.11/g' complete-demo.yaml
kubectl create namespace sock-shop
kubectl apply -f complete-demo.yaml
#Pod起動後
kubectl port-forward -n sock-shop svc/front-end 8080:80 --address 0.0.0.0

いい感じ。

ブラウザ側の準備

Browser Testではシナリオを作るためにHTMLの要素（テキストボックス、ボタン、リンクなど）のCSSやXPathを使います。
情報取得方法は以下の通りです（Chromeの場合）。

開発者ツールを使用
例えば「Login」に対して右クリック > 検証 > Elementsタブ内の対象のタグを右クリック > Copy > Copy XPathなど

これでもいいですが拡張機能を使うと便利です。

拡張機能
Chromeであれば、例えばSelectorsHubやPOM Builderがあります。

今回はSelectorsHubをインストールします。
右クリック一発で取得できるようになりました。

シナリオを構想

まずはユーザージャーニーを考えます。
Synthetic Monitoringの目的から考え、あくまでもサイトが正常に機能しているか、目的とするコンテンツが提供されるかを確認することにフォーカスします。
（テスト数が多いと課金額も増えますからね）

例えば今回のECサイトであれば以下の機能が正常に動作しているか（レイテンシー観点も含め）でチェックします。

ログイン
商品をカートに追加
チェックアウト

一般化すると、以下のようなチェックを行います。

特定データの表示（ニュースサイトであれば記事など）
特定機能の利用（ログイン、チェックアウト、SNS投稿、画像生成など）

シナリオ作成

それではSynthetic Montoring Browser Testのシナリオを作っていきましょう。

Synthetics > Add new test > Browser Test

テスト名、URL、Location（テスト実行元）などを埋めます。AdvancedからカスタムヘッダーやCookie、User Agentなどを設定できます。

Create detectorをクリックするとアラート条件を設定できます。シナリオ失敗の他にも各指標に対して条件を指定できます。

Edit steps or synthetic transactionsをクリックするとシナリオを編集画面に遷移します。
もし単にトップページにアクセスするだけのテストであれば何もいじる必要はありません。

各ステップではクリックや文字入力などアクションを選べます。

Transaction名を付けてあげましょう。Loginとします。

Transactionとはシナリオ内でステップをまとめる機能です。
Transaction別の処理時間やサイズなど計測が可能になります。そのようなものが不要な場合は特に分ける必要はないです。
今回はログイン⇒カート追加⇒チェックアウトの3つTransactionとします。

右下の・・・からInsert Step Afterを選択しステップを追加します。

Loginのクリックのステップを作ります。
ブラウザでLoginリンクに関するXPathやCSSSeceletorを取得します（XPathの方が複雑で柔軟な表現ができるので、私は大抵XPathを使っています）。

ステップ名、アクションをClick、SelectorをXPathにし取得した値を貼り付けます。
右側に見えるWait for navigationはアクション実行後、2秒間待機する機能です。時間がかかるアクションを挟む場合は使ってみると良いかもしれません。
右下の+ Stepでステップ追加できます。

次はUsernameの入力です。固定idがあるものはそちらを使った方が安全です、、、がXPathでもidは取れるので好みの問題かもしれません。

アクションはFill in fieldにし、Selectorを指定、Valueを「<ログインユーザー名>」にします。

同じようにPasswordも入力するステップを作りましょう。

でもPasswordを平文で書くのは嫌ですよね。そんな時はGlobal Variables機能を使います。

Variable nameを指定し、値を設定、Conceal valueにチェックを入れると不可視になります。

{{env.<Variable name>}}で参照できます。

Loginボタンをクリックしてみるステップです。

最後に、Loginが成功したかをチェックします。このサイトの場合は、ログインに成功すると画面に「Logged in」というテキストが表示されます。
これを成功基準とするため、アクションをAssert text presentにし、Valueに「Logged in」と設定します。Assertは一定時間待機し、対象のテキストや要素が出現するまで待ちます。タイムアウトするとシナリオ失敗と見なします。
このように、いくつかステップ実行し最後にAssertで結果を検証するという流れです。

問題無くステップ実行が完了しました。

もし問題が発生すると、どのステップで、どのような問題であったか表示されますので、Selectorの種類を変えたりして調整します。

Add to Cart

Transactionを分けるため、Synthetic transactionをクリックします。

Transaction名に「Add to Cart」と入力します。後のステップは同じように作っていきます。

できました。またTry nowしてチェックします。

Checkout

同じくTransactionを分け、ステップを作成し、Try nowします。全部無事通れば完成です。

左上のReturn to testで前の画面に戻り、Submitすれば後は自動で実行されます。

結果

しばらく経つと定期実行された結果が表示されます。
このように時系列で結果が見えます。詳細確認には下側のRecent run resultsから結果をクリックします。

Browser Testでは、画面上にシナリオの画面キャプチャ、動画、左下にウォーターフォール、右側にWeb Vitals（Webサイトのパフォーマンス、ユーザーエクスペリエンス）に関する指標が表示されます。

表示されているWeb Vitalsの意味：

Largest Contentful Paint (LCP)：ページの読み込みパフォーマンスを測定します。LCPは、ページの主要コンテンツが表示されるまでの時間を示します。2.5秒以内が理想的です。
Total Blocking Time (TBT):ページの読み込みが完了するまでにメインスレッドがブロックされる合計時間を測定します。これは、ページがどれだけ効率的にユーザーとインタラクションできるかを測定するためのものです。200ミリ秒以内が理想的です。
Cumulative Layout Shift (CLS)：ページの視覚的安定性を測定します。ページのコンテンツがどれだけ不安定に動いているかを測定し、ユーザーが誤ったクリックを引き起こすリスクを評価します。0.1未満が理想的です。

もしテストが失敗した場合（シナリオが完了しなかった場合）はFailureとなります。

どのステップで失敗したかが表示されます。

結果の見方の詳細についてはこちら。

（おまけ）軽めのシナリオで試しに作ってみたい場合

Splunkがデモサイトを公開しています。

http://splunk.o11ystore.com/

Advanced > TLS/SSL validationはOffにしてください。

こんな感じでシナリオを組みます。これは最低限のステップなので、ご興味あればチェックアウト時のテキスト入力など試してみてください。

o11ystore steps sample

[
  {
    "synthetic_transaction": "Checkout Flow",
    "steps": [
      {
        "name": "Go to URL",
        "type": "go_to_url",
        "url": "https://splunk.o11ystore.com/",
        "wait_for_nav": true
      },
      {
        "name": "Click Item",
        "type": "click_element",
        "selector_type": "xpath",
        "wait_for_nav": false,
        "selector": "//div[@class='container']//div[1]//div[1]//a[1]//div[1]"
      },
      {
        "name": "Click Add to Cart",
        "type": "click_element",
        "selector_type": "xpath",
        "wait_for_nav": false,
        "selector": "//button[@type='submit']"
      },
      {
        "name": "Click Place Order",
        "type": "click_element",
        "selector_type": "xpath",
        "wait_for_nav": false,
        "selector": "//button[normalize-space()='Place order']"
      },
      {
        "name": "Assert",
        "type": "assert_text_present",
        "wait_for_nav": false,
        "value": "Your order is complete!"
      }
    ]
  }
]

結果はこんな感じです。

Uptime Test

テスト対象サイト

Browser Testと同じサイトを使います。
なお、Uptime TestはHTTPの他、任意のTCPポートも試せますのでWebサイトに限定はされません。

設定

Synthetics > Add new test > Uptime Test > HTTP Test

Uptime Testは超シンプルです。最低限はテスト名とURLを指定するだけです。

結果

成功（ステータスコード200）か失敗かを時系列で表示されます。レイテンシーも見えます。

結果の詳細です。レイテンシーやレスポンス内容などが見れます。

結果の見方の詳細についてはこちら。

API Test

テスト対象API

こちらのAPIテストサイトを使わせてもらいます。

https://sampleapis.com/

https://api.sampleapis.com/beers/ale

設定

Synthetics > Add new test > API Test

テスト名を付け、+ Add requestsをクリックします。

API TestはSetup（事前処理）、Request（リクエスト内容）、Validation（結果の検証）に分かれます。最低限必要なのはRequestとValidationです。
単純にGETし、レスポンスが200でbodyに「price」が入っていると成功と見なすようにしました。