Chia Harvesters 모니터링 모범 사례¶

개요¶

Chia 사용자는 여러 호스트의 Harvester를 실시간으로 완전히 모니터링하고, 각 Harvester의 가용성, 상태 및 수익을 세부적으로 분석하여 Harvester에 대한 통제력을 지속적으로 향상시켜야 합니다. Guance는 능동 및 수동 모니터링,全域 이상 탐지 모듈을 채택하여 실제 Chia 사용자의 요구 사항과 결합, 통합된 Chia 비즈니스 관리 플랫폼을 구축합니다. 이를 통해 Chia 사용자는 Harvester의 실행 상태를 직관적으로 파악하고, 생산 효율성을 높이며, Harvester 장애나 예상 수익 부족 문제를 쉽게 해결할 수 있습니다. 또한 Chia 성능 전문가 서비스와 상주 지원 서비스를 제공하여 Chia 사용자가 더 높은 수익을 얻을 수 있도록 지원합니다. 모니터링해야 할 주요 영역은 다음과 같습니다.

• Harvester

• CPU

• 메모리
• 디스크
• 네트워크

시나리오 뷰¶

기본 제공 뷰¶

디스크¶

전제 조건¶

DataKit이 이미 설치되어 있어야 합니다. (DataKit 설치 문서)

구성¶

로그 수집¶

본 문서는 Windows 클라이언트를 기준으로 설명합니다. (Linux도 동일)

chia farm 로그 수집 스크립트 생성¶

Git이 설치되어 있어야 합니다. (Git 설치 참고)

chia-blockchain 디렉토리(C:\Users{사용자}\AppData\Local\chia-blockchain\app-{chia 버전}\resources\app.asar.unpacked\daemon)로 이동하여 로그 수집 스크립트 farmer.sh를 생성합니다. chia 클라이언트의 farm 정보를 farmer.log에 저장합니다.

먼저 C:\Users{사용자}\AppData\Local\chia-blockchain\app-{chia 버전} 에 data_collect 폴더를 생성하세요.

#!/bin/bash

while true; do
    sleep 2
    ./chia.exe farm summary  | awk '{line=line "," $0} NR%10==0{print substr(line,1); line=""}' >> ../../../data_collect/farmer.log
done

DataKit pipeline 구성¶

DataKit 설치 디렉토리 아래의 pipeline 디렉토리로 이동하여 farm_log.p와 chia_debug_log.p를 각각 생성하여 수집된 로그의 파싱을 수행합니다. 예시는 다음과 같습니다.

chai_debug_log.p¶

#chia_debug_log
#이름 설명
#strptime($timestamp, "2006-01-02T15:04:05") 
#total_plots  Plot 수
#eligible_plots   1차 필터 통과 Plot 수
#proofs_found   블록 발견 수
#check_duration  조회 시간

# 로그 예시:
#2021-04-24T11:01:53.390 harvester chia.harvester.harvester: INFO     1 plots were eligible for farming 940b588c2a... Found 0 proofs. Time: 0.98087 s. Total 19 plots


grok(_, "%{TIMESTAMP_ISO8601:strptime} harvester chia.harvester.harvester: INFO \\s+ %{NUMBER:eligible_plots} plots were eligible for farming \\w+\\.\\.\\. Found %{NUMBER:proofs_found} proofs\\. Time: %{NUMBER:check_duration} s\\. Total %{NUMBER:total_plots} plots.*")

# 숫자형 변환
cast(eligible_plots, "float")
cast(proofs_found, "float")
cast(check_duration, "float")
cast(total_plots, "float")

# 원본 내용 삭제
drop_origin_data()

farm_log.p¶

#farm_log
#이름 설명
#farming_status  farmer 상태
#xch_count  획득한 XCH
#last_farm_height  Farm 높이
#total_plot  경작 수
#total_plots_size_GiB 경작 크기
#total_plots_size_TiB 경작 크기
#total_plots_size_PiB 
#network_space   전체 네트워크 해시레이트 PiB

# 로그 예시:
#,Farming status: Farming,Total chia farmed: 0.0,User transaction fees: 0.0,Block rewards: 0.0,Last height farmed: 0,Plot count: 137,Total size of plots: 13.561 TiB,Estimated network space: 12457.266 PiB,Expected time to win: 5 months and 4 weeks,Note: log into your key using 'chia wallet show' to see rewards for each key

grok(_, ",Farming status: %{WORD:farming_status},Total chia farmed: %{NUMBER:xch_count},User transaction fees: %{NUMBER},Block rewards: %{NUMBER},Last height farmed: %{NUMBER:last_farm_height},Plot count: %{NUMBER:total_plot},Total size of plots: %{NUMBER:total_plots_size_GiB} GiB,Estimated network space: %{NUMBER:network_space_PiB} PiB.*")
grok(_, ",Farming status: %{WORD:farming_status},Total chia farmed: %{NUMBER:xch_count},User transaction fees: %{NUMBER},Block rewards: %{NUMBER},Last height farmed: %{NUMBER:last_farm_height},Plot count: %{NUMBER:total_plot},Total size of plots: %{NUMBER:total_plots_size_TiB} TiB,Estimated network space: %{NUMBER:network_space_PiB} PiB.*")
grok(_, ",Farming status: %{WORD:farming_status},Total chia farmed: %{NUMBER:xch_count},User transaction fees: %{NUMBER},Block rewards: %{NUMBER},Last height farmed: %{NUMBER:last_farm_height},Plot count: %{NUMBER:total_plot},Total size of plots: %{NUMBER:total_plots_size_PiB} PiB,Estimated network space: %{NUMBER:network_space_PiB} PiB.*")

# 숫자형 변환
cast(farming_status, "str")
cast(xch_count, "float")
cast(last_farm_height, "float")
cast(total_plot, "float")
cast(total_plots_size_GiB, "float")
cast(total_plots_size_TiB, "float")
cast(total_plots_size_PiB, "float")
cast(network_space_PiB, "float")

# 원본 내용 삭제
drop_origin_data()

DataKit 로그 수집 구성¶

DataKit 설치 디렉토리 아래의 conf.d/log 디렉토리로 이동하여 logging.conf.sample을 복사하고 이름을 logging.conf로 변경합니다. 예시는 다음과 같습니다.

두 logfiles의 경로를 사용자의 chia 로그 파일 디렉토리로 변경하세요.

[[inputs.logging]]
    # 필수, glob 로그 파일 경로
    logfiles = ['''C:\Users\Administrator\.chia\mainnet\log\debug.*''']

    # glob 필터
    ignore = [""]

    # 로깅 소스, 비워두면 'default' 사용
    source = "chia_harvester"

    # 서비스 태그 추가, 비워두면 $source 사용
    service = ""

    # grok pipeline 스크립트 경로
    pipeline = "chia_debug_log.p"

    # 선택적 상태:
    #   "emerg","alert","critical","error","warning","info","debug","OK"
    ignore_status = []

    # 선택적 인코딩:
    #    "utf-8", "utf-16le", "utf-16le", "gbk", "gb18030" 또는 ""
    character_encoding = ""

    # 패턴은 정규식이어야 합니다. '''이 정규식''' 사용에 유의하세요.
    # 정규식 링크: https://golang.org/pkg/regexp/syntax/#hdr-Syntax
    match = '''^\S'''

    [inputs.logging.tags]
    # tags1 = "value1"

[[inputs.logging]]
    # 필수, glob 로그 파일 경로
    logfiles = ['''C:\Users\Administrator\AppData\Local\chia-blockchain\app-1.1.6\data_collect\farmer.log''']

    # glob 필터
    ignore = [""]

    # 로깅 소스, 비워두면 'default' 사용
    source = "chia_farmer"

    # 서비스 태그 추가, 비워두면 $source 사용
    service = ""

    # grok pipeline 스크립트 경로
    pipeline = "farm_log.p"

    # 선택적 상태:
    #   "emerg","alert","critical","error","warning","info","debug","OK"
    ignore_status = []

    # 선택적 인코딩:
    #    "utf-8", "utf-16le", "utf-16le", "gbk", "gb18030" 또는 ""
    character_encoding = ""

    # 패턴은 정규식이어야 합니다. '''이 정규식''' 사용에 유의하세요.
    # 정규식 링크: https://golang.org/pkg/regexp/syntax/#hdr-Syntax
    match = '''^\S'''

    [inputs.logging.tags]
    # tags1 = "value1"

DataKit 재시작하여 적용¶

모니터링 메트릭 설명¶

1 Harvester¶

여러 호스트의 Harvester를 실시간으로 완전히 모니터링하고, 각 Harvester의 가용성, 상태 및 수익을 세부적으로 분석하여 Chia 사용자가 Harvester를 더 잘 통제할 수 있도록 지원합니다.

일일 예상 수익¶

매일 안정적으로 Plot을 추가하여 해시레이트 점유율을 안정적으로 유지하면 일일 예상 수익이 급격히 변동하지 않습니다. 일일 예상 수익이 빠르게 변동한다면 Harvester 노드가 오프라인 상태이거나 전체 네트워크 해시레이트가 급격히 증가하여 해시레이트 점유율이 너무 낮아진 것은 아닌지 주의해야 합니다. 일일 예상 수익을 지속적으로 모니터링하고 알림을 설정하여 수익의 안정성을 보장하는 것이 좋습니다.

Harvester 1차 필터 통과율¶

수익 안정성을 보장하려면 Harvester의 1차 필터 통과 수를 모니터링해야 합니다. 일반적으로 네트워크 상태와 디스크 상태가 모두 정상이면 Harvester 1차 필터 통과율은 일정 범위 내에서 안정적으로 유지되며 급격한 변동이 없습니다. Harvester 1차 필터 통과율이 급격히 변동하는 경우 디스크 및 네트워크 상태를 신속히 확인하여 수익 안정성을 보장하세요.

평균 챌린지 조회 시간¶

Harvester의 평균 챌린지 조회 시간을 지속적으로 모니터링하고 알림을 설정하여 각 Harvester의 조회 시간이 5초를 초과하지 않도록 하세요. 5초 이상 발견되면 네트워크 정보 또는 디스크 정보를 신속히 확인하여 수익 안정성을 보장하세요.

2 CPU 모니터링¶

CPU 모니터링은 CPU 부하 피크를 분석하고 과도한 CPU 사용 활동을 식별하는 데 도움이 됩니다. CPU 모니터링 메트릭을 통해 CPU 성능을 개선하거나 부하를 줄이고, 잠재적인 문제를 찾아내며 불필요한 업그레이드로 인한 과도한 비용을 방지할 수 있습니다. CPU 모니터링 메트릭은 실행 중인 불필요한 백그라운드 프로세스를 식별하고, 프로세스 또는 애플리케이션의 리소스 사용률과 전체 네트워크에 미치는 영향을 파악하는 데도 도움이 됩니다.

CPU 사용률¶

CPU 사용률은 User Time(사용자 프로세스 실행 시간 백분율), System Time(커널 프로세스 및 인터럽트 실행 시간 백분율), Idle Time(CPU 유휴 상태 시간 백분율)로 구분됩니다. CPU 성능 측면에서 각 CPU의 실행 큐는 3을 초과하지 않아야 합니다. 또한 CPU가 최대 부하 상태인 경우 User Time은 65%~70%, System Time은 30%~35%, Idle Time은 0%~5%여야 합니다.

3 메모리 모니터링¶

메모리는 Linux 성능에 영향을 미치는 주요 요소 중 하나이며, 메모리 리소스의 충분 여부는 애플리케이션 시스템의 사용 성능에 직접적인 영향을 미칩니다.

메모리 사용률¶

사용 가능한 메모리 사용량을 면밀히 모니터링하는 것이 중요합니다. RAM 경합은 필연적으로 페이징 및 성능 저하로 이어지기 때문입니다. 시스템을 정상적으로 작동시키려면 워크로드에 충분한 RAM이 있는지 확인하세요. 지속적으로 낮은 메모리 가용성은 세그멘테이션 오류 및 기타 심각한 문제를 유발할 수 있습니다. 이러한 경우 해결 방법으로 시스템의 물리적 메모리 용량을 늘리거나, 가능하다면 메모리 페이지 병합을 활성화하세요.

4 디스크 모니터링¶

디스크 공간¶

모든 운영 체제에서 충분한 여유 디스크 공간을 유지하는 것은 필수적입니다. 일반 프로세스 외에도 핵심 시스템 프로세스는 로그 및 기타 유형의 데이터를 디스크에 저장합니다. 사용 가능한 디스크 공간이 15% 미만으로 떨어지면 알림을 보내도록 알림을 구성하여 비즈니스 연속성을 보장할 수 있습니다.

디스크 읽기/쓰기 시간¶

이 메트릭은 디스크 읽기/쓰기 작업에 소요된 평균 시간을 추적합니다. 50밀리초보다 큰 값은 상대적으로 높은 지연 시간을 나타내므로 경고를 설정할 수 있습니다(일반적으로 10밀리초 미만이 가장 좋습니다). 일반적으로 더 빠른 디스크로 비즈니스 작업을 이동하여 지연 시간을 줄이는 것이 좋습니다. 서버 역할에 따라 다른 경고 값을 설정할 수 있으며, 역할마다 허용 가능한 임계값이 다릅니다.

디스크 읽기/쓰기¶

서버에서 요구 사항이 높은 애플리케이션을 호스팅하는 경우 디스크 I/O 속도를 모니터링하는 것이 좋습니다. 디스크 읽기/쓰기 메트릭은 디스크 레이블별 읽기(diskio.read_bytes) 및 쓰기(diskio.write_bytes) 활동의 집계입니다. 지속적인 높은 디스크 활동은 서비스 저하 및 시스템 불안정을 유발할 수 있으며, 특히 높은 RAM과 페이지 파일을 동시에 사용할 때 더욱 그렇습니다. 높은 디스크 활동이 발생하는 경우 사용 중인 디스크 수를 늘리고(특히 큐에 많은 작업이 있을 때), 더 빠른 디스크를 사용하며, 파일 시스템 캐시용으로 예약된 RAM을 늘리고, 가능하다면 작업 부하를 더 많은 시스템에 분산하는 것이 좋습니다.

디스크 온도¶

비즈니스에서 디스크 가용성 요구 사항이 매우 높은 경우 디스크 작동 온도를 모니터링하는 경고를 설정할 수 있습니다. 온도가 65℃(SSD의 경우 75℃ 이상)를 초과하면 주의해야 합니다. 디스크에 과열 보호 또는 온도 제어 메커니즘이 있는 경우 특히 주의하세요. 디스크 온도가 계속 상승하면 디스크가 손상되어 비즈니스 데이터가 손실될 수 있습니다.

5 네트워크 모니터링¶

애플리케이션과 인프라 구성 요소는 점점 더 복잡한 아키텍처로 서로 의존하고 있습니다. 모놀리식 애플리케이션을 실행하든 마이크로서비스를 실행하든, 클라우드 인프라, 프라이빗 데이터 센터 또는 둘 다에 배포하는지 여부에 관계없이 마찬가지입니다. 가상화 인프라는 개발자가 모든 규모에 대응할 수 있도록 하고 기존 네트워크 모니터링 도구와 잘 맞지 않는 동적 네트워크 패턴을 생성합니다. 환경의 모든 구성 요소와 이들 간의 모든 연결에 대한 가시성을 제공하기 위해 Guance는 클라우드 시대를 위한 네트워크 성능 모니터링을 도입했습니다.

네트워크 트래픽¶

이 두 메트릭은 함께 특정 네트워크 인터페이스의 총 네트워크 처리량을 측정합니다. 대부분의 소비자 하드웨어의 경우 NIC 전송 속도는 초당 1GB 이상이므로 가장 극단적인 경우를 제외하고 네트워크가 병목 현상이 될 가능성은 낮습니다. 인터페이스 대역폭의 80% 이상을 사용할 때 네트워크 포화를 방지하기 위해 알림을 보내도록 경고를 설정할 수 있습니다(1Gbps 링크의 경우 초당 100MB에 해당).

재전송 횟수¶

TCP 재전송은 자주 발생하지만 오류는 아닙니다. 그러나 재전송의 존재는 문제의 징후일 수 있습니다. 재전송은 일반적으로 네트워크 혼잡의 결과이며 높은 대역폭 소비와 관련이 있는 경우가 많습니다. 과도한 재전송은 애플리케이션에 심각한 지연을 유발할 수 있으므로 이 메트릭을 모니터링해야 합니다. 재전송을 보낸 발신자가 전송된 패킷에 대한 확인을 받지 못하면 더 많은 패킷 전송을 지연시켜(일반적으로 약 1초) 지연 시간을 증가시키고 혼잡 관련 속도를 저하시킵니다.

네트워크 혼잡으로 인한 것이 아니라면 재전송의 원인은 네트워크 하드웨어 결함일 수 있습니다. 드롭된 패킷 수는 적지만 재전송 속도가 높으면 과도한 버퍼링이 발생할 수 있습니다. 원인이 무엇이든 이 메트릭을 추적하여 네트워크 애플리케이션 응답 시간에서 무작위로 보이는 변동을 이해해야 합니다.

결론¶

이 문서에서는 채굴 시 태그를 유지하기 위해 모니터링할 수 있는 가장 유용한 메트릭 몇 가지를 언급했습니다. 채굴 작업을 수행 중이라면 아래 목록의 메트릭을 모니터링하여 채굴장의 운영 상태와 가용성에 대한 좋은 통찰력을 얻을 수 있습니다.

• 디스크 읽기/쓰기 지연 시간
• 디스크 온도
• 네트워크 트래픽
• 일일 예상 수익
• Harvester 1차 필터 통과율
• 프로세스

궁극적으로 사용자 고유의 사용 사례와 특히 관련된 다른 메트릭을 인식하게 될 것입니다. 물론 Guance을 통해 더 많은 내용을 알아볼 수 있습니다.