BigQuery+Data Studio의 요청 로그에 대한 간단한 분석

최근 실행 중인 응용 프로그램이 간혹 느린 현상을 만났다.체감상 10시에 한 번 정도 하는 것은 한순간이지만 억지스러운 느낌이다.원인을 찾기 위해 BigQuery와 Data Studio를 사용하여 요청 로그를 분석하여 원인을 순조롭게 확정할 수 있습니다.이것은 매우 간단한 설정과 지속적인 사용 방법입니다. 제가 소개하고 싶습니다.

1단계: BigQuery에 요청 로그 보내기

요청 로그에 URL와 Latency가 포함되어 있으면 모든 형식이 가능합니다.이 경우 애플리케이션은 Google Cloud의 App Engine (유연한 환경) 에서 실행되며, 기본적으로 Cloud Loging의nginx 로그로 출력되며, Cloud Loging의 Log Router (Sink) 를 사용하여 BigQuery 로 전송됩니다.
수신자를 "BigQuery 데이터 세트"로 지정하고 로그 필터를 다음과 같이 설정합니다.

resource.type="gae_app"
log_name="projects/PROJECT_ID/logs/appengine.googleapis.com%2Fnginx.request"
httpRequest.requestUrl!="/nginx_metrics"

시간이 지나면 새 로그는 BigQuery 측으로 전송되고 데이터 세트의 패턴은 자동으로 등록됩니다.

단계 2: 데이터 Studio를 통한 로그 분석

데이터 Studio에서 BigQuery에 연결하여 요청 로그의 데이터 세트를 볼 수 있습니다.

분포도에서 요구량이 많고 지연이 큰 단점을 지정하다

도표는'분포도'가 될 수 있지만 보다 직관적이고 알기 쉬운'기포도'를 선택하세요.

사이즈: URL에 해당하는 열

지표 X: Record Count의合計値

지표 Y:Latency열의 平均値

기포 사이즈의 지표: Record Count의合計値

지표 슬라이더: ON

정렬: Record Count의合計値//여기서 바꿀 수 있음

다음은 이벤트 발생 시 차트입니다.

요구 수량은 적지만 지연에는 종점이 많다는 것을 알 수 있다.(실제로는 경로 매개 변수가 다르기 때문에 최종 점은 하나입니다.)
이 도표에 따르면 이번 사건의 원인은'원래 지연이 대단점 캐시의 유효 시간을 줄였다'는 것이다.대용량 요청을 지연 처리할 때 다른 요청에 대한 대기 빈도가 많아지면서'가끔 지각하기도 한다'는 상황이 발생했다.
다음은 대책을 연구한 후의 도표다.

캐시 시간을 조정하는 것이 아니라 지연되는 원인을 수정했습니다.나는 연장전의 결승점이 현저히 줄었다는 것을 알아야 한다고 생각한다.
한 도표에 표시할 수 있는 데이터 포인트의 수량이 제한되어 있기 때문에 정렬을 바꾸거나 지표 슬라이더로 필터를 하면 또 다른 데이터를 볼 수 있다.예를 들어, 降順를 0.2 이상으로 필터링하면 다음과 같습니다.아직 개선할 여지가 있다!

접선 도표에서 이전 주기와 비교하면 지연의 변화를 나타낸다

이번 같은 현상은 아무리 주의를 기울여도 발생할 수 있다.발생하는 일을 더욱 빨리 검출할 수 있도록, 우리는 시간 지연의 변동에 주의하기 위해 도표를 준비했다.
차트 폴리라인 차트를 선택합니다.

유지 관리: Latency

지표: timestamp열의 Latency

기본 날짜 범위: 平均値

비교 시간: 過去７日間（今日を除く）

다음은 사건 발생 전후의 도표다.

이전 도표(연한 파란색)보다 현재 도표(짙은 파란색)의 지연치가 높다.만약 도표에 이렇게 큰 변동이 있다면, 네가 무엇을 했는지 알 수 있을 것이다.
Data Studio는 정기적으로 보고서를 전송하는 기능이 있으므로 정기적으로 확인하는 것이 좋습니다.

총결산

이번에는 처음으로 Data Studio를 사용해 로그 분석을 간단하게 진행했다.나는 같은 일을 이미 이루어진 감시 도구도 간단하게 할 수 있다고 생각한다. 그러나 Data Studio의 도표이기 때문에 BigQuery의 조회로 실제 데이터를 만들어 보면 데이터에 더욱 흥미를 가지고 주동적으로 분석할 수 있었으면 좋겠다.