Charity Majors의 이 인용문은 아마도 기술 산업의 현재 관찰 가능성 상태, 즉 완전하고 엄청난 혼란을 가장 잘 요약한 것입니다. 모두가 혼란스러워합니다. 추적이란 무엇입니까? 스팬이란 무엇입니까? 로그 라인은 범위입니까? 로그가 있는 경우에도 추적이 필요합니까? 좋은 지표가 있는데 추적이 필요한 이유는 무엇입니까? 목록은 계속해서 이어집니다. Charity는 Honeycomb 관찰 가능 시스템의 다른 뛰어난 인재들과 함께 이러한 문제를 해결하기 위해 열심히 노력해 왔습니다. 그러나 내 경험에 따르면 Charity가 "로그는 쓰레기다"라고 말할 때 로깅과 추적이 본질적으로 동일하다는 점은 말할 것도 없고 무엇을 의미하는지 설명하기가 여전히 어렵습니다. 왜 다들 그렇게 혼란스러워 하는 걸까요?
약간의 위험을 감수하고 Open Telemetry를 비난하겠습니다. 예, 이는 최신 관측성 스택의 강력한 요소이지만 혼란스러운 것에 대해 비난합니다. 그것은 나쁜 해결책이기 때문이 아닙니다. 그것은 훌륭합니다! 그러나 Open Telemetry의 개념과 기능을 소개하고 설명하면 관찰 가능성이 까다롭고 복잡해 보입니다.
첫째, Open Telemetry는 처음부터 추적, 지표, 로그를 명확하게 구분합니다.
OpenTelemetry 는 소프트웨어의 성능 및 동작 수집을 분석하는 데 도움이 되는 원격 측정 데이터(메트릭, 로그 및 추적)를 계측, 생성, 수집 및 내보내는 데 사용되는 API, SDK 및 도구 모음입니다.
그런 다음 이 세 가지 질문을 각각 더 자세히 설명하세요.
이는 OpenTelemetry 웹사이트의 추적 소개 부분 스크린샷입니다. OpenTelemetry 직원과 대화한 경험에 따르면 이 프레젠테이션은 실제로 관찰 가능성과 관련된 주요 그림 중 하나가 되었습니다. 일부에게는 이것이 관찰 가능성입니다. 또한 추적을 다른 것과 구별합니다. 이건 분명히 로그가 아니죠? 이것도 지표처럼 보이지 않죠? 이것은 특별하고 어쩌면 약간 멋진 일이며 학습에 대한 헌신이 필요합니다. 내 경험에 따르면 사람들이 트레이스를 이해하면 이 그림의 맥락과 범위, 루트 범위, 중첩 범위 등과 같은 관련 용어로만 트레이스를 생각합니다. OpenTelemetry 웹사이트에는 60개 이상의 용어가 포함된 용어집 페이지가 있습니다 ! 그것은 모두 매우 복잡합니다!
그러나 더 중요한 것은 "로그, 지표 및 링크 추적"에 초점을 맞추는 것이 관찰 가능성의 진정한 힘을 나타내는가입니다. 물론, 일부 시나리오도 다루지만 대규모 분산 시스템의 경우 데이터를 "쪼개고 쪼개고" 다양한 뷰를 구축 및 분석하고 상관관계를 도출하는 등 데이터를 깊이 파고드는 것이 더 중요합니다. 변칙 검색... 그리고 이러한 모든 기능을 제공하는 시스템이 존재합니다.
스쿠버: 관찰 가능성의 천국
제가 Meta에서 일했을 때, 지금까지 만들어진 최고의 관찰 시스템을 사용하여 작업할 수 있는 행운이 있다는 사실을 깨닫지 못했습니다. 이 시스템을 스쿠버라고 하는데, Meta Corporation을 떠난 후 사람들이 가장 그리워하는 것 중 하나가 바로 이것입니다.
스쿠버의 기본 아이디어는 이해하기 위해 용어 페이지를 읽을 필요가 없을 정도로 간단합니다. 와이드 이벤트를 사용합니다. 일반화된 이벤트는 JSON 문서와 마찬가지로 이름과 값이 포함된 필드 모음입니다. 시스템의 현재 상태인지, API 호출, 백그라운드 작업 또는 기타 이벤트로 인한 것인지 등 일부 정보를 기록해야 하는 경우 Scuba에 일반화된 이벤트를 작성하기만 하면 됩니다. 예를 들어 시스템이 광고를 제공하는 경우 자연스럽게 광고 노출, 즉 사용자가 광고를 본 사실을 기록하려고 합니다. 해당 일반화된 이벤트는 다음과 같습니다.
{
"Timestamp": "1707951423",
"AdId": "542508c92f6f47c2916691d6e8551279”,
"UserCountry": "US",
"Placement": "mobile_feed",
"CampaingType": "direct_ads",
"UserOS": "Android",
"OSVersion": "14",
"AppVersion": "798de3c28b074df9a24a479ce98302b6",
"...": ""
}이러한 이벤트를 일반화된 이벤트라고 합니다. 생각할 수 있는 모든 정보가 이벤트에 저장되도록 권장되기 때문입니다. 해당 특정 데이터의 맥락과 관련이 있을 수 있는 모든 것 - 그냥 거기에 놓아두면 나중에 유용할 수 있습니다. 이러한 접근 방식은 지금은 생각할 수 없지만 사고 조사 중에 밝혀질 수 있는 알려지지 않은 사항을 처리하기 위한 기반을 마련합니다.
알려지지 않은 알려지지 않은 상황을 다루는 것은 예를 통해 더 잘 설명될 수 있습니다. Scuba는 직관적이고 사용자 친화적인 인터페이스를 갖추고 있어 쉽게 탐색하고 조작할 수 있습니다. 볼 측정항목을 선택하는 섹션과 필터링 및 그룹화를 위한 섹션이 있습니다. Scuba는 멋진 시계열 차트를 구성합니다. 광고 노출 데이터세트를 처음 살펴보면 노출 수가 포함된 그래프가 표시됩니다.
여기서 정확히 선택된 항목을 SQL로 표현하면 다음과 같습니다.
SELECT COUNT(*) FROM AdImpressions
WHERE IsTest = False이것은 전적으로 사실이 아닙니다. 스쿠버에는 네이티브 샘플링이라는 개념도 있습니다. 이벤트가 스쿠버에 기록되면 이 특정 이벤트의 샘플링 속도를 나타내는 필드도 기록되어야 합니다. 스쿠버는 이 정보를 사용하여 차트에 표시된 결과를 정확하게 "확대"하므로 머리 속에서 확대할 필요가 없습니다. 이는 동적 샘플링을 허용하기 때문에 훌륭한 개념입니다. 예를 들어 특정 유형의 프리젠테이션은 UI에서 "실제" 값을 유지하면서 다른 유형의 프리젠테이션보다 더 자주 샘플링될 수 있습니다. 따라서 아래의 실제 쿼리는 다음과 같습니다. samplingRate
SELECT SUM(samplingRate) FROM AdImpressions
WHERE IsTest = False 전체 "확대"는 UI에 의해 투명하게 수행되며 사용자는 쿼리 중에 이에 대해 생각할 필요가 없습니다. 따라서 어떤 경고가 발생하고 귀중한 광고 노출 그래프가 이상해 보인다고 가정해 보겠습니다.
조사를 위해 스쿠버를 사용하는 모든 사람의 첫 번째 본능은 정보를 얻을 수 있는지 확인하기 위해 기준에 따라 필터링하거나 그룹화하는 것입니다. 우리는 우리가 찾고 있는 것이 무엇인지 모르지만 그것을 찾을 것이라고 믿습니다. 따라서 의심스러운 사항이 발견될 때까지 노출 유형, 사용자 국가 또는 광고 위치별로 그룹화합니다. 캠페인 유형(CampaignType)별로 그룹화한다고 가정해 보겠습니다.
in_app_purchases(본인이 만든 것임)라는 캠페인 유형이 다른 유형과 다르게 나타나는 것을 발견했습니다. 우리는 그것이 무엇을 의미하는지 실제로 알지 못합니다. 그리고 알 필요도 없습니다! - 계속 파헤쳐야 해요. 좋아요, 이제 이러한 캠페인만 필터링하고 우리가 생각할 수 있는 다른 기준에 따라 계속 그룹화할 수 있습니다. 예를 들어 사용자 운영 체제가 적합합니다.
음, 안드로이드에 문제가 있는 것 같습니다. iOS는 괜찮습니다. 이는 문제가 클라이언트 측에 있을 수 있음을 나타냅니다. 아마도 앱의 버그 버전일까요?
기묘. 어떤 사람들에게는 문제가 있고 다른 사람들에게는 문제가 없습니다. OS 버전을 확인해 볼까요?
하아! 이는 최신 OS 버전이며 일부 앱 버전은 이 OS 버전에서 이러한 유형의 캠페인에 대해 제대로 작동하지 않는 것 같습니다. 이 정보를 바탕으로 전담팀은 이제 더 깊이 조사할 수 있습니다.
무슨 일이에요? 시스템에 대한 지식 없이 문제의 범위를 좁히고 추가 조사를 담당하는 팀을 식별했습니다. OS, OS 버전, 캠페인 유형 및 앱 버전의 이상한 조합이 일부 문제를 일으킬 수 있다는 사실을 미리 알고 측정항목을 준비할 수 있었습니까? 물론 불가능합니다. 이것은 알려지지 않은 미지수를 다루는 예입니다. 우리는 일반화된 이벤트에 모든 관련 상황 정보를 저장하고 필요할 때 사용합니다. Scuba는 속도가 빠르고 매우 아름답고 사용하기 쉬운 사용자 인터페이스를 갖추고 있어 탐색을 쉽게 해줍니다. 또한 카디널리티에 대해서는 언급한 적이 없습니다. 그것은 중요하지 않습니다. 모든 필드는 임의의 카디널리티를 가질 수 있습니다. Scuba는 원시 이벤트로 작동하고 사전 집계를 수행하지 않으므로 카디널리티는 문제가 되지 않습니다.
때로는 인터페이스/시각화 측면이 충분한 관심을 받지 못하고 모니터링 시스템이 일부 쿼리 언어(독점적(특히 나쁜 경험)) 또는 SQL(약간 더 좋지만 여전히 좋지 않음)을 제공합니다. 이러한 인터페이스를 사용하면 유사한 설문조사를 수행하는 것이 거의 불가능해집니다. 스쿠버의 중요한 측면은 모든 필드(함수, 필터, 그룹화 등)를 탐색할 수 있다는 것입니다. 즉, 선택할 수 있는 값의 유형을 쉽게 확인할 수 있는 방법이 있습니다. 특정 데이터 분야의 담당자가 자신이 담당하는 데이터를 개선하기 위해 더욱 노력할 때, 단순히 데이터를 수집하는 수준을 넘어 관련 링크를 포함하여 해당 분야에 대한 자세한 설명까지 제공합니다. 이건 매우 중요합니다. 시스템 전체나 해당 데이터 세트에서 사용 가능한 데이터를 완전히 이해하지 못한 채 문제 해결을 여러 번 성공적으로 수행했습니다. 그리고 이러한 문제 해결 과정에서 저는 단순히 Scuba와 상호 작용함으로써 시스템에 대해 많은 것을 배웠습니다! 이거 엄청나 네. 이것은 관찰 가능성의 천국입니다.
메타를 떠난 후의 아픔
이제 내가 Meta를 떠나 외부 관찰 시스템의 상태를 알게 되었을 때의 혼란과 불신을 상상해 보십시오.
통나무? 길? 색인? 이것은 정확히 무엇입니까? 일반화된 이벤트에 대해 아는 사람이 있나요? 60개 용어집을 배우지 않고 그냥...탐색할 수는 없나요?
저는 Scuba 기반 정신 모델을 Open Telemetry 정신 모델에 매핑하는 데 꽤 많은 시간을 보냈습니다. Open Telemetry의 Span은 실제로 일반화된 이벤트라는 것을 깨달았습니다. 사실 제가 이 말을 제대로 이해했는지 아직도 잘 모르겠습니다.
광고 디스플레이의 예를 들면, 이 디스플레이는 실제로 작업이 아니라 우리가 기록하고 싶은 몇 가지 사실일 뿐입니다... 공평하게 말하면 Open Telemetry에는 이벤트 개념이 존재합니다.
하지만 링크를 따라가며 더 자세히 살펴보면 해당 이벤트가 실제로 추적, 지표 또는 로그 중 하나라는 것을 다시 알 수 있습니다.
그러나 어쨌든 Span은 일반화된 이벤트에 가장 가까운 개념입니다. 문제는 Open Telemetry가 제안한 정신 모델에 익숙해지면 이를 방어하기가 어렵다는 것입니다. 추적, 지표 및 로그는 실제로 일반화된 이벤트의 특수한 사례이기 때문에 이는 정말 실망스럽습니다.
- 추적 및 범위(Spans): SpanId, TraceId 및 ParentSpanId 필드가 있는 일반화된 이벤트입니다. 따라서 주어진 TraceId로 모든 범위를 필터링하고, SpanId → ParentSpanId 관계를 기반으로 토폴로지별로 정렬하고, 모두가 선호하는 분산 추적 보기를 그릴 수 있습니다.
- 로그: 솔직히 말해서 Open Telemetry가 로그라고 부르는 내용이 정말 혼란스럽습니다. 많은 내용이 포함되어 있는 것 같습니다. 그 중 하나는 기본적으로 광범위한 이벤트인 구조화된 로깅입니다. 매우 좋은! 그러나 문제는 "로그"가 상당히 잘 정의된 개념이고 일반적으로 사람들은 이러한 호출이 생성하는 것을 의미한다는 것입니다. 어쨌든, 그것이 무엇을 의미하든 로그는 확실히 광범위한 이벤트에 쉽게 매핑될 수 있습니다. 가장 간단한 경우에는 로그 메시지를 가져와서 "log_message" 필드에 넣고 많은 메타데이터를 추가한 후 만족합니다. 더 복잡한 경우에는 ID처럼 보이는 토큰을 제거하여 로그 메시지에서 자동으로 템플릿을 추출하고 이 템플릿의 해시를 가져올 수 있습니다. 이를 통해 예를 들어 이 해시별로 그룹화하여 가장 빈번한 오류를 빠르게 얻을 수 있습니다. 메타에는 이런 시스템이 있는데 꽤 멋지네요.
logger.info(…) - 측정항목: 측정항목을 쉽게 매핑할 수도 있습니다. 특정 간격 내에 시스템 상태(예: CPU 시스템 표시기, 다양한 카운터 등)가 포함된 광범위한 이벤트를 내보내면 됩니다. 그건 그렇고, Prometheus는 스크래핑 방법을 통해 이를 정확하게 수행합니다. 즉, 가끔 시스템의 스냅샷을 찍는 것입니다. 그러나 Prometheus와 달리 와이드 이벤트 접근 방식을 사용하면 카디널리티 문제를 걱정할 필요가 없습니다.
그러나 와이드 이벤트는 이러한 "세 가지 기둥"(추적, 로그, 지표)보다 훨씬 더 많은 것을 제공할 수 있습니다. 앞서 언급한 디버깅 세션은 이미 (적어도 자연스럽게는 아니지만) Traces, Logs 및 Metrics에서 다루는 사례입니다. 다른 사용 사례도 있을 수 있습니다. 예를 들어 연속 프로파일링 데이터는 와이드 이벤트로 쉽게 표현되고 쿼리되어 Flame 그래프를 작성할 수 있습니다. 이를 위해 별도의 시스템을 가질 필요가 없습니다. 광범위한 이벤트를 처리하는 단일 시스템으로 모든 작업을 수행할 수 있습니다. 모든 것이 한 곳에 함께 저장되어 있을 때 상호 상관 관계 및 근본 원인 분석의 가능성을 상상해 보십시오. 특히 데이터의 관계를 찾아내는 데 뛰어난 인공지능 도구가 등장하는 시대에는 더욱 그렇습니다.
그럼?
모르겠어요... 관찰 가능성이 너무 혼란스럽고 혼란스럽고 "세 기둥"이 무엇인지에 초점을 맞추고 있다는 실망감과 답답함을 표현하고 싶었습니다...
나는 관찰 가능성 공급업체가 혼란에 맞서 시스템과 상호 작용할 수 있는 간단하고 자연스러운 방법을 제공하기를 바랄 뿐입니다. Honeycomb이 이 작업을 수행하는 것으로 보이며 Axiom과 같은 다른 시스템도 이 작업을 수행하고 있습니다. 정말 좋아요! 다른 공급업체도 이를 따르기를 바랍니다.
첨부된
이 기사는 번역된 원본 텍스트입니다: https://isburmistrov.substack.com /p/ all -you-need-is-wide-events-not-metrics
기사 마지막에 작은 광고를 삽입할 수 있도록 허락해 주십시오. 제가 사업을 시작한지 2년이 되었는데, 저희 회사도 Observability를 하고 있는데, 이는 이 글의 생각과 다소 비슷합니다. 이 분야에 필요한 사항이 있으면 제품 및 기술 교환을 위해 언제든지 당사에 문의하십시오.
콰이마오 성운에 대하여
Kuaimao Nebula는 유명한 오픈 소스 프로젝트인 "Nightingale"의 핵심 개발 팀으로 구성되어 있는 클라우드 기반 지능형 운영 및 유지 관리 기술 회사입니다. 나이팅게일은 중국 컴퓨터 협회가 기부하고 주최하는 최초의 오픈 소스 프로젝트로 GitHub에 8,000개 이상의 별이 있고 100개 이상의 반복 버전이 출시되었으며 수백 개의 커뮤니티가 있습니다. 중국 최고의 오픈 소스 관측 솔루션입니다.
Kuaimao Nebula가 오픈 소스 Nightingale을 핵심으로 구축한 "Flashcat 플랫폼"은 국내 최고의 인터넷 기업의 관측 가능성 관행을 제품으로 구현한 것입니다. 이는 관측 가능성 기술을 기업에 더 잘 제공하고 서비스 안정성을 보장하기 위해 노력하고 있습니다. Flashcat 플랫폼에는 다음과 같은 기능이 있습니다.
- 통합 컬렉션: 플러그인 개념을 채택하여 수백 개의 내장 컬렉션 플러그인을 통합하여 서버, 네트워크 장비, 미들웨어, 데이터베이스, 애플리케이션 및 비즈니스를 모두 즉시 모니터링하고 사용할 수 있습니다.
- 통합 알람: 수십 개의 데이터 소스 도킹을 지원하고 다양한 모니터링 시스템에서 알람 이벤트를 수집하며 통합 알람 수렴, 소음 감소, 예약, 청구, 업그레이드 및 협업을 수행하여 알람 처리 효율성을 크게 향상시킵니다.
- 통합 관찰: 지표, 로그, 추적, 이벤트, 프로파일링 등 다양한 관찰 가능성 데이터와 미리 설정된 업계 모범 사례를 통합합니다. 글로벌 비즈니스 관점과 기술적 관점에서 조종석을 제공할 뿐만 아니라 드릴다운 오류도 제공합니다. 포지셔닝 기능으로 결함 발견 및 포지셔닝 시간을 효과적으로 단축합니다.
콰이마오 성운은 관측 가능성 데이터를 더욱 가치있게 만듭니다! https://flashcat.cloud/