레이블이 prometheus인 게시물을 표시합니다. 모든 게시물 표시
레이블이 prometheus인 게시물을 표시합니다. 모든 게시물 표시

2021년 8월 28일 토요일

5) 빅데이터 플랫폼 아키텍처에 대하여.. 데이터 시각화를 위한 프레임워크(DashBoard 구현에 필요한 Grafana, Prometheus, influxDB 등)

1편 Bigdata Architecture, 2편 Hadoop, 3편 Spark, 4편 Scheduler에 이어서 5편은 무슨 주제로 포스팅을 할까 하다가.. Hive나 Hue같은 부가적인 프레임워크보다는 시각화를 먼저 쓰는게 좋다고 문득 생각이 들었다.

데이터를 저장(Hadoop)하고 Spark로 처리하고 Scheduler로 정기적인 작업을 할 수 있다면 꾸준히 output data가 어딘가에 쌓일 것이다. 그 것을 HDFS로 저장하거나 또는 다른 DB에 저장해서 필요할 때 가져다 쓰면 된다.


대시보드를 만들 때 Tableau, Power BI 등 유료 대시보드를 쓰면 여러 기능들을 사용할 수 있고 잘만들면 drill down을 하면서 Olap처럼 사용할 수도 있다. 하지만 서버 상태 모니터링이나 실적 등 처럼 정형화된 그래프만 봐도 충분한 경우가 있다. 이럴 땐 굳이 유료 대시보드를 구매할 필요 없이 범용적으로 사용하는 Grafana를 권장한다.


Grafana는 Graph뿐만 아니라 alert 등을 걸고 이메일 알림을 받을 수 있다. 또한 공통적으로 사용하는 화면들은 다른 사람들이 잘 만들어놓고 grafana 공식 홈페이지에 dash board를 검색하여 json을 가져다가 쓰기만 하면 된다.


Grafana labs


Grafana는 대시보드다. 그럼 데이터는 어디에 있는 것을 사용하면 될까? mysql, postgresql, influxDB 등 다양한 connector(plugins)가 존재하며 데이터가 있는 DB와 연결하면 일정 주기마다 데이터가 불러와지면서 화면에 그려준다. 보통은 쿼리를 작성하고 그 쿼리가 일정 주기마다 DB에 날린다.


불러온 데이터는 각종 Graph로 표현할 수 있다. 클릭 몇번으로도 구현이 될 정도로 아주 간단하다. 버전마다 사용가능한 차트가 다르고 다른 사람들이 작성해놓은 dash board를 다운받아서 사용할 경우 데이터 형식만 맞춰주면 그대로 가져다 쓸 수 있다.


보통 시계열 데이터는 InfluxDB에 넣고 사용을 한다. time series DB이기 때문에 Timestamp로 구분을 하고 PK를 사용하지 않기 때문에 메트릭정보, 실시간 로그 분석 등에 사용하기 알맞다. Opensource olap 중에 하나인 druid와 철학을 같이하는 것처럼 보인다.


이렇게 grafana에 direct로 DB를 연결해서 보여주는 방식도 있지만 별도 수집기를 둘 수도 있다. 이는 Prometheus라는 프레임워크가 해줄 수 있다. Prometheus 역시 time series로 데이터를 수집하며 각종 metric을 수집할 수 있다.

중요한 것은 데이터를 필요한 곳에 넣어주느냐, 데이터가 필요한 곳에서 가져가느냐의 차이이다. 둘다 가능하지만 후자가 조금 더 안전하다. Destination의 문제로 인해 데이터를 더 이상 받으면 안될 때에도 데이터를 억지로 밀어넣고 있는다면 당연히 장애가 심각해질 것이다. 따라서 push 방식보다는 pull 방식을 더 선호하고 이 외에도 데이터를 받는 곳에서 장애가 나게된다면 pull 방식은 단지 데이터를 가져가지 않을 뿐이니 문제가 없다. 단지 수집기로 쓰기에 알맞다.


과거에 포스팅을 했지만 프로메테우스는 확장하기가 어렵다. 확장을 하려면 프로메테우스들끼리 묶고 다시 상단에서 그 데이터를 pull해오는 방식으로 구현을 해야한다. 즉 프로메테우스를 층층이 쌓아서 피라미드(?)처럼 설계를 해야한다. 다른 방식이 있는지는 모르겠지만 그 정도로 프로메테우스를 heavy하게 사용할 일이 있을까?



프로메테우스 아키텍처이다. 위에서 언급했던 데로 Grafana에서 direct로 DB를 붙게된다면 15초, 30초 마다 한번씩 쿼리를 수행하기 때문에 DB입장에서는 부담이 될 수 있다. 하지만 프로메테우스를 사용한다면 프로메테우스가 그 DB역할을 대신해주고, 프로메테우스는 pull 방식으로 데이터를 수집하므로 조금 더 안전한 구조가 될 수 있다.

아키텍처처럼 Pushgateway를 두고 Prometheus server가 데이터를 수집할 수도 있고 수집대상에 exporter를 띄워서 Prometheus server가 수집할 수도 있다. 즉 Prometheus server가 몸통이다. 또한 여기에서도 Alertmanager를 별도로 두어 email 등의 알람을 줄 수 있다. 또한 Prometheus 자체가 데이터를 들고있으니 그래프를 그리는 것 또한 가능하다. 하지만 이쁘지 않기 때문에 그라파나를 통해서 그리는 것이 훨씬 더 이쁘게 그릴 수 있다.


Prometheus는 필수는 아니고 Dashboard를 위해서는 Grafana만 있으면 된다. 
Grafana를 잘 활용하자.


2019년 11월 26일 화요일

Cassandra + Prometheus + Grafana Monitoring System unsing by jmx exporter(node exporter)

카산드라(cassandra) 모니터링을 하기 위한 시스템을 마련하기 위한 포스팅이다. InfluxDB를 사용하는 케이스가 많이 있지만 이번 포스팅에서는 InfluxDB 없이 모니터링 시스템을 구축해본다.


큰 틀은 cassandra의 jmx를 활성시키고 해당 로그를 Prometheus에서 수집해서 Grafana로 화면에 그려주는 방식이다.


사용 버전
- cassandra 3.11.4
- jmx_prometheus_javaagent-0.3.0.jar
- prometheus 2.14.0
- grafana 5.0.1


그럼 카산드라에서 발생시키는 로그를 수집서버에서 수집해보자.
그 로그들은 각 클라이언트에서 수집서버로 Push(Polling)하는 방식과 수집서버에서 카산드라 로그를 Pulling하는 방식 두 가지로 나뉠 수가 있다. 

일반적인 모니터링 툴들은 각 클라이언트에서 수집서버로 로그를 전송하는 형태를 띄고 있다면 프로메테우스는 각 로그들을 각 클라이언트에서 exporter를 통해 가져오는 방식을 차용하고 있어서 프로메테우스가 장애가 나더라도 서비스 어플리케이션에 문제가 되지 않는다. 왜냐하면 각 클라이언트 들은 메트릭 정보를 수집해놓고 수집해가기를 기다리기만 하기 때문에 프로메테우스의 장애와는 아무런 상관이 없다.


아래는 프로메테우스의 아키텍쳐이다.


간단하게 살펴보면 프로메테우스 서버가 있고 여기서는 PushgaeWay나 Jobs/exporters에서 메트릭정보를 Pulling 하게 된다. 즉 어플리케이션단에서 exporter를 띄워놓거나 Pushgateway로 메트릭 정보를 보내면 프로메테우스 서버에서는 저 메트릭 정보를 가져오는 형태이다.
이 포스팅에서는 node exporter(서버 로그)와 jmx exporter(카산드라 로그)를 사용할 것이다.

그리고 Prometheus server에서 설정해놓은 정보에 따라 AlterManager에 시그널을 주면 이메일같은 채널로 알림기능을 설정할 수 있다.


마지막으로 Prometheus web UI나, Grafana와 같은 Visualization 툴을 통해 프로메테우스에서 수집한 메트릭 정보를 그려줄 수 있다. 이를 위해 PromQL이라는 쿼리를 사용하게 되는데 그라파나에서 제공하는 대시보드를 보면 sum이나 count가 대부분이라서 크게 어렵지 않는 것 같다. 그러니 누가 카산드라 메트릭 정보를 잘 표현할 수 있는 쿼리를 아주 잘 만들어주면 기쁜마음으로 사용하겠다.


카산드라를 설치하고 jmx까지 활성화가 되있다고 가정하자.
jmx 활성화 하는 방법은 어렵지 않다.
필자의 경우 중간에 제대로 동작을 안했었는데 이유는 conf/cassandra-env.sh 파일에서 LOCAL_JMX가 yes로 세팅되어 있었기 때문이다.
따라서 다음과 같이 수정하였다.

if [ "x$LOCAL_JMX" = "x" ]; then
    LOCAL_JMX=no
fi


그럼 이 데이터를 Prometheus server가 가져갈 수 있도록 jmx exporter와 node exporter를 설치하도록 한다.


이 포스팅에서는 두 가지 모두 설치해보고 비교해보자.

먼저 node exporter 세팅이다.

프로메테우스 공식 홈페이지에서 tarball을 받아서 각 노드에 옮겨서 설치한다.

주소는 다음과 같다.
https://prometheus.io/docs/guides/node-exporter/

node exporter는 단순히 압축을 풀어서 실행하기만 하면 9100 포트로 수집된다.
따라서 prometheus server에서 각 노드 9100 port로 들어가서 수집해오면 된다.

UI로 들어가서 확인해보자.



다음은 prometheus server에서 node exporter를 수집해가면 된다.
prometheus.yml 파일에 수집타겟을 설정해주자.


프로메테우스 UI에 가서 targets를 확인해보면 잘 떠있는 것을 확인할 수 있고 실제로 수집 되는 데이터를 그래프로 확인도 가능하다.


테스트로 그래프를 그려본 결과 그려지긴 하지만 뭔가 다이나믹하지 않고 상당히 아쉬운 느낌이 든다.


따라서 위의 프로메테우스 결과를 다시 grafana로 가져와서 grafana를 통해 그려보도록 한다.


이 역시 공식 사이트에 들어가서 다운을 받아서 설치하도록 하자.
주소는 다음과 같다. https://grafana.com/grafana/download


이 역시 압축을 풀고 서버를 띄우기만 하면되서 간단하다.
서버가 올라오면 3000번 포트로 접속해보자.


누군가 만들어서 배포해놓은 대시보드를 사용하자.
https://grafana.com/grafana/dashboards/


아래는 대시보드 11074번을 import 하였다.



그 결과 다음과 같은 아름다운 화면이 완성되었다.




하지만 뭔가 아쉬운 점이 있다면 node exporter는 하드웨어 모니터링 느낌이 강하다.
우리는 카산드라 노드의 정보가 알고싶기 때문이다.

이를 위해서 jmx를 써야한다.
같은 방식으로 jmx exporter 세팅 후 프로메테우스+그라파나로 연동하자.


cassandra metric을 보기 위한 jmx exporter 세팅이다.

다운로드 링크
https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.3.0/

카산드라는 jmx 세팅을 위해 카산드라를 노드별로 한대씩 내렸다가 올려야하기 때문에 조금 귀찮을 수 있어서 한번에 성공하도록 한다.

jmx exporter가 사용할 cassandra.yml 파일은 아래 주소를 참고 했다.
혹시 바뀔수도 있으니 현재 시점 샘플을 포스팅 마지막에 구글 드라이브 링크로 첨부하였다.
https://raw.githubusercontent.com/prometheus/jmx_exporter/master/example_configs/cassandra.yml


저 두 파일을 카산드라 폴더에 넣고 conf/cassandra-env.sh에 JVM_OPTS에서 물고 올라갈 수 있도록 다음을 추가하자.

JVM_OPTS="$JVM_OPTS -javaagent:/sw/cassandra/jmx_prometheus_javaagent-0.3.0.jar=7070:/sw/cassandra/cassandra.yml"


또는 다음처럼 명령어로 추가를 해주자. 모든 수집대상 노드에서 똑같이 반복한다.
echo 'JVM_OPTS="$JVM_OPTS -javaagent:'$PWD/jmx_prometheus_javaagent-0.12.0.jar=7070:$PWD/cassandra.yml'"' >> conf/cassandra-env.sh


위처럼 conf/cassandra-env.sh 마지막 줄에 jmx 에이전트 세팅을 해주고 카산드라를 재기동 한다.

역시 프로메테우스에서도 target ip를 추가해주자.
(이후 dashboard를 하나도 수정하지 않기 위해 job_name을 cassandra_로 시작하도록 하였다. instance명을 반드시 cassandra_로 맞춰주도록 하자.)

위에서 JVM_OPTS 를 설정하면서 7070 포트로 설정했으니 이번에는 7070 포트로 수집을 하면 된다.



프로메테우스 target에서도 up 상태를 확인할 수 있다.


node exporter와는 다르게 cassandra metric이 수집되고 있다.




마지막으로 grafana에서 적당한 대시보드를 골라서 그려보도록 하자.

dashboard number 5408을 활용했다. (https://grafana.com/grafana/dashboards/5408)

datasource가 없다면 생성해주고 5408 json을 import하면 다음과 같은 화면이 그려진다.



이상으로 cassandra + jmx exporter(node exporter) + prometheus + grafana를 활용한 cassandra monitoring system 구축을 마친다.

관련 파일은 아래 구글드라이브에서 첨부하였다.
https://drive.google.com/open?id=16UtW5A175w1tVknXvHFTOQUU9W2d9bNS

내용물
1. cassandra.yml
2. cassandra_rev3.json
3. node_exporter-0.18.1.linux-amd64.tar.gz
4. jmx_prometheus_javaagent-0.3.0.jar








2022년 회고

 올해는 블로그 포스팅을 열심히 못했다. 개인적으로 지금까지 경험했던 내용들을 리마인드하자는 마인드로 한해를 보낸 것 같다.  대부분의 시간을 MLOps pipeline 구축하고 대부분을 최적화 하는데 시간을 많이 할애했다. 결국에는 MLops도 데이...