31.1. Alertmanager ServiceNow 웹훅 설정

예상 소요 시간: 2시간

작동 가능한 구성요소 소유자: TS

이 문서에는 Alertmanager ServiceNow 웹훅을 구성하고 활성 ServiceNow 티켓팅 시스템 인스턴스에서 알림을 만들 수 있도록 하는 안내가 포함되어 있습니다.

31.1.1. 시작하기 전에

ServiceNow 웹훅을 설정하기 전에 다음 단계를 따르세요.

  1. 보안 비밀 midserver-secret을 수동으로 만듭니다.
  2. TS-R0012 런북의 단계에 따라 보안 비밀을 올바르게 설정합니다.
  3. yq이 시스템에 설치되어 있는지 확인합니다.

    root@bootstrapper:~# yq --version
    yq (https://github.com/mikefarah/yq/) version v4.40.4
    
  4. obs-system 네임스페이스의 객체에 액세스하고 ServiceNow 애플리케이션을 관리하는 데 필요한 권한을 얻으려면 보안 관리자에게 다음 역할을 부여해 달라고 요청하세요.

    • 관측 가능성 디버거 (루트 관리자 클러스터의 경우 observability-admin-debugger, 조직 관리자 및 시스템 클러스터의 경우 observability-system-debugger)
    • Grafana 뷰어 (grafana-viewer)
    • ServiceNow 관리자 (system-service-now-admin)

    이러한 역할에 대한 자세한 내용은 인프라 운영자 역할을 참고하세요.

31.1.2. 웹훅 설정

Alertmanager ServiceNow 웹훅을 구성하려면 다음 단계를 따르세요.

  1. 조직에서 ServiceNow 웹훅을 구성할 수 있습니다.

    조직의 시스템 클러스터에서 ServiceNow 웹훅을 구성하려면 인프라 운영자 (IO)에게 다음 정보를 사용하여 OPA-R0005 런북을 실행하도록 요청하세요.

    • IO_GROUP 환경 변수의 값은 사용자가 속한 사용자 그룹입니다.
    • CONSTRAINT_NAME 환경 변수의 값은 restrict-system-project-namespace-resources입니다.
  2. 조직의 알림을 기반으로 인시던트를 만들 ServiceNow 서비스 계정을 만듭니다.

    1. ServiceNow 웹 인터페이스 URL을 엽니다.

      https://support.gdchservices.GDC_URL/navpage.do
      

      GDC_URL을 Google Distributed Cloud (GDC) 에어갭의 조직 URL로 바꿉니다.

      항상 gdchservices을 Operations Center IT 조직 이름으로 사용합니다.

    2. 모두 > 사용자 관리 > 사용자를 선택합니다.

    3. New(새로 만들기)를 클릭합니다.

    4. 새 창에 다음 값을 입력합니다.

      • 사용자 ID 필드에 SVC_ALERT_ORG를 입력합니다.
      • 이름 필드에 SVC_ALERT_ORG를 입력합니다.
      • 웹 서비스 액세스만 체크박스를 선택합니다.

      ORG을 조직 이름으로 바꿉니다. 루트 관리자 클러스터에서 이 단계를 실행할 때는 ORG 이름에 root 값을 사용하세요.

    5. 제출을 클릭합니다.

      새 사용자 레코드가 ServiceNow 계정 목록에 표시됩니다.

  3. itil 역할을 서비스 계정에 추가합니다.

    1. 목록에서 사용자 레코드를 엽니다.

    2. 역할 탭을 클릭한 다음 수정... 버튼을 클릭합니다.

    3. 컬렉션 메뉴에서 itil 역할을 선택합니다.

    4. 추가 () 버튼을 클릭하여 역할을 역할 목록 메뉴로 이동합니다.

    5. 저장을 클릭합니다.

  4. ServiceNow 서비스 계정의 비밀번호를 설정합니다.

    1. 목록에서 사용자 레코드를 엽니다.

    2. 비밀번호 설정을 클릭한 다음 생성을 클릭합니다.

    3. 창에 표시된 비밀번호를 복사하여 안전한 곳에 보관합니다.

    4. 비밀번호 저장을 클릭하고 창을 닫습니다.

  5. 명령줄 인터페이스를 엽니다.

  6. 다음 환경 변수를 설정합니다.

    export ORG=ORGANIZATION
    export SERVICENOW_INSTANCE_URL=SERVICENOW_INSTANCE_URL
    export SERVICENOW_USERNAME=SERVICENOW_USERNAME
    export SERVICENOW_PASSWORD=SERVICENOW_PASSWORD
    export SERVICENOW_AUTORESOLVE=SERVICENOW_AUTORESOLVE
    export SERVICENOW_AUTORESOLVE_REOPEN_DURATION=SERVICENOW_AUTORESOLVE_REOPEN_DURATION
    

    다음을 바꿉니다.

    • ORGANIZATION: 조직 이름
    • SERVICENOW_INSTANCE_URL: ServiceNow 웹 인터페이스 URL(예: https://support.gdchservices.GDC_URL)
    • SERVICENOW_USERNAME: ServiceNow 서비스 계정의 사용자 이름
    • SERVICENOW_PASSWORD: ServiceNow 서비스 계정의 비밀번호
    • SERVICENOW_AUTORESOLVE: 해당 알림이 트리거되지 않으면 ServiceNow 인시던트를 자동으로 해결하려면 'true'를, 그렇지 않으면 'false'를 지정합니다.
    • SERVICENOW_AUTORESOLVE_REOPEN_DURATION: 동일한 알림이 다시 발생할 경우 해결된 ServiceNow 인시던트를 다시 열 수 있는 기간입니다. 예: '5m', '30s', '24h' 등
  7. 다음 명령어를 실행합니다.

    cat << EOF > ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    apiVersion: lcm.private.gdc.goog/v1
    kind: SubcomponentOverride
    metadata:
      name: mon-alertmanager-servicenow-webhook
    spec:
      subComponentRef: "mon-alertmanager-servicenow-webhook"
      backend:
        operableParameters:
          servicenowCredentials:
            instanceName: ${SERVICENOW_INSTANCE_URL:?}
            username: ${SERVICENOW_USERNAME:?}
            password: ${SERVICENOW_PASSWORD:?}
          serviceNowSettings:
            autoResolve: ${SERVICENOW_AUTORESOLVE:?}
            autoResolveReopenDuration: ${SERVICENOW_AUTORESOLVE_REOPEN_DURATION:?}
    EOF
    cat << EOF > ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    apiVersion: lcm.private.gdc.goog/v1
    kind: SubcomponentOverride
    metadata:
      name: meta-alertmanager-servicenow-webhook
    spec:
      subComponentRef: "mon-meta-monitoring"
      backend:
        operableParameters:
          servicenowCredentials:
            instanceName: ${SERVICENOW_INSTANCE_URL:?}
            username: ${SERVICENOW_USERNAME:?}
            password: ${SERVICENOW_PASSWORD:?}
          serviceNowSettings:
            autoResolve: ${SERVICENOW_AUTORESOLVE:?}
            autoResolveReopenDuration: ${SERVICENOW_AUTORESOLVE_REOPEN_DURATION:?}
    EOF
    cat << EOF > ~/ts-networking-subcomponentoverride.yaml
    apiVersion: lcm.private.gdc.goog/v1
    kind: SubcomponentOverride
    metadata:
      name: ts-networking
    spec:
      subComponentRef: "ts-networking"
      backend:
        operableParameters:
          serviceNowEndpoint: ${SERVICENOW_INSTANCE_URL:?}
    EOF
    
  8. 다음 단계를 따라 클러스터에서 ServiceNow 웹훅을 구성합니다.

루트 관리자 클러스터

  1. 다음 환경 변수를 설정합니다.

    export ROOT_KUBECONFIG=PATH_TO_ROOT_ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • PATH_TO_ROOT_ADMIN_KUBECONFIG: 루트 관리자 클러스터의 kubeconfig 파일 경로
  2. 웹훅 배포를 찾습니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get deployment mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력에 READY 상태가 표시되어야 하며 다음 샘플과 같이 표시됩니다.

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. configmap YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get configmap/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Secret YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get secret/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. configmap YAML 파일을 구성합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n root -f ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    예상 출력:

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. 네트워킹을 구성합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n root -f ~/ts-networking-subcomponentoverride.yaml
    

    예상 출력:

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. 보조 모니터링 스택의 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. alertmanager-servicenow-webhook 배포의 로그를 확인하여 구성을 검증합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. 로그에 listening on: :9877 문자열이 포함되어 있으면 구성이 완료된 것입니다. 그렇지 않은 경우 문제 해결 지원을 요청하세요.

  11. 웹훅 배포를 찾습니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get deployment meta-alertmanager-servicenow-webhook -n mon-system
    

    출력에 READY 상태가 표시되어야 하며 다음 샘플과 같이 표시됩니다.

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. configmap YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get configmap/meta-alertmanager-servicenow-webhook -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Secret YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get secret/meta-alertmanager-servicenow-webhook -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. configmap YAML 파일을 구성합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    예상 출력:

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n mon-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. 보조 모니터링 스택의 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. meta-alertmanager-servicenow-webhook 배포의 로그를 확인하여 구성을 검증합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. 로그에 listening on: :9877 문자열이 포함되어 있으면 구성이 완료된 것입니다. 그렇지 않은 경우 문제 해결 지원을 요청하세요.

조직 인프라 클러스터

  1. 다음 환경 변수를 설정합니다.

    export ROOT_KUBECONFIG=PATH_TO_ROOT_KUBECONFIG
    export INFRA_KUBECONFIG=PATH_TO_INFRA_KUBECONFIG
    

    다음을 바꿉니다.

    • PATH_TO_ROOT_ADMIN_KUBECONFIG: 루트 관리자 클러스터의 kubeconfig 파일 경로
    • PATH_TO_INFRA_KUBECONFIG: 인프라 클러스터의 kubeconfig 파일 경로
  2. 웹훅 배포를 찾습니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get deployment mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력에 READY 상태가 표시되어야 하며 다음 샘플과 같이 표시됩니다.

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. configmap YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get configmap/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Secret YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get secret/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. configmap YAML 파일을 구성합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    예상 출력:

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. 네트워킹을 구성합니다.

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/ts-networking-subcomponentoverride.yaml
    

    예상 출력:

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. 보조 모니터링 스택의 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. alertmanager-servicenow-webhook 배포의 로그를 확인하여 구성을 검증합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. 로그에 listening on: :9877 문자열이 포함되어 있으면 구성이 완료된 것입니다. 그렇지 않은 경우 문제 해결 지원을 요청하세요.

  11. 웹훅 배포를 찾습니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get deployment meta-alertmanager-servicenow-webhook -n mon-system
    

    출력에 READY 상태가 표시되어야 하며 다음 샘플과 같이 표시됩니다.

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. configmap YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get configmap/meta-alertmanager-servicenow-webhook -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Secret YAML 파일이 있는지 확인합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get secret/meta-alertmanager-servicenow-webhook -n mon-system
    

    출력은 다음 샘플과 같이 표시되어야 합니다.

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. configmap YAML 파일을 구성합니다.

    kubectl --kubeconfig "${ROOT_ADMIN_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    예상 출력:

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n mon-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. 보조 모니터링 스택의 웹훅 배포를 다시 시작합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    출력은 다음 예와 같이 성공을 확인합니다.

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. meta-alertmanager-servicenow-webhook 배포의 로그를 확인하여 구성을 검증합니다.

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. 로그에 listening on: :9877 문자열이 포함되어 있으면 구성이 완료된 것입니다. 그렇지 않은 경우 문제 해결 지원을 요청하세요.

31.1.3. 구성 확인

다음 단계에 따라 구성이 성공적으로 완료되었는지 확인합니다.

  1. ServiceNow 웹 인터페이스 URL을 엽니다.

    https://support.gdchservices.GDC_URL/navpage.do
    

    GDC_URL을 Google Distributed Cloud (GDC) 에어갭의 조직 URL로 바꿉니다.

  2. 서비스 데스크 > 인시던트 페이지로 이동합니다.

  3. GDC 유니버스에 있는 각 조직에 IgnoreThisAlwaysFiringAlert이라는 간단한 설명이 포함된 인시던트가 있는지 확인합니다.

  4. 다음 필드가 인시던트에 입력되어 있는지 확인합니다.

    • 숫자
    • 우선순위
    • 발신자
    • 구성요소 코드
    • 영역 ID
    • 인시던트 상태
    • 조직 ID
    • 영역 ID
    • 간단한 설명
    • 설명 (지문이 포함되어야 함)