워크플로우는 의 기존 공지 시스템을 대체합니다. 워크플로우는 개선되고 유연한 공지 시스템이기 때문에 좋은 소식입니다. 워크플로우는 팀이 그리드의 더 큰 맥락 내에서 잠재적인 오류에 대해 학습하여 즉각적이고 효율적인 조치를 취할 수 있도록 도와줍니다.
이번 마이그레이션이 팀에 어떤 의미가 있나요? 이전 공지 모델에서 귀하의 팀은 다양한 레버 값, 컨테이너, 모델을 사용하여 공지 조건을 만들었습니다. 해당 조건이 특정 정책과 연관되어 있고 위반되었으며 팀이 이에 대해 즉시 알 수 있도록 하려면 notification settings 추가합니다. 우리의 공지 설정은 뉴렐릭에게 어떤 데이터를 어디로 보낼지 알려줍니다.
이제 워크플로를 추가했습니다. 앞으로는 클래식 알림 채널을 구성하고 이를 정책에 연결하는 대신 알림 대상이 생성되어 워크플로에 연결됩니다. 워크플로우는 다양한 정책의 데이터를 처리할 수 있으며 태그 또는 우선 순위와 같은 속성을 사용하여 알림을 구성할 수 있습니다.
뭘 기대 할까
기존 공지 시스템에서 워크플로우로의 마이그레이션은 각 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
는 웹후크를 제외한 모든 유형에 사용할 수 있는 경우 엔터티 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의 인시던트를 승인하거나 닫는 작업이 더 이상 작동하지 않게 됩니다.
커스텀 페이로드 구성
알림 채널에서 워크플로로 이동할 때 팀에서 사용자 지정 페이로드를 약간 조정해야 할 수 있습니다. 워크플로는 여전히 알림과 동일한 방식으로 작동합니다. 즉, 조건이 위반되면 알림이 웹훅으로 전송되고 전송되면 사용자 지정 페이로드와 함께 이동합니다. 알림 채널에서 워크플로로 마이그레이션하려면 이 페이로드의 일부 용어를 변경해야 합니다.
다음 표는 클래식 알림 시스템에서 사용되는 웹후크 페이로드 이름과 이슈 페이로드의 새로운 해당 이름 간의 변환을 제공합니다. 핸들바는 메시지 템플릿을 작성하는 데 사용되는 간단한 템플릿 언어입니다.
많은 키의 경우 문제 페이로드에 값 목록이 포함될 수 있습니다. 일대일 매핑을 제공하기 위해 첫 번째 값만 교체에 사용됩니다.
Alerts (classic) name | Alerts (classic) variable | Workflow message template replacement |
---|---|---|
|
|
|
|
|
|
|
|
모든 우선순위에서 종료된 인시던트 수입니다. |
|
|
경고 횟수를 대체할 수 없습니다. 종료된 모든 사고 수는 이중 계산 사고를 방지하기 위해 중요한 것으로 표시됩니다. |
|
|
사용자 정의 인시던트 설명(정의된 경우). |
|
|
|
| 해당 없음 |
조건에만 유효합니다. |
| 해당 없음 |
조건에만 유효합니다. |
|
|
|
|
|
문제의 상태에는 더 많은 상태가 있지만 확인된 상태는 없습니다. |
|
|
|
|
|
|
|
|
문제 수준에 일치하는 속성이 없습니다. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
우선 순위에 관계없이 모든 인시던트의 열린 인시던트 수입니다. |
|
|
우선 순위에 관계없이 모든 인시던트의 열린 인시던트 수입니다. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
문제에는 심각도와 다른 값을 가질 수 있는 우선 순위가 있습니다. |
|
|
|
|
|
|
|
|
|
|
|
문제 수준에 일치하는 속성이 없습니다. |
|
|
|
|
|
|