みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
最近急に寒くなってきましたね。今年は秋がなくて夏からいきなり冬になりませんでしたっけ（涙）できれば気持ちのいい秋が長く続いてくれる方が個人的には嬉しいです（願望
さてさて、今回もNew Relicの監視設定のお話です。New Relicの監視設定をしようとして、最初にAlert Conditionの画面を開いた後にストリーミングメソッドってのが出てきて、これって何を選んだらいいんだっけ？となっている方も多いのではないでしょうか。私も最初のころは違いがよくわからんとなってドキュメントを読み漁りあしたが、やっぱりよくわからんという状況でした。今回の記事ではそれぞれの違いや特徴、使いどころについてまとめてみました。
目次
対象読者
- New Relicを最近使い始めた方
- Condition設定のEvent Flow、Event Timer、Cadenceの違いについてよくわからない方
New Relicの監視設定における集計方法（ストリーミングメソッド）とは
New Relicを使用していると、データの集計方法について「Event Flow」「Event Timer」「Cadence」という3つの用語を目にすることがあります。これらの違いを理解することは、効果的な監視設計を行う上で非常に重要です。このデータの集計方法のことをストリーミングメソッドといい、New Relicではデータをどのように集計するかを定義する方法になります。例えば、1分間のCPU使用率の平均値を計算する場合、どのタイミングでその1分間を区切るのか、遅延したデータをどう扱うのかなどを決定します。
3つのストリーミングメソッドの特徴
Event Flow
Event Flowとは
Event Flowは、連続データ収集に適した方式で、現在のNew Relicで最も推奨される方式です。
仕組み
- データのタイムスタンプに基づいて集計ウィンドウを管理
- 設定されたDelay時間後に集計を実行
- データが継続的に到着することを前提とした設計
最適な使用シーン
- APMエージェントを使用した監視
- インフラストラクチャエージェントを使用した監視
- Cloudwatch Metrics Streamを使用したAWS基盤監視
具体例
監視条件が下記の場合の状況を順を追って見ていきましょう。
- 監視条件
- Window durationが60 (秒)
- delay=120 (秒)
- 閾値設定の評価時間が for at least in 2 min
- データポイントは閾値設定を超えている
ここから実際のデータポイントとWindow duration、delay、評価時間の関係を見ていきます。
まず、最初のデータポイントがNew Relicに届きます
次のデータポイントがNew Relicに届きます
ここで初めて最初のデータポイントの集計が始まります。
順次、次のデータポイントがNew Relicに届きます
次のデータポイントがNew Relicに届きます
ようやく集計時間のデータポイントが貯まりましたが、まだ閾値評価は始まりません
次のデータポイントがNew Relicに届きます
ここから評価が始まりますが、評価条件が for at least in 2 min のためインシデントになりません
次のデータポイントがNew Relicに届きます
ここですべての条件を満たしたため、インシデントが起票されます
私も最初の頃は delay という考え方に馴染めなくて、設定が何を意図しているのかなかなか腑に落ちなかったのですが、仕様として監視システム側の内部時計を使用しているのではなく、エンドポイントから発信されたデータに付属しているタイムスタンプ基準にインシデント設計をおこなっていることに起因していると推測しています。これはエンドポイントからNew Relicなどの監視システムにデータが届くまでの遅延を考慮する必要があるという点が、この delay という考え方の基礎となっており、これはNew Relicに限った話でもなく他の監視システムでも同様の仕組みが導入されています。
Event Timer
Event Timerとは
Event Timerは、不規則なデータ収集に適した方式です。
仕組み
- 最後のデータ到着からTimer時間経過後に集計
- データごとにタイマーがリセット
- 遅延データにも柔軟に対応
最適な使用シーン
- クラウドサービスの統合データ（APIポーリング方式）
- エラーログの監視
- バッチ処理の結果収集
具体例
監視条件が下記の場合の状況を順を追って見ていきましょう。
- 監視条件
- Window durationが60 (秒)
- timer=60 (秒)
- 閾値設定の評価時間が for at least once in 3 min
- データポイントは閾値設定を超えている
ここから実際のデータポイントとWindow duration、timer、評価時間の関係を見ていきます。
まず、最初のデータポイントがNew Relicに届きます
データは届かずに、時間が過ぎました
この間は後続のデータが届くかどうか待機しますが、データが届くとタイマーがリセットされて再度データが届くまでのカウントダウン（Timer=xx）が始まります
データは届かずに、さらに時間が過ぎました
ここで初めて閾値評価がはじまり、評価条件である3分間の間に1度でも検知にマッチしたためインシデントが起票されました
Cadence
Cadenceは従来の方式で、現在は非推奨となっています。
- 仕組み
- New Relicの内部時計で固定的に集計
- データの到着タイミングに関係なく定期実行
- シンプルだが柔軟性に欠ける
おおよその挙動に関しては監視システムの内部タイマーを使用した監視となっているため、従来型のシステムでよく使われている設定をイメージしていただければと思います。
使い分けのポイント
データの特性による選択
データの特性によってどのストリーミングメソッドを選択したらよいかについて表にまとめてみました。
| データの特性 | 推奨方式 | 理由 |
|---|---|---|
| 定期的なメトリクス | Event Flow | 正確な時系列での集計が可能 |
| 不規則なログ | Event Timer | データ欠損のリスクを軽減 |
| レガシーシステム | Cadence | 互換性維持が必要な場合 |
基本的にはEvent Flowを選択しつつも、場面場面によってEvent Timerを選択し、Event FlowでもEvent Timerでも監視設定が難しい場合のみCadenceを選択するのがよさそうです。
監視設計のベストプラクティス
New Relicのストリーミングメソッドを使い分ける際に、それぞれ下記の点に注意しながら設定すると安定した設定を行うことができます。
Event Flowを使用する場合
- Delay時間は想定される最大遅延より長めに設定
- アラート閾値は複数のウィンドウを考慮して設定
- データの欠損監視も併せて実装
Event Timerを使用する場合
- Timer時間はAggregation Window以上に設定
- データ到着の最大間隔を考慮
- アラートの遅延を考慮した設計
トラブルシューティング
最後によくある問題と対処方について簡単にまとめてみました。
よくある問題と対処法
データが集計されない
- Event Flow: Delay時間が短すぎないか確認
- Event Timer: Timer時間が適切か見直し
- データ送信側の遅延をチェック
アラートが遅れる
- 集計方式とWindow設定の見直し
- ネットワーク遅延の調査
- 監視設計の再検討
まとめ
いかがでしたでしょうか。New Relicのストリーミングメソッドは監視設計の要となる重要な機能で、Event Flow、Event Timer、Cadence の違いを理解した上で適切な方式を選択することで、より効果的な監視体制が構築できるでしょう。特にストリーミングメソッドは監視設計の際にとても重要なポイントになりますが、初見で理解しづらい内容になっているため、きっちり理解した上で監視設計を進めるとスムーズに監視導入ができると思います。
この記事がどなたかのお役に立てれば幸いです。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
