개요
마크베이스 네오는 데이터 수집부터, 저장, 추출, 가시화까지 모두 가지고 있는 통합형 시계열 데이터베이스이다. 특히, 시계열 데이터베이스의 특성상 특정한 포인트로부터 주기적으로 그 상태를 표현하는 센서류 그리고, IT 영역에서는 메트릭으로 불리는 시스템 리소스를 저장, 관리하는 데에 있어서 탁월하다.
대중적으로는 시각화 도구인 그라파나를 통해 구축을 많이 하고 있으며, 이 방법도 장점을 가지고 있다. 그러나, 대량의 데이터에 대한 처리 이슈가 발생하는 경우 이 조차도 성능 이슈로 인해 일부분만 모니터링 할 수 밖에 없거나, 데이터베이스 엔진과 시각화도구가 나뉘어져 관리 및 성능상의 불편함도 있기 때문에 마크베이스 네오와 같은 통합형 구조 구축을 통해 서로 장단점을 파악해 보는 것도 큰 의미가 있을 것 같다.
그런 이유로 대쉬보드가 지원되는 마크베이스 최신 버젼을 기반으로 실제 컴퓨터의 리소스 활용량을 실시간으로 수집하고, 알람 처리를 수행하는 서비스를 구축해 보도록 하겠다. 이 개발과정에 대한 글을 건너뛰고, 단지 모니터링 구축만 하고 싶을 경우에는 맨 아래 빠른 구축 방법에 대한 섹션을 참고하기 바란다.
<네오를 이용한 간단한 시스템 모니터링 화면>
메트릭 데이터 수집
일반 서버 혹은 개인용 컴퓨터에서 대표적으로 수집하는 리소스는 다음과 같다.
CPU 사용량 (%)
디스크 사용량 (GB)
디스크 여유분 (GB)
네트워크 트래픽 인바운드 (bytes/sec)
네트워크 트래픽 아웃바운드 (bytes/sec)
물론 IDC 센터와 같은 곳은 해당 공간의 습도나 온도, 소음, 전력 사용량, 순간 전력 최대 Peak 등을 측정하겠지만, 데모 측면에서 일반 서버 관점에서 필요한 정보를 소규모로 모으는 것으로 충분할 것이다.
문제는 이 메트릭을 어떻게 수집하느냐이다. 물론 데이터 수집을 위해 telegraf와 같은 전용 오픈 소스들도 있고, 여러 다양한 수집 솔루션들이 있지만, 여기에서는 가장 간단한 파이썬 코드를 통해 여러 운영체제에서 잘 동작하면서, 필요한 메트릭을 수집하는 방법을 채택해 본다.
데이터 수집 에이전트 설계
수집 에이전트는 간단하게 파이썬으로 작성할 수 있다.
그렇지만, 학습하는 유저를 위해 두 종류의 수집 에이전트를 준비했고, JSON 타입과 TQL 타입이라고 부른다.
JSON 타입
수집된 메트릭 데이터를 마크베이스 네오의 DBMS 엔진에 직접 입력하는 방식
입력 방법은 INSERT가 아닌, APPEND 방식으로서 빠르게 입력하도록 함.
단점은 데이터 입력전에 미리 조치를 할 수 없으며, 데이터가 입력된 이후 다시 추출하여 처리를 해야함.
알람의 경우 입력된 데이터를 다시 읽어서 특정 상황인지 검사할 수 있음. (구현하지 않음)
TQL 타입
수집된 메트릭 데이터를 마크베이스 네오의 TQL로 CSV 형태로 입력
입력을 받은 TQL은 데이터베이스에 입력하기 전 다양한 처리를 할 수 있음.
알람의 경우 입력된 메트릭이 CPU이고, 사용률이 10%를 넘는 경우 별도의 로그 테이블에 알람 정보 데이터를 입력 (구현됨)
이후 데이터베이스에 데이터를 입력하되, APPEND 형태로 빠르게 처리함.
에이전트는 두 종류이지만, 데이터를 수집하는 핵심 코드는 공유하도록 하였으며, 아래와 같은 소스코드 형태로 구성하였다. (github에 공개되어 있다)
agent_core.py : 수집 코어 라이브러리
run-agent-json.py : 수집 및 JSON으로 데이터베이스로 직접 입력하는 메인코드
run-agent-tql.py : 수집 및 CSV를 통해 TQL로 입력하는 메인 코드
구체적으로는 수집되는 메트릭은 다음과 같다. 참고로 아래의 디스크와 네트워크는 모든 장비의 총합으로 나타난다. 만일 개별적인 장치를 지정하고자 할 때에는 소스코드를 수정하면 될 것이다.
Tag 명 (Prefix) | 설명 |
CPU-{장비명} | CPU 사용률 (%) |
DT-{장비명} | 디스크 크기 (Bytes) |
DU-{장비명} | 디스크 사용량 (Bytes) |
DR-{장비명} | 디스크 남은 공간 (Bytes) |
NI-{장비명} | 네트워크 인바운드 (Bytes) |
NO-{장비명} | 네트워크 아웃바운드 (Bytes) |
따라서, 모니터링 할 장비당 6개의 메트릭이 자동으로 생성되고, 지정된 시간 주기마다 해당 값이 지속적으로 생성, 데이터베이스로 전송될 것이다.
에이전트 실행하기
JSON 에이전트
옵션 살펴보기
$ python3 run-agent-json.py -h
usage: run-agent-json.py [-h] [--ip_address IP_ADDRESS] [--interval INTERVAL] [--servername SERVERNAME]
[--debug DEBUG]
url tablename
System Statistics Collector
positional arguments:
url NEO-URL (e.g., http://host:port)
tablename Table name for data storage
options:
-h, --help show this help message and exit
--ip_address IP_ADDRESS
IP Address prefix to filter (default: "")
--interval INTERVAL Interval between posts in seconds (default: 3)
--servername SERVERNAME
servername
--debug DEBUG debuggingurl (필수) : 이는 네오 데이터베이스를 접근하는 URL이며, 일반적으로 테스트시에는 http://127.0.0.1:5654 으로 지정한다.
tablename(필수) : 이는 앞에서 생성한 메트릭 저장을 위한 태그 테이블명을 지정한다. (monitoring)
--ip_address : 장비명 생성시 사용할 IP 주소의 prefix를 지정한다. 지정하지 않으면, 192. 으로 시작하는 것의 첫번째 장치 주소로 이름으로 생성된다.
--interval : 수집주기를 지정하며, 디폴트는 3초이다.
--servername : 이는 장비명을 강제로 지정한다. 자신만이 알아볼 수 있는 이름이 편할 경우 이 옵션을 사용한다.
--debug : 부가 정보를 화면에 더 출력하는 경우 사용한다.
리눅스에서 실행하기
리눅스에서 실행하는 경우 아래와 같이 화면에 출력되면 정상이다.
이 환경에서는 네오 서버의 주소는 127.0.0.1이고, 포트는 5654, 그리고, 테이블명은 monitoring이며, 서버의 이름은 linux로 지정했다.
$ python3 run-agent-json.py http://127.0.0.1:5654 monitoring --servername linux
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-linux', 1713667837, 0.0], ['DU-linux', 1713667837, 154169008128], ['DT-linux', 1713667837, 538854957056], ['DR-linux', 1713667837, 384685948928], ['NI-linux', 1713667837, 0], ['NO-linux', 1713667837, 0]]}}
{'success': True, 'reason': 'success, 6 record(s) appended', 'elapse': '2.630386ms'}
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-linux', 1713667841, 0.0], ['DU-linux', 1713667841, 154169008128], ['DT-linux', 1713667841, 538854957056], ['DR-linux', 1713667841, 384685948928], ['NI-linux', 1713667841, 1245], ['NO-linux', 1713667841, 1245]]}}
{'success': True, 'reason': 'success, 6 record(s) appended', 'elapse': '7.586805ms'}
......위와 같이 출력되면, 성공적으로 데이터를 수집하기 시작한 것이다. 그러면, 데이터베이스의 결과를 잠깐 살펴보자.
아래 질의를 수행한 경우 다음과 같다.
select * from monitoring order by name, time;
위와 같이 정상적으로 수집된 것을 볼 수 있다.
윈도우에서 실행하기
C:\Temp> python3 run-agent-json.py http://127.0.0.1:5654 monitoring --servername windows윈도우의 경우도 동일한 소스코드로 장비명을 제외하고는 동일하게 데이터를 수집할 수 있다.
이상 상황 감지 및 알람 구축
개요
모니터링 시스템을 구축하는 가장 큰 이유는 비정상 상황을 예측하거나, 발생시 빠른 시간내에 조치를 취하기 위함이다. 이런 비정상 상황의 감지는 일반적으로 특정 메트릭의 값 범위가 지정한 값 초과 혹은 미만일 경우에 발생하도록 되어 있으며, 최근 들어 AI를 통한 비정형 이상 탐지도 가능하게 되었다.
이 글에서는 특정 범위를 벗어나는 경우에 대해서만 구현을 하였으며, 이 방법에 있어서도 크게 두 종류의 접근법이 존재한다.
Post-processing 방식
동작
이 방식은 데이터 발생시 저장공간에 모두 모은 후에, 그 저장공간에 대해 주기적으로 Polling 형태로 검사하는 방식이다.
장단점
검사 주기가 짧을 수록 더 빨리 이상을 감지하지만, 시스템의 부하는 많아진다. 반면, 검사 주기를 길게 하면 시스템의 부하는 낮아지지만, 이상을 감지하는 주기가 더 늦어질 수 있다.
Pre-processing 방식
동작 이 방식은 데이터를 저장 공간에 입력하기 이전에 검사하고, 이상이 있을 경우 조치 후 저장, 없을 경우에는 그냥 저장하는 방식이다.
장단점
이 방식은 Polling을 하지 않기 때문에 이상 상황이 가장 빠른 시간에 탐지가 가능하다. 그러나, 입력되는 데이터량이 시스템이 처리할 수 있는 범위를 넘을 경우에는 전체적인 처리 성능이 저하되는 문제가 있다.
이 예제에서는 마크베이스 네오가 제공하는 TQL의 장점을 활용할 수 있도록, Pre-processing 방식으로 이상 상황을 감지하는 코드를 만들어 본다.
append.tql
코드 설명
수집 에이전트 run-agent-tql.py가 Rest API POST 형태로 데이터를 전송하면, 그 데이터를 받은 append.tql이 알람 검사를 수행한 후 데이터베이스에 데이터를 입력하는 코드이다.
CSV(payload())
MAPVALUE(1, parseFloat(value(1)) * 1000000000)
MAPVALUE(2, parseFloat(value(2)))
WHEN(glob("CPU-*", value(0)) && value(2) > 10,
do( value(0), value(1), value(2), {
ARGS()
MAPVALUE(3, strSprintf("CPU overheating..: more than %.1f", 10))
INSERT("name", "time", "value", "desc", table("alarm_history"))
}
)
)
APPEND(table(param('table') ?? 'monitoring'))CSV(payload())
이 라인은 HTTP 프로토콜로 도착한 CSV 형태의 데이터를 읽고, 하나씩 다음 코드로 pipelining을 한다. 3개의 컬럼으로 name, time, value 로 구성되며, 각각 value(번호) 형태로 접근 가능하다.
MAPVALUE(1..) : 이는 도착한 시간이 second 형태이기에 네오가 처리할 수 있는 nano second 형태로 변환하기 위해 10억을 곱하는 라인이다.
MAPVALUE(2..) : 이 라인은 값으로 도착한 value(2)는 스트링 타입이기 때문에 이를 명시적으로 64비트 실수로 변환하는 코드이다.
WHEN(..) : 이 라인이 핵심이다.
glob() : 이 라인은 실제 태그명 value(0)이 "CPU-"로 시작하는 것들에 대해서 검사하겠다는 것이고, 그럴 경우 실제 CPU 사용률이 10보다 큰 경우 알람으로 간주하겠다는 의미이다. 이 값 10을 원하는 수준으로 고치거나, 범위를 주기 위해 ( value(2) < 10 && vlaue(2) > 90) 이렇게 조건을 변경할 수도 있다.
do() : 위 glob()의 조건이 True일 경우에 수행되는 영역이다. 즉, 알람이 발생한 경우 무엇을 할 것인지에 대한 라인이다.
위와 같이 알람이 발생한 경우에는 해당 정보를 로그 데이터 전용인 alarm_history 로그 테이블에 레코드를 하나 입력하도록 하였다. 마지막 인자인 value(3)는 strSprintf() 함수를 통해 부가 설명 정보를 생성하도록 하였다.
APPEND() : 해당 CSV를 테이블에 고속으로 입력한다.
param() 함수는 사용자가 URL에서 ?name=value 형태로 name을 통해 해당 값을 가져오는 함수이다.
위에서는 table 이라는 이름의 값을 가져오며, 만일 사용자가 table을 지정하지 않았을 경우 디폴트로 'monitoring' 테이블을 이용하도록 하였다.
추가 논의
이 append.tql의 확장을 위해 아래와 같은 추가 가능성에 대해 기술하고, 필요한 경우 직접 구현할 수 있도록 설명한다.
이상 감지된 데이터를 태그 테이블에 넣지 않고 싶을 경우
이상 데이터는 특수한 경우 노이즈일 경우도 많기에 수정 불가능한 태그 테이블에 입력하지 않을 경우에는 TQL에서 제공하는 FILTER() 함수를 사용한다.
FILTER() 함수는 조건에 맞는 것만 진행시키고, 그렇지 않으면, 데이터를 버린다.
만일 위의 조건처럼 알람으로 감지된 경우에 데이터를 저장하지 않는 코드는 다음과 같다.
CSV(payload())
MAPVALUE(1, parseFloat(value(1)) * 1000000000)
MAPVALUE(2, parseFloat(value(2)))
WHEN(glob("CPU-*", value(0)) && value(2) > 10,
do( value(0), value(1), value(2), {
ARGS()
MAPVALUE(3, strSprintf("CPU overheating..: more than %.1f", 10))
INSERT("name", "time", "value", "desc", table("alarm_history"))
}
)
)
FILTER( !( value(2) > 10) )
APPEND(table(param('table') ?? 'monitoring'))이상 감지된 데이터를 테이블에 저장하는 대신 Rest API의 URL로 데이터를 전송하는 경우
이를 위해 doHttp() 함수가 존재한다. 아래는 특정 URL로 GET/POST으로 데이터를 전송하는 예제이다. (더 자세한 내용은 여기를 참조하자)
HTTP 함수
doHttp("GET", strSprintf("http://127.0.0.1:5654/db/tql/alarm-input-get.tql? name=%s&time=%f&value=%f",value(0), value(1), value(2)), nil )
doHttp("POST", strSprintf("http://127.0.0.1:5654/db/tql/alarm-input-post.tql"), strSprintf(`%s,%.0f,%.0f`, value(0), value(1), value(2)), "Content-Type: text/csv", "X-Custom-Header: notification" )
TQL 에이전트 실행하기
리눅스와 윈도우 모두 동일하지만, URL을 지정할 때 적절한 위치의 append.tql을 지정해야 한다.
github에 있는 소스코드를 네오에서 직접 다운로드 했을 경우 아래와 같이 수행하면 된다.
$ python3 run-agent-tql.py http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql monitoring --servername linux수행 화면은 아래와 같은데, 출력이 CSV 형태로 바뀌어져서 전송된다는 점이 다르다. 아래의 ### 기호는 JSON에서 CSV로 변환되는 디버깅 정보이므로 참조만 하자.
$ python3 run-agent-tql.py http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql monitoring --servername linux
http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql?table=monitoring
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-linux', 1713673816, 0.0], ['DU-linux', 1713673816, 154170302464], ['DT-linux', 1713673816, 538854957056], ['DR-linux', 1713673816, 384684654592], ['NI-linux', 1713673816, 0], ['NO-linux', 1713673816, 0]]}}
###
CPU-linux,1713673816,0.0
DU-linux,1713673816,154170302464
DT-linux,1713673816,538854957056
DR-linux,1713673816,384684654592
NI-linux,1713673816,0
NO-linux,1713673816,0
{'success': True, 'reason': 'success', 'elapse': '6.961687ms', 'data': {'message': 'append 6 rows (success 6, fail 0)'}}
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-linux', 1713673820, 0.1], ['DU-linux', 1713673820, 154170302464], ['DT-linux', 1713673820, 538854957056], ['DR-linux', 1713673820, 384684654592], ['NI-linux', 1713673820, 1156], ['NO-linux', 1713673820, 1156]]}}
###
CPU-linux,1713673820,0.1
DU-linux,1713673820,154170302464
DT-linux,1713673820,538854957056
DR-linux,1713673820,384684654592
NI-linux,1713673820,1156
NO-linux,1713673820,1156
{'success': True, 'reason': 'success', 'elapse': '2.676484ms', 'data': {'message': 'append 6 rows (success 6, fail 0)'}}이제 데이터를 수집하는 작업이 완료되었다. 이제 화면에 출력하는 대시보드를 구축해 보자.
대쉬보드 만들기
대시보드 생성하기
네오의 탭에서 +를 누르면, 아래의 메뉴 리스트가 나타나는데, 이때 DASHBOARD 버튼을 누르면, 빈 대시보드가 나타난다.
초기 대시보드 화면에서 차트 생성하기
아래가 초기 대시보드 화면이고, Create New Panel을 누르면, 추가할 수 있는 차트 수정 화면으로 들어간다.
이제 차트를 추가할 수 있다.
CPU Usage
아래와 같이 Line 차트를 설정하고, 테이블명과 태그명을 아래와 같이 선택하자.
Apply를 눌러 미리 보기를 하고, 마음에 들면 우측 상단의 Save를 누르면 저장되어 화면에 출력된다.
CPU Guage Windows
다음 챠트는 CPU의 사용률을 게이지로 표현해 보자. 아래의 그림으로 설정하면 되는데, 중요한 점은 value가 "last value"로 측정 마지막 값을 가져오도록 한다.
CPU DIFF
다음 챠트는 CPU의 변화량을 보여준다. value에 diff를 설정하면 해당 측정 기간 동안의 CPU 변화량을 쉽게 시각화할 수 있다. (diff)
네트워크 사용량 (IN/OUT)
앞의 CPU Usage와 동일하게 테이블과 태그를 지정하면 된다.
차트 선택
연산 설정
KB 단위이기 때문에 value에 1024를 나누어준다. (value / 1024)
남은 디스크 용량
아래와 같이 전체 디스크의 남은 용량을 실시간으로 얻을 수 있다. 아래 챠트는 리눅스와 윈도우가 서로 크게 차이가 나서 직선으로 보이지만, 한 개만 출력하면 실시간으로 줄어들거나 늘어나는 디스크 용량을 시각화할 수 있다.
차트 선택
연산 설정
그리고, GB 단위로 출력하기 때문에 아래의 붉은 박스 기호를 클릭해서 실제 값에 대해 나누기 연산(value / 1024/1024/1024)을 각각 수행하여야 GB단위가 제대로 출력된다. 그렇지 않으면, 바이트 단위로 긴 숫자가 출력될 것이다.
알람 히스토리 (Scatter Chart)
아래 차트는 지난 5분간 얼마나 많이 알람이 발생했는지 내역을 한눈에 알 수 있도록 보여주는 Scatter 차트이다. 이 차트는 로그 테이블인 alarm_history를 활용한다.
로그 테이블의 경우 내부에 _ARRIVAL_TIME 이라고 하는 데이터 입력시 자동으로 지정되는 시간 값이 존재하므로, 차트에서 사용자가 정의한 TIME 컬럼이나 이 _ARRIVAL_TIME 중에 선택하면 된다. (후자가 더 빠르다. 그러나, 이 두개의 시간이 서로 다르므로 적절하게 선택한다.)
전체 화면 보기
아래와 같이 차트를 배치하였으며, 공개된 github의 machbase/neo-apps 소스코드에 DASHBOARD.dsh 로 저장되어 있다. 그리고, 우측 상단에 있는 링크 표시를 누르면, 이 대쉬보드를 위한 고유의 URL이 나오는데, 이것으로 별도의 브라우저 탭에서 이 대쉬보드만 출력할 수 있다.
별도의 대시보드 링크를 통해 출력하기
최종 화면이다. 아래의 그림과 같이 별도의 URL을 통해 독립된 브라우저에 대시보드를 보고 있으며, 우측의 시간 옵션을 통해 지난 5분간 데이터를 3초 간격으로 refresh 하도록 하였다.
[빠른 설치] 네오에서 시스템 모니터링 앱 활용
이 장에서는 가장 빠르게 네오를 통해 시스템의 메트릭을 출력하는 빠른 방법에 대해 순서대로 기술한다.
마크베이스 설치
본 데모에서는 네오 8.0.17을 설치하였다. 관련하여 다운로드 및 설치, 구동 방법은 아래의 영상을 참조하면 된다.
윈도우 설치 및 구동
리눅스/맥오에스 설치 및 구동
네오에 neo-apps 코드 다운로드
네오에서는 github의 소스코드를 직접 내부에 다운로드 받을 수 있는 방법을 제공한다. 따라서, 아래의 그림과 같이 신속하게 즉시 설치할 수 있다. 우선 네오 최신 버전이 설치되어 동작하고 있다고 가정한다.
아래의 좌윽 상단의 세번째 아이콘을 누르면, 중앙의 Git Clone 메뉴가 나타나는데, 여기에서 해당 소스코드 주소 https://github.com/machbase/neo-apps.git 를 입력하고, OK를 누르면, 자동으로 해당 앱이 설치가 된다.
설치 패키지 확인
설치가 완료되면, 아래의 그림과 같이 neo-apps라는 최상위 디렉토리가 생기고, 하위에 server-mon 이라는 디렉토리를 클릭하면, 아래와 같이 필요한 소스코드를 볼 수 있다. (python 에이전트 소스코드도 있지만, 네오에서는 보이지 않는다)
테이블 생성 및 워크시트 확인하기
위의 화일을 보면, setup.wrk 이라고 보일 것이다. 이 화일을 클릭하면, 아래와 같이 화면에 관련 내용이 나타난다. 참고로 worksheet 화일은 네오에서 제공하는 문서 작업 포맷의 화일이다.
이 워크시트에서는 직접 SQL을 수행할 수 있도록 지원한다.
위의 그림과 같이 커서를 첫번째 create tag table에 올려 놓고, 우측 상단의 플레이 버튼을 누르면 테이블이 생성된다.
성공하였으며, 커서를 두번째 create table alarm_history에 올려 놓고, 다시 플레이를 누르면, 두개의 테이블이 성공적으로 생성될 것이다.
TQL 에이전트 구동하기
이 과정은 위의 본문에서 자세히 설명했으므로, 그냥 수행 방법만 간단히게 설명한다. 그리고, 여기에서는 알람도 함께 검사하는 TQL 에이전트를 활용한다.
이를 위해 네오가 설치된 운영체제는 WSL2의 리눅스라고 가정하고, 장비명은 "linux"로 하겠다. 더불어서 호스트 운영체제인 윈도우에서 동일하게 "windows"라는 이름으로 에이전트를 수행한다.
파이썬 부가 패키지 미리 설치하기
파이썬 에이전트는 관련 외부 패키지를 아래와 같이 설치하자.
pip3 install argparse logging platform psutil requests socket
리눅스
해당 server-mon 소스코드 디렉토리에서 아래와 같이 수행한다.
디렉토리 내용 확인
~/neo/current/neo-apps/server-mon$ ls
DASHBOARD.dsh agent_core.py append.tql mon.sql run-agent-json.py run-agent-tql.py run.sh setup.wrk실행하기
~/neo/current/neo-apps/server-mon$ python3 run-agent-tql.py http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql monitoring --servername linux
http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql?table=monitoring
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-linux', 1713678506, 0.1], ['DU-linux', 1713678506, 154355449856], ['DT-linux', 1713678506, 538854957056], ['DR-linux', 1713678506, 384499507200], ['NI-linux', 1713678506, 0], ['NO-linux', 1713678506, 0]]}}
###
CPU-linux,1713678506,0.1
DU-linux,1713678506,154355449856
DT-linux,1713678506,538854957056
DR-linux,1713678506,384499507200
NI-linux,1713678506,0
NO-linux,1713678506,0
{'success': True, 'reason': 'success', 'elapse': '2.824225ms', 'data': {'message': 'append 6 rows (success 6, fail 0)'}}
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-linux', 1713678510, 0.1], ['DU-linux', 1713678510, 154355449856], ['DT-linux', 1713678510, 538854957056], ['DR-linux', 1713678510, 384499507200], ['NI-linux', 1713678510, 1156], ['NO-linux', 1713678510, 1156]]}}
###
CPU-linux,1713678510,0.1
DU-linux,1713678510,154355449856
DT-linux,1713678510,538854957056
DR-linux,1713678510,384499507200
NI-linux,1713678510,1156
NO-linux,1713678510,1156
{'success': True, 'reason': 'success', 'elapse': '4.977728ms', 'data': {'message': 'append 6 rows (success 6, fail 0)'}}
.....성공적으로 수집이 된다.
윈도우
디렉토리 내용
C:\Users\ratse\work\neo-apps\server-mon>dir
C 드라이브의 볼륨에는 이름이 없습니다.
볼륨 일련 번호: 9CFC-DC76
C:\Users\ratse\work\neo-apps\server-mon 디렉터리
2024-04-21 오후 02:50 <DIR> .
2024-04-20 오후 12:33 <DIR> ..
2024-04-20 오후 12:33 3,578 agent_core.py
2024-04-21 오후 02:50 431 append.tql
2024-04-21 오후 02:50 15,439 DASHBOARD.dsh
2024-04-20 오후 12:33 312 mon.sql
2024-04-20 오후 12:33 1,622 run-agent-json.py
2024-04-21 오후 02:50 2,358 run-agent-tql.py
2024-04-20 오후 12:33 51 run.sh
2024-04-21 오후 02:50 12,474 setup.wrk
2024-04-20 오후 12:33 <DIR> __pycache__
8개 파일 36,265 바이트
3개 디렉터리 20,532,850,688 바이트 남음실행하기
C:\Users\ratse\work\neo-apps\server-mon>python3 run-agent-tql.py http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql monitoring --servername windows
http://127.0.0.1:5654/db/tql/neo-apps/server-mon/append.tql?table=monitoring
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-windows', 1713678697, 13.4], ['DU-windows', 1713678697, 1835372167168], ['DT-windows', 1713678697, 1922094321664], ['DR-windows', 1713678697, 86722154496], ['NI-windows', 1713678697, 0], ['NO-windows', 1713678697, 0]]}}
###
CPU-windows,1713678697,13.4
DU-windows,1713678697,1835372167168
DT-windows,1713678697,1922094321664
DR-windows,1713678697,86722154496
NI-windows,1713678697,0
NO-windows,1713678697,0
{'success': True, 'reason': 'success', 'elapse': '5.638746ms', 'data': {'message': 'append 6 rows (success 6, fail 0)'}}
{'data': {'columns': ['name', 'time', 'value'], 'rows': [['CPU-windows', 1713678701, 5.2], ['DU-windows', 1713678701, 1835372167168], ['DT-windows', 1713678701, 1922094321664], ['DR-windows', 1713678701, 86722154496], ['NI-windows', 1713678701, 279462], ['NO-windows', 1713678701, 12224643]]}}
###
CPU-windows,1713678701,5.2
DU-windows,1713678701,1835372167168
DT-windows,1713678701,1922094321664
DR-windows,1713678701,86722154496
NI-windows,1713678701,279462
NO-windows,1713678701,12224643
{'success': True, 'reason': 'success', 'elapse': '925.549µs', 'data': {'message': 'append 6 rows (success 6, fail 0)'}}
.....대시보드 오픈하기
이제 모든 과정이 끝났다. 수집되는 장비명 두개 linux, windows 라는 이름으로 미리 대시보드를 생성해 놓았기 때문에 해당 대시보드를 오픈하면 바로 보일 것이다.
아래 그림과 같이 좌측의 DASHBOARD.dsh클릭하면 모든 과정이 끝난다.
기본 테마 확인
구동한지 약 3분 정도 지난 상태라 모든 챠트가 꽉 차지는 않았지만, 3초에 한번씩 refresh 하면서 실시간으로 출력되는 것을 볼 수 있다.
인포그래픽 테마 사용해보기
내부 소스코드에 추가로 DASHBOARD-infographic.dsh로 지정된 다른 테마의 대시보드가 아래와 같이 있으니 테스트해 보자.
마치면서
이번에는 마크베이스 8.0.17 최신 버전을 통해 실제로 시스템 모니터링 구축을 위해 메트릭 수집 및 알람 처리, 데이터 시각화까지 해 보았다. 데모 수준이기에 두대의 장비만을 예를 들었지만, 마크베이스 데이터베이스의 성능을 고려하면, 일반적으로 8 core, 16GB 정도의 서버에서 10만개 이상의 메트릭 종류를 지원하고, 1000억건 이상을 데이터를 저장할 수 있기 때문에 상용으로 고려하여 구축하는 것도 큰 문제가 없을 것이다.
실제 상황에서는 장기간의 데이터 시각화를 위한 Rollup 쿼리 활용과 데이터 백업 및 마운트, 3rd party 솔루션과의 연동 등이 구체적으로 고민되어야 할 것으로 보인다.
그러나, 처음 발걸음을 옮기는 단계로 고려하면, 마크베이스 네오를 통한 시스템 메트릭 수집과 활용에 대한 이해를 돕는 차원에서는 충분할 것으로 생각해 본다.
향후 여러가지 부분에서 많은 활용과 응용이 나오기를 기대해 본다.
Comentarios