컨텍스트가 풍부한 경고를 통해 이벤트 해결 시간 단축

경고 유효 하중을 표시하는 것은 간단하지만 팀 응답 이벤트에 필요한 시간을 현저히 줄일 수 있다.본 블로그에서 Squadcast의 자동 표기 기능이 어떻게 스마트 표기와 경보 발송을 통해 최종적으로 MTTR을 낮추고 게임 규칙을 바꾸는지 이해한다.
심각한 정지가 발생했을 때, 대기 엔지니어들이 자주 직면하는 문제는 고장점을 정확하게 파악하는 것이다.비록 현대 모니터링 도구와 사건 관리 플랫폼은 모든 경보에 배경 정보를 제공했지만 여전히 개선할 여지가 있다.비교적 간단한 해결 방안은 경보 유효 하중에 라벨을 추가하는 것이다.
부르는 대로 오는 엔지니어로서 주요 경보를 분류하는 데 시간이 오래 걸릴 수 있습니다. 이것은 경보가 Kubernetes 설정에 부하되어 호스트 이름/그룹 상세 정보 등 관건적인 정보가 부족하기 때문입니다.
이 블로그에서는 MTTR(평균 응답 시간)을 줄이기 위해 유효 로드의 중요 정보에 레이블을 추가하는 방법을 알아봅니다.
프로메테우스 경보 관리자와 Squadcast withRouting, and Tagging rules가 특정 라벨이 달린 경보의 효과적인 하중을 관련 엔지니어에게 보내 문제를 빨리 복구할 수 있도록 하는 방법도 논의할 것이다.
주: 유효 하중 라벨은 유효 하중 데이터를 분류하고 관건적인 정보를 식별하는 데 사용할 수 있다.이 블로그에서 Kubernetes의 특정한 예시를 소개했지만 다른 모니터링 도구를 통해 실현할 수 있습니다.
다음 화면 캡처는 기본적으로 유효하게 부하되는 예시입니다. (탭이 없습니다.)

부르는 대로 엔지니어가 되려면 다음과 같은 경고에 대한 자세한 정보가 필요합니다.

IP 주소/호스트 이름

클러스터 ID 등

이 메시지 때문에유효 로드에서는 사용할 수 없습니다. 문제를 해결하기 위해 IP 주소를 수동으로 가져와야 합니다.
만약 당신이 IP 주소 같은 세부 사항을 얻을 수 있다면, 당신의 생활은 더욱 간단해질 것이다.경고 자체의 호스트 이름, 애플리케이션 이름, 심각도 수준, 환경 이름 등입니다.경고가 테스트/스테이지 환경에서 온 경우, 부하에 환경과 관련된 라벨이 있기 때문에 무시할 수 있습니다.
비교적 간단한 방법은 선택한 감시 도구를 사용하여 유효 부하에 라벨을 추가할 수 있다.다음 예제에서는 Prometheus Alert Manager를 사용하여 컨텍스트의 풍부한 경고 유효 로드를 생성합니다.
다음 화면 캡처는 프로메테우스 경보 관리자의 설정 파일의 예입니다. 이 파일은 상하문에 풍부한 유효 하중 라벨을 가지고 있습니다.

프로메테우스 경보 관리자 설정 파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pubsub
  namespace: laddertruck
  labels:
    name: "laddertruck"
    language: "ruby"
    language-version: "3.0.0"
    framework: "rails"
    framework-version: "5.2.1"
    team: "xyz"
    developed-by: "diane"
    service-owner: "john"

위에서 언급한 각종 라벨에 주의해라.

어떤 탭을 유효 부하에 추가할지 어떻게 결정합니까?

태그의 이름은 기술 스택의 유형과 대기팀에 따라 달라집니다.사용된 레이블 유형은 심각한 가동 중지 시간이 발생할 경우 가장 먼저 응답하기 때문에 대기 팀에서 결정해야 합니다.
아래에 표시된 레이블은 팀이 작업을 시작할 때 사용할 수 있는 몇 가지 일반 레이블입니다.

소유자: 이 태그는 서비스의 소유자를 식별합니다.

언어: 서비스에 사용되는 프로그래밍 언어.

프레임워크: 서비스의 프레임워크를 구축한다.만약 여러 서비스가 같은 언어로 작성되지만, 서로 다른 프레임워크를 사용한다면, 이 점은 매우 중요하다.

이제 프로메테우스 경보 관리자에 경보 규칙을 설정합니다.

- alert: ContainerMemoryUsage
  expr: (sum(container_memory_working_set_bytes{namespace="default"}) BY (instance, name) / sum(container_spec_memory_limit_bytes{namespace="default"} > 0) BY (instance, name) * 100) > 90
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: "Container Memory usage (instance {{ $labels.instance }})"
    description: "Container Memory usage is above 90%\n VALUE = {{ $value }}\n LABELS: {{ $labels }}"

위 규칙에서 심각도 조건은 경고 규칙에 정의되어 있습니다.
현재 Alert 관리자가 Squadcast에 경보를 보낼 때, 모든 관련 정보는 유효 부하에 포함됩니다. 예를 들어 심각성, 배치, Prometheus 프로필에 언급된 다른 탭입니다.우리는 Squadcastrouting rules를 이용하여 효과적으로 관련자/팀에게 사건을 관리/전달할 수 있다.
또한, 우리는alert 관리자의annotations 옵션을 이용하여 경보 부하에서 더욱 상세하고 지루한 정보를 보낼 수 있습니다.매뉴얼/실행 매뉴얼에 의존하여 대기하는 조직에서 엔지니어는 사건 발생 시 관련 매뉴얼을 검색하는 것이 아니라 즉시 고장 제거를 시작할 수 있다.

Image Source
그림에서 보듯이 프로메테우스에서 온 경보 알림에는 내부 운행 매뉴얼을 가리키는 링크가 포함되어 있다.

태그를 사용하여 Squadcast 구성

다음 화면 캡처에서 이벤트 부하에 추가된 탭에 따라 경보를 설정하는 방법을 볼 수 있습니다.여기서 구성하고 있는 서비스를 "K8s 클러스터 모니터링"이라고 합니다.

태그 규칙은 Squadcast에서 처리할 태그를 정의하는 데 사용됩니다.레이블이 정의되면 라우팅 규칙을 사용하여 관련자, 팀 또는 에스컬레이션 정책에 경고를 보낼 수 있습니다.

이제 유효 하중에 정의된 모든 레이블이 Squadcast에서 레이블로 인식됩니다.이 단계를 완료하면 태그에 따라 라우팅 규칙을 사용자 정의할 수 있습니다.

위의 화면 캡처에서 우리는 다음과 같은 기준에 따라'서비스 소유자','팀','배치자'세 개의 탭을 만들었다.

현재 이 표시들이 정의되어 있습니다. 우리는 서비스에 입도 이벤트 루트 규칙을 계속 만들 수 있습니다.위의 화면 캡처에서, 경보 부하가 '서비스 owner' 를 'john' 으로 정의하면, 경보 알림은john에게 직접 발송되는 루트 규칙을 만들고 있습니다.

위에서 알 수 있듯이 경보 부하에 '팀' 라벨이 있을 때 루트 규칙이 만들어집니다.우리는 경보 통지가 특정 단체로 발송되는 것을 볼 수 있다.

이 경우 이 기능을 배포한 사람에게 경고가 전송됩니다("Diane").

이전에 우리는 경보가 특정한 개인에게 발송되는 것을 보았지만, Aler를 미리 정의된 escalation policies 로 보낼 수도 있다.위의 캡처에서 우리는 같은 예를 보았다.

여러 개의 태그와 부울 연산자('and')를 선택하여 루트 규칙을 최대한 구체화하고 가능한 한 많은 장면을 포괄합니다.

Squadcast에서는 라우팅 규칙이 하향식으로 실행됩니다.첫 번째 규칙을 실행하면 나머지 규칙은 자동으로 무시됩니다.Execution Priority 기능은 규칙의 실시 순서를 정의하는 데 도움이 된다.

문맥 인식 경고의 기타 이점

대수리 후post-mortems / reviews 기간에 상세한 이벤트 시간표가 자동으로 만들어지기 때문에 모든 유효 부하 주위에 상하문 정보가 있으면 매우 도움이 된다.상하문이 풍부한 경보 유효 하중의 개념은 보기에는 간단하지만 장기적으로 보면 시스템의 신뢰성을 높이는 데 도움이 된다.
다음은 Squadcast의 이벤트 실례와 관련 탭을 볼 수 있습니다.이 규칙을 기반으로 하는 자동 태그 시스템이 있습니다. 이벤트의 유효 하중에 따라 사용자 정의 태그를 정의할 수 있으며, 이벤트를 터치할 때 자동으로 이벤트에 할당할 수 있습니다.

결론

많은 경우 기존 아키텍처의 특수한 복잡성을 줄여서는 안 됩니다.컨텍스트 경고 + 스마트 라우팅 조합이 MTTA 및 MTTR을 대폭 감소시키는 데 도움이 되는 이유입니다.
위에서 제시한 예는 빙산의 일각일 뿐입니다. 사용자 정의 라벨과 배선 규칙을 만들 수도 있습니다.새로운 사용자와 의존 관계가 증가함에 따라 인프라가 확장되고, 더 좋은 태그와 루트로 인해 MTTR은 받아들일 수 있는 범위 내에 있을 것입니다.
DevOps/SRE로서 어떤 어려움이 있습니까?당신은 조직 내에서 사고에 어떻게 더 잘 대처할 것인가에 대해 어떤 생각을 가지고 있습니까?너의 소식을 들으면 우리는 매우 흥분할 것이다.저희에게 메시지를 남기거나 DM을 통해 저희에게 연락하여 당신의 생각을 알려 주십시오.
Squadcast는 SRE용으로 설계된 이벤트 관리 도구입니다.팀은 불필요한 경보를 없애고 관련 통지를 받거나 가상 이벤트 작전실을 이용하여 협업을 할 수 있으며 런북 등 자동화 도구를 사용하여 힘든 작업을 없앨 수 있습니다.