OpenTelemetry로 브라우저 애플리케이션 모니터링

많은 개발 팀이 서버 측에서 OTeL(OpenTelemetry)을 활용하여 애플리케이션에서 로그, 추적, 메트릭과 같은 신호를 수집합니다. 그러나 종종 간과되는 것은 OTeL 브라우저 계측의 힘입니다. 이 클라이언트 측 관찰 가능성 데이터는 클라이언트와 서버 간의 추적을 연결하여 의미 있는 통찰력을 제공하고 애플리케이션 성능에 대한 포괄적인 보기를 생성할 수 있습니다.

OpenTelemetry란 무엇입니까?

OpenTelemetry는 소프트웨어의 성능과 동작을 이해하기 위해 분석용 원격 측정 데이터(메트릭, 로그 및 추적)를 계측, 생성, 수집 및 내보내는 데 사용되는 도구, API 및 SDK 모음입니다.

OTeL에 대해 더 자세히 알아보고 싶다면 최근 기사인 OpenTelemetry란 무엇이며 왜 관심을 가져야 할까요?를 확인하세요.

브라우저 애플리케이션의 OpenTelemetry

브라우저 앱과 관련하여 OpenTelemetry는 다음에 대한 귀중한 통찰력을 제공할 수 있습니다.

1. 문서 로드 성능
2. 사용자 상호작용
3. 네트워크 요청(XMLHttpRequest 및 Fetch)

이러한 통찰력을 통해 개발자는 병목 현상을 식별하고, 사용자 상호 작용을 추적하고, 수동 계측 없이 네트워크 요청을 모니터링할 수 있습니다. 위에서 언급한 내용은 OTeL의 자동 계측을 활용하여 상대적으로 쉽게 얻을 수 있는 데이터이지만 수동 계측을 추가하여 클라이언트 측 앱의 다른 코드에 대한 추적을 수집할 수도 있습니다.

하이라이트 및 OpenTelemetry

Highlight의 JavaScript SDK는 클라이언트 측 애플리케이션에서 OpenTelemetry 데이터를 수집하기 위한 기본 지원을 제공합니다. 이러한 통합을 통해 OpenTelemetry 추적을 웹 애플리케이션에 원활하게 통합할 수 있습니다.

하이라이트로 OpenTelemetry 활성화

OTeL 데이터 수집은 아직 베타 버전이므로 SDK를 초기화할 때 활성화OtelTracing 구성 옵션을 설정하여 이를 명시적으로 활성화해야 합니다.

H.init({
  // ...
  enableOtelTracing: true
})

이 간단한 구성을 통해 하이라이트는 자동 계측을 활용하고 몇 가지 추가 처리를 수행하여 하이라이트에서 데이터를 더욱 유용하게 만들어 필요한 대부분의 OpenTelemetry 데이터를 자동으로 수집합니다.

클라이언트 및 서버 추적 연결

OpenTelemetry의 가장 강력한 기능 중 하나는 다양한 서비스와 환경에서 추적을 연결하는 기능입니다. 하이라이트의 SDK는 컨텍스트 전파를 통해 이를 촉진하므로 브라우저의 사용자 상호 작용부터 백엔드 서비스까지 포괄하는 엔드투엔드 추적을 생성할 수 있습니다.

작동 방식은 다음과 같습니다.

1. 추적 시작: 브라우저에서 사용자 상호작용이나 네트워크 요청이 시작되면 SDK는 새 범위를 생성하거나 기존 추적을 계속합니다.
2. 헤더 삽입: 나가는 HTTP 요청(XHR 및 Fetch 모두)의 경우 SDK는 추적 컨텍스트 헤더를 요청에 자동으로 삽입합니다. 이러한 헤더에는 일반적으로 다음이 포함됩니다.
   • Traceparent: 추적 ID, 상위 범위 ID 및 추적 플래그를 포함합니다.
   • Tracestate: 공급업체별 추적 정보를 전달합니다.
3. 서버 측 수신: 하이라이트 서버 측 SDK는 이러한 헤더를 추출하고 추적을 계속하여 서버 측 범위를 클라이언트 측 추적에 연결합니다.
4. 추적 완료: 요청이 완료되어 클라이언트로 반환되면 클라이언트와 서버 범위를 모두 포함한 전체 추적을 하이라이트 UI에서 시각화할 수 있습니다.

클라이언트와 서버 추적 간의 이러한 연결은 엔드 투 엔드 가시성을 제공하며 페이지 속도 통찰력 및 클라이언트/서버 오류 상관 관계에 필요한 링크입니다.

HTML이 브라우저로 전송되기 전에 서버에서 코드가 실행되는 서버 측 렌더링의 경우 추적 컨텍스트는 HTML에 추가되는 태그입니다.

예제 클라이언트-서버 추적 수명주기

실제 작동 방식을 보여주는 간단한 예는 다음과 같습니다.

1. 사용자가 웹 애플리케이션에서 버튼을 클릭합니다.
2. Highlight SDK는 이 사용자 상호작용을 위한 범위를 생성합니다.
3. 이 상호작용은 백엔드에 대한 API 호출을 트리거합니다.
4. SDK는 이 API 호출에 추적 헤더를 자동으로 삽입합니다.
5. 백엔드가 요청을 수신하고 추적 컨텍스트를 추출한 후 추적을 계속합니다.
6. 백엔드가 요청을 처리하고 응답을 보냅니다.
7. 클라이언트가 응답을 받고 범위를 완료합니다.

결과는 브라우저의 초기 사용자 상호 작용부터 백엔드 서비스를 거쳐 클라이언트로 돌아가는 요청의 전체 여정을 보여주는 단일 추적입니다.

이익

클라이언트와 서버 추적 간의 이러한 연결은 다음과 같은 여러 이점을 제공합니다.

• End-to-End Visibility: You can trace a user's action all the way through your system, making it easier to diagnose issues and understand performance bottlenecks.
• Performance Optimization: By seeing the complete picture, you can identify whether performance issues are occurring on the client-side, server-side, or in the network communication between them.
• Error Correlation: If an error occurs, you can see the full context of what led to that error, including any relevant client-side actions or server-side processing.

By leveraging Highlight's OpenTelemetry integration, you can gain these insights with minimal configuration, allowing you to focus on improving your application's performance and user experience.

Handling Server-Initiated Traces

When a request for a page is made by fetching a new URL in the browser we don't have the JS SDK initialized in the browser until the server returns the HTML and renders the page, then fetches all the JS assets to render the app. In this case you pass the trace ID from the server to the client in a tag to handoff the trace initiated on the server to the client.

Here is an example of what the meta tag looks like in the browser:

<meta
  name="traceparent"
  content="00-ab42124a3c573678d4d8b21ba52df3bf-d21f7bc17caa5aba-01"
>

Note that the Highlight server SDKs often have helpers to create this tag. Here's an example using the Highlight Ruby SDK

<%= highlight_traceparent_meta %>

The browser OTeL instrumentation gathers timing information from window.performance.timing and creates spans for all the different timing events in the browser. This instrumentation parses the tag and associates all the spans it creates with trace data from the tag. This is illustrated in the screenshot of the flame graph below.

Here's how to parse what's going on in this flame graph:

1. The documentLoad span shows the full timing from submitting the URL in the browser to be loaded to having all the assets loaded and the page being fully interactive. The timing data for this span is gathered from window.performance.timing since we can't actually initiate a span before the JS loads.
2. The PagesController#home is the first span created on the server. You can trace the server code execution required to render the HTML that will be returned to the browser. When the HTML is returned to the browser the documentFetch span finishes.
3. After the HTML is loaded int he browser you can see the requests for the page's resources (all the JS and CSS files), these are the resourceFetch spans.

These resource timings provide a full picture of your app's load time, making it clear where the opportunities are to improve performance and provide a better UX.

Leveraging OpenTelemetry Data in Highlight

Collecting OpenTelemetry data is one thing, but gleaning actionable insights is another. You need some way of visualizing the data (like the flame graph shown above) in order to get actionable insights. Highlight exposes this data a few ways.

Viewing Traces in Highlight

When you open Highlight's UI, you'll find a dedicated section for traces. Here, you can see a list of all the traces collected from your application, including those that span from the browser to your backend services.

1. Trace List: This view provides an overview of all traces, typically sorted by timestamp. You can filter and search for specific traces based on various criteria such as duration, error status, or custom attributes.

2. Trace Detail View: Clicking on a specific trace opens a detailed view, showing the full journey of a request or user interaction. This view includes:

   • A flame graph visualization of the trace, showing the hierarchy and timing of spans.
   • Detailed information about each span, including start time, duration, and any custom attributes or events.
   • For spans representing network requests, you can see details like HTTP method, status code, and headers.

3. Cross-Service Tracing: For traces that span from the browser to your backend services, you'll see a seamless view of the entire request lifecycle. This makes it easy to identify whether performance issues are occurring on the client-side, server-side, or in the network communication between them.

Analyzing Resource Timings and Web Vitals

Highlight's metrics product provides powerful tools for analyzing resource timings and Web Vitals, which are crucial for understanding and optimizing your application's performance.

1. 리소스 타이밍 대시보드: 이 대시보드는 웹 페이지에 다양한 리소스를 로드하는 데 걸리는 시간에 대한 개요를 제공합니다. 다음을 볼 수 있습니다:

   • 다양한 유형의 리소스(JS, CSS, 이미지 등)에 대한 로드 시간
   • 각 리소스에 대한 DNS 조회, TCP 연결, TLS 협상 등에 소요된 시간
   • 로딩 프로세스에서 느리게 로딩되는 리소스나 병목 현상을 식별하는 데 도움이 되는 시각화

2. 웹 바이탈 지표: 트랙을 강조 표시하고 다음을 포함한 주요 웹 바이탈 지표를 표시합니다.

   • LCP(Largest Contentful Paint): 로딩 성능 측정
   • 첫 번째 입력 지연(FID): 상호작용 측정
   • CLS(Cumulative Layout Shift): 시각적 안정성 측정
   • FCP(First Contentful Paint): 탐색부터 브라우저가 콘텐츠의 첫 번째 비트를 렌더링할 때까지의 시간을 측정합니다

3. 실적 추세: 하이라이트를 사용하면 시간 경과에 따른 이러한 측정항목을 추적하여 다음을 식별하는 데 도움이 됩니다.

   • 코드 변경 또는 배포가 성능에 미치는 영향
   • 눈에 띄지 않을 수도 있는 점진적인 저하
   • 최적화 노력으로 인한 개선

4. 세분화 및 필터링: 다음과 같은 다양한 요소를 기반으로 이러한 측정항목을 분류하고 필터링할 수 있습니다.

   • 기기 유형(모바일, 데스크톱, 태블릿)
   • 브라우저
   • 지리적 위치
   • 귀하가 정의한 맞춤 속성

상세한 추적 데이터를 이러한 높은 수준의 성능 지표와 결합하면 애플리케이션 성능을 포괄적으로 볼 수 있습니다. 이를 통해 신속하게 문제를 식별하고 근본 원인을 이해하며 최적화 노력의 영향을 측정할 수 있습니다.

결론

OpenTelemetry는 브라우저 애플리케이션을 모니터링하고 최적화하기 위한 강력한 도구를 제공합니다. 개발자는 하이라이트의 OpenTelemetry 통합을 활용하여 최소한의 구성으로 실행 가능한 통찰력을 얻을 수 있습니다.

클라이언트측 성능 문제, 서버측 병목 현상 또는 여러 서비스에 걸친 복잡한 사용자 여정을 처리하는 경우 OpenTelemetry 및 하이라이트는 뛰어난 웹 애플리케이션을 제공하는 데 필요한 가시성을 제공합니다.

위 내용은 OpenTelemetry로 브라우저 애플리케이션 모니터링의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!