AI 에러 로깅 알림 시스템 구축 1편 (feat. Claude Headless, Loki Ruler, Alert Manager)

🧐 들어가기전

"정말 필요한" 에러로그의 알림만 바로 슬랙으로 받으면 얼마나 좋을까?

Datadog을 사용하던 시절에는 자동 그룹화, 패턴 인식, 알림 설정까지 잘 갖춰져 있었기 때문에 에러 로그 모니터링이 비교적 수월했다고 한다 (팀에서 Datadog을 사용하던 당시에 나는 없었기에 그 이점을 잘 모른다). 그러나 Datadog의 비용 부담이 커지면서 지속해서 사용하기 어려웠고, 대체재로 오픈소스 기반의 Prometheus + Loki + Grafana + Tempo 스택으로 전환하게 되었다.

 

회사를 처음에 들어오던 당시에는 해당 스택에 대한 불편함을 전혀 느끼지 못하였다. 하지만 이제 서비스를 개발하기 시작하면서 정말 필요한 에러 로그 알림만 바로 받아보고 싶다는 생각이 강하게 들기 시작하였다. 그래서 로깅 알림 시스템을 직접 구축하고자 고민을 하기 시작하였다. 메트릭 알림은 이전 글에서 다뤘지만, 에러 로그 알림은 차원이 다른 문제였다.

 

우선 에러 로그의 알림 시스템을 구축하기 전에 현재의 Grafana에서 에러 로그를 직접 확인하는 방식에 대한 불편한 점을 정리해보았다.

1. 불필요한 에러와 중요한 에러를 한눈에 구분하기 어렵다. (NoResourceException과 OutOfMemoryError가 같은 무게로 나열된다)
2. 에러의 원인을 파악하는 데 리소스가 든다. 시스템 문제인지, 외부 API 문제인지, 클라이언트 요청 문제인지 매번 스택트레이스를 분석해야 한다.
3. 실시간 대응이 불가능하다. 로그를 계속 쳐다보고 있지 않는 이상, 에러 발생 시점을 놓치기 쉽다.
4. 중복 에러가 쏟아지면 정작 중요한 에러를 놓친다. 같은 NullPointerException이 500번 발생하면 그 사이에 섞인 새로운 에러를 발견하기 어렵다.

하지만 그렇다고 단순히 에러 로그를 곧바로 Slack으로 전송하면? 이는 알림 피로도가 급격히 올라간다. 레거시 코드에서 예외 처리가 미흡한 부분이 많아서 조치가 필요 없는 알림이 쏟아질 뿐만 아니라 단순 봇들의 크롤링으로 인한 NoResourceException과 같은 별다른 대응이 필요하지 않은 알림들이 무수히 쌓이게 된다. 이는 자칫하면 "정말 필요해서 바로 봐야하는 존재"가 아닌 "귀찮은 존재, 스팸"으로 인식될 수 있기에 "정말 필요한 에러 알림만 유니크하게 보내는 것"을 중심으로 설계하고자 하였다.

 

결론부터 말하자면 해당 시스템은 수많은 시행착오 끝에 다음과 같은 구조로 성공적으로 운영될 수 있었다.

시스템 아키텍처

에러 처리 플로우

실제 운영 중인 모습

에러로그가 떴을 때 바로 오는 슬랙 에러 알림

해당 에러로그에 대한 AI 분석이 스레드 댓글로 달림

 

유니크한 에러 로그 알림들의 중요도 별로 관리할 수 있는 UI 대시보드

이제 이 과정에 대해 글을 작성해보고자 한다.

---

🔸 1. Loki Alert Rule 설계

현재 에러 로그를 관리하는 주체는 Loki이다. 우리가 원하는 "정말 필요한 에러 알림"만 보내려면, 결국 Prometheus Alertmanager에서 커스텀하게 구현한 Webhook 서버로 알림을 전달해야 한다. 그래야 알림을 우리 마음대로 컨트롤할 수 있다.

그 전에 에러 로그가 Alertmanager까지 도달할 수 있도록 설계해야 한다. 이 역할을 하는 것이 바로 Loki Alert Rule이다. Loki Ruler가 정의된 규칙에 따라 로그를 평가하고, 조건을 만족하면 Alertmanager로 알림을 발송한다.

여기서 Loki Ruler와 Prometheus Alertmanager의 관계를 이해할 필요가 있다. Loki는 로그 수집 및 쿼리 시스템이고, Loki Ruler는 Loki에 내장된 알림 평가 엔진이다. Prometheus Alertmanager는 알림의 라우팅, 그룹화, 중복 제거, 발송을 담당하는 독립적인 컴포넌트이다. Loki Ruler가 "이 조건에 해당하는 로그가 발생했다"고 판단하면, 그 알림을 Alertmanager로 전송한다. Alertmanager는 수신한 알림을 설정된 규칙에 따라 Slack, Webhook, 이메일 등으로 라우팅한다.

즉, Loki Ruler는 "언제 알림을 발생시킬지"를 결정하고, Alertmanager는 "발생한 알림을 어디로 보낼지"를 결정한다.

---

1.1 에러 로그 감지 파이프라인

전체 흐름은 다음과 같이 설계하였다.

• Backend 서비스에서 발생한 로그는 Grafana Alloy(OTEL Collector)를 통해 Loki로 수집된다.
• Loki Ruler가 정의된 규칙에 따라 ERROR 레벨 로그를 감지한다
• 조건을 만족하면 Alertmanager로 알림을 전송한다.
• Alertmanager는 설정된 라우팅 규칙에 따라 Webhook 서버로 알림을 전달한다.

---

1.2 Alert Rule 구성: service_name + exception_type 그룹화

Loki Alert Rule을 설계할 때 가장 중요한 결정은 "어떤 기준으로 알림을 그룹화할 것인가"였다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: loki-ruler-rules
  namespace: devops
data:
  rules.yaml: |
    groups:
      - name: application-errors
        interval: 1m
        rules:
          - alert: ApplicationError
            expr: |
              sum by (service_name, exception_type) (
                count_over_time(
                  {service_name=~"accounts|booking|catalog|payments|..."}
                  | detected_level="ERROR"
                  | json
                  | label_format exception_type=attributes_exception_type
                  | exception_type != ""
                  [2m]
                )
              ) > 0
            for: 0m
            labels:
              alert_type: log
              severity: error
            annotations:
              summary: "애플리케이션 에러 발생"
              description: "{{ $labels.service_name }}에서 {{ $labels.exception_type }} 에러 감지"

이 규칙이 어떻게 동작하는지 단계별로 살펴보자.

• interval: 1m
  이 규칙을 1분마다 평가한다는 의미이다. Loki Ruler가 1분 간격으로 아래 expr 쿼리를 실행하여 조건을 만족하는지 확인한다.
• {service_name=~"accounts|booking|..."}
  모니터링 대상 서비스를 필터링한다. 정규표현식으로 여러 서비스를 한 번에 지정할 수 있다. 여기에 포함되지 않은 서비스의 에러 로그는 이 규칙의 평가 대상에서 제외된다.
• detected_level="ERROR"
  ERROR 레벨 로그만 선별한다. Loki가 로그 레벨을 자동으로 감지한 결과를 활용한다. DEBUG, INFO, WARN 레벨의 로그는 이 단계에서 필터링된다.
• json | label_format exception_type=attributes_exception_type
  SON 형식의 로그를 파싱하여 exception_type 필드를 라벨로 추출한다. 예를 들어 {"attributes": {"exception_type": "NullPointerException"}} 형태의 로그에서 NullPointerException을 추출하여 라벨로 사용할 수 있게 만든다.
• exception_type != ""
  부분은 exception_type이 추출되지 않은 로그를 제외한다. 스택트레이스 없이 단순 에러 메시지만 있는 로그는 이 규칙의 대상에서 제외된다.
• count_over_time(...[2m]) > 0
  최근 2분 동안 위 조건을 만족하는 로그가 1건 이상 있으면 알림을 발생시킨다.
• sum by (service_name, exception_type)
  이 부분이 핵심이다. 이 그룹화 기준에 따라 알림이 어떻게 묶이는지 결정된다.
• for: 0m
  조건을 만족하면 즉시 알림을 발생시킨다는 의미이다. 만약 for: 5m으로 설정하면 조건이 5분 동안 지속되어야 알림이 발생한다.
• labels에 정의된 alert_type: log
  이후 Alertmanager에서 라우팅 규칙을 적용할 때 사용된다. 메트릭 기반 알림과 로그 기반 알림을 구분하여 서로 다른 Webhook 서버로 전송할 수 있다.

여기서 의문이 생길 것이다. 왜 service_name과 exception_type 두 가지로 그룹화하는가?

다음 상황을 가정해보자. 2분 동안 아래와 같은 에러 로그가 발생했다.

시간 서비스 예외 타입 메시지

10:01	payments	NullPointerException	user is null
10:01	payments	NullPointerException	order is null
10:02	payments	IllegalStateException	invalid state
10:02	accounts	NullPointerException	account is null

sum by (service_name, exception_type) 그룹화를 적용하면 Alertmanager는 3개의 독립적인 알림을 수신한다.

• payments + NullPointerException 그룹에는 2건이 집계된다. user is null과 order is null은 같은 그룹으로 묶인다.
• payments + IllegalStateException 그룹에는 1건이 집계된다.
• accounts + NullPointerException 그룹에는 1건이 집계된다.

 

만약 service_name만으로 그룹화했다면 payments 서비스의 모든 에러가 하나로 묶여서, NullPointerException과 IllegalStateException을 구분할 수 없었을 것이다. 반대로 그룹화 없이 모든 에러를 개별 알림으로 보냈다면, 같은 NullPointerException이 100번 발생할 때 100개의 알림이 쏟아졌을 것이다.

---

1.3 Alertmanager 라우팅 설정

Loki Ruler에서 발생한 알림은 Alertmanager를 거쳐 Webhook 서버로 전달된다. Alertmanager는 수신한 알림을 어디로 보낼지, 어떻게 그룹화할지, 얼마나 자주 반복할지를 결정한다.

alertmanager:
  config:
    route:
      routes:
        - receiver: 'log-alert'
          matchers:
            - alert_type = log
          group_by: ['alertname', 'service_name', 'exception_type']
          group_wait: 1s
          group_interval: 30s
          repeat_interval: 30m

    receivers:
      - name: 'log-alert'
        webhook_configs:
          - url: 'http://claude-log-alert-manager.devops.svc.cluster.local/webhook'
            send_resolved: false

• matchers: alert_type = log
  조건으로 로그 기반 알림만 별도 라우팅한다. Loki Alert Rule에서 labels: alert_type: log로 설정한 알림만 이 라우팅 규칙을 타게 된다. 메트릭 기반 알림은 다른 라우팅 규칙으로 처리할 수 있다.
• group_by: ['alertname', 'service_name', 'exception_type']
  Alertmanager가 알림을 그룹화하는 기준이다. 이 세 가지 라벨이 모두 동일한 알림들은 하나의 그룹으로 묶여서 Webhook 서버로 전송된다.
• group_wait: 1s
  새로운 그룹의 알림이 발생했을 때 1초 동안 대기했다가 전송한다는 의미이다. 이 짧은 대기 시간 동안 같은 그룹에 속하는 다른 알림이 추가로 들어오면 함께 묶어서 전송한다. Loki가 HA 구성으로 운영될 경우 동일 알림이 여러 Ruler에서 중복 발생할 수 있는데, 이를 1초 내에 병합하는 효과가 있다.
• group_interval: 30s
  이미 알림이 전송된 그룹에 새로운 알림이 추가되면 30초 후에 업데이트를 전송한다는 의미이다.
• repeat_interval: 30m
  해결되지 않은 에러가 계속 발생하면 30분마다 알림을 다시 전송한다는 의미이다. 이 값이 너무 짧으면 같은 알림이 반복적으로 쏟아지고, 너무 길면 중요한 에러를 놓칠 수 있다.
• send_resolved: false
  에러가 해결되었다는 알림은 전송하지 않는다는 의미이다. 메트릭 기반 알림에서는 "CPU 사용률이 정상으로 돌아왔다"는 resolved 알림이 의미가 있지만, 로그 기반 알림에서는 "에러 로그가 더 이상 발생하지 않는다"는 것을 굳이 알릴 필요가 없다.

이렇게 Loki Alert Rule과 Alertmanager를 구성함으로써, 앞단에서 1차적인 필터링과 그룹화가 이루어진다. service_name + exception_type 기준으로 알림이 묶이기 때문에, 동일한 예외가 100번 발생해도 Alertmanager는 이를 하나의 그룹으로 인식하여 Webhook 서버에 단일 알림으로 전달한다. repeat_interval 설정 덕분에 해결되지 않은 에러라 하더라도 30분에 한 번만 알림이 반복된다.

 

하지만 이것만으로는 충분하지 않다. Alertmanager 수준의 그룹화는 service_name과 exception_type이라는 비교적 넓은 범위로 묶는다. 같은 NullPointerException이라도 발생 위치와 원인이 다를 수 있고, 이미 알고 있는 에러와 새로운 에러를 구분해야 한다. 

---

🔸 2. Fingerprint: 에러 식별의 첫 번째 시도

 

Alertmanager를 통해 에러 알림을 수신하는 것까지는 해결되었다. 하지만 가장 중요한 하나의 과제가 남아있다.

레거시 코드에서 예외 처리가 미흡한 부분이 많아서 조치가 필요 없는 알림이 쏟아질 뿐만 아니라 단순 봇들의 크롤링으로 인한 NoResourceException과 같은 별다른 대응이 필요하지 않은 알림들이 무수히 쌓이게 된다

이 문제를 해결하기 위해서는 두 가지의 방식이 제안되었다.

1. 코드 레벨에서 커스텀 Exception 클래스를 정의하고, 에러 로그 알림이 필요한 부분만 해당 클래스로 감싸는 것이다. 알림이 필요한 예외와 그렇지 않은 예외를 코드에서 명시적으로 구분할 수 있다.
2. "무음" 또는 "무시" 기능을 추가하는 것이다. Slack에서 특정 에러 알림에 "무시" 버튼을 누르면, 이후 같은 에러에 대해서는 알림이 발송되지 않도록 한다.

첫 번째 방식은 확실하지만, 현재 방대하게 구축된 모든 프로젝트에 동일하게 적용해야 한다는 점에서 많은 리소스가 필요했다. 기존 코드를 모두 수정해야 하고, 새로운 컨벤션을 개발자들에게 전파해야 하는 커뮤니케이션 비용도 상당했다.

반면 두 번째 방식은 Slack Bolt를 이용하여 버튼 인터랙션만 구현하면 된다. "무시" 버튼을 통해 점진적으로 불필요한 에러 알림을 줄여나갈 수 있기 때문에 초기 구축 비용이 크지 않다. 물론 개발자들이 적극적으로 "무시" 버튼을 눌러줘야 시간이 지남에 따라 불필요한 알림이 줄어드는 구조이지만, 운영하면서 자연스럽게 필터링이 강화되는 장점이 있다.

 

두 번째 방식을 채택하기로 했다. 그런데 "무시" 기능을 구현하려면 한 가지 전제 조건이 필요하다. 에러를 고유하게 식별할 수 있는 Unique한 식별자가 있어야 한다. "이 에러"를 무시하겠다고 했을 때, "이 에러"가 무엇인지 정의할 수 있어야 한다. 같은 에러가 다시 발생했을 때 이전에 무시 처리한 에러와 동일한지 판단할 수 있어야 한다.

 

이를 위해 각 에러를 고유하게 식별할 수 있는 Fingerprint 개념을 도입했다.

---

2.1 Fingerprint 구성 요소

Fingerprint는 다음 4가지 요소를 조합하여 SHA-256 해시로 생성한다.

구성요소 : service_name + exception_type + message_hash + frames

def generate_fingerprint(service_name: str, exception_type: str,
                         error_message: str, stacktrace: str) -> str:
    frames = extract_top_frames(stacktrace, count=3)
    message_hash = hashlib.sha256((error_message or "").encode()).hexdigest()[:16]
    fingerprint_source = f"{service_name}:{exception_type}:{message_hash}:{':'.join(frames)}"
    fingerprint = hashlib.sha256(fingerprint_source.encode()).hexdigest()[:32]
    return fingerprint

• service_name
  에러가 발생한 서비스를 식별한다. payments 서비스에서 발생한 에러와 accounts 서비스에서 발생한 에러는 설령 같은 예외 타입이라도 다른 Fingerprint를 갖는다.
• exception_type
  NullPointerException, IllegalStateException 등 예외 클래스를 식별한다. 같은 서비스에서 발생한 에러라도 예외 타입이 다르면 다른 Fingerprint를 갖는다.
• message_hash
  원본 에러 메시지의 해시값이다. 에러 메시지 전체를 저장하면 너무 길어지므로 SHA-256 해시의 앞 16자리만 사용한다.
• frames
  스택트레이스의 상위 3개 프레임이다. 에러가 발생한 코드 위치를 식별한다. 같은 예외 타입이라도 발생 위치가 다르면 다른 Fingerprint를 갖는다.

 

이 네 가지 요소를 조합하면 "어떤 서비스에서, 어떤 예외가, 어떤 메시지와 함께, 어떤 코드 위치에서 발생했는가"를 고유하게 식별할 수 있다.

---

2.2 스택트레이스에서 라인번호를 제외한 이유

스택트레이스에서 프레임을 추출할 때, 라인번호는 의도적으로 제외했다.

def extract_top_frames(stacktrace: str, count: int = 3) -> list:
    """Extract top N frames from stacktrace (without line numbers)"""
    if not stacktrace:
        return []
    
    frame_pattern = r'at\s+([\w.$]+)\(([\w]+\.java)'  # 라인번호 제외
    matches = re.findall(frame_pattern, stacktrace)
    
    frames = []
    for match in matches[:count]:
        method, file = match
        frames.append(f"{method}:{file}")
    
    return frames

초기에는 라인번호를 포함했었다. 그런데 운영하다 보니 문제가 생겼다. 코드에 주석 한 줄만 추가해도, 리팩토링으로 메서드 순서를 바꿔도 라인번호가 변경된다. 그러면 완전히 동일한 에러인데도 다른 Fingerprint로 인식되어 새로운 알림이 발송되었다.

라인번호를 제외하고 클래스명 + 메서드명 + 파일명 조합으로 프레임을 구성하니, 코드 변경에 영향받지 않으면서도 에러 위치를 충분히 식별할 수 있었다.

---

2.3 Fingerprint 기반 중복 알림 방지

Fingerprint를 도입하면서 다음과 같은 로직을 구현할 수 있었다.

동일 Fingerprint를 가진 에러가 1시간 내에 다시 발생하면 알림을 스킵하고 발생 횟수만 증가시킨다. 사용자가 특정 에러를 "무시"로 설정하면 해당 Fingerprint의 에러는 더 이상 알림을 보내지 않는다. "무음"으로 설정하면 지정된 시간 동안 알림을 중단한다.

---

2.4 한계: 동일 예외인데 메시지만 다른 경우

하지만 위와 같이 Fingerprint 시스템을 운영하다보니 다음과 같은 예상치 못한 문제가 발생하였다.

 

payments 서비스에서 UserNotFoundException이 발생하는데, 메시지가 매번 달랐다.

UserNotFoundException: User not found: userId=12345
UserNotFoundException: User not found: userId=67890
UserNotFoundException: User not found: userId=11111

세 에러 모두 같은 코드 위치에서, 같은 이유로 발생한 동일한 에러이다. 하지만 userId 값이 다르기 때문에 message_hash가 달라지고, 결과적으로 서로 다른 Fingerprint가 생성되었다.

 

하나의 에러를 "무시"로 설정해도 다음 요청에서 다른 userId로 에러가 발생하면 새로운 알림이 울렸다. AI 분석 결과도 캐시되지 않아서 매번 새로 분석을 요청했고, 토큰 소비가 급격히 늘어났다. (AI 분석에 대해서는 2편에서 다룰 예정이다.)

---

🔸 3. Chunk ID: 유사 에러 그룹화

3.1 문제 상황 분석

Fingerprint만으로는 해결할 수 없는 문제를 정리해보자.

 

[Fingerprint 예외 타입 메시지 발생 위치]

abc123	UserNotFoundException	userId=12345	UserService.getUser
def456	UserNotFoundException	userId=67890	UserService.getUser
ghi789	UserNotFoundException	userId=11111	UserService.getUser

세 에러는 논리적으로 완전히 동일한 에러이다. 같은 서비스, 같은 예외 타입, 같은 코드 위치에서 발생했다. 단지 요청 파라미터인 userId만 다를 뿐이다. 이런 "유사 에러"를 하나의 그룹으로 묶어서 관리할 수 있는 상위 개념이 필요했다. 그래서 Chunk ID를 도입했다.

---

3.2 Chunk ID 설계: 첫 번째 시도

처음에는 메시지를 제외하고 나머지 요소만으로 Chunk ID를 구성했다.

chunk_id = hash(service_name + exception_type + frame1 + frame2 + frame3)

이렇게 하면 userId=12345와 userId=67890 에러가 같은 Chunk로 묶인다. "무시" 설정을 Chunk 단위로 적용하면 한 번의 액션으로 모든 유사 에러를 무시할 수 있다. AI 분석 결과도 Chunk 단위로 캐시하면 토큰을 절약할 수 있다.

 

그런데 이 설계에는 문제가 있었다.

---

3.3 또 다른 문제: 같은 위치에서 다른 에러

같은 메서드에서 여러 종류의 에러가 발생할 수 있다.

fun getUser(userId: String?): User {
    requireNotNull(userId) { "userId is required" }
    
    val user = userRepository.findById(userId)
        ?: throw UserNotFoundException("User not found: $userId")
    
    if (user.isDeleted) {
        throw UserNotFoundException("User is deleted: $userId")
    }
    
    return user
}

세 가지 다른 에러가 모두 같은 UserService.getUser()에서 발생한다. 메시지를 완전히 제외하면 이 세 에러가 같은 Chunk로 묶여버린다.

"User not found"를 무시하면 "User is deleted"까지 함께 무시되는 상황이 발생했다. 이건 의도한 동작이 아니다.

---

3.4 메시지 정규화: g-z만 유지하는 이유

메시지를 완전히 제외하면 다른 에러가 같이 묶이고, 메시지를 그대로 사용하면 ID 값 때문에 같은 에러가 분리된다. 해결책은 메시지에서 "변동되는 부분"만 제거하는 것이었다. 변동되는 부분은 대부분 ID 값이다. 그리고 ID 값은 보통 다음 형태 중 하나이다.

• 숫자: userId=12345, orderId=67890
• UUID: 550e8400-e29b-41d4-a716-446655440000
• 16진수(hex): 0x1A2B3C, transactionId=a1b2c3d4

숫자는 0-9, UUID와 hex는 0-9와 a-f를 사용한다. 그렇다면 이것들을 제거하고 나머지 문자만 남기면 된다.

def normalize_message_for_chunk(message: str) -> str:
    """Normalize message for chunk ID (keep only g-z letters)"""
    if not message:
        return ""
    # g-z만 유지 (숫자 0-9, hex 문자 a-f 제거)
    msg = re.sub(r'[^g-zG-Z\s]', '', message)
    msg = re.sub(r'\s+', ' ', msg)
    return msg.strip()

알파벳 중 a-f는 hex 값에 포함되므로 제거하고, g-z만 남긴다. 결과적으로 "의미 있는 영어 단어의 핵심 글자"만 남게 된다.

실제 정규화 결과를 보자.

"User not found: userId=12345"     → "Usr not oun"
"User not found: userId=67890"     → "Usr not oun"  (같은 결과!)
"User is deleted: userId=12345"    → "Usr is lt"    (다른 결과!)

같은 에러 메시지는 같은 정규화 결과를 갖고, 다른 에러 메시지는 다른 정규화 결과를 갖는다. UUID가 포함된 경우도 잘 처리된다.

"Order 550e8400-e29b-41d4-a716-446655440000 failed" → "Orr il"
"Order a1b2c3d4-e5f6-7890-abcd-ef1234567890 failed" → "Orr il"  (같은 결과!)

정규화된 결과는 사람이 읽기 어렵지만, 해시 키로만 사용하므로 가독성은 중요하지 않다.

---

3.5 최종 설계: Fingerprint vs Chunk ID

def generate_fingerprint(service_name: str, exception_type: str,
                         error_message: str, stacktrace: str) -> tuple:
    frames = extract_top_frames(stacktrace, count=3)
    
    # Chunk ID: 정규화된 메시지 사용
    normalized_message = normalize_message_for_chunk(error_message or "")
    normalized_hash = hashlib.sha256(normalized_message.encode()).hexdigest()[:16]
    chunk_source = f"{service_name}:{exception_type}:{normalized_hash}:{':'.join(frames)}"
    chunk_id = hashlib.sha256(chunk_source.encode()).hexdigest()[:32]
    
    # Fingerprint: 원본 메시지 사용
    message_hash = hashlib.sha256((error_message or "").encode()).hexdigest()[:16]
    fingerprint_source = f"{service_name}:{exception_type}:{message_hash}:{':'.join(frames)}"
    fingerprint = hashlib.sha256(fingerprint_source.encode()).hexdigest()[:32]
    
    return (fingerprint, chunk_id)

 

Fingerprint	서비스 + 예외타입 + 원본 메시지 해시 + 프레임	개별 에러 케이스 식별, 1시간 내 중복 알림 방지
Chunk ID	서비스 + 예외타입 + 정규화 메시지 해시 + 프레임	유사 에러 그룹화, 일괄 무시/무음, AI 캐시 공유

두 ID의 관계를 그림으로 표현하면 다음과 같다.

하나의 Chunk ID 아래에 여러 Fingerprint가 속한다. AI 분석 결과는 Chunk 단위로 캐시되어 유사 에러 간에 공유된다. 무시/무음 설정도 Chunk 단위로 적용되어 한 번의 액션으로 모든 유사 에러를 처리할 수 있다.

---

3.6 데이터베이스 스키마

이 설계를 반영한 테이블 구조는 다음과 같다.

error_patterns 테이블은 개별 에러 케이스를 저장한다. fingerprint가 고유 키이다.

chunk_status 테이블은 Chunk 단위의 무시/무음/해결 상태를 관리한다. 이 테이블에 레코드가 있으면 해당 Chunk의 모든 에러에 상태가 적용된다.

chunk_ai_cache 테이블은 Chunk 단위로 AI 분석 결과를 캐시한다. 같은 Chunk에 속한 에러들은 이 캐시를 공유한다.

---

🪄 정리

Loki Alert Rule에서 service_name + exception_type으로 그룹화하여 에러 로그를 효과적으로 감지한다. 이 조합이 Alertmanager로 전달되는 알림의 단위를 결정한다.
Fingerprint는 개별 에러 케이스를 고유하게 식별한다. 서비스명, 예외 타입, 원본 메시지 해시, 스택트레이스 프레임으로 구성된다. 1시간 내 동일 Fingerprint의 에러는 알림을 스킵한다.
Chunk ID는 유사 에러를 하나의 그룹으로 묶는다. 메시지에서 ID 값(숫자, UUID, hex)을 제거한 정규화된 해시를 사용한다. g-z 문자만 남기는 정규화 전략으로 변동 값을 효과적으로 필터링한다.
Chunk 단위로 무시/무음 설정과 AI 캐시를 적용함으로써, 알림 피로도를 줄이고 AI 토큰 소비를 90% 이상 절감할 수 있었다.
2편에서는 4-Tier 에러 분류 체계, Claude Headless를 활용한 AI 분석 파이프라인, 그리고 Slack 인터랙션 설계를 다룬다.

---

📙 출처

• Loki Ruler 공식 문서: https://grafana.com/docs/loki/latest/alert/
• Alertmanager Configuration: https://prometheus.io/docs/alerting/latest/configuration/
• LogQL 쿼리 문법: https://grafana.com/docs/loki/latest/query/