クエリ結果の「和」の閾値タイプからスライディングウィンドウ集約への変換

本投稿は「Converting “Sum of” thresholds to use Sliding Windows Aggregation」の抄訳です。

先日スライディングウィンドウ集約（SWA）機能を新しくリリースしました。より詳しい内容はこちらの投稿で確認できます。SWAはクエリ結果の「和」の閾値タイプの条件の上位互換を目指しており、近い内にクエリ結果の和の閾値タイプを置き換える方針です。この案内についてはこちらの投稿で発表しており、EOLの時期が近づいたらさらに詳細を行う予定です。

時期が近づけば、クエリ結果の和の閾値タイプの条件をSWAに変換するための移行ツールを、単一の条件のみおよび複数の条件まとめて変換できるよう提供する方針です。しかし、前もって変換しておきたい方や、変換ロジックがどのように適用されるか心配な方もいるでしょう。以下で、この変換ルールを直接適用したくない場合や、どのように変換されるかのロジックそのものについて説明します。

まず、クエリ結果の和の閾値タイプの条件を使いたい理由や直接SWAに変換したくない理由を探ってみましょう。

和の閾値タイプを使いたい主な2つの理由

多くの人が クエリ結果の「和」の閾値に価値を見出したのは、揮発性のデータストリームを滑らかにするために働くからです。これは意図されたユースケースであり、SWAはタイミングと集計方法をより細かく制御することができますが、クエリ結果の「和」の閾値もまたそのためによく機能します。このような理由で作成されたクエリ結果の「和」の閾値タイプがある場合、ストレートに変換することは非常に理にかなっています。

クエリ結果の「和」の閾値を使用するもうひとつの最も一般的な理由は、散発的なデータに関する問題に対処するためである。「クエリ結果の「和」は歴史的には、集計ウィンドウが1分に固定され、「ギャップ埋め（Gap Filling）」オプションもなかった時代に導入されました。そのため、サポートやアカウントチームから、散発的なデータを「平準化」するためにクエリ結果の「和」の閾値を使用するようアドバイスを受けたユーザー、あるいは自分で考えて見つけたユーザーがいます。この場合、「ギャップ埋め」を設定することで、より直接的にニーズに対応できるようになりました。「ギャップ埋め」の詳細については、以下のリンクを参照してください。

• Alerting: Loss of signal detection and configurable gap-filling strategies
• ストリーミング・アラート：重要な用語と概念 「ギャップ埋め」
• NRQLアラート条件を作成する「データのギャップを埋める」
• Relic Solution: How Can I Figure Out When To Use Gap Filling and Loss of Signal?

なお、これらの後者のタイプのクエリ結果の「和」の閾値条件をSWAに変換しても、条件の機能には影響がなく、以前と同じように機能することに留意してください。

さて、クエリ結果の「和」の閾値を不安定なデータの平滑化のために使用することと、ギャップ埋め戦略の欠如を補うために使用することの微妙な違いを理解していただいた上で、クエリ結果の「和」の閾値をからSWAに変換するためのロジックについて説明します。

クエリ結果の「和」の閾値条件からスライディングウィンドウ集約に手動で変換する方法

1. スライディングウィンドウ集約を使用するトグルをオンにします
2. 「lide by interval」を「Window duration」に表示されている値に設定します
3. 条件のしきい値期間を決め（例：「10分以上」「5分に1回以上」など）、「Window duration」をこの値に設定します。
4. 条件を保存する

既存のクエリ結果の「和」の閾値条件を手動で変換する場合は、このの手順を利用してください。ただし、UIベースの変換方法（単一のアラート条件用）と一括編集のためのNR1アプリを提供する予定であることを念頭に置いてください。

この記事が、クエリ結果の「和」閾値からスライディングウィンドウの集約への変換方法について理解を深める一助となれば幸いです。ご意見、ご質問等ございましたら、原文の投稿に返信いただくか、日本法人までお問い合わせください。