
Syntheticsモニターのアラートを設定していく
おはようございます( ◜◡◝ )
ゲームソリューション部/業務効率化ソリューション部の きだぱん です。
今回はNew Relicのアラート機能を設定してみたいと思います。
New Relicについて
New Relic は、オンプレミスやクラウドを問わず、あらゆるシステムメトリクスを収集し、ボトルネックの特定や障害対応を高速化します。
アプリやインフラの性能、ユーザー側のレスポンスまでリアルタイムで一元的にモニタリング可能で、顧客体験の向上、クラウドコストの削減、デジタルビジネスの成功に不可欠なすべてのエンジニアリングプロジェクトをサポートしてくれる製品です。
Syntheticsモニター
Syntheticsモニターでは目的や対象に応じて最適なモニタータイプを選定できます。
Syntheticモニターのタイプ | API名 | 説明 |
---|---|---|
リンク切れモニター | BROKEN_LINKS |
ページ上のすべてのリンクが有効かテスト |
証明書チェックモニター | CERT_CHECK |
ドメイン証明書をプロアクティブに監視し更新が必要な場合に通知 |
Pingモニター | SIMPLE |
アプリケーションがオンラインであるかを確認 |
ステップモニター | STEP_MONITOR |
コードを使用せずユーザー操作をシミュレートする高度なブラウザテストを設定 |
シンプルブラウザモニター | BROWSER |
事前構築されたスクリプト化ブラウザモニター |
スクリプト化ブラウザモニター | SCRIPT_BROWSER |
カスタムスクリプトを使いより高度でカスタマイズされたブラウザテスト |
APIテスト | SCRIPT_API |
APIエンドポイントを監視しアプリケーションサーバーの稼働を確認 |
アラート設定
※前提条件:Syntheticsモニターの設定は終わっている。
監視を実装した次のステップは、検知した問題を迅速かつ正確にチームへ通知するアラートの構築です。
アラートポリシーの作成
Alert Policyは、複数のアラート条件と通知チャネルを束ねています。
サービス単位やチーム単位でポリシーを分割して管理するのが一般的です。
[Manege Alart] → [New alert condition]を選択します。
今回は「Use Guided Mode」で進めます。
何を対象とするか指定します。[Synthetic monitors]を選択しNextで進みます。
具体的なモニターをリストから選択します。 ※複数でも可
[Category]でMonitor failure
を選択します。
Syntheticsモニターのチェックが失敗したことをトリガーにできます。
NRQLでは以下のようになります。
より高度な条件(例:特定のリソース読み込みに5秒以上かかった場合など)を設定したい場合は、NRQLを利用した条件作成も可能です。
SELECT filter(count(*), WHERE result = 'FAILED') AS 'Failures' FROM SyntheticCheck WHERE entityGuid IN ('指定したID') AND NOT isMuted FACET location, monitorName
アラートの具体的な条件(閾値)を設定します。
今回はデフォルト設定のまま進みます。
大項目 | 設定項目 | 設定値 | 補足 |
---|---|---|---|
Data aggregation | Window duration | 1 minutes | データを集約する時間枠。 |
Streaming method | Event timer | データポイント間の待機時間を設定する方法。 | |
Timer | 5 秒 (seconds) | データポイントを待つ時間。 | |
Gap filling strategy | Fill data gaps with | なし (None) | データがない期間をどのように扱うかの設定。 |
閾値の設定
大項目 | 設定項目 | 設定値 |
---|---|---|
条件タイプ | (Static / Anomaly) | 静的 (Static) |
インシデントを開く条件 | 重大度レベル (Severity level) | Critical |
When a query returns a value | 次の条件を満たした場合:<br>・0 を 超える (above)<br>・1分 (minutes) 以内に 少なくとも1回 (at least once in) | |
オプション | ヘルス状態を判断する際にこのしきい値を無視する<br>(Ignore this threshold when determining health) | (チェックなし) |
最後の設定に進みます。
ここでは、アラート条件の名前や、インシデントをどのようにグループ化して通知するかといった詳細設定を行います。
- アラート条件名:アラート名を入力します。
- ポリシーへの接続:「新規ポリシー (New policy)」を選択
- ポリシー名を入力します
- インシデントのグループ化:「ポリシーごとに1つのイシュー (One issue per policy)」を選択
- ノイズの相関と抑制:無効 (チェックなし)
- オープンインシデントの自動クローズ:3日後
- インシデントのカスタマイズ
Alert condition enabled
設定完了です
NRQLでは、以下のようになりました。
SELECT filter(count(*), WHERE result = 'FAILED') AS 'Failures' FROM SyntheticCheck WHERE entityGuid IN ('NDY0NTU2MHxTWU5USHxNT05JVE9SfGY5ODkyNzJlLTk5YTctNDdhNC1iZjI2LWM4NGQ3NTE3MTg0NA') AND NOT isMuted FACET location, monitorName
通知
インシデントを通知する先も設定できます。
EmailやSlackへの通知はもちろん、PagerDuty, Opsgenie, VictorOpsといったインシデント管理ツールと連携することで、通知エスカレーションや、インシデント対応プロセスを自動化できます。
Webhookを利用すれば、独自のシステムへ通知を飛ばすといった柔軟な連携も可能です。
まとめ
今回は、Syntheticsモニターを活用した監視とアラート設定について書きました。
ぜひこの機会にSyntheticsモニターを試していただければと思います。
New Relicに関するブログも展開されていますので、是非こちらもご覧ください。
この記事がどなたかのお役に立てば幸いです。以上、きだぱんでした!