OpenCloud

최근에 nGrinder를 통해 부하테스트를 할일이 급하게 생겼다.

jMeter는 다운받으면 바로 실행가능하지만, nGrinder는 컨트롤 서버와 에이전트가 구분되어 있다.
Docker가 지원되어서 한결 쉽게 설치 가능합다.

1. 일단 CentOS 7기반의 VM 3개를 띄운다.(서버용 1대, 에이전트용 2대 (원하는 만큼))

2. 아래 커맨드로 각 서버에 모두 docker를 설치한다.

   sudo yum install -y yum-utils device-mapper-persistent-data lvm2
   sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
   sudo yum install -y docker-ce docker-ce-cli containerd.io
   sudo systemctl enable docker
   sudo systemctl start docker

3. 컨트롤 서버용 nGrinder 컨테이너 1대 먼저 설치

   docker pull ngrinder/controller:3.4
   docker run -d -v ~/ngrinder-controller:/opt/ngrinder-controller -p 80:80 -p 16001:16001 -p 12000-12009:12000-12009 ngrinder/controller:3.4

4. 에이전트용 2대에 각각 설치 ( CONTROL_SERVER_IP는 3번의 VM IP 사용 )

   docker pull ngrinder/agent:3.4
   docker run -v ~/ngrinder-agent:/opt/ngrinder-agent -d ngrinder/agent:3.4 CONTROL_SERVER_IP:80

5. 웹으로 CONTROL_SERVER_IP로 접속하면 끝

IPMI CLI의 경우 서버 자체에서 실행시 Admin으로 실행이 된다. (인증 정보를 묻지 않음)
네트워크(ipmilan)을 통해서 Admin으로 실행 시키기 위해서 root의 권한을 변경해보자.
(Softlayer의 IPMI에서 root는 일반 유저(Operator) 권한이다)

Windows (IPMICFG는 Supermicro 홈페이지에서 다운.)

IPMICFG-Win.exe -user list  
IPMICFG-Win.exe -user level 3 4

Linux

ipmitool user list 1  
ipmitool channel setaccess 1 3 privilege=4

편향적인 내용으로 당연히 절대 평가는 되지 않습니다. 상황에 맞게 써야 하며, 특성을 참고하는데 도움은 됩니다.

원문: https://bitworking.org/news/2017/03/prometheus

우리는 모든 모니터링을 InfluxDB 에서 Prometheus로 마이그레이션하는 작업을 끝내 었습니다. 변화에 대한 이유를 적어 두었 습니다. 이 내용은 저의 개인적인 관찰이며 특정 프로젝트와 관련이 있습니다. 이러한 문제는 귀하에게 적용되지 않을 수 있으며 각 제품을 귀하 자신의 용도로 평가해야합니다.

업데이트 : 명확히하기 위해 InfluxDB와 Prometheus의 버전은 InfluxDB 1.1.1과 Prometheus 1.5.2입니다.

Push vs Pull

InfluxDBInfluxDB는 Push 기반 시스템입니다. 즉, 실행중인 응용 프로그램이 데이터를 모니터링 시스템에 적극적으로 Push해야합니다. Prometheus는 Pull 기반 시스템이며, Prometheus 서버는 주기적으로 실행중인 응용 프로그램에서 메트릭 값을 가져옵니다.

Prometheus로 폴링하는 방법을 중앙에서 제어 할 수 있기 때문에 Prometheus 서버의 구성을 조정하는 것만으로 매분마다 폴링을 전환 할 수 있습니다. InfluxDB를 사용하면 메트릭을 얼마나 자주 Push해야하는지에 대한 변경으로 모든 애플리케이션을 재배포해야합니다. 또한 Prometheus pull 메서드를 사용하면 Prometheus가 응용 프로그램의 실행 여부를 모니터링하는 합성 "UP"메트릭을 만들고 제공 할 수 있습니다. 수명이 짧은 애플리케이션의 경우 Prometheus에는 푸시 게이트웨이가 있습니다.

데이터 저장소

InfluxDB는 메트릭 값과 인덱스 모두에 대해 모 놀리 식 데이터베이스를 사용합니다. Prometheus는 지표에 대해 LevelDB를 사용하지만 각 측정 항목은 자체 파일에 저장됩니다.

둘 다 키 / 값 데이터 저장소를 사용하지만 키 스토어를 사용하는 방법은 매우 다르며 제품의 성능에 영향을 미칩니다. InfluxDB는 느린 속도 였고 똑같은 측정법으로 Prometheus보다 훨씬 많은 디스크 공간을 차지했습니다. InfluxDB를 시작하고 그로 인해 측정 된 데이터의 수가 적 으면 데이터 저장소가 1GB로 증가한 다음 Prometheus가 모든 측정 항목을 사용하여 아직 10GB를 크랙하지 않은 채로 전체 측정 항목에 대해 데이터 저장소를 100GB까지 빠르게 확장했습니다. . InfluxDB가 우리가 실행하고 있던 InfluxDB 버전을 업그레이드하려는 시도가 실패하거나 실패했을 때 InfluxDB가 모든 데이터를 잃어 버렸습니다.

업데이트 : Prometheus는 몇 초 만에 시작되는 반면, InfluxDB는 색인을 유효화하거나 다시 작성하는 동안 정기적으로 5 분이 걸리고 전체 프로세스 중에 데이터를 수집하지 않는 등 시작 시간에 관한 또 다른 데이터 저장소 관련 문제가 있음을 상기했습니다.

CPU

아마도 데이터 저장소의 효율성과 밀접한 관련이있는 InfluxDB는 실행중인 서버를 최대한으로 늘려 가고 있었지만 Prometheus는 동일한 인스턴스에서 최대 0.2 개의로드를 넘었습니다.

검색어 언어

InfluxDB는 SQL의 변형을 사용합니다. Prometheus는 실질적으로 보다 간단하고 직접적인 쿼리 모델을 사용합니다.

무엇을 입력 하시겠습니까?

SELECT * FROM "cpu_load_short" WHERE "value" > 0.9

또는

cpu_load_short > 0.9

설정

InfluxDB : 설정 파일 & SQL 명령의 혼합

Prometheus : 텍스트 파일 사용

Prometheus 설정은 간단히 YAML 파일이며, 전체 설정은 파일을 통해 이루어진다. InfluxDB를 사용하면 예를 들어 메트릭스를 저장할 명명된 데이터베이스를 생성하는 등의 구성 중 일부가 실제로 수행되는 것을 우려해야 한다. 또한 Prometheus는 15일 동안만 데이터를 저장하는 것이 기본이고, InfluxDB는 모든 데이터를 영구적으로 저장하는 것이 기본이며, 모든 데이터를 영구적으로 저장하지 않으려면 데이터가 보존되는 방법을 제어하기 위해 서버로 전송하는 SQL 명령을 생성해야 한다.