Flask 샵의 /order 엔드포인트가 느리며, 병목 현상을 파악하는 것이 목표입니다. 기존의 스톱워치 방식은 코드 변경이 필요하고, 연결되지 않은 로그 줄을 생성하며, 간헐적인 느림 현상에 대처하기 어렵습니다. 프로파일러는 너무 많은 세부 정보를 제공하여 요청별 정보를 모호하게 만듭니다.기존 설정을 사용하여 초기 추적은 즉시 시간별 분석을 보여줍니다. 요청은 37.3ms, 뷰는 36.3ms, 서비스는 35.9ms, 원장은 35.1ms가 소요되는 반면, 게이트웨이는 8us에 불과합니다. 이는 원장이 느림 현상의 주요 원인임을 나타냅니다."자체 시간"이라는 개념은 자녀로 인해 느린 작업과 자체적으로 느린 작업을 구분합니다. Wrapture는 이를 계산하여 원장이 자체적으로 느리다는 것을 보여주고, 서비스와 뷰는 원장을 호출하기 때문에 느리다는 것을 보여줍니다.wrapture.instrumentation 및 wrapture.timeline을 사용한 테스트는 이를 확인합니다. OrderService.place는 31.0ms 중 173us의 자체 시간을 가지는 반면, Ledger.record가 대부분의 시간을 차지합니다. 이 정도의 세부 정보는 표준 프로파일러에서는 사용할 수 없습니다.장기 모니터링을 위해 Aggregate 수집기는 총 시간, 자체 시간, 최소 시간, 최대 시간을 포함한 여러 요청에 대한 통계를 수집합니다. 서버에 30개의 요청을 보낸 보고서는 Ledger.record가 자체 시간 기준으로 가장 큰 기여를 한다는 것을 확인합니다.테넌트별 느림 현상을 추적하기 위해 wrapture.annotate는 "X-Tenant"와 같은 사용자 지정 데이터를 인플라이트 이벤트에 추가할 수 있도록 합니다. 이를 통해 추적을 필터링하여 어떤 테넌트가 더 느린 요청을 경험하는지 파악할 수 있습니다.Counter 수집기는 지속 시간을 유지하지 않고 작업만 계산하는 더 저렴한 대안을 제공하며, 테스트 스위트에서 예산 기반 검증(예: N+1 쿼리 문제 감지)에 적합합니다. 다음 단계는 이러한 이벤트를 추적 백엔드로 전달하는 것입니다.