감사 합계 도구 사용
변경 제안
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 감사 합계 도구 설명서 사용" . |
| 암호 | 설명 | 참조하다 |
|---|---|---|
이델 |
ILM이 삭제를 시작함: ILM이 개체 삭제 프로세스를 시작할 때 기록됩니다. |
|
SDEL |
S3 DELETE: 객체나 버킷을 삭제하는 성공적인 트랜잭션을 기록합니다. |
|
SGET |
S3 GET: 버킷에 있는 객체를 검색하거나 객체를 나열하기 위한 성공적인 트랜잭션을 기록합니다. |
|
시어 |
S3 HEAD: 객체나 버킷의 존재 여부를 확인하기 위해 성공적인 트랜잭션을 기록합니다. |
|
뱉다 |
S3 PUT: 새로운 객체나 버킷을 생성하기 위한 성공적인 트랜잭션을 기록합니다. |
|
WDEL |
Swift DELETE: 객체나 컨테이너를 삭제하는 성공적인 트랜잭션을 기록합니다. |
|
WGET |
Swift GET: 컨테이너에 있는 객체를 검색하거나 나열하는 성공적인 트랜잭션을 기록합니다. |
|
훼아 |
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 메시지만 선택하고 긴 출력 옵션을 추가합니다.(
-l) 객체 경로를 포함하려면:grep SGET audit.log | audit-sum -l결과에는 유형(객체 또는 버킷)과 경로가 포함되며, 이를 통해 감사 로그에서 이러한 특정 객체와 관련된 다른 메시지를 grep하여 검색할 수 있습니다.
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 요청 3개는 크기가 약 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 메시지의 수보다 훨씬 많은데, 이는 대부분의 객체가 검색되지 않는다는 것을 의미합니다.
-
어제 검색이 느렸는지 확인하려면 다음을 수행하세요.
-
적절한 감사 로그에 명령을 실행하고 시간별 그룹 옵션을 사용합니다.(
-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 트래픽이 오전 6시에서 7시 사이에 급증했음을 보여줍니다. 이 시간대에는 최대 시간과 평균 시간이 모두 상당히 높았으며, 횟수가 증가함에 따라 점진적으로 증가하지 않았습니다. 이는 네트워크나 요청을 처리하는 그리드의 능력 등 어딘가에서 용량이 초과되었음을 시사합니다.
-
어제 매시간 검색된 객체 크기를 확인하려면 크기 옵션을 추가하세요.(
-s) 명령으로: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 객체 크기를 가지고 있는지 확인하려면 다음 두 가지를 모두 사용하십시오.
-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
-