SREの帽子を再び被って、オンラインブティックの監視を設定するよう依頼されました。アプリケーションが 24 時間 365 日、利用可能で良好なパフォーマンスを発揮していることを確認する必要があります。
アプリケーションを 24 時間 365 日監視し、問題が発生したときにアラートを受け取ることができたらいいと思いませんか？ここで Synthetics の出番です。オンラインブティックを通じて典型的なユーザージャーニーのパフォーマンスと可用性を毎分チェックする簡単なテストを紹介します。
Splunk Observability Cloud のメインメニューから、Syntheticsをクリックします。AllまたはBrowser testsをクリックして、アクティブなテストのリストを表示します。
RUM セクションでの調査中に、Place orderトランザクションに問題があることがわかりました。Synthetics テストからもこれを確認できるか見てみましょう。テストの 4 ページ目のFirst byte timeというメトリクスを使用します。これはPlace orderステップです。
現在、単一の Synthetic Browser テストの結果を見ています。このテストはビジネストランザクションに分割されています。これは、ビジネス上重要なユーザーフローを表す、論理的に関連する 1 つ以上の操作のグループと考えてください。
以下のスクリーンショットにはエラーを示す赤いバナーは含まれていませんが、あなたの実行結果には表示されている場合があります。これは、場合によってはテスト実行が失敗することがあり、ワークショップに影響しないため予期されることです。
デフォルトでは、Splunk Synthetics はテストのスクリーンショットとビデオキャプチャを提供します。これは問題のデバッグに役立ちます。例えば、大きな画像の読み込みが遅い、ページのレンダリングが遅いなどを確認できます。
今、以下のような表示が見えているはずです。
これらのテストを 24 時間 365 日実行できるため、テストが失敗したり、合意した SLA よりも長く実行され始めた場合に、ソーシャルメディアやアップタイムウェブサイトから通知される前に、早期に警告を受けるための理想的なツールです。
そのような事態を防ぐために、テストが 1.1 分以上かかっているかどうかを検知しましょう。
左側のメニューから Synthetics ホームページに戻ります
ワークショップのテストを再度選択し、ページ上部のCreate Detectorボタンをクリックします。
New Synthetics Detectorというテキスト（1）を編集し、イニシャル - [ワークショップ名]に置き換えます。
Run DurationとStatic threasholdが選択されていることを確認します。
Trigger threasholt（2）を65,000〜68,000に設定し、Enter キーを押してチャートを更新します。上図のように、しきい値ラインを切る複数のスパイクがあることを確認してください（実際のレイテンシーに合わせてしきい値を少し調整する必要があるかもしれません）。
残りはデフォルトのままにします。
スパイクの下に赤と白の三角形の列が表示されるようになったことに注意してください（3）。赤い三角形は、テストが指定されたしきい値を超えたことを Detector が検出したことを知らせ、白い三角形は結果がしきい値を下回ったことを示します。各赤い三角形がアラートをトリガーします。
アラートの重大度（4）は、ドロップダウンを別のレベルに変更することで変更できます。また、アラート方法も変更できます。受信者を追加しないでください。アラートストームの対象になる可能性があります！
Actibateをクリックして、 Detector をデプロイします。
新しく作成した Detector を見るには、Edit Testボタンをクリックします。
ページの下部にアクティブな Detector のリストがあります。
あなたの Detector が見つからず、新しい Synthetics Detectorという名前のものが表示されている場合は、あなたの名前で正しく保存されていない可能性があります。新しい Synthetics Detectorのリンクをクリックして、名前の変更をやり直してください。
閉じるボタンをクリックして編集モードを終了します。