🔔 Slack이 시끄럽다… 그래서 다이어트 시켜봤다

🚦 시작: 단순함이 부른 함정

처음에는 “그냥 ERROR 전부 Slack으로 쏘면 되겠지?” 라고 생각했다.
Logback에서 Slack Webhook만 붙이면 끝날 줄 알았다.

하지만 막상 구현해보니 하루에도 수십, 수백 건의 알림이 울렸고, 진짜 중요한 에러는 잡음 속에 묻혀버렸다. 알림이 많다는 건 안심이 아니라, 오히려 불안이었다. “혹시 진짜 중요한 걸 놓치고 있는 건 아닐까?” 하는 의심이 계속 따라다녔다.

그러던 중 Kafka와 Logstash를 붙여본 순간, 시야가 달라졌다.
👉 단순히 로그를 “보내는 것”이 아니라, 어떤 로그를 보내야 할지 선택할 수 있다는 걸 깨달았다. 필터링, 집계, 조건부 전송… 이 모든 걸 애플리케이션이 아닌 파이프라인에서 할 수 있었다.

이번 글에서는 Logback에서 시작해 Logstash, Slack, Kibana까지 이어지는 과정을 기록하려 한다.

---

🧩 Slack Webhook 만들기, 최대한 간단하게

Slack 앱 관리 페이지에서 From scratch로 앱을 만들고 Incoming Webhooks를 켰다. 이 방식은 채널 연결과 Webhook 발급 과정을 단계별로 확인할 수 있어 초반 실수를 줄여줬다.

Manifest 방식은 구성 이식에 좋지만 초기 디버깅 난도가 올라간다. 이번엔 첫 설정이어서 단순한 길을 택했다.

발급된 Webhook URL은 코드에 직접 박지 않고 환경변수로 숨겼다. SLACK_WEBHOOK_URL=https://hooks.slack.com/services/***** 형태로 관리했다.

---

🛠️ 첫 시도인 Logback → Slack 직결

처음에는 Logback HttpAppender로 Slack에 바로 붙였다.
root 로거에 걸어서 ERROR만 전송하게 했다.

<appender name="SLACK" class="net.logstash.logback.appender.HttpAppender">
  <encoder class="net.logstash.logback.encoder.LogstashEncoder" />
  <url>${SLACK_WEBHOOK_URL}</url>
  <connectTimeout>10000</connectTimeout>
  <readTimeout>10000</readTimeout>
  <includeCallerData>true</includeCallerData>
  <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    <level>ERROR</level>
  </filter>
</appender>

하지만 최신 버전에서는 HttpAppender가 제거되거나 분리돼 동작하지 않았다.
그리고 더 중요한 건, 설령 잘 붙더라도 재시도, Rate Limit, 대상 변경(Slack→Sentry/Discord) 같은 문제를 애플리케이션 코드 안으로 끌어오고 싶지 않았다.

여기서 결론을 냈다.

👉 애플리케이션은 로그를 남기는 일에만 집중하고,
👉 수집·가공·전송은 Logstash 같은 파이프라인이 담당해야 한다.

---

🔀 전략 전환: 역할을 분리하다

최종 설계는 이렇게 정리됐다.

구성 요소	역할
Logback	JSON 로그 생성 → Kafka로 전송
Logstash	Kafka 수집 → 필터링·임계치 판단 → ES 색인 + Slack 알림
Slack	Logstash가 보낸 요약 알림만 받음
Elasticsearch/Kibana	전체 로그 보관 + 시각화/분석

기존 ELK 출력에 Slack http output만 얹는 방식이었고, 애플리케이션은 깔끔하게 분리됐다.

원래 ELK 출력은 단순하게 이렇게 시작했다.

input {
  kafka {
    bootstrap_servers => "kafka:9092"
    topics => ["app-logs"]
    group_id => "logstash-consumer"
    codec => json
  }
}
filter {
  date { match => ["timestamp","ISO8601"] target => "@timestamp" remove_field => ["timestamp"] }
}
output {
  elasticsearch { hosts => ["http://elasticsearch:9200"] index => "app-logs-%{+YYYY.MM.dd}" }
  stdout { codec => json }
}

---

✂️ Slack은 요약, Kibana는 디깅

Slack에 무작정 스택트레이스를 다 보낼 수는 없었다. 메시지 길이 제한도 있고, 솔직히 긴 로그는 읽는 순간 눈이 미끄러졌다.

그래서 Slack에는 핵심 요약 + 상위 3~5줄 스택트레이스 + TraceId + Kibana 링크만 보내고, 전체 로그는 Kibana에서 보도록 분리했다.

이렇게 하면 Slack은 빠른 감지용, Kibana는 깊은 분석용으로 역할이 명확해졌다.

  # stack_trace 5줄 요약
  if [stack_trace] {
    ruby {
      code => '
        if event.get("stack_trace")
          stack = event.get("stack_trace").split("\n")[0..4].join("\n")
          event.set("stack_trace_short", stack)
        end
      '
    }
  }
  

  # Slack 메시지 템플릿
  if [level] == "ERROR" {
    mutate {
      add_field => {
        "slack_message" => ":rotating_light: *ERROR 발생!*%{NEWLINE}*Service:* 
        LogSentry%{NEWLINE}*Message:* %{message}%{NEWLINE}*TraceId:* %
        {traceId}%{NEWLINE}*User:* %{userId}%{NEWLINE}*URI:* %{uri}%
        {NEWLINE}%{stack_trace_short}%{NEWLINE}
        <http://localhost:5601/app/discover#/?_a=(query:
        (language:kuery,query:'traceId:\"%{traceId}\"'))|Kibana에서 전체 로그 확인>"
      }
    }
  }

}

Slack은 신속한 감지에, Kibana는 정밀 분석에 최적화되게 말이다.

---

📦 Logback → Kafka: JSON 로그 전송

Slack 알림을 요약했다면, 이제 원천 로그를 튼튼하게 남길 차례였다.
KafkaAppender를 통해 Logback에서 JSON 로그를 Kafka로 전송하고, MDC(traceId/spanId)와 stack_trace 필드를 포함시켰다.

이렇게 하면 Logstash에서 메시지를 가공할 때도, Kibana에서 전체 흐름을 볼 때도 빠짐없이 연결할 수 있다.

<appender name="KAFKA_JSON" class="com.github.danielwegener.logback.kafka.KafkaAppender">
  <topic>app-logs</topic>
  <encoder class="com.github.danielwegener.logback.kafka.encoding.LayoutKafkaMessageEncoder">
    <layout class="net.logstash.logback.layout.LogstashLayout">
      <includeMdc>true</includeMdc>
      <includeException>true</includeException>
      <includeCallerData>false</includeCallerData>
    </layout>
  </encoder>
  <producerConfig>XXXX 이하생략</producerConfig>
  ...
</appender>

🗂️ 인덱스 템플릿에서 stack_trace 정의

Elasticsearch는 기본적으로 동적 매핑(dynamic mapping)으로 새 필드를 자동 인식한다.

하지만 운영 환경에서는 필드 타입이 잘못 잡히거나, 검색·집계가 꼬일 위험이 있어서 인덱스 템플릿에 stack_trace 필드를 명시적으로 포함시켰다.

이렇게 템플릿에 포함해두면 Kibana Discover와 Lens에서 안정적으로 조회·필터링할 수 있다.

_

✅ 실제로 에러 API를 호출했을 때 stack_trace 필드가 잘 들어오는 것도 확인했다.

---

🧪 Logstash의 필터링과 임계치

처음엔 “모든 ERROR를 Slack으로!” 라고 단순하게 접근했지만, 알림 폭탄은 답이 아니었다.
Slack은 금방 시끄러워지고, 중요한 에러조차 잡음에 묻혀버렸다.

그래서 전략을 바꿨다. BizLogger 표준 로깅에 ALERT 마커를 도입하고, Logstash에서 임계치 조건을 걸어 의미 있는 이벤트만 Slack으로 보내도록 했다.

예를 들어, 코드에서는 이렇게 구분했다.

// 일반 예외 → Kibana에서만 확인
BizLogger.error("회원 가입 중 닉네임 중복 발생: {}", nickname);

// 중요한 예외 → Slack 알림까지 전송
BizLogger.alert("🚨 결제 API 호출 실패! 주문번호: {}", orderId);

🔎 Logstash에서 적용한 규칙

• ALERT 마커가 찍힌 에러는 즉시 Slack 전송
• 같은 URI에서 10분 동안 5회 이상 반복되면 Slack 전송
• 같은 traceId에서 10분 동안 3회 이상 반복되면 Slack 전송

즉, 단발성 예외는 Kibana에만 남기고, 반복되거나 치명적인 이벤트만 Slack을 울리게 했다.

⚙️ Logstash 설정 예시

# ALERT 마커 감지
if "ALERT" in [tags] {
  mutate { add_field => { "alert_flag" => "true" } }
}

# URI 임계치: 10분 내 5회
aggregate {
  task_id => "%{uri}"
  code => "
    map['count'] ||= 0
    map['count'] += 1
    event.set('error_count_uri_10m', map['count'])
  "
  timeout_task_id_field => "uri"
  timeout => 600
  push_previous_map_as_event => false
  timeout_code => "event.set('error_count_uri_10m', 0)"
}

# traceId 임계치: 10분 내 3회
aggregate {
  task_id => "%{traceId}"
  code => "
    map['count'] ||= 0
    map['count'] += 1
    event.set('error_count_trace_10m', map['count'])
  "
  timeout_task_id_field => "traceId"
  timeout => 600
  push_previous_map_as_event => false
  timeout_code => "event.set('error_count_trace_10m', 0)"
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "app-logs-%{+YYYY.MM.dd}"
  }

  stdout { codec => json }

  # Slack 알림 조건
  if (("ALERT" in [tags] or [error_count_uri_10m] >= 5 or [error_count_trace_10m] >= 3) and [level] in ["ERROR", "WARN"]) {
    http {
      url => "${SLACK_WEBHOOK_URL}"
      http_method => "post"
      format => "json"
      mapping => {
        "text" => ":rotating_light: ERROR 알림 (요약본 + Kibana 링크)"
      }
    }
  }
}

—

최종적으로 결과는 이렇게 나왔다.

• BizLogger.error → 임계치 통과 시, Slack 알림
  

• BizLogger.alert → Slack 알림 + Kibana 링크
  

• Slack에서 링크 클릭 → Kibana로 이동해 TraceId 기준 전체 흐름 추적
  

---

🧘 마무리하며

애초에 단순함을 믿고 Logback 직결을 택했지만, 운영은 다르게 굴렀다.
알림은 많다고 좋은 게 아니라, 제대로 오는 게 중요하다는 걸 이번에 느꼈다.

그래서

• 애플리케이션은 로그 생성에만 집중하게 하고,
• Logstash가 필터링·집계·Slack 전송을 맡도록 했다.

ALERT 마커와 임계치를 얹으니 알림은 덜 시끄럽고 더 정확해졌고, 원인 분석은 Kibana 링크를 통해 더 빨라졌다.

이번 과정을 통해 배운 건, 단순히 기술을 붙이는 게 아니라 운영자의 시선에서 “어떤 알림이 진짜 필요한가”를 고민하는 게 더 큰 설계 포인트라는 점이었다.