릴리즈

v0.151.0은 OTLP receiver 설정 구조체에서 API 수준의 breaking change가 있고, builder의 go.mod 생성 기본 동작이 바뀝니다. 듀얼스택 gRPC 연결 문제 해결과 pprofile 데이터 손상 버그 수정이 운영 측면에서 가장 주요한 변경입니다.

• breaking커스텀 콜렉터에서 OTLP receiver 필드 접근 방식 수정 필요

  OTLP receiver의 Config.Protocols가 이제 named field로 바뀌어, cfg.GRPC / cfg.HTTP를 직접 참조하는 코드는 컴파일이 깨집니다. OTLP receiver를 임베드하거나 확장한 커스텀 콜렉터가 있다면 cfg.Protocols.GRPC, cfg.Protocols.HTTP로 변경한 뒤 업그레이드하세요.

• breaking빌더 생성 결과물을 커밋한다면 go.mod 경로 방식 확인

  cmd/builder가 생성하는 go.mod의 replace 경로가 기본값으로 상대 경로로 바뀌었습니다. 여러 머신에서 동일한 생성 코드를 빌드한다면 이 변경이 유리하지만, 절대 경로를 파싱하는 스크립트나 툴링이 있다면 dist::use_absolute_replace_paths: true를 설정해 기존 동작을 유지하면서 마이그레이션하세요.

• enhancement듀얼스택 DNS 환경의 gRPC 연결 문제는 passthrough 리졸버로 해결

  grpc.NewClient 전환 이후 듀얼스택 DNS 환경에서 OTLP gRPC 익스포터 연결이 간헐적으로 실패하는 사례가 보고됐습니다. exporter 설정의 endpoint를 passthrough:///host:port 형식으로 바꾸면 해결됩니다. IPv4/IPv6 혼용 환경에서 연결 오류를 겪고 있다면 우선 이 방법을 시도해보세요.

v1.120.1은 탄소 비용 계산 오류 수정, AWS Spot 가격 캐싱, 메모리 최적화, 그리고 MCP 서버 기본값 변경을 담은 패치 릴리스입니다.

• breakingMCP 서버 기본값 변경 — 의존 중인 통합 환경 확인 필요

  MCP 서버가 기존에는 별도 설정 없이 활성화 상태였지만, 이번 변경으로 명시적으로 켜야만 동작합니다. 별도 설정 없이 MCP 서버를 사용하던 도구나 연동 시스템이 있다면 업그레이드 후 조용히 멈출 수 있습니다. 배포 전에 MCP_SERVER_ENABLED=true 설정이 필요한 환경인지 반드시 점검하세요.

• enhancementAWS Spot 사용 환경: Spot 가격 캐싱으로 API 부하 감소

  Spot 인스턴스를 사용한다면 기존에는 Spot Price History API를 빈번하게 호출했습니다. 캐싱 레이어 추가로 API 호출 횟수가 줄어 속도 제한 문제와 비용 귀속 지연이 완화됩니다. 별도 조치는 필요 없지만, 업그레이드 후 Spot 비용 데이터가 정확하게 집계되는지 확인해보는 게 좋습니다.

• enhancement탄소 비용 데이터 오류 수정 — 탄소 지표 사용 시 재기준선 설정 필요

  프로바이더 감지 오류와 폴백 로직 버그로 인해 이전 버전의 탄소 비용 수치가 부정확했을 수 있습니다. 탄소/배출량 데이터를 팀이나 대시보드에 제공하고 있다면, 업그레이드 후 이 버전 경계를 기준으로 과거 데이터와 단순 비교하지 말고 새로 기준선을 잡아야 합니다.

Prometheus v3.11.3은 자격증명 노출, snappy 페이로드를 통한 DoS, 구 UI의 저장형 XSS 등 세 가지 보안 취약점을 수정합니다.

• security/-/config 엔드포인트에 접근 가능했다면 AzureAD client_secret 즉시 교체

  AzureAD remote write를 사용 중이고 /-/config 엔드포인트가 신뢰할 수 없는 사용자에게 노출된 적이 있다면 client_secret이 이미 유출됐다고 봐야 합니다. Azure AD에서 즉시 시크릿을 교체한 뒤 v3.11.3으로 업그레이드하세요. 이 엔드포인트가 외부에 공개되어 있지 않은지도 함께 점검하세요.

• securityRemote-read를 외부에 노출 중이라면 즉시 업그레이드 필요

  snappy 디코드 취약점은 공격자가 디코딩 길이를 부풀린 요청을 전송해 메모리를 고갈시킬 수 있는 DoS 벡터입니다. remote-read 엔드포인트가 신뢰 경계 외부에서 접근 가능하다면 실제 위협입니다. 설정 레벨의 우회책은 없으므로 v3.11.3으로 빠르게 업그레이드하세요.

• security구 UI를 아직 사용 중이라면 XSS 노출 여부 확인 후 업그레이드

  구 UI 히트맵의 저장형 XSS는 사용자가 레이블 값에 영향을 줄 수 있는 환경(계측 애플리케이션 등)에서 다른 사용자가 해당 차트를 열람할 때 동작합니다. 이미 새 UI로 전환했다면 영향 없습니다. 그렇지 않다면 지금 바로 업그레이드하거나, 업그레이드 전까지 UI 접근을 신뢰할 수 있는 사용자로 제한하세요.

Prometheus v3.5.3은 보안 전용 릴리스로, 자격증명 노출, 스내피 압축 폭탄 2건, 레거시 UI의 저장형 XSS 등 4개의 취약점을 패치합니다.

• security/-/config 엔드포인트가 외부에 노출됐다면 즉시 AzureAD client_secret 교체

  AzureAD remote write를 사용하는 모든 Prometheus 인스턴스는 /-/config 엔드포인트에서 OAuth client_secret이 평문으로 드러났습니다. 해당 엔드포인트가 비인가 사용자나 모니터링 도구에 의해 접근 가능했다면 시크릿이 유출된 것으로 간주해야 합니다. Azure AD에서 시크릿을 교체하고 Prometheus 설정을 업데이트한 뒤 v3.5.3으로 업그레이드하세요. 업그레이드 후에는 리버스 프록시 또는 --web.enable-admin-api 설정으로 /-/config 접근을 제한하는 것이 좋습니다.

• security외부 소스로부터 remote-read/write를 받는다면 즉시 업그레이드

  remote-read와 remote-write 엔드포인트 모두 압축 폭탄 공격에 취약했습니다. 선언된 디코딩 크기를 부풀린 스내피 요청으로 메모리를 고갈시킬 수 있었습니다. 인터넷에 노출된 Prometheus이거나 멀티 테넌트 환경에서 데이터를 수신한다면 서비스 거부 공격 위험이 있습니다. 설정으로 우회할 방법은 없으므로 v3.5.3으로 업그레이드하는 것이 유일한 해결책입니다.

• security레거시 UI 사용 시 저장형 XSS 패치 적용 필요

  구형 UI 히트맵이 'le' 레이블 값을 이스케이프 없이 렌더링해 저장형 XSS가 가능했습니다. 외부나 사용자가 제어하는 시스템에서 'le' 레이블이 수집되고 있다면, 악성 자바스크립트가 브라우저에서 실행될 수 있습니다. v3.5.3으로 업그레이드하세요. 단기 조치로는 사용자를 신규 UI로 유도하는 방법도 있습니다.

Cortex v1.21.0은 여러 실험적 기능을 정식으로 졸업시키고, PRW2 데이터 손상 및 패닉 버그를 다수 수정했습니다. Store Gateway의 Parquet 모드와 테넌트 한도를 API로 제어하는 Overrides API도 새로 추가됐습니다.

• breaking업그레이드 전 이름 변경된 플래그 전수 점검 필요

  -experimental.ruler.enable-api는 -ruler.enable-api로, -experimental.alertmanager.enable-api는 -alertmanager.enable-api로 바뀌었습니다. -distributor.otlp.enable-type-and-unit-labels는 no-op이 되어 -distributor.enable-type-and-unit-labels로 통합됐고, parquet 캐시 플래그에서 'queryable'이 제거됐습니다. users-scanner의 cleanup-interval은 update-interval로 바뀝니다. 현재는 deprecated 상태라 바로 오류가 나지 않지만, 다음 릴리스에서 제거될 수 있으므로 지금 당장 설정 파일과 Helm values를 검토하세요.

• breakingPRW2 데이터 손상·패닉 수정 — PRW2 사용 중이라면 즉시 업그레이드 대상

  Remote Write V2 핸들러에서 세 가지 버그가 함께 수정됐습니다. Samples/Histograms 얕은 복사로 인한 데이터 손상, 더러운 sync.Pool 재사용으로 인한 index-out-of-range 패닉, 그리고 pool 반환 시 Symbols 배열 미초기화로 인한 메모리 누수입니다. PRW2를 운영 중이라면 이번 업그레이드는 선택이 아닌 필수입니다. 업그레이드 후 인제스천 파이프라인을 검증하고 메트릭 정합성을 확인하세요.

• enhancement버킷 인덱스 기본 활성화 — 스토리지 권한 사전 확인 필요

  버킷 인덱스가 이번 릴리스부터 기본으로 켜집니다. 의도적으로 비활성화해 두었거나 오브젝트 스토리지 IAM 정책에서 list 작업을 제한해 둔 경우, 업그레이드 후 인덱스 쓰기·읽기가 정상 동작하는지 반드시 확인하세요. 권한 오류는 명확한 설정 오류 메시지 대신 쿼리 실패로 나타날 수 있습니다.

Litmus 3.28.0은 프로브 설정 누수, 구독자 크래시, 프론트엔드 이미지의 Python 취약점을 수정한 유지보수 릴리스입니다.

• security프론트엔드 이미지 업그레이드로 Python 취약점 제거

  기존 ubi8 기반 프론트엔드 이미지에 Python CVE가 존재했습니다. 3.28.0에서 ubi9로 전환해 해소했습니다. Trivy, ACS, Prisma 등 이미지 스캐닝 정책을 운영 중이라면 3.28.0 프론트엔드 이미지로 재배포하면 해당 경고가 사라집니다. 별도 설정 변경 없이 이미지 교체만으로 충분합니다.

• breaking프로브 설정 누수 수정으로 동일 타입 다중 프로브 동작 변경 가능

  동일 타입의 프로브를 한 실험에 여러 개 정의했을 때, 이전 버전은 프로브 간 설정이 암묵적으로 공유됐습니다. 이번 수정으로 프로브별 설정이 완전히 분리됩니다. 업그레이드 전에 관련 실험을 점검하세요. 설정 누수에 의존하던 케이스가 있다면 결과가 달라질 수 있습니다.

• enhancementGitOps 및 이벤트 기반 워크플로우의 구독자 안정성 개선

  Argo Workflow ADD 이벤트에 ChaosEngine 노드가 포함된 환경에서 구독자가 간헐적으로 크래시되던 문제가 수정됐습니다. 이런 패턴을 사용 중이었다면 3.28.0 업그레이드 후 구독자 파드를 수동으로 재시작할 필요가 없어집니다. 업그레이드 후 구독자 파드 안정성을 확인해 기존 재시작 이슈가 해소됐는지 검증하세요.

OpenCost v1.120.0은 OVH 클라우드 프로바이더 지원, AWS CUR 2.0 호환성을 추가하고, AWS·DigitalOcean·S3 통합 전반의 리소스 누수 및 버그를 수정했습니다.

• breaking업그레이드 후 PV 비용 수치 검증 필요

  이전 버전에서 Ki/Mi/Gi/Ti 단위의 PV 용량을 잘못 파싱해 영구 볼륨 비용 할당이 틀렸을 가능성이 있습니다. 업그레이드 후 PV 비용 데이터를 반드시 확인하세요. 이상한 PV 비용 수치를 보고 있었다면 이번 수정으로 해결될 겁니다.

• enhancementAWS CUR 2.0으로 전환 — 지금이 적기

  AWS가 CUR 1.0 지원 종료를 예고한 상황에서, 이번 릴리스로 CUR 2.0 지원이 추가됐습니다. 아직 CUR 1.0 내보내기를 사용 중이라면 AWS 빌링 내보내기 설정을 CUR 2.0으로 전환하고 OpenCost가 새 형식을 바라보도록 구성을 업데이트하세요. AWS가 강제 전환하기 전에 미리 진행하는 게 좋습니다.

• enhancementSpot 미사용 팀은 Spot Data Feed 토글 비활성화로 로그 정리

  AWS Spot 인스턴스를 쓰지 않는 환경에서도 Spot 데이터 피드 관련 경고 로그가 계속 발생하는 문제가 있었습니다. 이제 설정 토글로 명시적으로 비활성화할 수 있으니, Spot을 사용하지 않는다면 해당 옵션을 꺼두는 게 좋습니다. 오해를 유발하는 로그도 함께 정리됩니다.

Prometheus v3.11.2은 웹 UI의 저장형 XSS 취약점(CVE-2026-40179)을 패치하고 Consul SD 버그 2건을 수정합니다. UI가 외부에 노출된 환경이라면 즉시 업그레이드하세요.

• securityPrometheus UI가 노출된 환경이라면 CVE-2026-40179 즉시 패치

  스크레이프 대상이 메트릭 이름이나 레이블 값을 조작하면 UI에 악성 스크립트를 심을 수 있는 저장형 XSS입니다. 운영팀 외 사용자가 Prometheus UI에 접근할 수 있는 환경(내부 대시보드, 페더레이션 구성 등)이라면 즉각 v3.11.2로 업그레이드하세요. 당장 업그레이드가 어렵다면 네트워크 정책이나 인증 프록시로 UI 접근을 제한하는 것이 먼저입니다.

• breaking업그레이드 후 Consul SD 스크레이프 대상 변경 여부 반드시 확인

  Consul Health API에 filter 파라미터가 잘못 적용되던 버그가 수정됐습니다. 의도치 않게 해당 동작에 의존하고 있었다면 업그레이드 후 발견되는 서비스 목록이 달라질 수 있습니다. 프로덕션 배포 전에 Consul SD 설정을 검토하고, 스크레이프 대상이 예상과 일치하는지 검증하세요.

• enhancementConsul SD의 `health_filter`로 비정상 서비스 제거 간소화

  새로 추가된 `health_filter` 필드를 사용하면 SD 레이어에서 직접 Consul Health API 응답을 필터링할 수 있습니다. 지금까지 릴레이블링 규칙으로 비정상 인스턴스를 걸러내고 있었다면, `health_filter: healthy`로 설정해 그 규칙들을 정리하세요. 불필요한 타깃 변동(churn)도 줄어듭니다.

v0.150.0은 소규모 버그 수정 릴리스입니다. print-config --unredacted 출력 누락, 내부 OTLP 익스포터 헤더 노출, debug 익스포터 인덱스 범위 초과 등 세 가지 버그를 고쳤습니다.

• securitymarshaled config에서 내부 OTLP 익스포터 헤더 redact 처리

  내부 텔레메트리 OTLP 익스포터의 헤더가 config를 marshal할 때 평문으로 노출됐습니다. 헤더에 인증 토큰이 담길 수 있으므로 설정 스냅샷을 로그나 저장소에 기록하는 팀은 기존 저장본을 점검하세요. 업그레이드 후에는 marshal 시 자동으로 redact됩니다.

• enhancementprint-config --unredacted 모드의 기본값 누락 버그 수정

  print-config 명령의 --unredacted 모드가 기본값 옵션을 모두 누락했던 버그가 수정됐습니다. confmap.WithUnredacted MarshalOption 도입으로 컴포넌트 기본값이 이제 정상 출력됩니다. 설정 감사나 디버깅에 print-config를 쓴다면 업그레이드 후 재실행해 출력이 완전한지 확인하세요.

v3.11.0은 새로운 서비스 디스커버리 기능과 TSDB 실험적 기능을 대거 추가했습니다. 특히 보존 기간이 설정값보다 100만 배 길어지는 심각한 버그가 수정되었으니 즉시 업그레이드해야 합니다.

• breakingTSDB 보존 기간 버그 수정 — 디스크 폭증 전에 업그레이드

  config 파일에서 `storage.tsdb.retention.time`을 설정할 때 단위 파싱 오류로 인해 실제 보존 기간이 설정값의 100만 배로 동작했습니다. CLI 플래그 대신 config 파일로 retention을 지정하고 있다면 디스크가 예상보다 훨씬 많은 데이터를 보유하고 있을 수 있습니다. 3.11.0으로 업그레이드 후 디스크 사용량을 반드시 확인하세요. 아울러 config에서 retention 설정을 제거하면 CLI 플래그 값으로 폴백되도록 동작이 바뀌었으니 설정을 재검토하세요.

• breakingHetzner hcloud SD 레이블 2026년 7월 전에 마이그레이션

  `__meta_hetzner_datacenter`, `__meta_hetzner_hcloud_datacenter_location*` 레이블은 hcloud 역할에서 2026년 7월 1일부터 동작하지 않습니다. relabeling 설정과 recording rule을 전수 점검해 `__meta_hetzner_hcloud_location`, `__meta_hetzner_hcloud_location_network_zone`으로 교체하세요. robot 역할의 기존 레이블은 하위 호환성을 위해 유지됩니다.

• enhancementretention.percentage로 TSDB 디스크 사용량 상한 설정

  새로 추가된 `storage.tsdb.retention.percentage` 설정을 사용하면 TSDB가 사용할 수 있는 디스크 비율의 상한을 지정할 수 있습니다. 데이터 수집량이 가변적인 환경에서 바이트 기반 상한을 추정하는 것보다 훨씬 관리하기 쉽습니다. 기존 시간 기반 retention을 대체하기보다는 함께 설정해 두 조건 모두 적용되도록 운영하는 것을 권장합니다.