# Chapter 1. Basic Concept

## 구성 요소

arcus-hubble-v3의 구성 요소는 다음과 같습니다.

### Exporter(ARCUS Exporter, Node Exporter, ZK Exporter)

* metric 데이터를 수집하여 제공하는 하나의 HTTP 서버입니다.
* VictoriaMetrics로부터 요청이 오면 metric 데이터를 수집하여 전달합니다.
* Exporter 종류
  * Arcus Exporter: zk ensemble 마다 구동되어 `stats` 명령을 통해 Arcus 캐시 프로세스 상태를 수집합니다.
  * Node Exporter: Arcus 캐시 장비 마다 구동되어 리소스 상태를 수집합니다.
  * Zk Exporter: `mntr` 명령을 통해 ZooKeeper 프로세스 상태를 수집합니다.

### Orbiter

* Grafana [대시보드 변수](https://grafana.com/docs/grafana/latest/dashboards/variables/) 혹은 ZooKeeper/ARCUS 클러스터 구성 정보에 대한 값을 반환합니다.
* Grafana 대시보드 변수는 대시보드 자체에서 조건을 통해 값을 결정할 수 없는 등 커스텀이 제한적입니다. 따라서 Orbiter에 요청을 보내 특정 로직을 거친 값을 받아 사용하도록 합니다.

### VictoriaMetrics

* 정해진 주기로 exporter의 url 호출하여 metrics 데이터를 받아 효율적으로 압축된 형태로 저장합니다.
* Pull 방식으로 metric을 수집하므로, 다양한 운영 환경에 유연하게 대처할 수 있습니다.
* 최신 데이터를 빈번한 간격으로 저장하는 Short Term 프로세스와 장기 데이터를 드문 간격으로 저장하는 Long Term 프로세스를 각각 구동하여 오랜 기간 데이터를 효율적으로 저장하도록 합니다.

### Promxy

* Grafana로부터 promQL 질의가 오면, 해당하는 metrics 데이터를 반환해줍니다.
* 여러 VictoriaMetrics 인스턴스를 하나의 엔드포인트로 통합하는 프록시 역할을 합니다.

### VMAlert

* VictoriaMetrics에서 제공하는 알림 시스템입니다.
* VictoriaMetrics에 존재하는 metrics 데이터를 기반으로 알림 규칙을 주기적으로 평가하여, 임계값을 초과하거나 이상 상태가 감지되면 알림을 생성합니다.
* 생성된 알림은 Alertmanager에 전달하여 각 엔드포인트로 전파되도록 합니다.

### Alertmanager

* SMS, 이메일, 슬랙 등으로 알림 메시지를 발송하는 프로세스입니다.
* VMAlert 프로세스에서 지정한 알람 규칙에 의해 발생한 알람이 AlertManager로 전달되어 각 Receiver에게 알림을 전파합니다.

### Grafana

* promQL을 사용해 Promxy에 질의를 보내 metrics 데이터를 가져와 시각화합니다.
* 대시보드 변수와 ZooKeeper/ARCUS 클러스터 구성 정보는 Orbiter에 요청하여 얻어옵니다.

## 구성도

### 구성 요소 배치

* 아래 그림은 arcus-hubble-v3의 구성 요소를 나타냅니다.
* 1대의 모니터링 장비에 Node Exporter를 제외한 모든 구성 요소가 설치되고, Node Exporter는 각 캐시 장비에 설치됩니다.

<div align="center"><img src="https://3770298291-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxfxNrdMVvsws02PNqgYu%2Fuploads%2Fgit-blob-d2ac3cf3698ccfe020c026cdbac93e582a5bcf7e%2Fhubble-v3-architecture.png?alt=media" alt="hubble-v3-downsample" width="600"></div>

### 메트릭 수집 및 조회 절차

* 아래 그림은 arcus-hubble-v3의 메트릭 수집, 조회 과정을 나타냅니다.
* 메트릭 수집 및 서비스 코드 단위의 집계는 Short Term VictoriaMetrics 프로세스에서 이뤄집니다.
* 알람 규칙 검사 및 다운샘플링은 VMAlert 프로세스에서 이뤄집니다. 다운샘플링된 메트릭은 Long Term VictoriaMetrics 프로세스에 전달되고, 알람 이벤트는 AlertManager로 전달됩니다.
* 사용자가 Grafana에 접근하여 특정 구간의 메트릭 조회 요청을 보내면 Promxy에서 단기/장기 보관용 VictoriaMetris에 모두 요청을 보내고, 질의문에 의해 둘 중 한 군데에서만 조회 결과가 오게 됩니다. 이는 Grafana 대시보드에 작성된 질의문 특성에 의한 효과입니다.

<div align="center"><img src="https://3770298291-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxfxNrdMVvsws02PNqgYu%2Fuploads%2Fgit-blob-1a577a061debe1055c4473823f17612366be70d5%2Fhubble-v3-downsample.png?alt=media" alt="hubble-v3-downsample" width="600"></div>

## 메트릭 수집 간격

* 기본적으로 메트릭을 5초 간격으로 수집합니다.

  * 요청량 등 계속해서 값이 누적되는 `counter` 성격의 수치는 초당 변화량을 의미하며, 직전에 수집된 값과 차를 계산한 뒤 5로 나눈 값을 표현합니다.
  * 예를 들어 초당 요청량이 100인 경우, 5초동안 500만큼 증가했음을 의미합니다. 이 때 1초 이내에 500개의 요청을 몰아서 처리했는지, 매 초 100개의 요청을 일정하게 처리했는지는 알 수 없습니다.

  <div align="center"><img src="https://3770298291-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxfxNrdMVvsws02PNqgYu%2Fuploads%2Fgit-blob-b31a5897362a82154b0c70da00a9043815d348a0%2Frequest-example.png?alt=media" alt="" width="600"></div>

  \- Prefix, ZooKeeper 메트릭은 1분 간격으로 수집합니다.
* 넓은 범위의 데이터 조회 시 최대값을 대표값으로 선택합니다.

  * spike 데이터를 보존하므로 이슈 분석에 유리합니다.
  * 하지만 일반적으로 낮은 수치를 보이다가 갑자기 spike가 발생하는 상황이 지속적으로 발생하는 경우, 넓은 범위 조회 시에 값이 전부 커보일 수 있습니다.
  * 이러한 경우, 좁은 간격으로 조회해보며 정확한 수치를 파악해야 합니다.

  <div align="center"><img src="https://3770298291-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxfxNrdMVvsws02PNqgYu%2Fuploads%2Fgit-blob-de03fdeb569f8d9868e066dfe642e66ba3ac889f%2Fmetric-diff-time-range.png?alt=media" alt="" width="800"></div>