통합(Integrations)

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • GitLab 12.4에서 도입되었습니다.
  • GitLab 12.8에서 GitLab Ultimate에서 GitLab Free로 이동되었습니다.

GitLab는 웹훅 수신기를 통해 모든 소스에서 알림을 수락할 수 있습니다. 알림 알림페이징을 트리거하여 온콜 로테이션을 사용하거나 사고를 생성하는 데 사용할 수 있습니다.

통합 목록

Maintainer 역할을 갖고 있으면 프로젝트의 사이드바 메뉴에서 Settings > Monitor로 이동하여 구성된 알림 통합 목록을 볼 수 있습니다. 목록에는 통합 이름, 유형 및 상태(활성화 또는 비활성화)이 표시됩니다:

현재 통합

구성(Configuration)

GitLab는 구성한 HTTP 엔드포인트를 통해 알림을 받을 수 있습니다.

단일 HTTP 엔드포인트

GitLab 프로젝트에서 HTTP 엔드포인트를 활성화하면 JSON 형식의 알림 페이로드를 받을 수 있습니다. 원하는 대로 페이로드를 사용자 정의할 수 있습니다.

  1. Maintainer 역할을 갖고 있는 사용자로 GitLab에 로그인합니다.
  2. 프로젝트에서 Settings > Monitor로 이동합니다.
  3. Alerts 항목을 확장하고, Select integration type 드롭다운 목록에서 HTTP Endpoint를 선택합니다.
  4. Active 알림 설정을 토글합니다. 웹훅 구성의 URL 및 인증 키는 통합을 저장한 후 View credentials 탭에서 확인할 수 있습니다. 외부 서비스에도 URL과 인증 키를 입력해야 합니다.

HTTP 엔드포인트

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

GitLab Premium에서는 JSON 형식으로 외부 소스에서 알림을 받기 위해 여러 고유한 HTTP 엔드포인트를 만들 수 있으며, 페이로드를 사용자 정의할 수 있습니다.

  1. Maintainer 역할을 갖고 있는 사용자로 GitLab에 로그인합니다.
  2. 프로젝트에서 Settings > Monitor로 이동합니다.
  3. Alerts 항목을 확장합니다.
  4. 생성하려는 각 엔드포인트에 대해:

    1. Add new integration을 선택합니다.
    2. Select integration type 드롭다운 목록에서 HTTP Endpoint를 선택합니다.
    3. 통합에 이름을 지정합니다.
    4. Active 알림 설정을 토글합니다. 웹훅 구성의 URLAuthorization Key는 통합을 저장한 후 View credentials 탭에서 확인할 수 있습니다. 외부 서비스에도 URL과 인증 키를 입력해야 합니다.
    5. 다음은 선택 사항입니다. 모니터링 도구의 알림을 GitLab 필드에 매핑하려면 샘플 페이로드를 입력하고 Parse payload for custom mapping을 선택합니다. 유효한 JSON이 필요합니다. 샘플 페이로드를 업데이트하면 필드도 다시 매핑해야 합니다.
    6. 선택 사항입니다. 유효한 샘플 페이로드를 제공했다면 Payload alert key의 각 값 중에서 GitLab alert key에 매핑할 값을 선택합니다.
    7. 통합을 저장하려면 Save Integration을 선택합니다. 원하는 경우, 통합 저장 후 Send test alert 탭에서 통합의 테스트 알림을 전송할 수 있습니다.

새로운 HTTP 엔드포인트는 통합 목록에 표시됩니다. 통합 목록 오른쪽에 있는 설정 아이콘을 선택하여 통합을 편집할 수 있습니다.

사용자 정의 경고 매핑(Mapping)

모니터링 도구의 경고 형식을 GitLab 경고와 통합할 수 있습니다. HTTP 엔드포인트를 생성할 때 GitLab 필드에 경고 필드를 매핑하여 Alert listAlert Details page에 올바른 정보를 표시할 수 있습니다.

알림 관리 목록

GitLab 외부에서 알림 페이로드 사용자 정의

사용자 정의 매핑 없는 HTTP 엔드포인트의 경우 다음 매개변수를 전송하여 페이로드를 사용자 정의할 수 있습니다. 모든 필드는 선택 사항입니다. 들어오는 알림에 Title 필드의 값이 포함되지 않은 경우 기본 값 New: Alert가 적용됩니다.

속성 타입 설명
title 문자열 경고의 제목.
description 문자열 문제에 대한 개략적인 요약.
start_time 날짜 및 시간 경고 시간. 제공되지 않으면 현재 시간이 사용됩니다.
end_time 날짜 및 시간 경고의 해결 시간. 제공되는 경우 경고가 해결됩니다.
service 문자열 영향을 받는 서비스.
monitoring_tool 문자열 연관된 모니터링 도구의 이름.
hosts 문자열 또는 배열 발생한 이슈의 하나 이상의 호스트.
severity 문자열 경고의 심각성. 대소문자를 구분하지 않습니다. critical, high, medium, low, info, unknown 중 하나일 수 있습니다. 누락된 경우나 이 목록에 값이 없는 경우 기본값은 critical입니다.
fingerprint 문자열 또는 배열 경고의 고유 식별자. 동일한 경고 발생을 그룹화하는 데 사용될 수 있습니다. generic_alert_fingerprinting 기능이 활성화된 경우 페이로드( start_time, end_time, hosts 매개변수 제외)를 기반으로 자동으로 fingerprint가 생성됩니다.
gitlab_environment_name 문자열 연관된 GitLab 환경의 이름. 대시보드에 경고 표시를 위해 필요합니다.

경고 페이로드에 사용자 정의 필드를 추가할 수도 있습니다. 추가 매개변수의 값은 기본 유형(문자열 또는 숫자와 같은)으로 제한되지 않으며 중첩된 JSON 객체일 수 있습니다.예를 들어:

{ "foo": { "bar": { "baz": 42 } } }

참고:
요청이 페이로드 애플리케이션 제한보다 작아야 합니다.

예시 요청 본문

예시 페이로드:

{
  "title": "사건 제목",
  "description": "사건에 대한 간단한 설명",
  "start_time": "2019-09-12T06:00:55Z",
  "service": "영향을 받는 서비스",
  "monitoring_tool": "값",
  "hosts": "값",
  "severity": "높음",
  "fingerprint": "d19381d4e8ebca87b55cda6e8eee7385",
  "foo": {
    "bar": {
      "baz": 42
    }
  }
}

Prometheus 엔드포인트

전제 조건:

  • 프로젝트에 대한 적어도 Maintainer 역할이 있어야 합니다.
  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 모니터를 선택합니다.
  3. 알림 섹션을 확장하고 새 통합 추가를 선택합니다.
  4. 통합 유형 선택 드롭다운 목록에서 Prometheus를 선택합니다.
  5. 활성화 토글을 켭니다.
  6. Prometheus API 기본 URL을 입력합니다. 이 필드를 사용하는 기능은 폐기되었으며, GitLab 16.0에서 삭제 예정입니다.
  7. 통합 저장을 선택합니다.

웹훅 구성의 URL 및 인증 키는 자격 증명 보기 탭에서 확인할 수 있습니다.

외부 서비스에 URL 및 인증 키를 입력합니다. 또한, 통합의 테스트 알림 보내기 탭에서 테스트 알림을 보낼 수도 있습니다.

Prometheus Alertmanager에 통합 자격 증명 추가

Prometheus 경고 알림을 GitLab로 보내려면 Prometheus 통합에서 URL 및 인증 키를 복사하여 Prometheus Alertmanager 구성의 webhook_configs 섹션에 붙여넣습니다:

receivers:
  - name: gitlab
    webhook_configs:
      - http_config:
          authorization:
            type: Bearer
            credentials: 1234567890abdcdefg
        send_resolved: true
        url: http://IP_ADDRESS:PORT/root/manual_prometheus/prometheus/alerts/notify.json
        # 나머지 구성은 생략됨
        # ...

예상 요청 속성

경고는 Prometheus 웹훅 수신기에 맞게 서식이 지정된 것으로 예상됩니다.

최상위 필수 속성:

  • alerts
  • commonAnnotations
  • commonLabels
  • externalURL
  • groupKey
  • groupLabels
  • receiver
  • status
  • version

Prometheus 페이로드의 alerts에서, 배열의 각 항목에 대해 GitLab 경고가 생성됩니다. 아래 나열된 중첩 매개변수를 수정하여 GitLab 알림을 구성할 수 있습니다.

속성 유형 필수 여부 설명
annotations/title, annotations/summary, 또는 labels/alertname 중 하나 String 경고의 제목
startsAt 날짜 및 시간 경고의 시작 시간
annotations/description String 아니오 문제에 대한 개략적인 요약
annotations/gitlab_incident_markdown String 아니오 GitLab Flavored Markdown으로 경고에서 생성된 이벤트에 추가할 마크다운
annotations/runbook String 아니오 이 경고를 관리하는 방법에 대한 설명 또는 문서 또는 지침 링크
endsAt 날짜 및 시간 아니오 경고의 해결 시간
g0.expr generatorUrl의 쿼리 매개변수 String 아니오 관련 메트릭의 쿼리
labels/gitlab_environment_name String 아니오 연관된 GitLab 환경의 이름. 대시보드에서 경고 표시에 필요합니다.
labels/severity String 아니오 경고의 심각성. Prometheus 심각성 옵션 중 하나어야 합니다. 누락된 경우 또는 값이 이 목록에 없는 경우 기본값은 critical입니다.
status String 아니오 Prometheus의 경고 상태. 값이 ‘resolved’인 경우 경고가 해결됩니다.
annotations/gitlab_y_label, annotations/title, annotations/summary, 또는 labels/alertname 중 하나 String 아니오 GitLab Flavored Markdown에이 경고에 대한 메트릭을 포함할 때 사용될 Y축 레이블

annotations 하위에 포함된 추가 속성은 경고 세부 정보 페이지에서 사용할 수 있습니다. 다른 속성은 무시됩니다.

속성은 기본 유형(문자열 또는 숫자와 같은)으로 제한되지 않지만 중첩된 JSON 객체가 될 수 있습니다. 예를 들어:

{
    "target": {
        "user": {
            "id": 42
        }
    }
}

참고: 귀하의 요청이 payload application limits 보다 작은지 확인하십시오.

프로메테우스 심각도 옵션

프로메테우스에서의 경보는 경보 심각도에 대해 대소문자를 구분하지 않는 다음 값을 제공할 수 있습니다:

  • Critical: critical, s1, p1, emergency, fatal
  • High: high, s2, p2, major, page
  • Medium: medium, s3, p3, error, alert
  • Low: low, s4, p4, warn, warning
  • Info: info, s5, p5, debug, information, notice

값이 누락되었거나 이 목록에 없는 경우 심각도는 기본적으로 critical로 설정됩니다.

프로메테우스 경보 예시

경보 규칙 예시:

groups:
- name: example
  rules:
  - alert: ServiceDown
    expr: up == 0
    for: 5m
    labels:
      severity: high
    annotations:
      title: "예시 제목"
      runbook: "http://example.com/my-alert-runbook"
      description: "서비스가 5분 이상 다운되었습니다."
      gitlab_y_label: "y-축 라벨"
      foo:
        bar:
          baz: 42

요청 페이로드 예시:

{
  "version" : "4",
  "groupKey": null,
  "status": "firing",
  "receiver": "",
  "groupLabels": {},
  "commonLabels": {},
  "commonAnnotations": {},
  "externalURL": "",
  "alerts": [{
    "startsAt": "2022-010-30T11:22:40Z",
    "generatorURL": "http://host?g0.expr=up",
    "endsAt": null,
    "status": "firing",
    "labels": {
      "gitlab_environment_name": "production",
      "severity": "high"
    },
    "annotations": {
      "title": "예시 제목",
      "runbook": "http://example.com/my-alert-runbook",
      "description": "서비스가 5분 이상 다운되었습니다.",
      "gitlab_y_label": "y-축 라벨",
      "foo": {
        "bar": {
          "baz": 42
        }
      }
    }
  }]
}

인증

다음과 같은 인증 방법을 받아들입니다:

  • Bearer 인증 헤더
  • 기본 인증

<authorization_key><url> 값은 경보 통합을 구성할 때 찾을 수 있습니다.

Bearer 인증 헤더

인증 키는 Bearer 토큰으로 사용할 수 있습니다:

curl --request POST \
  --data '{"title": "사건 제목"}' \
  --header "Authorization: Bearer <authorization_key>" \
  --header "Content-Type: application/json" \
  <url>

기본 인증

인증 키는 password로 사용할 수 있습니다. username은 공란으로 남겨둡니다:

  • username: <공란>
  • password: <authorization_key>
curl --request POST \
  --data '{"title": "사건 제목"}' \
  --header "Authorization: Basic <base_64_encoded_credentials>" \
  --header "Content-Type: application/json" \
  <url>

기본 인증은 URL에 직접 자격 증명을 사용하여도 됩니다:

curl --request POST \
  --data '{"title": "사건 제목"}' \
  --header "Content-Type: application/json" \
  <username:password@url>

경고: URL에 인가 키를 사용하는 것은 보안상 취약하며 서버 로그에 표시됩니다. 도구가 지원하는 경우 위의 헤더 옵션 중 하나를 사용하는 것이 좋습니다.

응답 본문

JSON 응답 본문에는 요청 내에서 생성된 경보 목록이 포함되어 있습니다:

[
  {
    "iid": 1,
    "title": "사건 제목"
  },
  {
    "iid": 2,
    "title": "두 번째 사건 제목"
  }
]

성공적인 응답은 200 응답 코드를 반환합니다.

테스트 경보 트리거

프로젝트 유지 관리자 또는 소유자가 통합을 구성한 후, 테스트 경보를 트리거하여 통합이 올바르게 작동하는지 확인할 수 있습니다.

  1. 적어도 개발자 역할을 가진 사용자로서 로그인합니다.
  2. 프로젝트에서 설정 > 모니터로 이동합니다.
  3. 섹션을 확장하려면 경보를 선택합니다.
  4. 목록의 통합 오른쪽에 있는 설정 아이콘을 선택합니다.
  5. 테스트 경보 보내기 탭을 선택하여 엽니다.
  6. 페이로드 필드에 테스트 페이로드를 입력합니다(유효한 JSON이 필요합니다).
  7. 보내기를 선택합니다.

GitLab은 테스트 결과에 따라 오류 또는 성공 메시지를 표시합니다.

동일한 경고의 자동 그룹화

자세한 정보: Tier: 프리미엄, 얼티밋 Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab 버전 13.2 이상에서 GitLab은 페이로드를 기반으로 경고를 그룹화합니다. 들어오는 경고가 다른 경고와 동일한 페이로드를 포함하는 경우(start_timehosts 속성은 제외), GitLab은 이러한 경고들을 함께 그룹화하고 알림 관리 목록 및 세부 정보 페이지에 카운터를 표시합니다.

기존 경고가 이미 해결됨 상태인 경우, GitLab은 대신 새로운 경고를 생성합니다.

알림 관리 목록

회복 경고

GitLab의 경고는 HTTP 엔드포인트가 경고의 종료 시간이 설정된 페이로드를 수신하면 자동으로 해결됩니다. 사용자 정의 매핑이 없는 HTTP 엔드포인트의 경우, 예상 필드는 end_time입니다. 사용자 정의 매핑을 통해 예상 필드를 선택할 수 있습니다.

GitLab은 제공된 페이로드의 일부로 제공할 수 있는 fingerprint 값을 기반으로 어떤 경고를 해결할지 결정합니다. 경고 속성 및 매핑에 대한 자세한 정보는 GitLab 외부에서 경고 페이로드 사용자 정의를 참조하세요.

또한 경고가 해결되면 연관된 사건을 자동으로 닫을 수 있습니다.

Opsgenie 경고로의 링크

자세한 정보: Tier: 프리미엄, 얼티밋 Offering: GitLab.com, Self-managed, GitLab Dedicated

경고: Opsgenie 및 기타 경고 도구와의 깊은 통합을 HTTP 엔드포인트 통합을 통해 구축 중이므로 GitLab 인터페이스에서 경고를 볼 수 있습니다. 결과적으로, 이전에 GitLab 경고 목록에서 Opsgenie 경고로의 직접 링크는 GitLab 버전 13.8 이상에서는 사용되지 않습니다.

Opsgenie와의 GitLab 통합을 사용하여 경고를 모니터링할 수 있습니다.

Opsgenie 통합을 활성화하면 동시에 다른 GitLab 경고 서비스를 활성화할 수 없습니다.

Opsgenie 통합을 활성화하려면:

  1. Maintainer 또는 Owner 역할을 가진 사용자로서 로그인합니다.
  2. Monitor > Alerts로 이동합니다.
  3. Integrations 선택 상자에서 Opsgenie를 선택합니다.
  4. 활성화 토글을 선택합니다.
  5. API URL 필드에 Opsgenie 통합의 기본 URL(예: https://app.opsgenie.com/alert/list)을 입력합니다.
  6. 변경 사항 저장을 선택합니다.

통합을 활성화한 후, Monitor > Alerts 페이지로 이동한 다음 Opsgenie에서 경고 보기를 선택합니다.