감사 합계 도구를 사용합니다
변경 제안
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 감사 메시지의 수와 시간을 제공합니다.
|
|
기능이 더 이상 사용되지 않으므로 제품 및 설명서에서 감사 코드가 제거됩니다. 여기에 나열되지 않은 감사 코드가 발생하는 경우 이전 SG 릴리스에 대한 이 항목의 이전 버전을 확인하십시오. "감사 합계 도구 문서 사용 StorageGRID 11.8"예를 들어, |
| 코드 | 설명 | 을 참조하십시오 |
|---|---|---|
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.logaudit-sum 2019-08-12.txt.gz -
여러 파일을 동시에 처리합니다. 예를 들면 다음과 같습니다.
audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gzaudit-sum /var/local/log/* -
파이프의 입력을 수락하면 명령 또는 다른 방법으로 입력을 필터링하고 사전 처리할 수 있습니다.
grep예를 들면 다음과 같습니다.grep WGET audit.log | audit-sumgrep bucket1 audit.log | audit-sumgrep SPUT audit.log | grep bucket1 | audit-sum
|
|
이 도구는 압축된 파일을 파이프된 입력으로 허용하지 않습니다. 압축된 파일을 처리하려면 파일 이름을 명령줄 인수로 제공하거나 도구를 사용하여
|
명령줄 옵션을 사용하여 객체에 대한 작업과 별도로 버킷 작업을 요약하거나 버킷 이름, 기간 또는 목표 유형별로 메시지 요약을 그룹화할 수 있습니다. 기본적으로 요약에는 최소, 최대 및 평균 작업 시간이 표시되지만 옵션을 사용하면 개체 크기를 확인할 수 size (-s) 있습니다.
옵션을 사용하여 help (-h) 사용 가능한 옵션을 확인합니다. 예를 들면 다음과 같습니다.
$ audit-sum -h
-
기본 관리자 노드에 로그인합니다.
-
다음 명령을 입력합니다.
ssh admin@primary_Admin_Node_IP -
파일에 나열된 암호를
Passwords.txt입력합니다. -
다음 명령을 입력하여 루트로 전환합니다.
su - -
파일에 나열된 암호를
Passwords.txt입력합니다.루트로 로그인하면 프롬프트가 에서
$로 `#`변경됩니다.
-
-
쓰기, 읽기, 헤드 및 삭제 작업과 관련된 모든 메시지를 분석하려면 다음 단계를 수행하십시오.
-
다음 명령을 입력합니다. 여기서 는 분석할 파일의 이름과 위치를 나타냅니다.
/var/local/log/audit.log$ audit-sum /var/local/log/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 메시지만 선택하고 long 출력 옵션을 (`-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.logmessage 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 1Hmessage 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 GET 트래픽이 06:00에서 07:00사이에 급증함을 보여줍니다. 최대 시간과 평균 시간도 이 시기에 상당히 높으면서, 수가 증가할수록 점차 증가하지는 않았습니다. 이는 네트워크 또는 그리드의 요청 처리 능력 중 어느 곳보다 용량이 초과된 것을 의미합니다.
-
어제 매시간마다 검색되는 크기 개체를 확인하려면 (`-s`명령에 size 옵션)을 추가합니다.
grep SGET audit.log | audit-sum -gt 1H -smessage 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
이러한 결과는 전체 검색 트래픽이 최대값일 때 매우 큰 검색 결과가 발생했음을 나타냅니다.
-
자세한 내용을 보려면 를 사용하여 "감사 - 설명 도구"해당 시간 동안 모든 SGET 작업을 검토합니다.
grep 2019-09-05T06 audit.log | grep SGET | audit-explain | less
grep 명령의 출력이 여러 줄로 예상되는 경우 감사 로그 파일의 내용을 한 번에 한 페이지(한 화면)씩 표시하는 명령을 추가합니다
less. -
-
버킷의 SPUT 작업이 개체에 대한 SPUT 작업보다 느리는지 확인하려면 다음을 수행합니다.
-
오브젝트 및 버킷 작업에 대한 메시지를 별도로 그룹화하는 옵션을 사용하여 시작합니다
-go.grep SPUT sample.log | audit-sum -gomessage 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 -gbmessage 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 개체 크기가 가장 큰 버킷의 크기를 확인하려면 및
-s옵션을 모두-gb사용합니다.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
-