ワークフローは、 の従来の通知システムに代わるものです。 これは朗報です。ワークフローは改良された柔軟な通知システムだからです。 ワークフローは、チームがスタックのより大きなコンテキスト内で潜在的なエラーを把握するのに役立ち、迅速かつ効率的なアクションを実行できます。
この移行はあなたのチームにとって何を意味しますか? 以前の通知モデルでは、チームは異なる閾値と論点を持つアラート条件を作成します。 その条件が特定のポリシーに関連付けられており、違反があり、それをチームにすぐに知らせたい場合は、 notification settingsを追加します。 通知設定により、New Relic にどのデータをどこに送信するかが伝えられます。
これで、ワークフローが追加されました。今後は、従来の通知チャネルを構成してポリシーに関連付ける代わりに、通知先を作成してワークフローに関連付けます。ワークフローは、さまざまなポリシーからのデータを処理でき、タグや優先度などの属性を使用して通知を整理できます。
何を期待します
クラシック通知システムからワークフローへの移行では、各classic notification channelにdestinationが作成され、各policy.に作成されたworkflowsに接続されます。チャネル関連付けのあるポリシーのみが移行されます。
- 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 のマッピングを提供するために、最初の値のみが置換で使用されます。
Alerts (classic) name | Alerts (classic) variable | Workflow message template replacement |
---|---|---|
|
|
|
|
|
|
|
|
すべての優先度にわたるクローズされたインシデントの数。 |
|
|
警告カウントに代わるものはありません。インシデントの二重カウントを避けるために、すべてのクローズされたインシデント カウントは重大として表されます。 |
|
|
カスタム インシデントの説明 (定義されている場合)。 |
|
|
|
| 該当なし |
条件に対してのみ有効です。 |
| 該当なし |
条件に対してのみ有効です。 |
|
|
|
|
|
問題の状態には複数の状態がありますが、承認済みの状態はありません。 |
|
|
|
|
|
|
|
|
問題レベルに一致する属性はありません。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
優先度に関係なく、すべてのインシデントのオープン インシデント カウント。 |
|
|
優先度に関係なく、すべてのインシデントのオープン インシデント カウント。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
問題には優先度があり、重大度とは異なる値を持つことができます。 |
|
|
|
|
|
|
|
|
|
|
|
問題レベルに一致する属性はありません。 |
|
|
|
|
|
|