Kafka 클라이언트 메트릭 시작하기
Kafka를 사용하여 모니터링에는 일반적으로 토픽, 파티션, 브로커 및 이용자 그룹과 관련된 다양한 지표가 포함됩니다. 표준 Kafka 지표에는 처리량, 대기 시간, 복제 및 디스크 사용량에 대한 정보가 포함되어 있습니다. Kafka 문서 및 관련 모니터링 도구를 참조하여 Kafka 버전에 사용 가능한 특정 메트릭 및 이를 효과적으로 해석하는 방법을 이해하십시오.
Kafka 클라이언트를 모니터하는 것이 중요한 이유는 무엇입니까?
Event Streams 인스턴스 모니터링은 데이터 파이프라인의 전체 상태 및 최적의 기능을 보장하는 데 중요합니다. Kafka 클라이언트를 모니터링하면 높은 자원 사용량, 지체된 이용자 및 병목 현상과 같은 애플리케이션 장애의 초기 징후를 식별하는 데 도움이 됩니다. 이러한 경고 징후를 조기에 식별하면 가동 중단 시간을 최소화하고 비즈니스 운영 중단을 방지하는 잠재적인 문제에 사전 예방적으로 대응할 수 있습니다.
Kafka 클라이언트 (생성자 및 이용자) 에는 성능 및 상태를 모니터하기 위한 자체 메트릭 세트가 있습니다. 또한 Event Streams 서비스는 서버에서 생성되는 풍부한 메트릭 세트를 지원합니다. 자세한 정보는 IBM Cloud Monitoring 을 사용하여 Event Streams 서비스 메트릭 모니터링을 참조하십시오.
모니터할 클라이언트 메트릭
작성자 메트릭
| 메트릭 | 설명 |
|---|---|
| 레코드 오류 비율 | 이 메트릭은 오류를 발생시킨 초당 평균 보낸 레코드 수를 측정합니다. 높은 record-error-rate 또는 record-error-rate 의 증가는 데이터의 손실 또는 데이터가 예상대로 처리되지 않음을 표시할 수 있습니다. 이러한 모든 영향은 Kafka에서 처리하고 저장하는 데이터의 무결성을 손상시킬 수 있습니다. 이 메트릭을 모니터링하면 생성자가 전송하는 데이터가
Kafka 주제에 정확하고 안정적으로 기록되는지 확인하는 데 도움이 됩니다. |
| 요청-대기 시간-평균 | 이는 각 생성 요청에 대한 평균 대기 시간 (밀리초) 입니다. 대기 시간의 증가는 성능에 영향을 주며 문제를 신호할 수 있습니다. request-latency-avg 메트릭을 측정하면 인스턴스에서 병목 현상을 식별하는 데 도움이 될 수 있습니다. 많은 애플리케이션의 경우 높은 품질의 사용자 경험을 보장하기 위해 낮은 대기 시간이 중요하며 request-latency-avg 의 스파이크는 프로비저닝된 인스턴스의 한계에 도달하고 있음을 표시할 수 있습니다. 예를 들어, 성능을 최적화하기 위해 계획을 일괄처리하거나 스케일링하여 작성자 설정을 변경하여 문제를 수정할 수 있습니다. |
| 바이트 비율 | 토픽에 대해 초당 송신된 평균 바이트 수는 처리량의 척도입니다. 정기적으로 데이터를 스트리밍하는 경우 처리량의 감소는 Kafka 인스턴스에서 이상 항목을 표시할 수 있습니다. Event Streams 엔터프라이즈 플랜은 Ingress와 egress간에 초당 150MB의 일대일 분할에서 시작하며 효율적인 용량 계획을 위해 이용하는 양을 아는 것이 중요합니다. 내부 업데이트 또는 장애 모드 (예: 가용성 구역 유실) 와 같은 운영 조치의 가능한 영향을 설명하기 위해 최대 처리량의 2/3를 초과하지 마십시오. |
이용자 메트릭
| 메트릭 | 설명 |
|---|---|
| 페치 비율 페치 크기 평균 | 초당 페치 요청 수 (fetch-rate) 및 요청당 페치된 평균 바이트 수 (fetch-size-avg) 는 Kafka 이용자의 성능을 나타내는 주요 지표입니다. fetch-rate 가 높으면 데이터가 충분하지 않거나 매번 수신되는 데이터가 없음을 의미하므로 특히 적은 수의 메시지에서 비효율성을 나타낼 수 있습니다. fetch-rate 및 fetch-size-avg 는 세 가지 설정 ( fetch.min.bytes, fetch.max.bytes 및 fetch.max.wait.ms) 의 영향을 받습니다. 페치 요청 수 및 잠재적으로 브로커 CPU의 로드를 최소화하면서 원하는 전체 대기 시간을 달성하려면 이 설정을 조정하십시오. 두 메트릭을 모두 모니터링하고
최적화하면 현재 및 향후 워크로드에 대해 데이터를 효율적으로 처리할 수 있습니다. |
| commit-latency-avg | 이 메트릭은 커미트된 레코드가 전송되는 시간과 커미트 응답이 수신되는 시간 사이의 평균 시간을 측정합니다. request-latency-avg 를 생성자 메트릭으로 사용하는 것과 유사하게, 안정적인 commit-latency-avg 은 오프셋 커미트가 시기 적절한 방식으로 발생함을 의미합니다. 높은 커미트 대기 시간은 오프셋을 빠르게 커미트하지 못하게 하는 이용자의 문제점을
표시할 수 있으며, 이는 데이터 처리의 신뢰성에 직접적인 영향을 줍니다. 이용자가 이전에 커미트되지 않은 오프셋에서 메시지를 다시 시작하고 재처리해야 하는 경우 메시지의 중복 처리가 발생할 수 있습니다. 커미트 대기 시간이 길다는 것은 또한 실제 메시지 처리보다 관리 조작에 더 많은 시간을 소비하는 것을 의미합니다. 이 문제로 인해 특히 볼륨이 큰 환경에서 처리 대기 중인 메시지의 백로그가 발생할 수 있습니다. |
| 소비된 바이트 비율 | 초당 소비되는 평균 바이트 수를 측정하는 이용자 페치 메트릭입니다. byte-rate 와 유사하게 생성자 메트릭이며 안정적이고 예상되는 메트릭이어야 합니다. bytes-consumed-rate 의 예상 상태동향이 갑자기 변경되면 애플리케이션에 문제가 있을 수 있습니다. 낮은 비율은 데이터 페치 또는 초과 프로비저닝된 자원의 효율성 신호일 수 있습니다. 더 높은 비율은
이용자의 처리 기능을 압도할 수 있으므로 크기 조정이 필요하고, 더 많은 이용자를 작성하여 로드의 균형을 맞추거나 페치 크기와 같은 이용자 구성을 변경해야 합니다. |
| 시간당 재조정 비율 | 시간당 참여한 그룹 재밸런싱의 수입니다. 재밸런싱은 새 이용자가 있을 때마다 또는 이용자가 그룹을 떠나서 처리가 지연될 때마다 발생합니다. 이는 파티션이 다시 지정되기 때문에 발생합니다. 이로 인해 시간당 재밸런싱이 많은 경우 Kafka 이용자의 효율성이 낮아집니다. 잘못된 구성으로 인해 불안정한 이용자 동작이 발생하여 시간당 더 높은 리밸런싱 비율이 발생할 수 있습니다. 이러한 재조정 조치로 인해 대기 시간이 증가하고
애플리케이션 충돌이 발생할 수 있습니다. 낮고 안정적인 rebalance-rate-per-hour 를 추적하여 이용자 그룹이 안정적인지 확인하십시오. |