이더 리움 노드 (EVM), 애플리케이션 (Geth) & amp; 스마트 계약 — 모니터링

소개 :

최근에는 기업 & amp; 금융 기관은 이더 리움 블록 체인 또는 프로덕션 애플리케이션을위한 자체 프라이빗 블록 체인에 노드를 배포하고 있습니다. Hyperledger, Ethereum 등 블록 체인에서 스마트 계약과 동일한 배포를 이해하기위한 탐구를 시작하면서 블록 체인의 일부를 구성하는 기업 노드가 제대로 모니터링되는지 확인해야 할 타당한 필요성이 있습니다. 업 / 다운뿐만 아니라 하드웨어, 소프트웨어, 애플리케이션 및 애플리케이션 경험을 모니터링하고보고 할 수 있습니다.

나는 t h 가 이러한 노드와 스마트 계약을 모니터링하는 것에 대한 내 생각에 대한 작은 문서를 작성하기에 좋은시기라고 생각했습니다. 대부분 이것은 제가 연구실에서 복잡한 블록 체인 생태계를 테스트하고 구축 할 때 후속 조치를 취할 수있는 참고 자료입니다.

이 기술이 주류가됨에 따라 기존 애플리케이션 모니터링 도구에 대한 매우 구체적인 도구와 모듈이 개발되기 시작할 것이라고 확신합니다. 그 때까지 블록 체인에서 실행되는 스마트 계약과 함께 Ethereum 노드 (EVM) 모니터링을 처리하는 데 도움이 될 수있는 몇 가지 팁과 결과가 있습니다.

내 생각은 다른 Microsoft Windows 서버 또는 Linux 서버를 모니터링하는 것과 동일한 방식으로 서버를 모니터링하는 것이었지만, 애플리케이션 (이더 리움 노드)의 상태 및 상태를 위해 서버를 폴링하는 위치에서 애플리케이션 별 구성이 변경됩니다. 현명한 계약.

하드웨어 모니터링 (VMWARE ESXI 게스트)-

테스트를 위해 Ubuntu 16.04 LTS 가상 머신을 사용하고 EVM (GETH)을 설치하여 “testnet”블록 체인에 연결했습니다. 실습 ESXi 시스템에 배포했습니다. 명심해야 할 한 가지는 모든 블록을 다운로드 할 수있는 충분한 디스크 공간이 필요하다는 것입니다. 권장하는대로 디스크 공간을 250GB로 설정했습니다. 나머지 설정은 표준이었습니다.

VMWARE ESXi는 SNMP 및 VMWARE API를 사용하는 PRTG를 통해 이미 모니터링되고 있으므로 그 부분에 대해서는 자세히 설명하지 않겠습니다.

시스템 모니터링 — (OS 수준)-

Ubuntu 서버에서 모든 SNMP 바이너리를 설치하고 시스템에 SNMP 데몬을 활성화하여 원격 폴링을 허용했습니다.

이것은 표준 구성이며 인터넷에서 매우 잘 문서화되어 있으므로 온라인에서 찾은 단계를 따르십시오.

테스트 시스템의 경우 Lab PRTG 애플리케이션을 사용하여 EVM 노드를 원격으로 모니터링했습니다. 노드 모니터링을 위해 표준 KPI를 따랐습니다. 디스크, 메모리, CPU 등. 모든 애플리케이션 서버를 모니터링하기위한 잘 정의 된 전략이 있어야하며이 EVM 노드는 그 측면에서 다르지 않습니다.

EVM (GETH 애플리케이션) 모니터링-

블록 체인에 연결할 수있는 애플리케이션의 상태를 모니터링하는 것이 설정의 다음 단계였습니다. 저는 GETH를 사용하여 “testnet”블록 체인 (testnet)에 연결했습니다. 현재 블록 체인 상태에 대한 애플리케이션에서 커스텀 트랩과 syslog를 보내는 실험을 한 후, 블록 체인의 상태를 얻기위한 마지막 기능으로 syslog를 결정했습니다. EVM이 애플리케이션 상태 수준에서 수행해야하는 작업을 수행하는지 확인하려면 두 가지 모니터링 KPI가 필요하다는 결론을 내 렸습니다.

1) GETH 프로세스가 실행 중이고 테스트 넷 블록 체인에 연결되었습니다

2) GETH 애플리케이션 로그 파일에 기록 된 모든 데이터를 가져 왔습니다.

항목 1, GETH 프로세스가 실행되고 있는지 확인하는 것은 설정이 매우 간단합니다. 모든 회사는 Windows 또는 Linux 서버에서 프로세스, 서비스 또는 데몬의 상태를 모니터링 할 수있는 다른 도구, 에이전트 또는 에이전트를 갖지 않습니다. 제 경우에는 PRTG를 사용하여 서버에 ssh하고 스크립트를 실행하기로 결정했습니다. 스크립트의 출력은 GETH 프로세스가 실행 중인지 여부를 확인하고 GETH 프로세스가 중지되면 PRTG에서 알려줍니다.

이것은 EVM 노드에 추가 한 매우 간단한 스크립트입니다. 다음 PRTG 관련 정보는 무시하지만 스크립트 형식은 아래에 설정 한 것과 유사합니다.

PRTG는 간단한 Linux SSH 센서를 사용하여 모니터링되는 노드에서 스크립트를 실행할 수 있습니다. 센서는 / var / prtg / scripts / 디렉토리에서 스크립트를 찾습니다. 디렉토리를 만든 다음 checkproc.sh라는 스크립트를 추가했습니다. PRTG 또는 원격 모니터링 도구에서 스크립트를 실행할 수있는 권한이 있는지 확인하고 두 번째로 스크립트 및 디렉터리 이름 지정 형식이 PRTG에 필요한 형식인지 확인합니다.

스크립트는 다음과 같습니다 –

dtembe @ labevmnode01 : / var / prtg / scripts $ more checkproc.sh

#! / bin / bash

# geth가 실행 중인지 확인

# -x 플래그는 이름 (또는 -f 인 경우 명령 줄

)을 가진 프로세스와 만 일치합니다.

# 개 지정됨) 패턴과 정확히 일치합니다.

pgrep -x“geth”& gt; / dev / null

다음

echo “0 : 200 : GETH is running.”

기타

echo“1 : 404 : GETH is not running.”

fi

내가 여기서하는 일은 pgrep를 실행하고 GETH가 존재하는지 확인하는 것입니다. 그렇다면 에코 프로세스가 실행되고있는 경우 PRTG가 이해할 수있는 형식입니다. echo 문을 snmptrapd 또는 logger와 같은 다른 것으로 변경하여 snmp 트랩을 통해 원격 시스템에 경고를 보내거나 로컬 / 원격 syslog 서버에 로그 할 수 있습니다.

PRTG 측에서는 스크립트를 실행하기 위해 센서를 추가했습니다 (시간 설정 가능, 재실행하는 데 5 분 선택). PRTG와 같은 도구가없는 경우 선택한 간격으로 crontab을 통해이 스크립트를 실행할 수 있습니다.

출력은 PRTG 서버가 EVM 노드를 폴링하고 GETH 프로세스를 쿼리 할 때 표시되는 내용 위에 있습니다. 프로세스가 실행 중이 아니면 센서가 경고 상태가됩니다. 이 모든 것은 필요에 따라 사용자 정의 할 수 있습니다 (센서에서 경고 대신 위험 상태가 될 수 있음).

다음 단계는 GETH가 생성하는 로그 파일에서 모든 데이터를 수집하고 있는지 확인하는 것입니다. GETH를 시작하는 데 사용하는 명령은 다음과 같습니다.

dtembe @ labevmnode01 : ~ $ geth — testnet — datadir“~ / .ethereum-testnet”— 광산 콘솔 2 & gt; & gt; ~ / .ethereum-testnet.log

그래서 내 홈 디렉토리에는 필요한 모든 블록 체인 상태 정보를 추적 할 수있는“.ethereum-testnet.log”라는 로그 파일이 있습니다. GETH 로그 파일의 데이터를 관찰 한 후 모든 데이터를 syslog 서버로 전송하기로 결정했습니다. 여기서 필터와 정규식을 사용하여 데이터를 조작 한 다음 “가상적인”NOC 또는 SOC에 맞게 데이터를 보강 할 수 있습니다.

Ubuntu 서버에서 /etc/rsyslog.conf 파일을 다음과 같이 변경합니다. 파일 맨 아래에 다음 코드 스 니펫을 추가하고 강조 표시된 부분을 특정 환경에 맞게 변경하십시오. IP 주소가있는 마지막 두 줄은 원격 syslog 서버입니다. IP 주소 앞의 @는 UDP를 나타내고 @@는 원격 syslog에 보낼 프로토콜로 TCP를 나타냅니다.

# 원격 서버에 로그를 보내는 코드 추가

# / etc / rsyslog.conf

$ ModLoad imfile

$ InputFileName /home/dtembe/.ethereum-testnet.log

$ InputFileTag ethereum-testnet

$ InputFileStateFile stat-ethereum-testnet

$ InputFileSeverity 오류

$ InputFileFacility local3

$ InputRunFileMonitor

*. * @http : //192.168.1.230

*. * @http : //192.168.1.210

rsyslog.conf를 변경하면 EVM 노드 서버에서 syslog 서비스를 다시 시작합니다.

이제 syslog에서 모든 EVM 노드 GETH 메시지를보기 시작해야합니다. 모든 syslog 메시지를 수집하는 PRTG syslog 센서를 보여줍니다. 또한 동일한 데이터를 가져 오는 PCI DSS 준수보고를 위해 ELK (WAZUH)를 실행하는 서버도 있으므로 PCI DSS 관련 보고서를보고 할 수 있습니다.

블록 체인 상태 모니터링, 채굴 해시 비율 & amp; 동료 –

EVM 노드 모니터링을 검색하는 동안 Luis Daniel Lucio Quiroz 씨의 게시물을 발견했습니다. 다음은 그의 블로그 링크, GITHUB 저장소 및 모니터링 구성에 대한 게시물입니다.

http://inside-out.xyz/technology/configure-nagios-to-monitor-your-ethereum-node.html

https://github.com/daniel-lucio/ethereum-nagios-plugins

https://github.com/daniel-lucio/ethereum-nagios-plugins/releases

나는 Quiroz 씨가 개발 한 스크립트를 사용하고 위에서 언급 한 그의 블로그에 제공된 단계를 따랐습니다. EVM 노드에 “jq”패키지를 설치했는지 확인하십시오. PRTG에 친숙해 지도록 스크립트를 편집했습니다. 변경 사항을 사용하여 다음을 구현할 수있었습니다. –

1) 블록 체인 상태를 모니터링하는 PRTG Custom Script 센서

2) 마이닝 상태를 모니터링하는 PRTG 사용자 지정 스크립트 센서

3) 마이닝 상태를 모니터링하는 PRTG 사용자 지정 스크립트 센서

모든 센서는 스크립트 작성자가 설정 한 동일한 매개 변수를 기반으로 경고하도록 설정됩니다. PRTG ssh Exe / Shell 센서에 필요한 것과 일치하도록 echo 문의 형식 만 변경했습니다.

다음 단계에서는 PCI 분석을 위해 이러한 경고를 syslog에 전달하는 두 번째 작업을 추가 할 계획입니다. 스크립트 또는 센서 작업 설정을 통해 수행 할 수 있습니다.

이 단계에서 EVM 노드, 마이닝 KPI 및 GETH 특정 프로세스 및 로그의 모든 주요 상태 표시기가 모니터링 도구로 들어옵니다.

스마트 계약 모니터링-

스마트 계약 모니터링은 내가 접근하는 방법이 적어도 두 가지가 있기 때문에 약간 모호하지만, 대부분은 현재 스마트 계약의 실제 형식과 현재 사용할 수있는 도구 / 기능에 대해 아직 배우고 있고 초보자이기 때문입니다. 우아하게하세요.

스마트 계약 작성의 모범 사례는 스마트 계약이 블록 체인에서 실행될 때 스마트 계약의 상태와 관련된 모든 이벤트를 기록해야한다고 명시합니다.

이는 스마트 계약의 원활한 실행을 보장하려는 모든 회사의 핵심입니다. 스마트 계약을 실행하는 블록 체인 (공개 또는 개인)과 도구 기능에 따라 내가하는 일을 수행하는 방법이 다르거 나 더 좋을 수 있습니다. 규제 감사를 위해 스마트 계약을 모니터링하고 데이터를 규정 준수 소프트웨어로 푸시하는 것이 중요합니다.

원격 모니터링 도구를 통해 스마트 계약을 모니터링 할 수있는 가장 좋은 방법은 다음과 같습니다. 귀하의 경우 ETH 퍼블릭 체인에서 계약을 실행할 수 있으므로 curl 또는 인증 된 API를 통해 Etherscan (https://etherscan.io)과 같은 사이트에 쿼리를 작성하고 응답을 다시 게시 할 수 있습니다. 모니터링 도구에.

주요 항목을 기억하십시오. 스마트 계약을 구축하는 개발자는 감사 기능 및 모니터링에 대한 요구 사항을 알고 있습니다.

스마트 계약 모니터링을 위해 다음 두 가지 방법을 생각했습니다.

저는 스마트 계약의 전문가 (또는 초보자 😊)가 아니기 때문에 모든 이벤트 (결과 및 오류)를 console.log에 기록하면서 스마트 계약을 복사하여 testnet 블록 체인에 배포했습니다.

그런 다음 동일한 프로세스를 사용하여 GETH 이벤트를 syslog에 푸시하고 /etc/rsyslog.conf를 편집하여 console.log를 추가 입력 파일로 포함했습니다.

# / etc / rsyslog.conf

$ ModLoad 이미지

$ InputFileName /home/dtembe/console.log

$ InputFileTag ethereum-smartcontract

$ InputFileStateFile 통계 -ethereum-smartcontract

$ InputFileSeverity 오류

$ InputFileFacility local3

$ InputRunFileMonitor

*. * @http : //192.168.1.230

*. * @http : //192.168.1.210

이로써 console.log 파일, PRTG syslog 서버 및 ELK / WAZUH 서버에 기록 된 모든 스마트 계약 이벤트를 푸시 할 수있었습니다.

이 시점에서 이러한 경고 (스마트 계약 상태)를받는 데 관심이있는 NOC 또는 SOC가있는 경우이를 필터링하고 이벤트를 강화하는 규칙을 작성하고 실시간으로 표시하거나 푸시 할 수 있습니다. 이를 ITSM 프로세스 워크 플로에 추가합니다.

알림에 사용할 수있는 형식이 있으므로 강화 된 이벤트를 가져 와서 PCI / HIPAA 규정 준수를 위해 SIEM으로 쉽게 푸시 할 수 있습니다. 실제로 PRTG syslog 센서의 동일한 경고도 WAZUH를 실행하는 ELK 스택으로 전송되었으므로 사소한 구성 변경과 PCI 준수 관련 보고서가 있습니다. 이는 현명한 계약을 사용하는 대부분의 기업에 큰 도움이 될 수 있습니다.

최종 생각-

스마트 계약 배포에 대해 더 많이 알게되면 모니터링 방법론을 변경할 것입니다. 더 많은 명령 줄 도구를 사용할 수 있으므로 Syslog 사용을 중단하고 API 또는 다른 모니터링 기능으로 이동하여이를 우아하게 수행 할 것입니다.

현재는 PRTG 설정에서 노드 대시 보드가 표시됩니다. 다시 한 번, PRTG에서 편집하고 작업 할 수있는 Nagios 모니터링 스크립트에 대해 Quiroz 씨에게 감사드립니다.

내 목록에서 가장 중요한 것은 스마트 계약 배포 및 모범 사례를 배우는 것이므로이 환경을 더 잘 모니터링하는 데 계속해서 적응할 수 있습니다.

면책 조항-

여기에 표현 된 의견은 내 의견입니다. & amp; 내 고용주의 것이 아닙니다. 다른 기술을 연구하고 배우면 내 생각과 의견이 바뀔 것입니다. 기술이 변하면 제 의견도 변합니다.

시간을내어 읽어 주셔서 감사합니다.