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ホームページに戻ります
ワークショップのテストを再度選択し、ページ上部のボタンをクリックします。
New Synthetics Detectorというテキスト（1）を編集し、イニシャル -[ワークショップ名]に置き換えます。
とが選択されていることを確認します。
Trigger threasholt（2）を 65,000〜68,000 に設定し、Enterキーを押してチャートを更新します。上図のように、しきい値ラインを切る複数のスパイクがあることを確認してください（実際のレイテンシーに合わせてしきい値を少し調整する必要があるかもしれません）。
残りはデフォルトのままにします。
スパイクの下に赤と白の三角形の列が表示されるようになったことに注意してください（3）。赤い三角形は、テストが指定されたしきい値を超えたことをDetectorが検出したことを知らせ、白い三角形は結果がしきい値を下回ったことを示します。各赤い三角形がアラートをトリガーします。
アラートの重大度（4）は、ドロップダウンを別のレベルに変更することで変更できます。また、アラート方法も変更できます。受信者を追加しないでください。アラートストームの対象になる可能性があります！
をクリックして、 Detectorをデプロイします。
新しく作成したDetectorを見るには、ボタンをクリックします。
ページの下部にアクティブなDetectorのリストがあります。
あなたのDetectorが見つからず、新しい Synthetics Detectorという名前のものが表示されている場合は、あなたの名前で正しく保存されていない可能性があります。新しい Synthetics Detectorのリンクをクリックして、名前の変更をやり直してください。
ボタンをクリックして編集モードを終了します。