콘텐츠로 이동

Swarm Bee 관측 가능성 모범 사례

개요

Swarm은 이더리움 프로젝트의 공식 일부로, 주로 재단에서 개발하며, 채굴 풀의 스토리지, 대역폭 및 컴퓨팅 리소스가 이더리움 네트워크 기반 애플리케이션을 지원할 수 있도록 합니다. 팀은 다운타임 없이, 장애 제로, 검열에 강한 P2P 스토리지 및 서비스 솔루션을 만드는 것을 목표로 합니다. Swarm 내에 경제적 인센티브 시스템을 구축하여 리소스 교환 가치의 지불 및 전송을 촉진하며, 이더리움 블록체인의 다양한 프로토콜과 기술을 사용합니다. Swarm의 탈중앙화 콘텐츠 스토리지 및 배포 서비스는 CDN처럼 인터넷을 통해 컴퓨터 간에 배포할 수 있습니다. 이더리움 노드를 실행하는 것처럼 Swarm 노드를 실행하고 Swarm 네트워크에 연결할 수 있습니다. 이는 BitTorrent와 유사하며 IPFS와 비교할 수 있으며, ETH를 보상 인센티브로 사용합니다. 파일은 블록으로 분할되어 참여하는 자원봉사자들에게 할당 및 저장됩니다. 블록을 저장하고 제공하는 노드는 데이터 스토리지 및 검색 서비스를 필요로 하는 노드로부터 ETH를 보상으로 받습니다. Swarm은 채굴 방식을 사용하지 않으므로 블록 보상이 없으며, 다른 노드와의 상호 작용을 통해 보상을 받고, 상호 작용 후 수표를 받을 수 있으며, 이 수표는 BZZ로 교환할 수 있습니다. 따라서 BZZ 클러스터의 네트워크 환경과 노드 상태가 특히 중요합니다.

  • Bee

  • CPU

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

사용 사례 뷰

image.png

기본 제공 뷰

디스크

image.png

전제 조건

DataKit이 설치되어 있어야 함 ( DataKit 설치 문서)

Docker가 설치되어 있고 Docker Swarm이 초기화되어 있어야 함 ( Docker 설치 참고)

설정

Prom Exporter 설정

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

 ## Exporter 주소
  url = "http://127.0.0.1:1635/metrics"

  ## 메트릭 유형 필터, 가능한 값: counter, gauge, histogram, summary
  # 기본적으로 counter와 gauge 유형의 메트릭만 수집합니다.
  # 비어 있으면 필터링을 수행하지 않습니다.
  metric_types = ["counter", "gauge"]

  ## 메트릭 이름 필터
  # 정규식을 지원하며, 여러 개를 설정할 수 있으며, 그중 하나만 만족하면 됩니다.
  # 비어 있으면 필터링을 수행하지 않습니다.
  # metric_name_filter = ["cpu"]

  ## 메저먼트 이름 접두사
  # 이 항목을 설정하면 메저먼트 이름에 접두사를 추가할 수 있습니다.
  #  measurement_prefix = "prom_"

  ## 메저먼트 이름
  # 기본적으로 메트릭 이름을 밑줄 "_"로 분할하며, 분할된 첫 번째 필드를 메저먼트 이름으로 사용하고 나머지 필드를 현재 메트릭 이름으로 사용합니다.
  # measurement_name을 설정하면 메트릭 이름 분할을 수행하지 않습니다.
  # 최종 메저먼트 이름에는 measurement_prefix 접두사가 추가됩니다.
  # measurement_name = "prom"

  ## 수집 간격 "ns", "us" (또는 "µs"), "ms", "s", "m", "h"
  interval = "10s"

  ## TLS 설정
  tls_open = false
  # tls_ca = "/tmp/ca.crt"
  # tls_cert = "/tmp/peer.crt"
  # tls_key = "/tmp/peer.key"

  ## 사용자 정의 메저먼트 이름
  # 접두사 prefix가 포함된 메트릭을 하나의 메저먼트로 그룹화할 수 있습니다.
  # 사용자 정의 메저먼트 이름 설정은 measurement_name 설정 항목보다 우선합니다.
  #[[inputs.prom.measurements]]
  #  prefix = "cpu_"
  #  name = "cpu"

  # [[inputs.prom.measurements]]
  # prefix = "mem_"
  # name = "mem"

  ## 사용자 정의 태그
  [inputs.prom.tags]
  bee_debug_port = "1635"
  # more_tag = "some_other_value"

Swarm API 서비스 수집기 설정

Dataflux Func 설치

DataKit 변경

datakit 설치 디렉터리의 conf.d 디렉터리로 이동하여 datakit.conf 파일의 http_listen을 변경합니다. 예시는 다음과 같습니다: 

http_listen = "0.0.0.0:9529"
log = "/var/log/datakit/log"
log_level = "debug"
log_rotate = 32
gin_log = "/var/log/datakit/gin.log"
protect_mode = true
interval = "10s"
output_file = ""
default_enabled_inputs = ["cpu", "disk", "diskio", "mem", "swap", "system", "hostobject", "net", "host_processes", "docker", "container"]
install_date = 2021-05-14T05:03:35Z
enable_election = false
disable_404page = false

[dataway]
  urls = ["https://openway.dataflux.cn?token=tkn_9a49a7e9343c432eb0b99a297401c3bb"]
  timeout = "5s"
  http_proxy = ""

[http_api]
  rum_origin_ip_header = "X-Forward-For"

[global_tags]
  cluster = ""
  host = "df_solution_ecs_004"
  project = ""
  site = ""

[[black_lists]]
  hosts = []
  inputs = []

[[white_lists]]
  hosts = []
  inputs = []
저장 후 DataKit 재시작 
datakit --restart

Func 설치

DataFlux Func 종속 파일 다운로드 

/bin/bash -c "$(curl -fsSL https://t.dataflux.cn/func-portable-download)"
명령 실행이 완료되면 모든 필요한 파일이 현재 디렉터리에 새로 생성된 dataflux-func-portable 디렉터리에 저장됩니다.

다운로드한 dataflux-func-portable 디렉터리에서 다음 명령을 실행하면 자동으로 설정되고 최종적으로 전체 DataFlux Func가 시작됩니다: 

sudo /bin/bash run-portable.sh
설치 성공 
Please wait for the container to run, wait 30 seconds...
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES


Installed dir:
    /usr/local/dataflux-func
To shutdown:
    sudo docker stack remove dataflux-func
To start:
    sudo docker stack deploy dataflux-func -c /usr/local/dataflux-func/docker-stack.yaml
To uninstall:
    sudo docker stack remove dataflux-func
    sudo rm -rf /usr/local/dataflux-func
    sudo rm -f /etc/logrotate.d/dataflux-func

Now open http://<IP or Hostname>:8088/ and have fun!
http://<IP or Hostname>:8088에 접속하면 다음 화면을 볼 수 있습니다.

image.png

DataKit 데이터 소스 설정하여 데이터 업로드

image.png

스크립트 작성하여 peer 데이터 수집

image.png 

import requests


@DFF.API('peer')
def peer():
    # DataKit 작업 객체 가져오기
    datakit = DFF.SRC('datakit')
    response = requests.get("http://172.17.0.1:1635/peers")
    response_health = requests.get("http://172.17.0.1:1635/health")
    peers = response.json()
    health = response_health.json()
    res = datakit.write_metric(measurement='bee', tags={'bee_debug_port':'1635','host':'df-solution-ecs-013'}, fields={'swap_peers':len(peers["peers"]),'version':health["version"]})
    print(res, "swap_peers: ", len(peers["peers"]), "    version: ", health["version"])

DataFlux Func는 Docker Stack 방식으로 실행되어 호스트의 docker0에 브리지되며, 호스트 로컬 네트워크와 직접 연결되지 않습니다. 따라서 DataFlux Func와 DataFlux DataKit이 동일한 서버에 설치되어 있어도 DataFlux DataKit의 수신 포트를 로컬 네트워크(127.0.0.1)에 바인딩할 수 없습니다.

이 경우 설정을 수정하여 수신 포트를 docker0(172.17.0.1) 또는 0.0.0.0에 바인딩해야 합니다. 이때 swarm bee 설정을 변경하여 로컬 수신 포트 :1635 앞에 0.0.0.0을 추가해야 합니다.

API 요청을 통해 얻은 데이터를 해당 measurement에 삽입하고 적절한 태그를 추가하여 studio에서 표시할 수 있도록 합니다.

관리에서 자동 트리거 실행을 새로 생성하여 함수 스케줄링

image.png

방금 작성한 실행 함수를 선택하고 예약 작업을 설정하며, 유효 기간을 추가하고 저장을 클릭합니다.

예약 작업의 최소 간격은 1분입니다. 특별한 요구 사항이 있는 경우 while + sleep 방식을 사용하여 데이터 수집 빈도를 높일 수 있습니다.

자동 트리거 구성을 통해 함수 실행 상태 확인

image.png

성공으로 표시되면 축하드립니다! 이제 studio에서 업로드한 메트릭을 확인할 수 있습니다.

모니터링 메트릭 설명

1 Bee

여러 호스트의 Harvester를 실시간으로 모니터링하여 다양한 Harvester의 가용성, 상태 및 수익을 세밀하게 분석하고, Chia 사용자의 Harvester 제어 능력을 지속적으로 향상시킵니다.

image.png

메트릭 설명 이름 측정 기준
수신된 수표 수 bee.swap_cheques_received 수익 메트릭
거부된 수표 수 bee.swap_cheques_rejected 수익 메트릭
전송된 수표 수 bee.swap_cheques_sent 수익 메트릭
연결된 피어 수 bee.swap_peers 성능 메트릭

거부된 수표 수

일일 안정적인 수익을 보장하려면 반드시 거부된 수표 수 메트릭을 주시해야 합니다. 거부된 수표 수가 급격히 증가하는 경우, 즉시 bee 노드 및 네트워크 상태를 점검하여 일일 안정적인 수익을 보장하세요.

연결된 피어 수

수익과 네트워크 안정성을 보장하려면 연결된 피어 수를 모니터링해야 합니다. 일반적으로 네트워크 상태와 노드 상태가 정상일 때 연결된 피어 수는 일정한 범위 내에서 안정적으로 유지되며 급격한 변동이 없습니다. 연결된 피어 수에 급격한 변동이 발생하는 경우, 즉시 bee 노드 및 네트워크 상태를 점검하여 수익 안정성을 보장하세요.

2 CPU 모니터링

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

image.png

메트릭 설명 이름 측정 기준
CPU 부하 system.load1
systeml.load5
system.load15		 리소스 사용률
CPU 사용률 cpu.usage_idle
cpu.usage_user
cpu.usage_system		 리소스 사용률

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

image.png

메트릭 설명 이름 측정 기준
메모리 사용률 mem.used_percent 리소스 사용률
메모리 사용량 mem.free
mem.used		 리소스 사용률
메모리 캐시 mem.buffered 리소스 사용률
메모리 버퍼 mem.cached 리소스 사용률

메모리 사용률

사용 가능한 메모리 사용량을 면밀히 주시하는 것이 중요합니다. RAM 경합은 필연적으로 페이징 및 성능 저하로 이어지기 때문입니다. 시스템을 정상적으로 운영하려면 워크로드에 충분한 RAM이 있는지 확인하세요. 지속적인 낮은 메모리 가용성은 세그먼테이션 오류 및 기타 심각한 문제를 유발할 수 있습니다. 발생 시 시스템의 물리적 메모리 용량을 늘리거나, 가능한 경우 메모리 페이지 병합을 활성화하는 등의 개선 조치를 취하세요.

4 디스크 모니터링

image.png

메트릭 설명 이름 측정 기준
디스크 상태 disk.health
disk.pre_fail		 가용성
디스크 공간 disk.free
disk.used		 리소스 사용률
디스크 Inode disk.inodes_free
disk.inodes_used		 리소스 사용률
디스크 읽기/쓰기 diskio.read_bytes
diskio.write_bytes		 리소스 사용률
디스크 온도 disk.temperature 가용성
디스크 모델 disk.device_model 기본
디스크 읽기/쓰기 시간 diskio.read_time
disk.io.write_time		 리소스 사용률

디스크 공간

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

디스크 읽기/쓰기 시간

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

디스크 읽기/쓰기

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

디스크 온도

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

5 네트워크 모니터링

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

image.png

메트릭 설명 이름 측정 기준
네트워크 트래픽 net.bytes_recv
net.bytes_sent		 리소스 사용률
네트워크 패킷 net.packets_recv
net.packets_sent		 리소스 사용률
재전송 횟수 net.tcp_retranssegs 가용성

네트워크 트래픽

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

재전송 횟수

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

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

결론

이 문서에서는 채굴 시 태그를 유지하기 위해 모니터링할 수 있는 가장 유용한 메트릭 중 일부를 언급했습니다. 채굴 작업을 수행하는 경우 아래 목록의 메트릭을 모니터링하면 채굴장의 운영 상태와 가용성을 잘 파악할 수 있습니다:

  • 디스크 읽기/쓰기 지연 시간

  • 디스크 온도

  • 네트워크 트래픽
  • 일일 예상 수익
  • Harvester 1차 검증 통과율
  • 프로세스

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

문서 평가

이 페이지가 도움이 되었나요?