오픈소스 관측 가능성

7장. 관측 가능성의 미래 트렌드

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 글을 쓰는 현재, OpenTelemetry는 빠르게 움직이고 있는 목표입니다. 2025년 이후의 주요 노력 중 하나는 의미 규칙(1단계)과 스키마(2단계)를 개발하는 데 도움이 되는 Rust 기반 플랫폼인 OTel Weaver의 추가 개발을 포함합니다. 향후 단계에서는 개발자들이 시스템을 확장하기 위해 웹어셈블리(WASM) 플러그인을 추가할 계획도 세우고 있습니다.

Go 런타임 메트릭, 로그 API, otelhttp를 비롯한 여러 기능의 Go SDK 자체 관찰 가능성과 안정화는 2025년(얀 2025)에 OTel Go 프로젝트에서 제공될 예정입니다. 또한, 수동 코드 수정이나 바이너리 리빌드 없이 Go 애플리케이션에서 추적을 수집할 수 있도록 eBPF를 사용하는 Go 자동 계측의 베타 버전도 최근 출시되었습니다(Yahn 2025).

플랫폼 엔지니어링 팀의 경험 향상

원격 분석의 최종 소비자는 SRE, DevOps 엔지니어, 플랫폼 엔지니어이며, 이들을 통틀어 플랫폼 엔지니어링 팀이라고 부릅니다. 결국, 통합 가시성 솔루션이 이들의 업무를 더 빠르고, 더 쉽고, 더 성공적으로 수행할 수 있게 해 주는지에 대한 질문을 던져야 합니다. 그리고 이들의 경험을 통해 기업이 시스템의 안정성, 가용성, 확장성, 성능, 그리고 궁극적으로 운영상의 비용 효율성이 더 높아졌는지에 대한 질문입니다.

통합 가시성 솔루션이 팀의 인지 부하를 얼마나 가중시키나요? 일상적인 업무와 중요한 이슈를 관리하는 긴급한 활동 시간 모두에 자연스럽고 원활하게 적용될 수 있나요?

잘 설계된 분리된 통합 가시성 스택은 그 자체가 눈에 거슬리지 않아야 합니다. 사실, 가능한 한 눈에 띄지 않는 것이 이상적입니다. 인사이트 자체에 가장 중점을 두어야 합니다. 이 메트릭은 무엇을 의미할까요? 이 임계값을 초과하면 어떻게 되나요? 이 명목상의 조건에 대한 예외를 플레이북에 어떻게 기록해야 할까요?

SRE는 어떤 계층에서든 통합 가시성 솔루션 자체가 문제인지에 대해 걱정할 필요가 없어야 합니다. 예를 들어, 고장나거나 신뢰할 수 없는 원격 분석 파이프라인 또는 원하는 대로 사용자 지정할 수 없는 까다로운 대시보드가 있을 수 있습니다. 위기의 순간에 마지막으로 걱정해야 할 것은 통합 가시성 플랫폼 자체를 돌보는 것입니다. 평상시에도 플랫폼이 광고한 대로 작동하도록 하는 데만 절반의 노력을 기울이고 싶지 않을 것입니다.

이를 위해, 통합 가시성 모범 사례를 통합 가시성 솔루션 자체에 적용하는 것이 반복적으로 필요하며, 이는 기술적으로 "누가 파수꾼을 감시하는가 ?" 에 해당하는 Quis custodiet ipsos custodes? (대략 "누가 파수꾼을 감시하는가?"로 번역됨). 자체 통합 가시성 시스템을 계측하여 그 자체가 운영 비효율성과 통합 가시성 격차의 원인이 되고 있지 않은지 확인해야 합니다.

과거에는 통합 ...