アラートとAI機能に関する大規模変更について

2022年10月31日更新:追加・廃止予定時期などを更新し、詳細を編集しました。

2022年1月31日更新: 追加・廃止予定時期を更新しました

Big News For Alerts and Applied Intelligence  の抄訳記事です。

弊社ではアラートとAIの新機能の開発と、旧機能の廃止を慎重に検討しています。以下では、期待される新機能、廃止される機能、そして変更に備えてお客様ができることをご紹介します。

なお、今回の発表は今後1年間に向けた必要な作業を計画していただくための早期発表です。計画を立てる際の参考になるように、すべての日程が確定しているわけではありませんが大まかなスケジュールを発表いたします。

なぜこのようなことをしているのでしょうか？

一言で言えば、全く新しいアラートのライフサイクル体験を提供するためです。解決までの時間を短縮し、ノイズを減らし、信頼性を向上させます。

お客様からのフィードバックをもとに、インシデント対応のための全く新しいワークフローを設計しました。このワークフローでは、中核となるインシデントに関連する他の異常を関連付けることで、お客様のシステム全体で起こりうる問題の原因を可視化します。今回計画している変更点の一部は、この新しいワークフローに直接関連しています。

さらに、アラートの設定を簡素化し、アラート条件を1種類に統一することで、より詳細な機能を提供し、信頼性を高めることができます。今回の変更点の中には、アラートの条件とその作成プロセスの合理化に関連するものもあります。

最後に、「クエリ結果の合計」オプションを使用していたしきい値に、より柔軟性と回復力を提供する全く新しい評価方法（スライディングウィンドウ集計）を導入します。

これらの取り組みには、新機能の導入と旧機能の廃止が含まれます。

何が追加されますか？

• リリース済 新しいインシデント対応エクスペリエンス（2022年1月）
  • インシデントとバイオレーションに代わって、イシューとインシデントが導入されます。
  • 新しいイシューページでは、イシューに関連する詳細情報が表示されます。
  • 新しいNerdgraph API機能
• リリース済 通知を管理する新しい方法（2022年1月）
  • 移行に関する詳細については、Notification ChannelからWorkflow/Destinationsへの移行計画についてをご覧ください。
  • 新しい名称：DestinationsおよびWorkflows
  • 柔軟性と設定性の向上
  • 警告のしきい値で通知する機能
  • 通知内容を設定可能
• 進行中 アラートタイプの合理化と簡素化（2022年10月）
  • すべてのアラート条件はNRQLを使って設定できるようになり、NRQL条件の使い方だけを覚えればよいことになります。
  • プラットフォーム全体でのアラート作成の統合
• リリース済 スライディングウィンドウ集計により、柔軟な平均値の評価が可能に（2022年2月）
  • これは「クエリ結果の合計」のしきい値を置き換えます。
  • これによりアラートで監視するシグナルをよりコントロールできるようになります。

何が廃止されますか？

• 完了 現在のインシデント対応のワークフロー（新しいインシデント対応のエクスペリエンスに置き換えられます）（2022年10月）
  • インシデントページ
  • バイオレーションの詳細ページ
  • インシデントとバイオレーションのAPI（まだ利用可能ですが、将来的に廃止される予定です）
• 完了 "Sum of query results”（クエリー結果の合計）しきい値 (スライディングウィンドウ集計に置き換えられます）(2022年6月)
  • 詳細についてはアラート："Sum of query results"のEOLと移行ツールのリリースを参照してください。
  • "Sum of query results”（クエリー結果の合計）しきい値のスライディングウィンドウ集計への置き換えは完了しました。
• 完了 異常値のNRQLアラート条件タイプ（置き換える新機能はありません）（2022年3月31日）
  • 利用が少ないため、この機能は廃止となります。
  • 詳細についてはNRQLアラート条件の異常値検出のEOLを参照してください。
  • こちらの廃止については完了しました。
• 進行中 通知チャネルとポリシーの関係（通知を管理する新しい方法であるDestinationsとWorkflowsに置き換えられます）（2022年8月〜2023年2月）
  • 詳細については、Notification ChannelからWorkflow/Destinationsへの移行計画についてをご覧ください。
• その次  すべてのアラート条件タイプは、あらゆるエンティティの種類とテレメトリー信号を監視するために使用できる共通のアラート条件エクスペリエンスに統一される予定です。
  • すべてのアラート条件タイプエクスペリエンスは2023年後期までに統合される予定です。
  • NRQLアラート条件のエクスペリエンスは顕著に機能拡張され、統合されたアラートエクスペリエンスの基礎として使われます。
  • 現在の計画では、エクスペリエンスの統一に関してお客様の作業は不要な予定です。
  • 既存のアラートAPIはすべて、2024年半ばまで維持される予定です。NRQLアラート条件APIが唯一のAPIとなる予定です。
  • 開発者がNRQLアラート条件APIで一元管理できることを助けるツールを提供する予定です。

準備のために何をすべきですか？

このセクションでは、上述の機能が廃止される前に行う必要のある変更について説明します。

• インシデントまたは違反の詳細に関連するAPIを使用している場合、またはインシデントの承認/クローズなどのアクションを実行している場合、インシデント（旧称：バイオレーション）およびイシュー（旧称：インシデント）のNerdgraphの新しいエンドポイントを使用するようにスクリプトを修正する必要があります。
  • これらの機能にAPIを使用していない場合は、新しいインシデントワークフローのために何かする必要はありません。
• 従来のアラートチャンネルを管理する自動化スクリプトをアップグレードし、WorkflowsとDestinationsに対応したNerdGraph APIまたはTerraformリソースを利用するようにしてください。
• NRQLアラート条件以外のアラート条件を管理する自動化スクリプトを、NRQLアラート条件のAPIを使用するように変換します。 移行を支援するツールは提供されます。

これらの変更点をどのように把握すればよいですか？

このスレッド（原文）をフォローしてください。最新の情報や手順はここに掲載されます。

ヘルプはどこにありますか？

サポートが必要な場合は、アカウントチームにご連絡ください。また、このスレッドでご質問いただくことも可能です。