메트릭스 & 모니터링

메트릭스 & 모니터링 (Metrics & Monitoring)

HBase가 어떤 메트릭을 제공하고, 그것을 어떻게 수집·조회·모니터링하는지를 정리한 페이지예요. Ganglia 연동부터 Prometheus 서블릿, 슬로우 쿼리 로그와 블록 캐시·스냅샷 모니터링까지 폭넓게 다룬답니다. 클러스터 상태를 파악하고 성능 문제를 진단할 때 아주 유용해요.

출처: 문서

본문

HBase 메트릭 (HBase Metrics)

HBase는 Hadoop Metrics API를 따르는 메트릭을 발행해요. HBase 0.95부터는 기본적으로 10초마다 한 번씩 기본 메트릭 집합을 발행하도록 설정되어 있어요. HBase 메트릭은 Ganglia와 함께 사용할 수 있고, 발행되는 메트릭을 필터링하거나 여러분 환경에 맞는 커스텀 메트릭을 캡처하도록 메트릭 프레임워크를 확장할 수도 있어요.

메트릭 설정 (Metric Setup)

HBase 0.95 이상에서는 기본 메트릭 설정(또는 sink)이 기본 제공돼요. 여기에는 다양한 개별 메트릭이 포함되며 기본적으로 10초마다 발행되죠. 특정 region server의 메트릭을 설정하려면 conf/hadoop-metrics2-hbase.properties 파일을 편집하면 돼요. 변경 사항을 적용하려면 region server를 재시작해야 해요.

기본 sink의 샘플링 주기를 바꾸려면 *.period로 시작하는 줄을 편집하면 돼요. 어떤 메트릭을 발행할지 필터링하거나 메트릭 프레임워크를 확장하려면 https://hadoop.apache.org/docs/current/api/org/apache/hadoop/metrics2/package-summary.html를 참고하세요.

HBase Metrics and Ganglia기본적으로 HBase는 region server당 매우 많은 수의 메트릭을 발행해요. Ganglia가 이 모든 메트릭을 처리하기 어려울 수 있어요. Ganglia 서버의 용량을 늘리거나 HBase가 발행하는 메트릭 수를 줄이는 것을 고려해 보세요. Metrics Filtering을 참고하세요.

메트릭 비활성화 (Disabling Metrics)

region server의 메트릭을 비활성화하려면 conf/hadoop-metrics2-hbase.properties 파일을 편집해서 주석 처리되지 않은 줄을 모두 주석 처리하면 돼요. 변경 사항을 적용하려면 region server를 재시작해야 해요.

메트릭 서블릿 활성화 (Enabling Metrics Servlets)

HBase는 JSON, prometheus 형식 등 다양한 형식으로 메트릭을 서로 다른 서블릿(/jmx, /metrics, /prometheus)을 통해 노출해요. 이 중 아무 서블릿이나 hbase.http.metrics.servlets 설정 속성으로 활성화/비활성화할 수 있어요. 속성 값은 {jmx, metrics, prometheus} 중 서블릿 별칭을 콤마로 구분한 목록이에요. /jmx, /metrics, /prometheus는 기본적으로 활성화돼요. 이 서블릿들로 메트릭을 얻으려면 http://SERVER_HOSTNAME:SERVER_WEB_UI_PORT/endpoint URL에 접근하면 되는데, endpoint는 /jmx, /metrics, /prometheus 중 하나예요. 예: http://my.rs.xyz.com:16030/prometheus

Prometheus 서블릿 (Prometheus servlets)

HBase는 /prometheus 서블릿을 통해 prometheus 친화적인 형식으로 메트릭을 노출해요. 현재 /prometheus는 사용 가능한 모든 메트릭을 노출하죠.

사용 가능한 메트릭 찾기 (Discovering Available Metrics)

HBase가 기본적으로 발행하는 각 메트릭을 일일이 나열하는 대신, JSON 출력이나 JMX를 통해 사용 가능한 메트릭을 탐색할 수 있어요. Master 프로세스와 각 region server 프로세스마다 서로 다른 메트릭이 노출돼요.

절차: 사용 가능한 메트릭을 JSON으로 확인하기

HBase를 시작한 후 기본적으로 http://REGIONSERVER_HOSTNAME:16030인 region server의 웹 UI에 접근하세요. 상단 근처의 Metrics Dump 링크를 클릭하면 돼요. region server의 메트릭이 JSON 형식의 JMX 빈 덤프로 표시돼요. 그러면 모든 메트릭 이름과 값이 덤프돼요. 메트릭 설명까지 목록에 포함하려면 — 무엇이 있는지 탐색할 때 유용하죠 — ?description=true 쿼리 문자열을 추가해서 URL을 http://REGIONSERVER_HOSTNAME:16030/jmx?description=true 로 만들면 돼요. 모든 빈과 속성에 설명이 있는 것은 아니에요. Master의 메트릭을 보려면 대신 Master의 웹 UI(기본값 http://localhost:16010)에 접속해서 Metrics Dump 링크를 클릭하면 돼요. 메트릭 설명을 목록에 포함하려면 ?description=true 쿼리 문자열을 추가해서 URL을 http://REGIONSERVER_HOSTNAME:16010/jmx?description=true 로 만들면 돼요. 모든 빈과 속성에 설명이 있는 것은 아니에요.

MBeans를 탐색해서 JMX 콘텐츠를 볼 수 있는 많은 도구를 사용할 수 있어요. 이 절차에서는 보통 JDK에 포함된 애플리케이션인 jvisualvm을 사용해요.

절차: 사용 가능한 메트릭의 JMX 출력 탐색하기

HBase가 이미 실행 중이 아니라면 시작하세요.GUI 디스플레이가 있는 호스트에서 jvisualvm 명령을 실행하세요. 명령줄이나 운영체제에 적합한 다른 방법으로 실행할 수 있어요.VisualVM-MBeans 플러그인이 설치되어 있는지 확인하세요. Tools → Plugins로 이동해서 Installed를 클릭하고 플러그인이 나열되어 있는지 확인하세요. 없다면 Available Plugins를 클릭해서 선택하고 Install을 클릭하세요. 완료되면 Close를 클릭하세요.특정 HBase 프로세스의 세부 정보를 보려면 왼쪽 패널의 Local 서브 트리에서 프로세스를 더블클릭하세요. 그러면 오른쪽 패널에 상세 뷰가 열려요. 오른쪽 패널 상단에 탭으로 나타나는 MBeans 탭을 클릭하세요.HBase 메트릭에 접근하려면 적절한 하위 빈으로 이동하세요: .* Master: .* RegionServer:각 메트릭의 이름과 현재 값은 Attributes 탭에 표시돼요. 각 속성의 설명까지 포함된 더 상세한 뷰를 보려면 Metadata 탭을 클릭하세요.

메트릭 측정 단위 (Units of Measure for Metrics)

메트릭마다 상황에 맞게 서로 다른 단위로 표현돼요. 종종 측정 단위가 이름에 포함돼요(shippedKBs 메트릭처럼요). 그 외에는 다음 지침을 따라보세요. 확실하지 않을 때는 특정 메트릭의 소스 코드를 살펴볼 필요가 있어요.

• 어떤 시점을 가리키는 메트릭은 보통 타임스탬프로 표현돼요.
• 나이를 가리키는 메트릭(ageOfLastShippedOp 같은)은 보통 밀리초로 표현돼요.
• 메모리 크기를 가리키는 메트릭은 바이트 단위예요.
• 큐 크기(sizeOfLogQueue 같은)는 큐에 있는 항목 수로 표현돼요. 크기는 블록 크기(HDFS 기본값 64 MB)를 곱해서 구해요.
• 특정 유형의 연산 개수 같은 것(logEditsRead 같은)을 가리키는 메트릭은 정수로 표현돼요.

가장 중요한 Master 메트릭 (Most Important Master Metrics)

참고: 카운트는 보통 마지막 메트릭 보고 간격 동안의 값이에요.

hbase.master.numRegionServers

살아 있는 regionserver 수

hbase.master.numDeadRegionServers

죽은 regionserver 수

hbase.master.ritCount

전환 중(transition)인 region 수

hbase.master.ritCountOverThreshold

임계 시간(기본값: 60초)보다 오래 전환 중인 region 수

hbase.master.ritOldestAge

가장 오래된 전환 중 region의 나이(밀리초)

가장 중요한 RegionServer 메트릭 (Most Important RegionServer Metrics)

참고: 카운트는 보통 마지막 메트릭 보고 간격 동안의 값이에요.

hbase.regionserver.regionCount

regionserver가 호스팅하는 region 수

hbase.regionserver.storeFileCount

regionserver가 현재 관리하는 디스크의 store file 수

hbase.regionserver.storeFileSize

디스크에 있는 store file의 총합 크기

hbase.regionserver.hlogFileCount

아직 아카이브되지 않은 write ahead log 수

hbase.regionserver.totalRequestCount

수신한 총 요청 수

hbase.regionserver.readRequestCount

수신한 읽기 요청 수

hbase.regionserver.writeRequestCount

수신한 쓰기 요청 수

hbase.regionserver.numOpenConnections

RPC 계층의 열린 연결 수

hbase.regionserver.numActiveHandler

요청을 적극적으로 처리 중인 RPC 핸들러 수

hbase.regionserver.numCallsInGeneralQueue

현재 큐에 대기 중인 사용자 요청 수

hbase.regionserver.numCallsInReplicationQueue

복제로부터 수신해 현재 큐에 대기 중인 연산 수

hbase.regionserver.numCallsInPriorityQueue

현재 큐에 대기 중인 우선순위(내부 하우스키핑) 요청 수

hbase.regionserver.flushQueueLength

memstore flush 큐의 현재 깊이. 증가하고 있다면 memstore를 HDFS로 비우는 속도를 따라가지 못하고 있다는 뜻이에요.

hbase.regionserver.updatesBlockedTime

memstore를 flush할 수 있도록 업데이트가 차단된 밀리초 수

hbase.regionserver.compactionQueueLength

컴팩션 요청 큐의 현재 깊이. 증가하고 있다면 storefile 컴팩션을 따라가지 못하고 있다는 뜻이에요.

hbase.regionserver.blockCacheHitCount

블록 캐시 히트 수

hbase.regionserver.blockCacheMissCount

블록 캐시 미스 수

hbase.regionserver.blockCacheExpressHitPercent

캐시가 켜진 요청이 캐시에 히트하는 비율(퍼센트)

hbase.regionserver.percentFilesLocal

로컬 DataNode에서 읽을 수 있는 store file 데이터의 비율, 0-100

hbase.regionserver._

연산 지연 시간으로, 는 Append, Delete, Mutate, Get, Replay, Increment 중 하나이고 는 min, max, mean, median, 75th_percentile, 95th_percentile, 99th_percentile 중 하나예요.

hbase.regionserver.slowCount

느리다고 판단된 연산 수로, 는 위 목록 중 하나예요.

hbase.regionserver.GcTimeMillis

가비지 컬렉션에 소요된 시간(밀리초)

hbase.regionserver.GcTimeMillisParNew

young generation 가비지 컬렉션에 소요된 시간(밀리초)

hbase.regionserver.GcTimeMillisConcurrentMarkSweep

old generation 가비지 컬렉션에 소요된 시간(밀리초)

hbase.regionserver.authenticationSuccesses

인증에 성공한 클라이언트 연결 수

hbase.regionserver.authenticationFailures

클라이언트 연결 인증 실패 수

hbase.regionserver.mutationsWithoutWALCount

write ahead log를 우회해야 한다는 플래그를 달고 제출된 쓰기 수

Meta 테이블 로드 메트릭 (Meta Table Load Metrics)

HBase meta 테이블 메트릭 수집 기능은 HBase 1.4+에서 사용할 수 있지만, 기본적으로는 비활성화되어 있어요. 클러스터 성능에 영향을 줄 수 있기 때문이죠. 이 기능을 활성화하면 클라이언트 접근 패턴을 모니터링하는 데 도움이 되는 다음 통계를 수집해요:

• hbase:meta 테이블에 대한 get, put, delete 연산 수
• 상위 N개 클라이언트가 수행한 get, put, delete 연산 수
• 각 테이블과 관련된 연산 수
• 상위 N개 region과 관련된 연산 수

이 기능을 사용하는 시기 이 기능은 meta 정보가 수정(예: 테이블 create, drop, split, move)되거나 가장 자주 조회되는 region이나 테이블을 보여줘서 meta 테이블의 핫스팟을 식별하는 데 도움을 줘요. 또한 meta 테이블을 가장 많이 사용하는 클라이언트를 보여줘서 잘못 동작하는 클라이언트 애플리케이션을 찾는 데도 도움이 되는데, 예를 들어 클라이언트 애플리케이션에 meta 테이블 버퍼링이 없거나 열린 클라이언트 연결을 재사용하지 않는다는 것을 암시해 주거든요.

이 기능 활성화의 잠재적 부작용클러스터에 클라이언트와 region이 많으면 많은 수의 메트릭 등록과 추적이 발생해서 hbase:meta 테이블을 처리하는 HBase region server의 메모리와 CPU footprint가 커질 수 있어요. 또한 JMX 덤프 크기가 크게 늘어나서 HBase 옆에서 사용하는 모니터링이나 로그 집계 시스템에 영향을 줄 수도 있어요. 이 기능은 디버깅 중에만 켜는 것이 권장돼요.

JMX에서 메트릭을 찾을 위치

각 메트릭 속성 이름은 'MetaTable_' 접두사로 시작해요. 모든 메트릭에서 다섯 가지 JMX 속성(count, mean rate, 1 minute rate, 5 minute rate, 15 minute rate)을 볼 수 있어요. 이 메트릭들은 JMX에서 다음 MBean 아래에서 찾을 수 있어요: Hadoop → HBase → RegionServer → Coprocessor.Region.CP_org.apache.hadoop.hbase.coprocessor.MetaTableMetrics.

예: JMX 덤프에서 볼 수 있는 몇 가지 Meta Table 메트릭

{
  "MetaTable_get_request_count": 77309,
  "MetaTable_put_request_mean_rate": 0.06339092997186495,
  "MetaTable_table_MyTestTable_request_15min_rate": 1.1020599841623246,
  "MetaTable_client_/172.30.65.42_lossy_request_count": 1786
  "MetaTable_client_/172.30.65.45_put_request_5min_rate": 0.6189810954855728,
  "MetaTable_region_1561131112259.c66e4308d492936179352c80432ccfe0._lossy_request_count": 38342,
  "MetaTable_region_1561131043640.5bdffe4b9e7e334172065c853cf0caa6._lossy_request_1min_rate": 0.04925099917433935,
}

설정

이 기능을 켜려면 hbase-site.xml에 다음 섹션을 추가해서 커스텀 코프로세서를 활성화해야 해요. 이 코프로세서는 모든 HBase RegionServer에서 실행되지만, 메모리/CPU를 실제로 소비하며 활성화되는 것은 hbase:meta 테이블이 있는 서버뿐이에요. 해당 RegionServer의 웹 UI나 간단한 REST 호출로 다운로드할 수 있는 JMX 메트릭을 생성하죠. 이 메트릭은 다른 RegionServer의 JMX 덤프에는 나타나지 않아요.

Meta Table Metrics 기능 활성화하기

<property>
    <name>hbase.coprocessor.region.classes</name>
    <value>org.apache.hadoop.hbase.coprocessor.MetaTableMetrics</value>
</property>

상위 N 메트릭은 어떻게 계산되나요?'top-N' 유형의 메트릭은 Lossy Counting Algorithm(정의는 Motwani, R; Manku, G.S (2002). "Approximate frequency counts over data streams")을 사용해서 계산돼요. 이 알고리즘은 데이터 스트림에서 사용자가 지정한 임계값을 초과하는 빈도를 가진 요소를 식별하도록 설계됐어요. 이 알고리즘이 계산한 빈도는 항상 정확한 것은 아니지만 사용자가 설정 파라미터로 지정할 수 있는 오류 임계값이 있어요. 알고리즘에 필요한 실행 시간 공간은 지정된 오류 임계값에 반비례하므로, 오류 파라미터가 클수록 footprint는 작아지고 메트릭 정확도는 떨어져요.알고리즘의 오류율을 0과 1 사이(배타적)의 부동소수점 값으로 지정할 수 있는데 기본값은 0.02예요. 오류율을 E로 설정하고 전체 meta 테이블 연산 수를 N이라 하면(낮은 빈도 요소의 활동이 균등하게 분포한다고 가정), 최대 7 / E개의 미터만 유지되고 유지된 각 요소는 E * N보다 높은 빈도를 가지게 돼요.예를 들어 보죠: meta 테이블에 가장 활발하게 접근하는 HBase 클라이언트가 궁금하다고 가정해요. 지금까지 meta 테이블 연산이 1,000,000건 있었고 오류율 파라미터가 0.02라면, JMX에는 최대 350개의 클라이언트 IP 주소 관련 카운터만 존재하고 이 각 클라이언트는 meta 테이블에 최소 20,000번 접근했다고 가정할 수 있어요.

<property>
    <name>hbase.util.default.lossycounting.errorrate</name>
    <value>0.02</value>
</property>

HBase 모니터링 (HBase Monitoring)

개요 (Overview)

다음 메트릭은 "매크로 모니터링(macro monitoring)"을 위해 각 RegionServer에서 가장 중요하게 모니터링할 만한 메트릭이라고 할 수 있어요. OpenTSDB 같은 시스템과 함께 사용하는 것이 좋아요. 클러스터에 성능 문제가 있다면 이 그룹에서 뭔가 이상한 점을 발견할 가능성이 높아요.

HBase

• rs 메트릭 참고

OS

• IO Wait
• User CPU

Java

• GC

슬로우 쿼리 로그 (Slow Query Log)

HBase 슬로우 쿼리 로그는 실행하는 데 너무 오래 걸렸거나, 너무 많은 출력을 만들어낸 클라이언트 연산(Get, Put, Delete 등)의 속성을 설명하는 파싱 가능한 JSON 구조로 구성돼요. "너무 오래 걸림"과 "너무 많은 출력"의 임계값은 아래에 설명하는 대로 설정 가능해요. 출력은 메인 region server 로그 안에 인라인으로 생성돼서 다른 로그 이벤트 문맥에서 추가 세부 정보를 쉽게 발견할 수 있어요. 또한 슬로우 쿼리만 보고 싶은 경우 grep으로 쉽게 필터링할 수 있도록 (responseTooSlow), (responseTooLarge), (operationTooSlow), (operationTooLarge) 같은 식별 태그가 앞에 붙어요.

설정 (Configuration)

쿼리가 로그에 기록되는 임계값을 조정하는 데 사용할 수 있는 네 가지 설정 노브가 있어요. 두 개는 모든 쿼리에 대한 크기·시간 임계값을 제어하고, Scan은 다른 쿼리 유형보다 크고 느릴 수 있으므로 Scan만을 위한 크기·시간 임계값을 제어하는 추가 노브 두 개가 더 있어요.

• hbase.ipc.warn.response.time 쿼리가 로그에 기록되지 않고 실행될 수 있는 최대 밀리초 수. 기본값은 10000, 즉 10초예요. -1로 설정하면 시간 기준 로깅을 비활성화할 수 있어요.
• hbase.ipc.warn.response.size 쿼리가 로그에 기록되지 않고 반환할 수 있는 응답의 최대 바이트 크기. 기본값은 100MB예요. -1로 설정하면 크기 기준 로깅을 비활성화할 수 있어요.
• hbase.ipc.warn.response.time.scan Scan이 로그에 기록되지 않고 실행될 수 있는 최대 밀리초 수. 기본값은 hbase.ipc.warn.response.time 값이에요. -1로 설정하면 시간 기준 로깅을 비활성화할 수 있어요.
• hbase.ipc.warn.response.size.scan Scan이 로그에 기록되지 않고 반환할 수 있는 응답의 최대 바이트 크기. 기본값은 hbase.ipc.warn.response.size 값이에요. -1로 설정하면 크기 기준 로깅을 비활성화할 수 있어요.

메트릭 (Metrics)

슬로우 쿼리 로그는 두 개의 메트릭을 JMX에 노출해요.

• hadoop.regionserver_rpc_slowResponse 로깅을 트리거한 모든 응답의 지속 시간을 반영하는 전역 메트릭
• hadoop.regionserver_rpc_methodName.aboveOneSec 1초 이상 지속된 모든 응답의 지속 시간을 반영하는 메트릭

출력 (Output)

출력은 호출이 Put, Get, Delete 같은 클라이언트 연산이라면 (operationTooSlow) 같은 연산 태그로 표시되고, 자세한 지문(fingerprint) 정보가 노출돼요. 그렇지 않으면 (responseTooSlow)로 태그되고 여전히 파싱 가능한 JSON 출력을 생성하지만, RPC 자체의 지속 시간과 크기에 관한 덜 상세한 정보만을 담아요. 응답 크기가 로깅을 트리거했다면 TooSlow 대신 TooLarge가 사용되며, 크기와 지속 시간이 모두 로깅을 트리거한 경우에도 TooLarge가 나타나요.

예 (Example)

2011-09-08 10:01:25,824 WARN org.apache.hadoop.ipc.HBaseServer: (operationTooSlow): {"tables":{"riley2":{"puts":[{"totalColumns":11,"families":{"actions":[{"timestamp":1315501284459,"qualifier":"0","vlen":9667580},{"timestamp":1315501284459,"qualifier":"1","vlen":10122412},{"timestamp":1315501284459,"qualifier":"2","vlen":11104617},{"timestamp":1315501284459,"qualifier":"3","vlen":13430635}]},"row":"cfcd208495d565ef66e7dff9f98764da:0"}],"families":["actions"]}},"processingtimems":956,"client":"10.47.34.63:33623","starttimems":1315501284456,"queuetimems":0,"totalPuts":1,"class":"HRegionServer","responsesize":0,"method":"multiPut"}

"tables" 구조 안의 모든 것은 MultiPut의 지문이 생성한 출력이고, 나머지 정보는 처리 시간과 클라이언트 IP/포트 같은 RPC 관련 정보라는 점에 주목하세요. 다른 클라이언트 연산도 각 연산의 특성에 따른 필요 차이와 함께 같은 패턴과 일반적인 구조를 따릅니다. 호출이 클라이언트 연산이 아닌 경우에는 그 자세한 지문 정보가 완전히 없어져요.

이 특정 예는, 예를 들어, 느림의 원인이 아마도 단순히 매우 큰(100MB 수준) multiPut일 것임을 가리키는데, 이는 multiPut 안의 각 put의 "vlen"(값 길이) 필드에서 알 수 있어요.

셸에서 슬로우 응답 로그 얻기 (Get Slow Response Log from shell)

개별 RPC가 설정 가능한 시간 범위를 초과하면 로깅 서브시스템을 통해 불만 사항을 기록해요.

예를 들어

2019-10-02 10:10:22,195 WARN [,queue=15,port=60020] ipc.RpcServer - (responseTooSlow):
{"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)",
"starttimems":1567203007549,
"responsesize":6819737,
"method":"Scan",
"param":"region { type: REGION_NAME value: \"t1,\\\\000\\\\000\\\\215\\\\f)o\\\\\\\\\\\\024\\\\302\\\\220\\\\000\\\\000\\\\000\\\\000\\\\000\\\\001\\\\000\\\\000\\\\000\\\\000\\\\000\\\\006\\\\000\\\\000\\\\000\\\\000\\\\000\\\\005\\\\000\\\\000<TRUNCATED>",
"processingtimems":28646,
"client":"10.253.196.215:41116",
"queuetimems":22453,
"class":"HRegionServer"}

불행히도 요청 파라미터는 위 예처럼 잘리는 경우가 많아요. 파라미터가 잘리면 경고의 유용성이 많이 줄어들기 때문에 안타깝죠. 예를 들어 region 이름, 시작/끝 키, 필터 계층은 모두 중간~낮은 선택성 쿼리나 높은 비율로 만들어진 쿼리로 인한 성능 문제를 디버깅할 때 중요한 단서가 돼요.

HBASE-22978은 responseTooSlow 로깅에 더해 너무 느리다고 판단된 요청의 인메모리 링 버퍼를 유지하는 기능을 도입했어요. 인메모리 표현은 완전할 수 있어요. 높은 비율의 요청이 발생하면 다른 흥미로운 요청에 대한 정보가 읽히기 전에 덮어써질 가능성이 있어요. 이는 감수할 만한 트레이드오프예요.

RegionServer에서 인메모리 링 버퍼를 활성화하려면 다음 설정을 활성화해야 해요:

hbase.regionserver.slowlog.buffer.enabled

링 버퍼의 크기를 결정하는 설정이 하나 더 있어요:

hbase.regionserver.slowlog.ringbuffer.size

자세한 설명은 설정 섹션을 확인하세요.

이 설정은 기본적으로 비활성화되어 있어요. 켜면 다음 셸 명령들이 링 버퍼에서 예상한 결과를 제공할 거예요.

RegionServer에서 slowlog 응답을 조회하는 셸 명령들:

각 RegionServer 또는 특정 RegionServer가 유지하는 최신 SlowLog 응답을 검색해요. '*'를 지정하면 모든 RS를 포함하고, 그렇지 않으면 특정 RS의 서버 이름 배열을 지정해요. 서버 이름은 RegionServer의 호스트, 포트, startcode예요. 예: host187.example.com,60020,1289493121758 (서버 이름은 master ui 또는 셸에서 detailed status를 할 때 찾을 수 있어요)

선택적 필터 파라미터를 Hash로 제공할 수 있어요. 각 서버별 슬로우 로그 레코드 기본 제공 개수 제한은 10이에요. 10개 이상의 레코드를 검색하려면 'LIMIT' 파라미터로 더 많은 제한을 지정할 수 있어요.

예:

  hbase> get_slowlog_responses '*'                                 => get slowlog responses from all RS
  hbase> get_slowlog_responses '*', {'LIMIT' => 50}                => get slowlog responses from all RS
                                                                      with 50 records limit (default limit: 10)
  hbase> get_slowlog_responses ['SERVER_NAME1', 'SERVER_NAME2']    => get slowlog responses from SERVER_NAME1,
                                                                      SERVER_NAME2
  hbase> get_slowlog_responses '*', {'REGION_NAME' => 'hbase:meta,,1'}
                                                                   => get slowlog responses only related to meta
                                                                      region
  hbase> get_slowlog_responses '*', {'TABLE_NAME' => 't1'}         => get slowlog responses only related to t1 table
  hbase> get_slowlog_responses '*', {'CLIENT_IP' => '192.162.1.40:60225', 'LIMIT' => 100}
                                                                   => get slowlog responses with given client
                                                                      IP address and get 100 records limit
                                                                      (default limit: 10)
  hbase> get_slowlog_responses '*', {'REGION_NAME' => 'hbase:meta,,1', 'TABLE_NAME' => 't1'}
                                                                   => get slowlog responses with given region name
                                                                      or table name
  hbase> get_slowlog_responses '*', {'USER' => 'user_name', 'CLIENT_IP' => '192.162.1.40:60225'}
                                                                   => get slowlog responses that match either
                                                                      provided client IP address or user name

위 필터가 있는 모든 쿼리는 기본적으로 OR 연산이 적용돼요. 즉 제공된 필터 중 어떤 것이라도 적용된 모든 레코드가 반환돼요. 하지만 AND 연산자도 적용할 수 있어요. 즉 제공된 모든(어떤 것이 아니라) 필터에 일치하는 레코드만 반환돼요.

hbase> get_slowlog_responses '*', {'REGION_NAME' => 'hbase:meta,,1', 'TABLE_NAME' => 't1', 'FILTER_BY_OP' => 'AND'}
                                                                   => get slowlog responses with given region name
                                                                      and table name, both should match

  hbase> get_slowlog_responses '*', {'REGION_NAME' => 'hbase:meta,,1', 'TABLE_NAME' => 't1', 'FILTER_BY_OP' => 'OR'}
                                                                   => get slowlog responses with given region name
                                                                      or table name, any one can match

  hbase> get_slowlog_responses '*', {'TABLE_NAME' => 't1', 'CLIENT_IP' => '192.163.41.53:52781', 'FILTER_BY_OP' => 'AND'}
                                                                   => get slowlog responses with given region name
                                                                      and client IP address, both should match

OR이 기본 필터 연산자이므로 'FILTER_BY_OP'를 제공하지 않으면 'FILTER_BY_OP' ⇒ 'OR'를 제공한 것과 같은 결과가 되요.

가끔 출력이 한 화면에서 스크롤하기엔 너무 긴 예쁘게 포맷된 json일 수 있어서, 사용자는 get_slowlog_responses의 출력을 파일로 리다이렉트하는 걸 선호할 수 있어요.

예:

echo "get_slowlog_responses '*'" | hbase shell > xyz.out 2>&1

슬로우 RPC 로그와 비슷하게, 클라이언트는 큰 RPC 로그도 검색할 수 있어요. 성능 문제를 디버깅하는 데 중요한 슬로우 로그가 크기가 더 큰 경우가 있거든요.

hbase> get_largelog_responses '*'                                 => get largelog responses from all RS
  hbase> get_largelog_responses '*', {'LIMIT' => 50}                => get largelog responses from all RS
                                                                       with 50 records limit (default limit: 10)
  hbase> get_largelog_responses ['SERVER_NAME1', 'SERVER_NAME2']    => get largelog responses from SERVER_NAME1,
                                                                       SERVER_NAME2
  hbase> get_largelog_responses '*', {'REGION_NAME' => 'hbase:meta,,1'}
                                                                    => get largelog responses only related to meta
                                                                       region
  hbase> get_largelog_responses '*', {'TABLE_NAME' => 't1'}         => get largelog responses only related to t1 table
  hbase> get_largelog_responses '*', {'CLIENT_IP' => '192.162.1.40:60225', 'LIMIT' => 100}
                                                                    => get largelog responses with given client
                                                                       IP address and get 100 records limit
                                                                       (default limit: 10)
  hbase> get_largelog_responses '*', {'REGION_NAME' => 'hbase:meta,,1', 'TABLE_NAME' => 't1'}
                                                                    => get largelog responses with given region name
                                                                       or table name
  hbase> get_largelog_responses '*', {'USER' => 'user_name', 'CLIENT_IP' => '192.162.1.40:60225'}
                                                                    => get largelog responses that match either
                                                                       provided client IP address or user name

  hbase> get_largelog_responses '*', {'REGION_NAME' => 'hbase:meta,,1', 'TABLE_NAME' => 't1', 'FILTER_BY_OP' => 'AND'}
                                                                   => get largelog responses with given region name
                                                                      and table name, both should match

  hbase> get_largelog_responses '*', {'REGION_NAME' => 'hbase:meta,,1', 'TABLE_NAME' => 't1', 'FILTER_BY_OP' => 'OR'}
                                                                   => get largelog responses with given region name
                                                                      or table name, any one can match

  hbase> get_largelog_responses '*', {'TABLE_NAME' => 't1', 'CLIENT_IP' => '192.163.41.53:52781', 'FILTER_BY_OP' => 'AND'}
                                                                   => get largelog responses with given region name
                                                                      and client IP address, both should match

RegionServer에서 slow/largelog 응답을 지우는 셸 명령:

각 RegionServer 또는 특정 RegionServer가 유지하는 SlowLog 응답을 지워요. 특정 RS의 서버 이름 배열을 지정하세요. 서버 이름은 RegionServer의 호스트, 포트, startcode예요. 예: host187.example.com,60020,1289493121758 (서버 이름은 master ui 또는 셸에서 detailed status를 할 때 찾을 수 있어요)

예:

  hbase> clear_slowlog_responses                                     => clears slowlog responses from all RS
  hbase> clear_slowlog_responses ['SERVER_NAME1', 'SERVER_NAME2']    => clears slowlog responses from SERVER_NAME1,
                                                                        SERVER_NAME2

시스템 테이블 hbase:slowlog에서 슬로우/라지 응답 로그 얻기 (Get Slow/Large Response Logs from System table hbase:slowlog)

위 섹션은 Admin API에 대한 세부 사항을 제공해요:

• get_slowlog_responses
• get_largelog_responses
• clear_slowlog_responses

위 모든 API는 개별 RegionServer의 온라인 인메모리 링 버퍼에 접근하고 링 버퍼에서 로그를 누적해서 최종 사용자에게 표시해요. 하지만 로그가 메모리에 저장되므로 RegionServer가 재시작된 후에는 그 RegionServer의 메모리에 들고 있던 모든 객체가 정리되고 이전 로그가 손실돼요. 모든 로그를 영원히 영속화하고 싶다면 어떨까요? 연산자가 일부 필터로 모든 과거 레코드를 얻을 수 있게 저장하고 싶다면 어떨까요? 예를 들어 user1이 트리거하고 region: cluster_test,cccccccc,1589635796466.aa45e1571d533f5ed0bb31cdccaaf9cf. 와 관련된 모든 large/slow RPC 로그를 달라고 해보세요.

시간 순서(엄격하진 않지만)대로 증가하며 이런 로그를 저장하는 시스템 테이블이 있다면, 연산자가 상세한 입력이 포함된 과거 이벤트(scan, get, put, compaction, flush 등)를 디버깅하는 데 확실히 도움이 될 거예요.

시스템 테이블이 생성되어 모든 로그 이벤트를 저장하도록 하는 설정은 hbase.regionserver.slowlog.systable.enabled예요.

이 설정의 기본값은 false예요. true로 제공하면(참고: hbase.regionserver.slowlog.buffer.enabled도 true여야 해요), 매 RegionServer에서 실행되는 cron 작업이 slow/large 로그를 hbase:slowlog 테이블에 영속화해요. 기본적으로 cron 작업은 10분마다 실행돼요. 지속 시간은 hbase.slowlog.systable.chore.duration 키로 설정할 수 있어요. 기본적으로 RegionServer는 내부 큐에 최대 1000개(hbase.regionserver.slowlog.systable.queue.size 설정 키)의 slow/large 로그를 저장하고 chore가 이 큐에서 로그를 가져와 hbase:slowlog에 배치 삽입을 수행해요.

hbase:slowlog는 단일 ColumnFamily info를 가져요. info는 get_slowlog_responses API 응답의 일부로 존재하는 것과 같은 속성인 여러 qualifier를 포함해요.

• info:call_details
• info:client_address
• info:method_name
• info:param
• info:processing_time
• info:queue_time
• info:region_name
• info:response_size
• info:server_class
• info:start_time
• info:type
• info:username

hbase:slowlog scan 결과의 2개 행 예:

\x024\xC1\x03\xE9\x04\xF5@                                  column=info:call_details, timestamp=2020-05-16T14:58:14.211Z, value=Scan(org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ScanRequest)
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:client_address, timestamp=2020-05-16T14:58:14.211Z, value=172.20.10.2:57347
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:method_name, timestamp=2020-05-16T14:58:14.211Z, value=Scan
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:param, timestamp=2020-05-16T14:58:14.211Z, value=region { type: REGION_NAME value: "hbase:meta,,1" } scan { column { family: "info" } attribute { name: "_isolationle
                                                             vel_" value: "\x5C000" } start_row: "cluster_test,33333333,99999999999999" stop_row: "cluster_test,," time_range { from: 0 to: 9223372036854775807 } max_versions: 1 cache_blocks
                                                             : true max_result_size: 2097152 reversed: true caching: 10 include_stop_row: true readType: PREAD } number_of_rows: 10 close_scanner: false client_handles_partials: true client_
                                                             handles_heartbeats: true track_scan_metrics: false
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:processing_time, timestamp=2020-05-16T14:58:14.211Z, value=18
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:queue_time, timestamp=2020-05-16T14:58:14.211Z, value=0
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:region_name, timestamp=2020-05-16T14:58:14.211Z, value=hbase:meta,,1
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:response_size, timestamp=2020-05-16T14:58:14.211Z, value=1575
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:server_class, timestamp=2020-05-16T14:58:14.211Z, value=HRegionServer
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:start_time, timestamp=2020-05-16T14:58:14.211Z, value=1589640743732
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:type, timestamp=2020-05-16T14:58:14.211Z, value=ALL
 \x024\xC1\x03\xE9\x04\xF5@                                  column=info:username, timestamp=2020-05-16T14:58:14.211Z, value=user2
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:call_details, timestamp=2020-05-16T14:59:58.764Z, value=Scan(org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ScanRequest)
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:client_address, timestamp=2020-05-16T14:59:58.764Z, value=172.20.10.2:57348
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:method_name, timestamp=2020-05-16T14:59:58.764Z, value=Scan
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:param, timestamp=2020-05-16T14:59:58.764Z, value=region { type: REGION_NAME value: "cluster_test,cccccccc,1589635796466.aa45e1571d533f5ed0bb31cdccaaf9cf." } scan { a
                                                             ttribute { name: "_isolationlevel_" value: "\x5C000" } start_row: "cccccccc" time_range { from: 0 to: 9223372036854775807 } max_versions: 1 cache_blocks: true max_result_size: 2
                                                             097152 caching: 2147483647 include_stop_row: false } number_of_rows: 2147483647 close_scanner: false client_handles_partials: true client_handles_heartbeats: true track_scan_met
                                                             rics: false
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:processing_time, timestamp=2020-05-16T14:59:58.764Z, value=24
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:queue_time, timestamp=2020-05-16T14:59:58.764Z, value=0
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:region_name, timestamp=2020-05-16T14:59:58.764Z, value=cluster_test,cccccccc,1589635796466.aa45e1571d533f5ed0bb31cdccaaf9cf.
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:response_size, timestamp=2020-05-16T14:59:58.764Z, value=211227
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:server_class, timestamp=2020-05-16T14:59:58.764Z, value=HRegionServer
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:start_time, timestamp=2020-05-16T14:59:58.764Z, value=1589640743932
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:type, timestamp=2020-05-16T14:59:58.764Z, value=ALL
 \x024\xC1\x06X\x81\xF6\xEC                                  column=info:username, timestamp=2020-05-16T14:59:58.764Z, value=user1

연산자는 ColumnValueFilter를 사용해서 region_name, username, client_address 등을 기준으로 레코드를 필터링할 수 있어요.

시간 범위 기반 쿼리도 매우 유용해요. 예:

scan 'hbase:slowlog', { TIMERANGE => [1589621394000, 1589637999999] }

블록 캐시 모니터링 (Block Cache Monitoring)

HBase 0.98부터 HBase 웹 UI에는 블록 캐시 성능을 모니터링하고 보고하는 기능이 포함돼요. 블록 캐시 보고서를 보려면 region server UI의 Block Cache 섹션을 확인하세요. 다음은 보고 기능의 몇 가지 예시예요.

Basic Info는 캐시 구현을 보여줘요.

Config는 모든 캐시 설정 옵션을 보여줘요.

Stats는 캐시 성능에 대한 통계를 보여줘요.

L1과 L2는 L1/L2 캐시에 대한 정보를 보여줘요.

이것이 가능한 모든 화면과 보고서의 전체 목록은 아니에요. 웹 UI를 살펴보세요.

스냅샷 공간 사용량 모니터링 (Snapshot Space Usage Monitoring)

HBase 0.95부터 개별 스냅샷의 사용량 정보가 HBase Master 웹 UI에 표시됐어요. HBase 1.3부터는 스냅샷 세트의 총 Storefile 크기를 표시하도록 더욱 강화됐죠. 다음 메트릭은 HBase 1.3 이상에서 Master 웹 UI에 표시돼요.

• Shared Storefile Size는 스냅샷과 활성 테이블 간에 공유되는 Storefile 크기예요.
• Mob Storefile Size는 스냅샷과 활성 테이블 간에 공유되는 Mob Storefile 크기예요.
• Archived Storefile Size는 Archive에 있는 Storefile 크기예요.

Archived Storefile Size의 형식은 NNN(MMM)이에요. NNN은 Archive에 있는 총 Storefile 크기이고, MMM은 Archive에서 그 스냅샷에 특화된(다른 스냅샷·테이블과 공유되지 않는) 총 Storefile 크기예요.

Master Snapshot Overview

Snapshot Storefile Stats Example 1

Snapshot Storefile Stats Example 2

Empty Snapshot Storfile Stats Example

Footnotes

메트릭 시스템은 HBase 0.96에서 재작업됐어요. 자세한 내용은 Elliot Clark의 Migration to the New Metrics Hotness – Metrics2를 참고하세요. ↩

더 알아보기 (Learn more)

• HBase 설정 (Configuration)
• 노드 관리 (Node Management)
• 운영 관리 (Operational Management)