김민주 7주차 JSP CAFE 학습 일지
Spring Boot 액츄에이터, 마이크로 미터에서 메트릭 생성해주고
Prometheus의 구현체가, 프로메테우스가 읽을 수 있는 포멧으로 메트릭을 만들어서 수집, DB에 저장
spring-boot-starter-actuator를 통해 어플리케이션 모니터링, 메트릭 수집, 트래픽 모니터링 가능
- micrometer는 vendor 중립 적인 API를 통해 코드를 시간, 계산 측정할 수 있도록 하는 목표, slf4j같지만, 메트릭 용이라고 이해하면 될 듯
- Spring Boot Actuator에 포함되어있음
- 만약 Prometheus를 쓴다면 prometheus Export라는 Micrometer를 붙이면 됨
메트릭이란?
- 하드웨어나 소프트웨어에 대한 성능 측정을 위한 측정 수치 값
@AutoConfiguration으로 지표 수집을 추가하면
출처 : https://velog.io/@songs4805/Spring-micrometer와-metric
이러한 정보들을 확인할 수 있음
- JVM 메트릭
- 시스템 메트릭
- 애플리케이션 시작 메트릭
- Spring MVC 메트릭
- Tomcat 메트릭
- Datasource 메트릭
- 로그 메트릭
Health Endpoint에 의해 노출되는 정보는 management.endpoint.health.show-details 및 management.endpoint.health.show-components 속성에 따라 달라짐
| 이름 | 설명 |
|---|---|
| never | 세부 정보가 절대 표시되지 않습니다. |
| when-authorized | 세부 정보가 인증된 사용자에게만 표시됩니다. 인증된 역할은 management.endpoint.health.roles를 사용하여 구성할 수 있습니다. |
| always | 세부 정보가 모든 사용자에게 표시됩니다. |
출처: https://docs.spring.io/spring-boot/docs/3.0.5/reference/html/actuator.html#actuator.endpoints.health
Spring Boot Actuator에서 수집한 메트릭에서 micrometer의 적절한 구현체 (ex, Prometheus, JMX) 같은 것들을 끼워넣어서 넣어주면 각각의 서비스가 이해하는 구조화된 메트릭이 되고, (ex 프로메테우스)가 그 구조화된 메트릭을 읽어서 ㄷDB에 저장하게 되는 구조
일반적인 모니터링 시스템은 발생 서버에서 push해주는 구조이지만
Prometheus는 중앙 서버에서 polling하는 구조가 됨
출처: https://gompangs.tistory.com/entry/Prometheus-를-알아보자
push를 하는 구조면, 로그 전송을 같은 process에서 진행하게 됨,
- 로그 전송의 부하 때문에 App부하가 생길 수 있고, 반대로 App 부하로 로그가 전송되지 않을 가능성도 존재함
polling하는 경우
- 일단 다른 process에서 수집하기 대문에 메트릭 수집과 App의 관심사 분리가 이루어짐
- endpoint가 열려있어야함
- polling주기, scrap하는 시점 때문에 interval이 생겨서 문제가 생길 수도 있음
출처: https://jominseoo.tistory.com/76
대상 서버에 HTTP 접근하여 메트릭을 가져오거나
Pushgateway란 것을 통해서 접근할 수 없는 곳에 대한(방화벽도 있는 경우) 데이터를 가져오게 됨, polling하는 주체
시간의 흐름에 따라 조회를 할 수 있어야하기 때문에 시-계열 데이터 저장소가 구현이 되어있어야한다고 함
Lcoal Storage를 쓰거나, Remote Storage를 이용하는 방법이 있음
내부 저장소는 Google의 key-value 저장소인 LevleDB를 쓴다고함
출처 : [[https://velog.io/@songs4805/Spring-micrometer와-metric](https://velog.io/@songs4805/Spring-micrometer%EC%99%80-metric)](https://velog.io/@songs4805/Spring-micrometer%EC%99%80-metric)이러한 정보들을 확인할 수 있음
- JVM 메트릭
- 시스템 메트릭
- 애플리케이션 시작 메트릭
- Spring MVC 메트릭
- Tomcat 메트릭
- Datasource 메트릭
- 로그 메트릭
Health Endpoint에 의해 노출되는 정보는 management.endpoint.health.show-details 및 management.endpoint.health.show-components 속성에 따라 달라짐
| 이름 | 설명 |
|---|---|
| never | 세부 정보가 절대 표시되지 않습니다. |
| when-authorized | 세부 정보가 인증된 사용자에게만 표시됩니다. 인증된 역할은 management.endpoint.health.roles를 사용하여 구성할 수 있습니다. |
| always | 세부 정보가 모든 사용자에게 표시됩니다. |
출처: https://docs.spring.io/spring-boot/docs/3.0.5/reference/html/actuator.html#actuator.endpoints.health
Spring Boot Actuator에서 수집한 메트릭에서 micrometer의 적절한 구현체 (ex, Prometheus, JMX) 같은 것들을 끼워넣어서 넣어주면 각각의 서비스가 이해하는 구조화된 메트릭이 되고, (ex 프로메테우스)가 그 구조화된 메트릭을 읽어서 ㄷDB에 저장하게 되는 구조
일반적인 모니터링 시스템은 발생 서버에서 push해주는 구조이지만
Prometheus는 중앙 서버에서 polling하는 구조가 됨
출처: [https://gompangs.tistory.com/entry/Prometheus-를-알아보자](https://gompangs.tistory.com/entry/Prometheus-%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90)
push를 하는 구조면, 로그 전송을 같은 process에서 진행하게 됨,
- 로그 전송의 부하 때문에 App부하가 생길 수 있고, 반대로 App 부하로 로그가 전송되지 않을 가능성도 존재함
polling하는 경우
- 일단 다른 process에서 수집하기 대문에 메트릭 수집과 App의 관심사 분리가 이루어짐
- endpoint가 열려있어야함
- polling주기, scrap하는 시점 때문에 interval이 생겨서 문제가 생길 수도 있음
출처: https://jominseoo.tistory.com/76
대상 서버에 HTTP 접근하여 메트릭을 가져오거나
Pushgateway란 것을 통해서 접근할 수 없는 곳에 대한(방화벽도 있는 경우) 데이터를 가져오게 됨, polling하는 주체
시간의 흐름에 따라 조회를 할 수 있어야하기 때문에 시-계열 데이터 저장소가 구현이 되어있어야한다고 함
Lcoal Storage를 쓰거나, Remote Storage를 이용하는 방법이 있음
내부 저장소는 Google의 key-value 저장소인 LevleDB를 쓴다고함
- 저장된 메트릭을 읽어야하니깐, Prometheus 자체에서도 웹서버가 존재, 하지만 여기에서 Grafana를 통해 더 깔끔하게 볼 수도 있는 듯
문제가 발생하면 알람으로 보내주는 역할, Prometheus에서 문제가 발생했다고 생각되는 시점에 slack이나 hipchat을 통해 알람을 보내줌
출처:[https://gompangs.tistory.com/entry/Prometheus-를-알아보자#Alert%--Manager](https://gompangs.tistory.com/entry/Prometheus-%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90#Alert%25--Manager)
시계열 데이터를 시각화 하는데 가장 최적화된 대시보드를 제공해주는 오픈소스 툴킷임
- Grafana에 Prometheus 데이터 소스르 추가함 (db url적듯이)
- PromQL(Prometheus Query Language)을 사용하여 특정 메트릭 데이터를 요청
---
https://aws.amazon.com/ko/compare/the-difference-between-cassandra-and-mongodb/
여러 노드가 있는 환경에서 강력한 기능을 제공하는 NoSQL DB
→ 클러스터링 된 상황을 염두에 두고 설계된 NoSQL DB임
- 확장 시 다운 타임 없이도 노드 추가가 가능함
- 클러스터에서 여러 노드에 복제되어 고가용성 가능
MongoDB에서는 (MySQL Replication 처럼) 하나의 primary node에서만 쓰기를 지원함,
→ 따라서 해당 쓰기 노드가 SpoF가 될 수 있음
하지만 Cassandra는 여러 노드가 모두 쓰기 작업을 진행할 수 있음
→ 쓰기에 대한 SpoF가 발생하지 않음
- 한 노드가 요청을 받으면
- 파티션 키를 통해 저장할 노드를 결정
- 데이터가 저장될 노드와, 복제가 저장될 테이블 등
- 인 메모리 캐시인 MemTable에 쓰고 (Mysql에서 버퍼 풀 같은 역할?)
- 주기적으로 SSTable이라는 자료구조로 Disk에 저장됨
- SSTable은 불변, 정렬된 구조임
- SSTable은 불변이라 업데이트를 하게 되면 새로운 SSTable이 생김
- 데이터 검색 시 여러 SSTable을 검색하여 최신 값을 반환함, 주기적으로 compaction하는 시간을 가짐 (데이터의 변경 흐름인 SSTable을 합침)
- 파티션 키를 user_id로 사용한다고 예를 들면
- 토큰 링 (Cassandra 클러스터 내의 노드들을 원형으로 배열하한 구조)에서 노드와 매핑
- 해시 값과 가장 가까운 노드가 )ex Node B)해당 데이터를 저장함
- 추가적으로 replication을 위해 인근 ex) Node C, D에도 데이터를 저장
- 특정 노드가 요청을 받음
- 파티션 키를 통해 해싱
- 해시 값과 가장 가까운 노드와 Node C, D에 모두 데이터 조회 요청을 보냄
- 이 때 일관성 수준이라는 정책을 통해, 한 노드의 값만, 일부 노드를 비교, 전체 노드를 비교할 지 선택 가능