ワークフローは、 の従来の通知システムに代わるものです。 これは朗報です。ワークフローは改良された柔軟な通知システムだからです。 ワークフローは、チームがスタックのより大きなコンテキスト内で潜在的なエラーを把握するのに役立ち、迅速かつ効率的なアクションを実行できます。
この移行はあなたのチームにとって何を意味しますか? 以前の通知モデルでは、チームは異なる閾値と論点を持つアラート条件を作成します。 その条件が特定のポリシーに関連付けられており、違反があり、それをチームにすぐに知らせたい場合は、 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_stringYYYY-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 |
|---|---|---|
|
|
|
|
|
|
|
|
すべての優先順位にわたるクローズされたイベントの数。 |
|
|
警告カウントに代わるものはありません。集中イベントの二重カウントを避けるため、クローズされた集中イベントのカウントはすべてクリティカルとして表示されます。 |
|
|
カスタムの集中イベントの説明 (定義されている場合)。 |
|
|
|
| 該当なし |
条件に対してのみ有効です。 |
| 該当なし |
条件に対してのみ有効です。 |
|
|
|
|
|
問題の状態には複数の状態がありますが、承認済みの状態はありません。 |
|
|
|
|
|
|
|
|
問題レベルに一致する属性はありません。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
優先度に関係なく、すべての集中イベントのオープン数。 |
|
|
優先度に関係なく、すべての集中イベントのオープン数。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
問題には優先度があり、重大度とは異なる値を持つことができます。 |
|
| |
|
|
|
|
|
|
|
|
問題レベルに一致する属性はありません。 |
|
|
|
|
|
|