ワークフローは、従来の通知システムに取って代わります。 そして応用知性。 ワークフローは改良された柔軟な通知システムであるため、これは朗報です。 ワークフローは、チームがスタックのより大きなコンテキスト内で潜在的なエラーについて学習するのに役立ち、迅速かつ効率的なアクションを実行できるようにします。
この移行は あなたのチームにとって何を意味しますか?以前の通知モデルでは、チームはさまざまなしきい値とパラメーターを使用してアラート条件を作成します。その条件が特定のポリシーに関連付けられており、違反があり、それをチームにすぐに知らせたい場合は、 通知設定を追加します。通知設定は、New Relic にどのデータをどこに送信するかを指示します。
これで、ワークフローが追加されました。今後は、従来の通知チャネルを構成してポリシーに関連付ける代わりに、通知先を作成してワークフローに関連付けます。ワークフローは、さまざまなポリシーからのデータを処理でき、タグや優先度などの属性を使用して通知を整理できます。
何を期待します
従来の通知システムからワークフローへの移行により、従来の通知チャネルごとに宛先が作成され、ポリシーごとに作成されたワークフローに接続されます。チャネルが関連付けられているポリシーのみが移行されます。
- New Relic は、2023 年 1 月 23 日から 5 月 15 日までアカウントを自動的に移行します。
- New Relic はアカウントを早期に移行できます。アカウント チームに連絡してください。
- ポリシーからチャネルを削除することで、チームは自動移行を回避できます。
- 通知チャネル API と Terraform リソースは、2023 年 12 月 31 日まで引き続き機能します。
既知の変更
移行中に通知が大幅に変更されることはありません。それらは、同じ属性名とほとんど同じ値を持ち続けます。ワークフローへの移行により、以下が変更されます。
- すべての _url 属性値が変更され、インシデント ベースのページではなく、問題ベースのページにつながります。
condition_id
は常にcondition_family_id
と同じ値になります。 issue_id
追加されました。incident_id
はいずれ削除されるため、消費者はincident_id
} の代わりにissue_id
を使用するようにすべての統合を切り替える必要があります。radar_entity.entityGuid
また、targets[0].id
は、Webhook を除くすべてのタイプで使用できるエンティティ GUID になります。targets[0].labels
ターゲットによって定義されたエンティティのタグだけでなく、問題からのすべてのタグが含まれます。targets[0].link
そしてviolation_callback_url
は課題ページにつながります。open_violations_count.critical
すべての優先度にわたるすべてのオープン インシデントの数が含まれます。プライオリティ固有のカウントは利用できません。open_violations_count.warning
常に 0 になります。優先度固有のカウントは使用できません。closed_violations_count.critical
すべての優先度にわたるすべてのクローズされたインシデントの数が含まれます。プライオリティ固有のカウントは利用できません。closed_violations_count.warning
常に 0 になります。優先度固有のカウントは使用できません。owner
問題が認識されていない場合、値は NA になります。timestamp_utc_string
YYYY-MM-DD, HH:MM UTC
から ISO 8601 準拠のYYYY-MM-DDThh:mm:ss.sssZ
形式に切り替わります。violation_chart_url
グラフの生成が失敗したか、タイムリーに返されなかった場合、値はNot Available
になります。- メール送信者は
noreply@notifications.newrelic.com
に変わります。
インシデント_id
PagerDuty、Webhook、VictorOps、OpsGenie、および xMatters 通知の incident_id
は、従来のインシデント ID を参照します。クラシック インシデント ID は非推奨になりました。消費者は代わりに issue_id
の使用を開始する必要があります。
Incident_id
変更:
- 固有の
incident_id
は引き続き問題ごとに生成されます。この値は、非推奨のインシデント API で使用される値とは異なります。 - VictorOps、OpsGenie、および xMatters 通知への影響を制限するために、incident_id には課題 ID が入力されます。これにより、xMatters のインシデントを確認またはクローズする New Relic の手順が機能しなくなります。
カスタム ペイロードの構成
通知チャネルからワークフローに移行するとき、チームはカスタム ペイロードにいくつかの調整を加えたい場合があります。ワークフローは、条件に違反すると通知が Webhook に送信され、送信される際にはカスタム ペイロードとともに送信されるという点で、通知と同じように機能します。通知チャネルからワークフローに移行するには、このペイロード内の用語の一部を変更する必要があります。
次の表は、従来の通知システムで使用されている Webhook ペイロード名と、問題ペイロード内の対応する新しい名前の間の翻訳を示しています。Handlebars は、メッセージ テンプレートの作成に使用されるシンプルなテンプレート言語です。
多くのキーでは、問題のペイロードに値のリストが含まれる場合があります。1 対 1 のマッピングを提供するために、最初の値のみが置換で使用されます。
アラート (クラシック) 名 | アラート (クラシック) 変数 | ワークフロー メッセージ テンプレートの置き換え |
---|---|---|
|
|
|
|
|
|
|
|
すべての優先度にわたるクローズされたインシデントの数。 |
|
|
警告カウントに代わるものはありません。インシデントの二重カウントを避けるために、すべてのクローズされたインシデント カウントは重大として表されます。 |
|
|
カスタム インシデントの説明 (定義されている場合)。 |
|
|
|
| 該当なし |
のみ有効 条件。 |
| 該当なし |
のみ有効 条件。 |
|
|
|
|
|
問題の状態には複数の状態がありますが、承認済みの状態はありません。 |
|
|
|
|
|
|
|
|
問題レベルに一致する属性はありません。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
優先度に関係なく、すべてのインシデントのオープン インシデント カウント。 |
|
|
優先度に関係なく、すべてのインシデントのオープン インシデント カウント。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
問題には優先度があり、重大度とは異なる値を持つことができます。 |
|
|
|
|
|
|
|
|
|
|
|
問題レベルに一致する属性はありません。 |
|
|
|
|
|
|
まだお持ちでない場合は、以下で無料の New Relic アカウントを作成して、今すぐデータの監視を開始してください。