request.log analysis의 예 | AEM

설명 description

환경

Experience Manager 6.5

문제/증상

Adobe Experience Manager(AEM) request.log 에는 성능 문제를 분석하는 데 유용한 여러 정보(예: 응답 시간)가 포함되어 있습니다. 다음은 Linux 명령(ruby와 같은 일부 외부 명령 포함)을 사용한 분석 예제 목록입니다 [ 1] 및 datamash [ 2] ).

설치 안내서

[ 1] https://www.ruby-lang.org/en/documentation/installation/

[ 2] https://www.gnu.org/software/datamash/download/

해결 방법 resolution

목차

A. 소개

B. 준비 단계

C. 분석 예

D. 결론

A. 소개

형식: request.log

AEM 6.5는 다음을 생성합니다 request.log 기본적으로 다음 형식을 사용합니다. 시스템 제한으로 인해 해당 문서의 명령줄은 일반 텍스트 대신 이미지로 표시됩니다.

예 request.log:

이 문서에서 "-> "를 "요청 레코드"라고 합니다. " "이 포함된 줄< -"는 "응답 레코드"입니다.

레코드 요청:

AEM에서 요청을 받으면 요청 레코드가 기록됩니다. 해당 기록에는 수신 날짜와 시간, 요청 ID, 요청 방법 및 URL이 포함됩니다.

응답 레코드:

AEM이 요청에 응답하면 응답 레코드가 기록됩니다. 해당 기록에는 응답 날짜 및 시간, 요청 ID, 상태 코드, 콘텐츠 유형 및 응답 시간(밀리초)이 포함됩니다.

에서 해당 설명서 찾기 request.log 해석.

B. 준비 단계

1단계. 데이터 정리

분석하기 전에 request.log, 로그 레코드를 표준화하는 것이 중요합니다.

첫 번째 sed command는 공백 대신 잘못된 필드가 구분되지 않도록 Content-Type의 응답 레코드에서 추가 공백을 제거합니다. ruby 명령(참조) [ 1] 위의 루비 설치)는 날짜 형식을 ISO 8601로 변환합니다. 또한 ruby 명령은 콜론 대신 공백으로 날짜와 시간을 구분합니다.

2단계. 재실행 시간

AEM을 다시 시작하면 서비스 팩 설치가 요청 ID를 재설정합니다. request.log. 요청은 요청과 함께 기록됩니다 ID = 0 은 이러한 종류의 작업이 있을 수 있음을 나타냅니다.

위의 예에서는 요청 ID는 13:08:49 및 13:26:13에서 0으로 재설정되었습니다.

3단계. 시간당 액세스 수

시간당 액세스 횟수와 시간 범위 계산 request.log.

4단계. 최대 동시 처리

동시 처리 수는 AEM의 서버 부하를 추측하는 데 도움이 됩니다.

기본적으로 AEM에서 Jetty에 대한 최대 동시 연결 수는 200으로 설정됩니다. 응답을 완료한 후 소켓을 릴리스하는 데 지연이 있습니다. 동시 처리 수가 약 170을 초과하면 새로운 요청을 수락할 수 없게 됩니다.

5단계. 로그 파일 분할

의 요청 ID request.log AEM을 다시 시작하거나 서비스 팩이 설치되면 재설정됩니다. 이러한 비헤이비어로 인해 request.log 에는 이러한 작업이 포함되어 있습니다. 정확한 분석을 수행하고 한 번에 처리되는 파일 크기를 줄이려면 request.log 요청에 요청 레코드 사용 ID = 0.

6단계. 요청 레코드와 응답 레코드 병합

요청 ID별로 요청 및 응답 레코드를 병합하면 성능 문제가 시작된 시점을 보다 쉽게 파악할 수 있습니다. 이 병합된 로그 파일은 이후 예에서 사용됩니다.

마지막 sed 명령은 해당 응답 레코드가 없는 요청 레코드에 더미 응답을 추가합니다. 요청 레코드가 없는 응답 레코드도 있을 수 있습니다. 그러나 해당 레코드는 일반적으로 조사 대상이 아니므로 무시할 수 있습니다.

병합된 로그 파일은 다음과 같습니다.

C. 분석 예

예제 1. 가장 많은 액세스

응답 없는 액세스를 포함하여 병합된 로그 파일을 응답 시간별로 내림차순으로 정렬합니다.

예제 2. 누락된 응답에 대한 액세스

더미 응답 시간을 사용하여 해당 응답 레코드가 누락된 액세스를 추출합니다.

응답 없이 액세스를 수신하는 타이밍이 서버 부하의 증가와 관련이 있는 경우 이러한 액세스로 인해 성능 문제가 발생할 수 있습니다.

예제 3. 느린 액세스

10초 이상 소요된 액세스를 추출합니다.

히트 수가 너무 많으면 을(를) 대체합니다. [ 0-9] {5} 포함 [ 0-9] {6} 다음에서 grep 100초 이상 걸린 액세스로 좁히는 명령입니다.

예제 4. 응답 시간의 시계열 데이터

데이터에서 타임스탬프와 응답 시간만 추출하면 그래프를 만드는 데 유용하게 활용할 수 있습니다.

즉시 응답한 액세스를 생략하면 데이터의 효율성이 향상됩니다. 다음 예제는 1초 이상 소요된 액세스를 추출합니다.

예제 5. 최소, 평균, 중앙값, 최대 응답 시간

위의 예에서는 통계 처리를 위해 datamash 명령(https://www.gnu.org/software/datamash/)을 사용합니다. 로그에 응답 없는 액세스가 포함된 경우 더미 값이 결과에 영향을 미칩니다.

예제 6. 기간별 액세스 수

10분당 액세스 수를 계산합니다. 산출된 결과는 볼륨이 큰 트래픽이 성능 문제를 유발했는지 확인하는 데 도움이 됩니다.

다음 예에서는 데이터의 범위를 POST 요청으로만 좁힙니다. 일반적인 사용 사례는 게시 계층에 콘텐츠 작성 또는 복제가 집중되어 있는지 확인하기 위한 것입니다.

예제 7. 기간별 응답 상태 수

datamash 명령을 사용하여 10분당 각 응답 상태 수를 나타내는 테이블을 작성합니다.

예제 8. 가장 자주 사용되는 URL

10분마다 가장 자주 액세스된 상위 3개의 URL을 인쇄합니다.

예 9. access.log 레코드 request.log 기록

검색 access.log 특정 요청 ID에 해당하는 레코드.

동일한 URL에 대한 여러 액세스가 동시에 발생한 경우 결과는 다중 을 표시합니다 access.log 단일 요청 ID에 대한 레코드입니다.

D. 결론

이 문서의 예는 성능 문제를 분석하는 데 도움이 됩니다.

나열된 예제는 CentOS 7.5 및 Ubuntu 22.04LTS에서 테스트되었지만 다른 버전이나 명령의 변형과 같은 사용자의 환경에 따라 예상대로 작동하지 않을 수 있습니다. 환경에 설치된 명령에 따라 조정하시기 바랍니다.