728x90
최근 그라파나를 본격적으로 운영하면서 있었던 이슈이다.
사실 모든 문제는 다 스케일 업 시키면 되긴했지만, 근본적으로 왜? 에러가 나는지 초점에 맞추어 근본 원인을 찾아냈다
문제 1 : Mimir / Out of order sample
sample has been rejected because another sample with a more recent timestamp has already been ingested
Mimir는 Push된 시계열(metric sample) 들을 시간 순서대로 처리
그런데 다음과 같은 상황에서 out-of-order sample 에러 발생
- 같은 시계열(metric series) 에 이미 T2 시점의 샘플이 들어왔는데
- 그 다음에 T1 (< T2) 시점의 샘플이 들어옴
- → 이건 “순서 어긋남”, 즉 Out-of-order라고 간주되어 거부됨
원인
Distributor ⇒ Ingester로 보내는 속도 / 양이 너무 작았음
Mimir는 Distributor가 ingester에게 데이터를 밀어넣는 속도가 한계치를 초과하면 enqueue 지연 + 데이터 reorder 문제 발생
- 버스트량이 작으면 → 내부 큐에 다 못 넣음 → 샘플 전송 순서가 꼬임
- 초당 처리량 제한이 작으면 → 샘플이 오래 대기 → 타임스탬프 기준으로 out-of-order
해결
mimir ingester 설정 값 허용 증가
ingestion_rate: 150_000 # 초당 허용 샘플 수
ingestion_burst_size: 1_500_000 # 단기 폭발적 수용 허용치
- Distributor → Ingester로 빠르게 샘플이 보내짐
- 큐 overflow 없이 → 시간 순서 보존됨
- 그래서 Out-of-order sample 거부가 사라짐
문제 2 : Mimir err-mimir-max-series-per-user
mimir ingester 지속적인 에러 발생
tenant=서비스명: per-user series limit of 150000 exceeded (err-mimir-max-series-per-user)
원인
- grapqhl 특성
- 리스트(예: 유저 100명)를 조회하는 요청일 경우, 내부적으로 각 유저마다 리졸버가 실행되고, 이때 매번 세부적인 추적 정보(span)가 생김
graphql.resolve boards.nodes.1.title
graphql.resolve boards.nodes.2.title
graphql.resolve boards.nodes.3.title
graphql.resolve boards.nodes.4.title
graphql.resolve boards.nodes.5.title
graphql.resolve boards.nodes.6.title
graphql.resolve boards.nodes.7.title
graphql.resolve boards.nodes.8.title
graphql.resolve boards.nodes.9.title
따라서 span_name에 약 4만개 이상의 정보가 들어가 이슈가 발생
- RestAPI서버 : 약 800개
- Graphql서버 : 약 4만개 이상
해결
- opentelmetry sdk에서 제시한 방안 중 mergeItems옵션을 추가
- mergeItems를 사용 시
- 각 항목(예: 사용자 100명)에 대해 매번 추적 정보를 남기지 않고 첫 번째 항목 하나만 대표로 기록
- 적용 이후 모습
graphql.resolve boards.nodes.*.title
문제 3 : Tempo / TRACE_TO_LARGE 이슈
tempo ingester에서 다음과 같은 지속적인 에러 발생 TRACE_TOO_LARGE max=5000000
원인
- db 커넥션을 관리하는 @opentelemetry/instrumentation-generic-pool 라이브러리에서 모든 풀 맺고 끊는 모든 span을 기록 중
해결
- 불필요한 기록 데이터로 보임
- @opentelemetry/instrumentation-generic-pool 라이브러리 false로 처리
728x90