감사 합계 도구 사용
변경 제안
PDF
를 사용할 수 있습니다 audit-sum 감사 메시지 쓰기, 읽기, 헤드 및 삭제 횟수를 세고 각 작업 유형에 대한 최소, 최대 및 평균 시간(또는 크기)을 확인하는 도구입니다.
-
특정 액세스 권한이 있어야 합니다.
-
에 가 있어야 합니다
Passwords.txt파일. -
기본 관리 노드의 IP 주소를 알아야 합니다.
를 클릭합니다 audit-sum 기본 관리 노드에서 사용할 수 있는 도구는 기록된 쓰기, 읽기 및 삭제 작업의 수와 이러한 작업이 소요된 시간을 요약합니다.
|
를 클릭합니다 audit-sum 도구는 주로 문제 해결 작업 중에 기술 지원 부서에서 사용하도록 설계되었습니다. 처리 중입니다 audit-sum 쿼리는 많은 양의 CPU 성능을 소모하여 StorageGRID 작업에 영향을 줄 수 있습니다.
|
이 예는 의 일반적인 출력을 보여줍니다 audit-sum 도구. 이 예에서는 프로토콜 작업이 얼마나 오래 걸렸는지 보여 줍니다.
message group count min(sec) max(sec) average(sec) ============= ===== ======== ======== ============ IDEL 274 SDEL 213371 0.004 20.934 0.352 SGET 201906 0.010 1740.290 1.132 SHEA 22716 0.005 2.349 0.272 SPUT 1771398 0.011 1770.563 0.487
를 클릭합니다 audit-sum 툴에서 감사 로그에 다음 S3, Swift 및 ILM 감사 메시지의 수와 시간을 제공합니다.
| 코드 | 설명 | 을 참조하십시오 |
|---|---|---|
ARCT |
클라우드 계층에서 아카이브 검색 - 계층 |
|
ASCT |
Archive Store Cloud - Tier 를 선택합니다 |
|
IDEL |
ILM에서 삭제 시작: ILM이 개체 삭제 프로세스를 시작할 때 기록합니다. |
|
SDEL |
S3 삭제: 오브젝트 또는 버킷을 삭제하기 위해 트랜잭션을 성공적으로 기록합니다. |
|
SGET |
S3 GET: 성공적인 트랜잭션을 로그하여 객체를 검색하거나 버킷의 오브젝트를 나열합니다. |
|
셰어 |
S3 HEAD: 성공한 트랜잭션을 로그하여 오브젝트 또는 버킷의 존재 여부를 확인합니다. |
|
SPUT |
S3 PUT: 새 오브젝트 또는 버킷을 생성하기 위한 성공적인 트랜잭션을 기록합니다. |
|
WDEL |
SwiFT DELETE(빠른 삭제): 성공한 트랜잭션을 로그하여 오브젝트 또는 컨테이너를 삭제합니다. |
|
윙입니다 |
SwiFT GET: 성공한 트랜잭션을 로그하여 객체를 검색하거나 컨테이너의 객체를 나열합니다. |
|
WHEA |
SwiFT HEAD: 성공한 트랜잭션을 로그하여 오브젝트 또는 컨테이너의 존재를 확인합니다. |
|
WPUT |
SwiFT PUT: 새 개체 또는 컨테이너를 생성하기 위해 트랜잭션을 성공적으로 기록합니다. |
를 클릭합니다 audit-sum 도구는 일반 감사 로그 또는 압축 감사 로그를 처리할 수 있습니다. 예를 들면 다음과 같습니다.
audit-sum audit.log
audit-sum 2019-08-12.txt.gz
를 클릭합니다 audit-sum 또한 도구는 여러 파일을 한 번에 처리할 수 있습니다. 예를 들면 다음과 같습니다.
audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gz
audit-sum /var/local/audit/export/*
마지막으로, 입니다 audit-sum 또한 이 도구는 파이프에서 입력을 받아 을 사용하여 입력을 필터링하고 미리 처리할 수 있습니다 grep 명령 또는 기타 방법. 예를 들면 다음과 같습니다.
grep WGET audit.log | audit-sum
grep bucket1 audit.log | audit-sum
grep SPUT audit.log | grep bucket1 | audit-sum
|
이 도구는 압축된 파일을 파이프된 입력으로 허용하지 않습니다. 압축된 파일을 처리하려면 파일 이름을 명령줄 인수로 제공하거나 를 사용합니다 zcat 먼저 파일의 압축을 푸는 도구입니다. 예를 들면 다음과 같습니다.
|
audit-sum audit.log.gz
zcat audit.log.gz | audit-sum
명령줄 옵션을 사용하여 객체에 대한 작업과 별도로 버킷 작업을 요약하거나 버킷 이름, 기간 또는 목표 유형별로 메시지 요약을 그룹화할 수 있습니다. 기본적으로 요약에는 최소, 최대 및 평균 작동 시간이 표시되지만 을 사용할 수 있습니다 size (-s) 대신 개체 크기를 보는 옵션입니다.
를 사용합니다 help (-h) 옵션을 클릭하여 사용 가능한 옵션을 표시합니다. 예를 들면 다음과 같습니다.
$ audit-sum -h
-
기본 관리자 노드에 로그인합니다.
-
다음 명령을 입력합니다.
ssh admin@primary_Admin_Node_IP -
에 나열된 암호를 입력합니다
Passwords.txt파일.
-
-
쓰기, 읽기, 헤드 및 삭제 작업과 관련된 모든 메시지를 분석하려면 다음 단계를 수행하십시오.
-
다음 명령을 입력합니다. 여기서
/var/local/audit/export/audit.log분석할 파일의 이름과 위치를 나타냅니다.$ audit-sum /var/local/audit/export/audit.log
이 예는 의 일반적인 출력을 보여줍니다
audit-sum도구. 이 예에서는 프로토콜 작업이 얼마나 오래 걸렸는지 보여 줍니다.message group count min(sec) max(sec) average(sec) ============= ===== ======== ======== ============ IDEL 274 SDEL 213371 0.004 20.934 0.352 SGET 201906 0.010 1740.290 1.132 SHEA 22716 0.005 2.349 0.272 SPUT 1771398 0.011 1770.563 0.487
이 예에서 SGET(S3 GET) 작업은 평균 1.13초 동안 가장 느리지만, SGET 및 SPUT(S3 PUT) 작업은 모두 1,770초 정도의 긴 최악의 경우를 나타냅니다.
-
가장 느린 10개의 검색 작업을 표시하려면 grep 명령을 사용하여 SGET 메시지만 선택하고 긴 출력 옵션을 추가합니다 (
-l) 개체 경로를 포함하려면 다음을 수행합니다.grep SGET audit.log | audit-sum -l결과에 유형(오브젝트 또는 버킷) 및 경로가 포함되어 있어 이러한 특정 오브젝트와 관련된 다른 메시지에 대해 감사 로그를 작성할 수 있습니다.
Total: 201906 operations Slowest: 1740.290 sec Average: 1.132 sec Fastest: 0.010 sec Slowest operations: time(usec) source ip type size(B) path ========== =============== ============ ============ ==== 1740289662 10.96.101.125 object 5663711385 backup/r9O1OaQ8JB-1566861764-4519.iso 1624414429 10.96.101.125 object 5375001556 backup/r9O1OaQ8JB-1566861764-6618.iso 1533143793 10.96.101.125 object 5183661466 backup/r9O1OaQ8JB-1566861764-4518.iso 70839 10.96.101.125 object 28338 bucket3/dat.1566861764-6619 68487 10.96.101.125 object 27890 bucket3/dat.1566861764-6615 67798 10.96.101.125 object 27671 bucket5/dat.1566861764-6617 67027 10.96.101.125 object 27230 bucket5/dat.1566861764-4517 60922 10.96.101.125 object 26118 bucket3/dat.1566861764-4520 35588 10.96.101.125 object 11311 bucket3/dat.1566861764-6616 23897 10.96.101.125 object 10692 bucket3/dat.1566861764-4516+ 이 예제 출력에서 세 개의 가장 느린 S3 GET 요청은 크기가 약 5GB인 오브젝트에 대해 다른 오브젝트보다 훨씬 크다는 것을 알 수 있습니다. 크기가 크면 검색 시간이 느려질 수 있습니다.
-
-
그리드에서 인제스트되고 검색되는 오브젝트 크기를 결정하려면 크기 옵션을 사용합니다 (
-s):audit-sum -s audit.log
message group count min(MB) max(MB) average(MB) ============= ===== ======== ======== ============ IDEL 274 0.004 5000.000 1654.502 SDEL 213371 0.000 10.504 1.695 SGET 201906 0.000 5000.000 14.920 SHEA 22716 0.001 10.504 2.967 SPUT 1771398 0.000 5000.000 2.495
이 예에서 SPUT의 평균 개체 크기는 2.5MB 미만이지만 SGET의 평균 크기는 훨씬 큽니다. SPUT 메시지 수가 SGET 메시지 수보다 훨씬 많음을 나타내며, 이는 대부분의 개체가 검색되지 않음을 나타냅니다.
-
어제 검색 속도가 느리는지 확인하려면:
-
적절한 감사 로그에 명령을 실행하고 GROUP-By-TIME 옵션을 사용합니다 (
-gt), 그 다음에 시간(예: 15M, 1H, 10S):grep SGET audit.log | audit-sum -gt 1H
message group count min(sec) max(sec) average(sec) ============= ===== ======== ======== ============ 2019-09-05T00 7591 0.010 1481.867 1.254 2019-09-05T01 4173 0.011 1740.290 1.115 2019-09-05T02 20142 0.011 1274.961 1.562 2019-09-05T03 57591 0.010 1383.867 1.254 2019-09-05T04 124171 0.013 1740.290 1.405 2019-09-05T05 420182 0.021 1274.511 1.562 2019-09-05T06 1220371 0.015 6274.961 5.562 2019-09-05T07 527142 0.011 1974.228 2.002 2019-09-05T08 384173 0.012 1740.290 1.105 2019-09-05T09 27591 0.010 1481.867 1.354
이러한 결과는 S3이 06:00에서 07:00 사이에 트래픽이 증가하는 것을 보여줍니다. 최대 시간과 평균 시간도 이 시기에 상당히 높으면서, 수가 증가할수록 점차 증가하지는 않았습니다. 이는 네트워크 또는 그리드의 요청 처리 능력 중 어느 곳보다 용량이 초과된 것을 의미합니다.
-
어제 매시간 검색되는 개체의 크기를 확인하려면 크기 옵션을 추가합니다 (
-s) 명령으로:grep SGET audit.log | audit-sum -gt 1H -s
message group count min(B) max(B) average(B) ============= ===== ======== ======== ============ 2019-09-05T00 7591 0.040 1481.867 1.976 2019-09-05T01 4173 0.043 1740.290 2.062 2019-09-05T02 20142 0.083 1274.961 2.303 2019-09-05T03 57591 0.912 1383.867 1.182 2019-09-05T04 124171 0.730 1740.290 1.528 2019-09-05T05 420182 0.875 4274.511 2.398 2019-09-05T06 1220371 0.691 5663711385.961 51.328 2019-09-05T07 527142 0.130 1974.228 2.147 2019-09-05T08 384173 0.625 1740.290 1.878 2019-09-05T09 27591 0.689 1481.867 1.354
이러한 결과는 전체 검색 트래픽이 최대값일 때 매우 큰 검색 결과가 발생했음을 나타냅니다.
-
자세한 내용은 를 참조하십시오
audit-explain해당 시간 동안 모든 SGET 작업을 검토하는 도구:grep 2019-09-05T06 audit.log | grep SGET | audit-explain | less
grep 명령의 출력이 여러 줄로 예상되는 경우 를 추가합니다
less한 번에 한 페이지(한 화면)씩 감사 로그 파일의 내용을 표시하는 명령입니다.
-
-
버킷의 SPUT 작업이 개체에 대한 SPUT 작업보다 느리는지 확인하려면 다음을 수행합니다.
-
을 사용하여 시작합니다
-go오브젝트 및 버킷 작업에 대한 메시지를 개별적으로 그룹화하는 옵션:grep SPUT sample.log | audit-sum -go
message group count min(sec) max(sec) average(sec) ============= ===== ======== ======== ============ SPUT.bucket 1 0.125 0.125 0.125 SPUT.object 12 0.025 1.019 0.236
결과는 버킷에 대한 SPUT 작업의 성능 특성이 객체에 대한 SPUT 작업과 다르다는 것을 보여줍니다.
-
어떤 버킷이 가장 느린 SPUT 작업을 가지는지 확인하려면 를 사용합니다
-gb버킷별로 메시지를 그룹화하는 옵션:grep SPUT audit.log | audit-sum -gb
message group count min(sec) max(sec) average(sec) ============= ===== ======== ======== ============ SPUT.cho-non-versioning 71943 0.046 1770.563 1.571 SPUT.cho-versioning 54277 0.047 1736.633 1.415 SPUT.cho-west-region 80615 0.040 55.557 1.329 SPUT.ldt002 1564563 0.011 51.569 0.361
-
어떤 버킷이 최대 SPUT 객체 크기를 가지는지 확인하려면 두 가지를 모두 사용하십시오
-gb및-s옵션:grep SPUT audit.log | audit-sum -gb -s
message group count min(B) max(B) average(B) ============= ===== ======== ======== ============ SPUT.cho-non-versioning 71943 2.097 5000.000 21.672 SPUT.cho-versioning 54277 2.097 5000.000 21.120 SPUT.cho-west-region 80615 2.097 800.000 14.433 SPUT.ldt002 1564563 0.000 999.972 0.352
-