현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보
맞춤 보고서를 사용하면 특정 API 측정항목을 드릴다운하고 원하는 데이터를 정확히 볼 수 있습니다. API Monitoring 대시보드에서는 생성 시 구성된 조건을 기반으로 필터 및 측정항목이 사전 설정된 커스텀 보고서를 만들 수 있습니다. 또한 기본 측정기준 및 측정항목 모음이 보고서에서 자동으로 구성됩니다.
상황에 따른 맞춤 보고서 만들기
다음 표에 요약된 것처럼 상황에 따라 맞춤 보고서를 빠르게 만들 수 있습니다. 맞춤 보고서 페이지에서 API 모니터링을 사용하여 만든 맞춤 보고서의 이름은 표에 표시된 대로 기본적으로 고유하며, 맞춤 보고서를 수정할 때 이름을 변경할 수 있습니다.
| 맞춤 보고서 컨텍스트 | 맞춤 보고서의 기본 이름 지정 규칙 |
|---|---|
| 최근 대시보드 | API Monitoring Recent Generated |
| 타임라인 대시보드 | API Monitoring Timeline Generated |
| 대시보드 조사 | API Monitoring Investigate Generated |
| 알림 조건 | API Monitoring Generated: alert-name |
기본 측정기준 및 측정항목
맞춤 보고서에는 기본적으로 API 모니터링에서 생성된 모든 보고서에 대해 다음 표에 나열된 측정기준과 측정항목이 포함됩니다.
| 구성요소 | 기본값 |
|---|---|
| 크기 | 요청 URI |
| 측정항목 |
|
맞춤 보고서 수정
이전 섹션에서 언급했듯이 사전 정의된 API Monitoring 기본 측정기준 및 측정항목 모음은 맞춤 보고서에 사전 구성되어 있습니다. 생성된 후에는 맞춤 보고서를 수정하여 필요에 따라 측정항목과 측정기준을 추가하거나 삭제할 수 있습니다. 예를 들어 특정 액세스 토큰, 개발자 앱, API 프록시 또는 요청 ID로 조사 범위를 좁힐 수 있습니다.
다음 맞춤 보고서에서 사전 정의된 Gateway Flow ID 측정기준을 추가합니다. 여기서 Gateway Flow ID에는 Edge에 대한 각 API 요청의 고유한 UUID가 포함됩니다.
보고서에서는 이미 Request URI 측정기준을 사용하고 있습니다.
다음 예에서는 맞춤 보고서에 Client ID 측정기준을 추가합니다.
Client ID 측정기준에는 요청에서 API 키로 전달되거나 OAuth 토큰에 포함되었는지에 관계없이 API를 호출하는 개발자의 소비자 키 (API 키)가 포함됩니다.
맞춤 보고서에는 모든 Client ID 값에 대한 정보가 포함됩니다.
다음 예에서는 특정 Client ID의 맞춤 보고서를 만들 수 있도록 필터를 추가합니다.
보고서에 추가할 수 있는 사전 정의된 모든 측정기준 및 측정항목에 대해 자세히 알아보려면 애널리틱스 측정항목, 측정기준 및 필터 참조를 참고하세요.
다음 예에서는 policies.ratelimit.QuotaViolation 오류 코드 및 5xx 상태 코드의 기본 측정항목과 측정기준을 캡처하는 필터를 맞춤 보고서에 추가합니다.
맞춤 보고서를 수정하는 방법을 자세히 알아보려면 맞춤 보고서 관리하기를 참고하세요.
예: 커스텀 보고서를 사용한 배포 문제 진단
API 프록시에 StatisticsCollector 정책을 연결하여 사용자 또는 제품 ID, 가격, REST 작업, 대상 버전, 대상 URL, 메시지 길이와 같은 커스텀 분석 데이터를 수집합니다. 데이터는 Apigee에서 사전 정의한 흐름 변수, 요청 헤더, 쿼리 매개변수 또는 사용자가 정의한 커스텀 변수에서 가져올 수 있습니다.
예를 들어 API 프록시 요청에는 제품 ID, 사용자 ID, 대상 서버 버전에 대한 헤더가 포함됩니다. 이 요청은 다음 형식일 수 있습니다.
curl -H "prodid:123456" -H "userid:98765" -H "targetversion:beta" http://myapi.com/myapi
그런 다음 헤더의 정보를 사용하여 API 프록시의 런타임 문제를 진단할 수 있습니다.
이러한 헤더에 대한 맞춤 보고서를 만드는 방법은 다음과 같습니다.
API에 StatisticsCollector 정책을 추가하여 커스텀 헤더 값을 캡처합니다.
<StatisticsCollector name="publishPurchaseDetails"> <Statistics> <Statistic name="prodid" ref="request.header.prodid" type="integer">0</Statistic> <Statistic name="userid" ref="request.header.userid" type="integer">0</Statistic> <Statistic name="targetversion" ref="request.header.targetversion" type="string">alpha</Statistic> </Statistics> </StatisticsCollector>
프록시를 배포하고 액세스할 때까지 기다립니다.
Edge UI에서 분석 > API 모니터링 > 최근을 클릭하여 API 관련 문제를 확인합니다. myapi 프록시에 4xx 및 5xx 오류가 발생한 것을 알 수 있습니다.
최근 대시보드의 오른쪽 창에서 자세한 내용을 보려면 myapi 프록시 행을 선택합니다.
최근 대시보드의 오른쪽 창에서
> 조사에서 보기를 선택하여 조사 대시보드에 액세스합니다.
myapi 프록시로 조사 대시보드를 필터링한 후 상단 차트에서 상태 코드를 확인합니다. 403 및 501 오류가 발생합니다.
Edge UI에서 애널리틱스 > 맞춤 보고서 > 보고서를 선택하여 맞춤 측정항목의 값이 측정기준으로 포함된 맞춤 보고서를 만듭니다.
+ 맞춤 보고서를 선택하여 myapi_errors라는 맞춤 보고서를 만듭니다.
측정항목에 프록시 오류를 선택하고 집계 함수를 Sum으로 설정합니다. 원하는 경우 측정항목을 더 추가할 수 있습니다.
사전 정의된 응답 상태 코드 측정기준을 선택한 다음 3가지 맞춤 통계 prodid, targetersion, userid를 측정기준에 추가합니다.
myapi API 프록시
(apiproxy eq 'myapi')의 데이터만 포함하도록 필터를 설정합니다.
보고서를 저장합니다.
지난 24시간에 대한 보고서를 실행합니다. 보고서가 처음 열리면 HTTP 403 및 501 오류 차트가 표시됩니다.
요약에서 403 또는 510을 클릭하여 어떤 제품에서 오류가 발생하는지 확인합니다. 예를 들어 403을 선택합니다.
요약 아래의 제품 ID를 클릭하여 대상 버전 (알파 또는 베타)별로 오류를 확인하세요.
요약에서 대상 버전을 클릭하여 사용자별 오류를 확인합니다.
