day-log

absent_over_time 알람에 for 절 안 넣으면 생기는 일

무슨 일이 벌어지는가absent_over_time(up{job="api"}[5m]) 같은 알람 표현식은 "지정한 메트릭이 5분 동안 한 번도 안 보이면 1을 반환"한다. 그래서 잡 다운 감지용으로 흔히 쓴다. 근데 함정이 있다.Prometheus 프로세스가 막 기동했을 때, 아직 첫 스크레이프가 끝나지 않은 시점에서 이 표현식이 평가되면 어떻게 될까? 메트릭이 없으니까 그냥 1 이 나온다. 그리고 알람룰에 for 절이 없으면 그 즉시 firing.# 이렇게 쓰면 Prometheus 재시작할 때마다 알람 옴- alert: ApiDown expr: absent_over_time(up{job="api"}[5m]) labels: severity: critical룰 평가 주기가 보통 30초~1분이라, P..

Grafana Alloy vs OpenTelemetry Collector, 결국 뭘로 갈까

관측성 파이프라인 한 번이라도 운영해본 사람이면 다 비슷한 고민을 한다. "에이전트는 뭘로 깔지?" 예전에는 Prometheus + Promtail + Tempo agent 같은 식으로 컴포넌트별로 따로 깔거나, 통합하려면 OpenTelemetry Collector 한 장 깔거나, 그것도 아니면 Grafana Agent 깔거나. 그런데 Grafana Agent가 Alloy로 리브랜딩된 이후, 그리고 그 사이에 OTel Collector contrib도 계속 두꺼워지면서 선택지가 다시 흐릿해졌다.우리 팀에서도 작년 말에 한 번 정리하고 갔는데, 최근 Alloy v1.16 시리즈가 나오고 OTel Collector 쪽도 컴포넌트가 또 바뀌면서 다시 비교할 필요가 생겼다. 이번 글은 그 정리 노트다. 어느 쪽..

들어가며작년 말부터 트레이싱 백엔드를 갈아엎자는 얘기가 팀 내부에서 계속 나왔다. 직접적인 계기는 Jaeger v1이 2025년 12월 31일부로 EOL을 맞은 것이었다. 어차피 손을 대야 한다면 Jaeger v2로 갈지, Tempo로 옮길지 둘 중 하나를 골라야 했다. 결론부터 말하면 우리는 Tempo로 갔다. 그런데 솔직히 말해서 이 결정이 모든 팀에 정답은 아니다.두 솔루션이 지금 어디쯤 와 있는지Jaeger v2는 2024년 11월에 정식 릴리즈됐는데, 기존 코드베이스를 거의 다 버리고 OpenTelemetry Collector 위에 다시 쌓아 올린 구조다. 그러니까 Jaeger v2는 사실 "Jaeger 구성요소가 추가된 OTel Collector distribution"에 가깝다. 최근 2.1..

지난주 화요일 새벽 3시쯤이었다. 슬랙 oncall 채널에 "그라파나 대시보드 일부 패널이 No data로 뜬다"는 핑이 올라왔다. 자다가 받은 알림이라 멘탈이 좀 나간 상태에서 노트북을 열었는데, 진짜로 우리 결제 서비스 P99 레이턴시 그래프가 새벽 1시 47분부터 약 한 시간 동안 비어 있었다.문제는 Prometheus 자체는 멀쩡했다는 거다. up{} 메트릭도 정상이고 로컬 쿼리도 잘 됐다. 그런데 Thanos를 통해 보던 장기 보관 대시보드에서만 그 구간이 통째로 비어 있었다. 결론부터 말하면 remote_write 큐가 막혀서 WAL에서 읽기가 블록됐고, 그 사이에 들어온 샘플들이 일부 누락됐다. 이게 내가 새벽 4시까지 깨어 있었던 이유다.처음 의심한 것들 (다 틀렸음)가장 먼저 의심한 건 ..

지난주 새벽에 알림으로 깼다. otel-collector 데몬셋의 절반이 CrashLoopBackOff로 떨어졌다는 메시지. 그 시점에 트레이스 수집이 사실상 끊겨 있어서 우리 팀이 운영하는 서비스 절반 정도의 트레이스 대시보드가 비어 있었다. 평일 새벽 두 시였고 멘탈은 그닥이었다.처음엔 단순히 노드 메모리 압박이려니 했다. 그런데 살펴보니까 콜렉터만 죽는 거다. 다른 파드는 다 멀쩡. OOMKilled가 한두 번이 아니라 5분에 3-4번씩 반복되고 있었다. 메모리 limit이 1Gi였는데, 어떻게 잡힌 메모리가 그 한도를 매번 풀로 채우고 떨어졌다 다시 살아나고를 반복.일단 상황 정리kubectl describe로 보니까 Last State가 Terminated, Reason: OOMKilled, E..

라벨 vs structured metadata, 결정 기준오늘 알게 된 건데, 아직 Loki에서 pod나 trace_id를 라벨로 박고 계신 분들 꽤 많더라. Loki 3.x부터는 structured metadata가 정식으로 들어왔는데 활용 안 하면 진짜 손해다. 라벨 카디널리티 폭증 없이 검색 가능한 메타데이터를 붙일 수 있는 기능이다.Loki에서 라벨은 인덱스가 만들어지는 대상이라 카디널리티가 곧 비용이다. namespace, app 같은 저카디널리티 값만 라벨로 두고, trace_id, request_id, pod_name, thread_id 같은 고카디널리티 값은 structured metadata로 옮기는 게 정석이다. Grafana 공식 가이드도 "OpenTelemetry 데이터 ingest..

요즘 운영하는 클러스터에서 메트릭 카디널리티가 슬슬 부담스러워졌다. http_request_duration_seconds 하나만 봐도 le 버킷이 12개씩 붙고, 거기에 method/status/route 라벨까지 곱해지면 한 서비스가 5만 series를 우습게 넘긴다. 그래서 작년부터 native histogram 으로 옮기는 작업을 조금씩 해왔는데, v3.8 부터 stable 표기가 붙으면서 본격적으로 손을 댔다.이번 글은 "어떻게 켜는지"가 아니라 "왜 이게 그렇게 효율적인지"에 대한 이야기다. 사실 내부 구조를 모르고 켜면 ingester 메모리만 튀어서 한참 헤매게 된다.classic histogram 의 비효율은 어디서 오는가classic histogram 은 도구라기보다 관행에 가깝다. le..

작년 말부터 트레이스 양이 폭증했다. 서비스가 늘어난 것도 있고, 한 요청이 마이크로서비스 7~8개를 거치다 보니 한 트랜잭션에 span이 200개 가까이 붙는 케이스도 생겼다. 그대로 Tempo에 다 밀어 넣었더니 스토리지 비용이 분기마다 1.6배씩 뛰었다. 샘플링을 손봐야 한다는 결론은 너무 자명했는데, 막상 head냐 tail이냐를 고르는 자리에선 팀 안에서도 의견이 갈렸다.결론부터 말하면 우리는 두 개를 섞었다. 그래서 이 글은 어느 한쪽이 정답이라는 얘기가 아니다. 각각의 결을 보고, 어디서 어떤 걸 골랐는지 정리한다.Head sampling — 빠르고 가난한 선택지Head sampling은 트레이스가 시작되는 시점, 그러니까 SDK가 root span을 만들 때 보낼지 말지를 결정한다. Par..

지난주 새벽에 페이지가 울렸다. OTel Collector DaemonSet이 또 OOMKilled. 이번 분기에만 세 번째다. 솔직히 처음 두 번은 "그냥 limit을 올리지" 하고 넘어갔는데, 이번엔 메모리를 2Gi → 4Gi로 올렸는데도 또 죽으니까 멘탈이 살짝 나갔다.근본 원인을 보려고 새벽 3시에 노트북을 열었다. 결론부터 말하면 memory_limiter 설정과 GOMEMLIMIT이 둘 다 잘못 잡혀 있었고, batch processor의 순서까지 어긋나 있었다. 우리 팀은 1년 전에 OTel Collector를 처음 도입했을 때 공식 예제 그대로 복붙해 놓고 그동안 트래픽이 4배가 늘었는데도 손을 안 댔던 거다. 부끄럽다.일단 무슨 일이 일어났던 건가우리 클러스터는 노드 80대 정도 되고 각..

작년 말쯤 로그 파이프라인을 다시 손볼 일이 생겼다. 기존엔 모든 노드에 Fluent Bit DaemonSet으로 쓰고 있었는데, 트랜스폼 규칙이 복잡해지면서 Lua 필터가 점점 괴물이 되어가는 게 보였다. 그래서 한쪽 클러스터에 Vector를 시범 도입했고, 결국 6개월 동안 두 도구를 같은 워크로드에 나란히 굴려보게 됐다. 이 글은 그 결과 정리다. 결론부터 말하면, 둘 다 자리가 있다. 다만 자리가 다르다.우리 환경먼저 맥락. 이걸 안 깔면 비교가 의미가 없다.EKS 클러스터 2개, 합쳐서 노드 약 90대 (m6i.2xlarge ~ m7i.4xlarge 혼재)로그 발생량: 평시 평균 35k logs/sec, 피크 110k logs/sec목적지: S3 (장기), OpenSearch (검색), Kafk..