New Relic 2026年8月7日アップデート情報
はじめに
今回はQiitaコミュニティから、New Relic Workflow Automationを活用した月次バッチの非実行検出に関する解説ガイドが公開されています。バッチジョブの監視自動化という、SRE業務において実践的なテーマを扱った内容となっており、特に定期実行ジョブの信頼性向上に課題を持つチームにとって参考となる情報です。
注目アップデート深掘り
New Relic Workflow Automationを活用した月次バッチ監視の実装
バッチジョブの監視、特に月次や週次といった低頻度の定期実行タスクの監視は、SRE業務における古典的な課題の一つです。実行タイミングが限られているため、障害が発生してもすぐに気付けず、次回実行時まで問題が放置されるリスクがあります。
この課題に対する素直な発想は、New Relic の信号損失（Signal Loss）機能を使って「来るはずのメトリクスが来ない」ことを検知する方法です。しかし解説ガイドは、この方法が月次バッチには使えないことを出発点にしています。信号損失の閾値の有効期限は最大48時間であり、これを超える間隔で実行される月次バッチの非実行検知には、そもそも設定できないためです。
そこで採られているのが、Workflow Automation で「期待される実行時間帯にメトリクスが存在するか」を能動的にポーリングし、存在しなければカスタムイベントを送出するというアプローチです。ガイドでは月次実行の AWS Lambda 関数（go-runtime）を対象に、以下の構成が示されています。
Workflow Automation を月次・日本時間 10:00 に1回実行するようスケジュールする
ワークフロー内で NRQL クエリを実行し、想定実行ウィンドウ（9:30〜9:40）における Lambda のメトリクス件数を数える
SELECT count(provider.functionName) AS count FROM ServerlessSample WHERE provider='LambdaFunction' AND provider.functionName = 'go-runtime' SINCE '09:30:00 +0900' UNTIL '09:40:00 +0900'件数が 0 だった場合に、
BatchExecutedカスタムイベントをexecuted = 'false'属性付きで送信するそのカスタムイベントを監視するアラート条件（
SELECT count(*) FROM BatchExecuted WHERE executed = 'false'、ウィンドウ1分、しきい値 1 以上）を作成する
ポイントは、バッチ側に完了通知メトリクスを送信する実装を追加する必要がない点です。既に取得済みの Lambda メトリクスの不在を、ワークフローが定刻にチェックしてイベント化するため、監視対象アプリケーションへの改修を伴いません。
SRE視点での活用ポイント
バッチ監視における実践的な適用シナリオ
ガイドの対象は月次実行の Lambda 関数ですが、「定刻に NRQL で存在確認し、無ければイベント化する」という骨格自体はバッチ処理の実行基盤を問いません。ECS Scheduled Tasks や EC2 上の cron ジョブなど、New Relic 側に何らかのテレメトリが届いている定期実行であれば、NRQL クエリの対象イベント型と絞り込み条件を差し替えるだけで同じ構成に載せられます。
導入時に決める必要があるのは、主に3点です。第一に、実行の有無を判定する NRQL のイベント型（Lambda なら ServerlessSample）と識別子。第二に、想定実行ウィンドウ（ガイドの例では10分幅）。第三に、ワークフローを起動するスケジュールです。ウィンドウはバッチの実行時刻のブレを吸収できる幅に取る必要があり、狭すぎると正常実行を非実行と誤判定します。
注意点としては、バッチ実行時間が変動する場合や、祝日などで実行スケジュールが変わる場合への対処が挙げられます。ワークフローのスケジュールと NRQL のウィンドウはいずれも固定値として設定するため、実行スケジュールの変動が大きい場合は、ウィンドウ幅の見直しやメンテナンスウィンドウの活用が必要になります。
また、検知結果が通常のアラート条件として表現されるため、既存の通知チャネルやインシデント管理のワークフローにそのまま乗せられる点も、運用への組み込みやすさという観点でメリットになります。
全アップデート一覧
| カテゴリ | 対象 | 概要 | リンク |
|---|---|---|---|
| Other | Workflow Automation | New Relic Workflow Automationを使った月次バッチの非実行検出方法の解説。信号損失（Signal Loss）が閾値の有効期限上限48時間により月次バッチに適用できないことを踏まえ、定刻のNRQLポーリングとカスタムイベント送出で代替する実装手法を紹介 | 詳細 |
Note: Signal Loss（信号損失）は、New Relicが一定時間メトリクスやイベントを受信しなかった場合にアラートを発火させる機能ですが、閾値の有効期限は最大48時間です。Workflow Automationは、スケジュールやトリガーに応じてNRQLクエリの実行やカスタムイベント送信などの処理を自動実行する仕組みで、本ガイドではこの48時間の制約を回避する手段として使われています。
まとめ
今回は公式リリースではなく、コミュニティによる技術解説ガイドの紹介でしたが、バッチジョブ監視という実務上重要なテーマを扱った実践的な内容でした。信号損失の48時間という制約を正面から指摘したうえで、Workflow AutomationによるNRQLポーリングとカスタムイベント送出という回避策を具体的なクエリ付きで示している点に、このガイドの実用的な価値があります。
特に月次や週次といった低頻度のバッチ処理は、実行タイミングが限られているため見落としが発生しやすく、ビジネスへの影響も大きくなりがちです。監視対象アプリケーション側の改修を必要とせず、既に収集済みのテレメトリの不在を判定する構成であるため、すでにNew Relicを導入している環境であれば追加の実装コストを抑えて導入できます。