promkr 뉴스레터 2025년 10월호

이 호에 실린 소식 10개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2025년 소식에 있습니다.

1. karma의 Alertmanager 경보 집계와 관리

원문: karma · GitHub

karma는 Alertmanager의 경보 조회와 silence 관리 기능을 대시보드 형태로 확장한 도구입니다. 0.7.0부터 여러 Alertmanager의 경보를 모으고 중복을 제거합니다. HA 구성과 서로 독립된 인스턴스를 모두 지원하며, 경보를 발견한 인스턴스 이름을 @alertmanager 태그로 표시해 필터링에 사용합니다. 이 태그는 여러 인스턴스를 설정했을 때만 나타납니다. HA 클러스터를 구성했다면 @cluster도 사용할 수 있습니다.

화면은 Alertmanager의 group_by 설정을 유지하며 receiver별로 경보 그룹을 만듭니다. 각 경보에 고유한 레이블과 주석은 개별 영역에, 그룹 전체가 공유하는 값은 하단에 배치합니다. 같은 silence가 그룹의 모든 경보를 억제하면 silence도 하단에 한 번만 표시됩니다. 다른 경보 때문에 억제된 경보에서는 버튼을 눌러 억제 원인이 된 경보 목록을 확인할 수 있습니다. 레이블 값마다 별도 그리드를 만드는 기능도 제공합니다.

경보 이력은 Alertmanager의 장기 저장 기능을 사용하는 방식이 아닙니다. history:enabled를 true로 설정하면 각 경보의 source를 바탕으로 Prometheus에 관련 메트릭을 질의합니다. 지난 24시간의 시간별 경보 발생 횟수가 24개 블록으로 표시되며, 횟수가 많을수록 색이 짙어집니다. 이 기능에는 모든 관련 Prometheus 서버로의 연결이 필요합니다. 문서는 --web.external-url에 접근 가능한 서버 URL을 지정하도록 안내합니다.

karma는 Alertmanager >=0.22.0을 요구합니다. 수집한 경보 자체를 변경하지는 않지만 웹 UI에서 silence를 생성하거나 수정할 수 있습니다. 읽기 전용으로 제공하려면 모든 서버 설정에 readonly: true를 지정하고, 사용자에게 Alertmanager API 직접 접근을 허용하지 않아야 합니다. silence 생성·수정에 ACL을 적용하는 기능은 proxy 모드를 요구합니다.

2. 카카오의 OpenTelemetry와 ClickHouse 통합 플랫폼

원문: 카카오 Observability 도입 여정: OpenTelemetry와 ClickHouse 기반의 새로운 표준 · SecondB · 2025-09-24(영상 업로드)

카카오 김예솔의 발표 영상을 자동 요약한 SecondB 문서를 기준으로 정리했습니다. 카카오는 여러 서비스와 운영 팀이 서로 다른 모니터링 도구를 사용하면서 장애 범위 파악과 담당자 간 소통에 시간이 걸렸습니다. 로그는 Kibana, 지표는 Grafana에서 확인했고, Elasticsearch 확장 한계 때문에 로그 클러스터도 나눠 운영했습니다. 발표는 모든 텔레메트리를 OpenTelemetry로 수집하고 ClickHouse에 통합 저장하는 전사 플랫폼을 제시합니다. 팀마다 별도 시스템을 구축하고 운영하는 부담을 줄이는 것도 목표입니다.

새 K8S 클러스터에는 OpenTelemetry 에이전트가 자동으로 설치됩니다. 파드와 노드의 텔레메트리는 게이트웨이를 거쳐 ClickHouse로 전달되며, 물리 서버·VM·DB·네트워크 장비도 수집 대상에 포함됩니다. 수집 경로에는 법적 이슈와 데이터 유실 방지를 고려해 Kafka를 넣었습니다. Kafka retention을 이용해 데이터를 복구하도록 설계했습니다. 서비스별 Grafana에서는 담당 애플리케이션과 K8S의 로그·메트릭을 함께 조회하도록 구성합니다.

발표자는 실제 로그 데이터로 시험했을 때 Elasticsearch 대비 저장 용량이 85% 줄었다고 밝혔습니다. 이를 바탕으로 데이터 노드 수를 줄이고 데이터를 두 벌로 저장해 안정성을 확보할 수 있다고 봤습니다. ClickHouse의 높은 압축률, 컬럼 기반 처리, SIMD를 고려한 설계도 선택 이유로 제시했습니다. 여러 클러스터를 하나로 합쳐 운영 리소스를 줄이는 효과는 기대 사항으로 설명합니다.

도입 과정에서는 OpenTelemetry 버전별 옵션 동작과 Kafka 라이브러리 변경에 대응해야 했습니다. OTLP 벌크 처리는 여러 로그를 Kafka 메시지 하나에 담아 Kafka 지표만으로 트래픽과 처리량을 정확히 판단하기 어려웠습니다. Protobuf와 Zstandard로 인코딩·압축된 메시지는 디버깅도 어려웠고, 중간 processor 오류에 따른 유실 가능성도 확인했습니다. ClickHouse 전송 배치는 처리 성능을 확보하면서 OOM을 피해야 하므로 워크로드별 테스트가 필요했습니다. 필요한 컬럼 선택과 적절한 인덱스 등 데이터 모델링·쿼리 튜닝 이해도 요구된다고 설명합니다.

3. OpenTSLM의 시계열 언어 모델 구상

원문: OpenTSLM · OpenTSLM

OpenTSLM의 짧은 프로젝트 소개 페이지를 기준으로 정리했습니다. 프로젝트는 심박, 가격 변동, 센서 신호, 기계 로그처럼 시간에 따라 이어지는 데이터를 AI의 추론 대상으로 삼습니다. TSLM은 시계열을 텍스트와 나란히 네이티브 모달리티로 다루는 멀티모달 기반 모델입니다. 시계열 데이터를 자연어로 설명하고 추론하거나 예측하는 기능을 지향합니다.

공개 모델과 독점 모델은 학습 데이터와 제공 방식이 다릅니다. OpenTSLM은 공개 데이터로 학습한 경량 기반 모델을 개방해 개발자와 연구자가 사용하도록 합니다. Frontier TSLMs는 특화 데이터로 학습한 독점 모델로, 기업용 API·미세 조정·분야별 솔루션을 제공하는 방향입니다. 프로젝트는 연속적인 현실 신호를 지능형 의사결정과 자율 에이전트에 연결하는 계층을 만들겠다고 설명합니다.

연구진은 더 작고 빠른 기반 모델을 사용해도 시간적 추론 성능이 자릿수가 달라질 만큼(order-of-magnitude) 높아졌다고 주장합니다. 소개 페이지에는 이 주장을 확인할 벤치마크 조건이나 상세 측정값이 없습니다. 의료, 로봇, 인프라는 범용 TSLM이 지원할 미래 활용 분야로 제시됩니다.

4. Mercari IBIS의 사고 보고서 검색과 Slack 응답

원문: LLM x SRE: Mercari’s Next-gen Incident Handling Buddy · Tianchen Wang · 2025-02-06

Mercari의 Platform Enabler 팀은 사고 대응을 돕는 생성형 AI 시스템 IBIS를 개발했습니다. 목표는 과거 사고에서 얻은 정보를 활용해 MTTR과 온콜 담당자의 부담을 줄이는 것입니다. IBIS는 사고 관리 도구 Blameless의 회고 보고서에서 임시 조치, 근본 원인, 피해 내용을 가져옵니다. 정제·번역·요약한 보고서를 벡터로 저장하고, Slack에서 받은 자연어 질문과 관련된 자료를 찾아 답변을 생성합니다.

보고서 수출은 Google Cloud Scheduler가 주기적으로 시작하고 Cloud Run Jobs가 실행합니다. 파일이 Cloud Storage에 추가되면 Eventarc가 Cloud Workflow를 시작해 후속 처리를 연결합니다. 정제 단계에서는 LangChain의 Markdown Splitter로 필요한 절을 추출해 검색을 방해하는 템플릿을 제거합니다. 개인 식별 정보는 SpaCy의 토큰화와 단어 유형 판별을 이용해 제거합니다. 일본어와 영어가 섞인 보고서는 GPT-4o로 영어로 번역하고 요약한 뒤, OpenAI 임베딩 모델로 벡터화해 BigQuery에 저장합니다.

Slack 요청을 받는 서버는 Cloud Run Service에서 실행됩니다. 질문과 관련된 정보를 BigQuery에서 가져와 LLM 응답의 근거로 사용합니다. 같은 스레드의 후속 질문에는 앞선 질문과 답변도 입력에 포함해 대화 맥락을 유지합니다. 이 단기 기억은 인스턴스 메모리에 있으므로 재배포하면 사라집니다. 팀은 콜드 스타트에 따른 기억 손실을 피하려고 정기적인 uptime check를 보내고, 최소·최대 인스턴스 수를 모두 1로 설정했습니다.

첫 릴리스는 2024년 12월 말에 완료됐고, 글을 집필한 2025년 1월에는 주요 사고 대응 채널 여러 곳에 연결돼 있었습니다. MTTR 영향은 계속 관찰할 대상으로 남아 있으며, 글에는 감소 폭을 측정한 결과가 제시되지 않았습니다. 후속 계획에는 사람의 피드백을 반영하는 평가, 질문을 구체화하기 위한 Slack 폼, 사내 문서 기반 모델 미세 조정이 포함됩니다.

5. Go 서비스의 OpenTelemetry 계측과 LGTM 연계

원문: Observability made painless: Go, Otel & LGTM stack · SecondB · 2025-09-18(영상 업로드)

Haseeb Majid의 GopherCon UK 발표를 자동 요약한 SecondB 문서를 기준으로 정리했습니다. 발표는 마이크로서비스의 디버깅이 어려워진 상황에서 Go 웹 서비스를 OpenTelemetry로 계측하고 LGTM 스택으로 관찰하는 과정을 다룹니다. 로그는 특정 시점의 사건과 맥락, 트레이스는 요청의 생애 주기와 지연, 메트릭은 집계된 수치와 추세를 담습니다. OpenTelemetry의 API·SDK·Collector를 사용해 이 신호들을 수집하면서 벤더 종속을 피하는 방향을 설명합니다.

LGTM에서 Loki는 로그 본문 대신 레이블을 인덱싱하고 LogQL로 조회합니다. Tempo는 트레이스를 S3·GCS 같은 오브젝트 스토리지에 저장하며 Loki·Prometheus와 연동됩니다. Mimir는 Prometheus 메트릭을 위한 수평 확장 TSDB로 소개합니다. Grafana는 각 데이터 소스를 연결해 시각화, 대시보드, 알림을 담당합니다. Collector는 사이드카 또는 독립 프로세스로 배포할 수 있습니다.

Go 서비스에서는 SDK와 OTLP gRPC 익스포터를 설치하고 tracer provider와 meter provider를 초기화합니다. HTTP 핸들러, DB 쿼리, Redis 캐시 작업에 스팬을 만들고 HTTP 메서드·URL·상태 코드, DB 이름·쿼리, Redis 명령을 속성으로 기록합니다. 로그는 slog로 작성하고 trace ID와 span ID를 넣어 트레이스와 연결합니다. Grafana에서는 Exemplars로 메트릭 그래프에서 관련 트레이스로 이동하고, Baggage로 값을 다운스트림 서비스에 전파하는 기능을 소개합니다.

goroutine을 시작할 때는 context를 명시적으로 전달해야 새 스팬이 현재 스팬의 자식으로 이어집니다. 전달하지 않으면 트레이스가 끊기거나 잘못된 맥락에 연결될 수 있습니다. 오류는 스팬 상태와 메시지에 기록합니다. 저장량 조절에는 고정 비율 샘플링과 부하·중요도에 따라 비율을 바꾸는 적응형 샘플링을 소개합니다. 비율이 너무 낮으면 정보를 잃고, 너무 높으면 리소스 사용량이 증가한다고 설명합니다.

6. Gonzo의 터미널 로그 탐색과 AI 분석

원문: Gonzo: 실시간 로그 분석을 위한 Go 기반 TUI 도구 · 파파누보 · 2025-09-16

이 글은 다양한 형식의 로그를 터미널에서 실시간으로 분석하는 Go 기반 도구 Gonzo를 소개합니다. Gonzo는 stdin, 파일, 네트워크에서 로그를 받아 스트리밍 처리합니다. JSON, logfmt, 일반 텍스트를 자동으로 구분하며, OpenTelemetry 로그를 받는 OTLP 기능과 내장 gRPC·HTTP 리시버도 제공합니다. 입력 경로와 형식이 다른 로그를 대화형 화면에서 탐색하는 방식입니다.

화면은 k9s 스타일의 2×2 그리드로 구성됩니다. 단어 빈도, 속성 분포, 심각도, 타임라인 차트를 표시하며 전체 화면 로그 뷰어와 상세 보기 모달도 제공합니다. 심각도에 따라 색상을 구분하고 정규표현식·속성·심각도 필터로 분석 범위를 좁힐 수 있습니다. 로그 스트림 일시정지와 버퍼링도 지원합니다. 글의 Kubernetes 예제는 kubectl logs -f my-app | gonzo로 로그를 전달한 뒤, space 키로 흐름을 멈추고 :/error로 오류 로그를 필터링합니다.

AI 분석 기능은 반복 패턴과 비정상적인 로그 패턴을 분석하고 원인 후보를 제안합니다. 글은 OpenAI, LM Studio, Ollama 연동과 로컬 모델을 사용한 오프라인 분석을 지원한다고 설명합니다. 연계 대상에는 Kubernetes, Docker, CloudWatch, Victoria Logs가 포함됩니다. 화면 테마는 Dracula·Nord·Monokai 등 11개 이상이며, 라이트·다크 모드와 YAML 기반 사용자 설정도 제공합니다.

7. Parca Agent의 오프라인 프로파일 기록과 업로드

원문: Offline Mode for the Parca Agent · Brennan Vincent · 2025-08-07

Parca Agent의 오프라인 모드는 네트워크가 없거나 연결이 불안정한 기기에서 CPU 프로파일을 수집하기 위해 만들어졌습니다. 기존 방식은 CPU에서 실행된 코드의 스택 트레이스를 주기적으로 백엔드에 보내므로 연결이 끊긴 동안 수집한 데이터가 보고되지 않는 문제가 있었습니다. 새 모드는 데이터를 로컬에 저장하고 나중에 Parca 또는 Polar Signals Cloud 백엔드로 전송합니다. 글은 스마트폰과 자율주행차처럼 인터넷 연결을 항상 보장할 수 없는 기기를 배경으로 제시합니다.

온라인 모드에서는 스택을 해시한 ID와 출현 횟수를 먼저 보내고, 백엔드가 요청한 ID의 전체 스택만 추가로 전송합니다. 오프라인 모드에서는 5초마다 파일에 레코드를 기록합니다. 첫 레코드는 스택 ID와 횟수이고, 다음 레코드는 같은 파일에 아직 기록하지 않은 ID의 전체 스택입니다. 각 레코드 앞에는 바이트 크기가 붙습니다. 에이전트는 fsync를 호출한 뒤 파일 헤더의 배치 개수를 갱신합니다. 이 순서 덕분에 일부만 기록된 파일을 읽어도 완성된 배치만 보게 됩니다. 종료 시점에 쓰던 마지막 배치 전체는 누락될 수 있습니다.

파일은 기본 10분마다 회전하고 ZSTD로 압축됩니다. 이름은 {timestamp}-{pid}.padata 형식입니다. 업로더는 파일명의 타임스탬프 순서로 읽어 온라인 모드와 같은 프로토콜로 전송합니다. 성공한 파일은 저장 디렉터리에서 삭제하므로 중단 후 남은 파일부터 이어서 처리할 수 있습니다. 수집한 디렉터리에 접근할 수 있다면 업로드는 다른 기기에서도 가능합니다.

대상은 저장소에 안정적으로 접근할 수 있는 x86-64 또는 aarch64 Linux입니다. 수집 시 --offline-mode-storage-path로 저장 경로를 지정합니다. 업로드할 때는 같은 경로에 --offline-mode-upload와 --remote-store-address 같은 백엔드 설정을 함께 전달합니다.

8. Perses Go SDK의 재사용 가능한 대시보드 구성

원문: Composable Dashboards - Lessons from building Perses Community Dashboards · Perses · 2025-06-10

Perses 커뮤니티는 오래된 대시보드를 고치거나 다른 구성에 맞추기 위해 같은 대시보드를 반복해서 만드는 문제를 제기합니다. 대시보드와 알림을 코드와 함께 묶는 mixin도 재사용을 목표로 했지만, 글은 Jsonnet 학습 부담과 애플리케이션 코드와의 분리를 한계로 꼽습니다. Go 구조체를 직접 사용할 수 없어 코드 변경에 맞춘 자동 검증이 어렵습니다. Jsonnet으로 만든 kube-prometheus 스택에서도 많은 사용자는 Jsonnet을 쓰지 않습니다. 렌더링된 YAML만 가져온 뒤 Kustomize 같은 도구로 수정합니다. 이 과정에서 원래 의도한 재사용과 표준화가 약해진다고 설명합니다.

Perses는 설정과 플러그인을 Go 구조체로 정의한다는 점을 활용합니다. Go SDK가 이 구조체를 가져와 대시보드를 구성하므로 본체의 데이터 모델과 패널 플러그인 버전에 맞춰 타입 안전성을 유지할 수 있습니다. community-dashboards는 완성된 YAML뿐 아니라 Go 모듈로 가져올 수 있는 대시보드와 패널 라이브러리를 제공합니다. 사용자는 필요한 대시보드 일부만 생성하거나 공통 패널을 조합해 원하는 화면을 만들 수 있습니다.

예제의 CPUUsage 함수는 데이터 소스와 레이블 매처를 받아 시계열 패널을 만듭니다. process_cpu_seconds_total에 $__rate_interval을 적용한 rate 쿼리를 구성하고 범례·축·선 표시를 설정합니다. 이 패널을 Workload / Overview 대시보드에 넣을 때는 job 변수와 클러스터 레이블 매처를 전달합니다. 패널 정의를 재사용하면서 데이터 선택 조건을 대시보드에 맞추는 사례입니다.

글은 컴파일 시점의 타입 검사, 패널 중복 제거, 한 곳에서 수정한 정의의 재사용, CI/CD에서의 버전 관리·리뷰·테스트를 이 접근의 장점으로 설명합니다. 초기 대시보드 대상에는 Kubernetes, Prometheus, Node Exporter, Blackbox Exporter, Thanos가 포함됩니다. 커뮤니티는 지원 프로젝트를 넓히고 패널 라이브러리와 문서를 개선할 계획입니다.

9. 파드 재시작 정보 수집과 Slack 알림

원문: Optimize kubernetes stability with k8s-pod-restart-info-collector · Vadiraj Puranik · 2024-09-15

이 글은 파드 재시작 원인을 조사할 때 필요한 정보를 자동으로 모으는 k8s-pod-restart-info-collector를 소개합니다. 인프라 문제, 리소스 제한, probe 실패, 애플리케이션 충돌 등 재시작 원인은 다양합니다. Kubernetes 명령으로 정보를 조회할 수 있지만, 저자는 빠른 조사를 위해 관련 자료를 모아 전달하는 도구가 필요하다고 설명합니다. Airwallex 팀이 만든 이 오픈소스 도구는 재시작 시각, 오류 코드, 로그, 이벤트와 파드·노드 상태를 수집해 지정한 Slack 채널로 보냅니다.

설치 예제는 minikube 클러스터와 Slack 계정·채널을 사용합니다. Slack 앱에서 Incoming Webhooks를 활성화하고 대상 채널에 연결한 뒤, Helm에 slackWebhookUrl, clusterName, slackChannel 값을 전달합니다. 배포된 수집기는 파드로 실행되며 클러스터를 관찰합니다. 글은 Slack 앱 생성부터 Webhook 설정, Helm 배포까지의 절차를 제시합니다.

시연에서는 정상 파드에 polinux/stress로 메모리 부하를 가해 재시작을 유도했습니다. 출력에는 OOMKilled 상태와 재시작 횟수 1이 나타납니다. 이어서 받은 Slack 알림의 Pod Status 영역에는 재시작 원인, 이전·현재 상태, 리소스 할당량, 재시작 횟수가 포함됩니다. 파드 이벤트와 노드 이벤트도 함께 제공됩니다. 이 사례는 메모리 부족으로 종료된 파드의 상태와 주변 이벤트를 한 알림에서 확인하는 과정을 보여줍니다.

10. gmon의 고루틴 생성·종료 추적

원문: Goroutine MONitor (gmon) · GitHub

gmon은 Go 프로그램에서 고루틴의 생성과 종료를 관찰하는 eBPF 도구입니다. README는 Real World Debugging with eBPF 발표에서 영감을 얻었다고 설명합니다. 실행할 때 필수 옵션 -path로 관찰할 실행 파일을 지정합니다. 같은 프로그램의 실행 인스턴스가 많으면 -pid로 대상을 지정할 수 있습니다. 고루틴 생성 이벤트는 ID와 스택 트레이스를 포함해 표준 출력에 기록됩니다.

실행 조건은 amd64(x86_64), Linux Kernel 5.8 이상, Go 1.23 이상으로 컴파일한 대상 바이너리입니다. 커널 조건은 BPF ring buffer 사용 때문이며, Go 버전 조건은 고정 오프셋으로 고루틴 ID를 읽는 방식에서 비롯됩니다. 로그 수준은 DEBUG, INFO, WARN, ERROR 중에서 고르며 기본값은 INFO입니다. -pprof에 포트를 지정하면 pprof 서버를 시작하고, 값이 0이면 시작하지 않습니다. -trace는 Go runtime/trace 출력 경로를 지정하는 옵션입니다.

메트릭 서버는 기본 포트 5500에서 실행되며 GET /metrics에 OpenMetrics 형식으로 데이터를 노출합니다. 예제 메트릭에는 stack_0, stack_1처럼 호출 스택을 나타내는 레이블이 붙습니다. 생성·종료 횟수는 counter이고, 고루틴 생존 시간은 초 단위 histogram으로 제공합니다.

• gmon_goroutine_creation: 생성된 고루틴 수
• gmon_goroutine_exit: 종료된 고루틴 수
• gmon_goroutine_uptime: 고루틴 생존 시간의 초 단위 분포