ES, Kibana, Grafana, Prometheus, Thanos, Logstash 사이의 관계 이해하기

모니터링 (Monitoring)과 로깅 (Logging)

개인 프로젝트를 할 때와 실제 회사에서 제품을 운영할 때의 가장 큰 차이점은 모니터링과 로깅입니다. 회사에 가서 처음 들어보는 여러 모니터링과 로깅 기술들을 보며 굉장히 당황했는데요. 키바나, ES, 타노스 (마블의 타노스...?), 프로메테우스... 이런 용어들이 섞인 대화를 이해하는 데는 시간이 걸렸습니다.

이 로깅과 모니터링 도구들의 관계를 간단히 설명해 드리겠습니다!

---

🐜 로깅(Logging)이 뭐야?

내 프로그램이 문제가 생기면 어떻게 해야 할까요? 당연히 원인을 찾아서 고쳐야 합니다. 근데 이 원인을 찾기 위해서는 단서가 있어야겠죠? 보통 이런 단서는 이 에러가 발생하기 전에 어떤 동작들이 있었는지, 이 에러가 발생한 당시의 여러 상태나 값들은 뭐였는지를 봐야 합니다. 물론 이런 단서들이 DB에 남아 있을 수도 있지만 보통은 그렇지 않습니다.

그래서 이럴 떄를 대비에 프로그램 곳곳에 이런 단서를 미리 남겨 둡니다. 이걸 로깅이라고 합니다. 예를 들어...

fun is자연상계(
    oldBonds: Bonds,
    newBonds: Bonds,
): Boolean {
    log.info { "oldBonds: $oldBonds, newBonds: $newBonds" } // 로깅 남기기
    
    // 비즈니스 로직 (생략)
    val result = true
    
    log.info { "자연상계 판별 결과: $result" } // 로깅 남기기
}

도메인 용어들은 (자연상계, 채권) 무시하셔도 됩니다! 중요한 건 나중에 분명 자연상계가 되면 안 되는 케이스인데 자연상계가 됐다고 해 봅시다. 이미 DB 값들은 업데이트 됐고 API에서 받아온 값은 달라졌습니다. 이럴 때 로깅을 남겨 두지 않으면 디버깅이 굉장히 어렵겠죠? 🤔 (불가능에 가깝...)

하지만 로깅을 남겨 두면 아래와 같이 내가 남겨둔 로그들을 검색해서 볼 수 있습니다.

 

🐜 모니터링(Monitoring)이 뭐야?

모니터링은 중요한 여러 지표들을 시간을 두고 보면서 이상이 없는지 보는 일입니다. 배포를 하면 반드시 모니터링을 해야 하고 모니터링을 잘하는 건 개발자의 필수 역량입니다. 모니터링은 사실 크게 2종류가 있는데요.

1. 기술적인 지표들 (DB Idel Connection, 요청수, CPU 사용량, 에러 수등)
2. 비즈니스적인 지표들 (특정 상품의 신청율, 결제 성공률 등)

요런 지표들을 보통 아래와 같이 멋있게 생긴 그래프들로 관찰하며... 이상이 없는지 봐야 합니다.

---

로깅 (Logging) 도구들 간의 관계

로깅을 남길 때는 흔히 ELK 스택이라고 부르는 기술들을 사용합니다.

ELK Stack: Elasticsearch, Kibana, Beats, Logstash

 

우선 Application에서 로그를 남겨야 합니다. 이 과정은 어떤 기술을 쓰냐에 따라 매우 다릅니다. Java 진형의 기술을 쓸 경우 흔히 SLF4J라는 표준 interface를 사용합니다. 그리고 이 구현체 중 1개인 Logback 같은 기술을 써서 Logging을 처리합니다.

Logback 간단하게 알아보기

 

아무튼 이런 식으로 로그를 남기면 크게 3가지 과정으로 이 로그들을 볼 수 있습니다.

1. Logstash가 Log를 수집하고 처리를 합니다. (시간, 서버 IP, 민감 정보 마스킹 등)
2. 처리한 Log를 Elastic Search에 보냅니다.
3. Elastic Search가 Log들을 인덱싱하면 키바나 (Kibana)로 접근해서 볼 수 있습니다.

정리하면 우리가 코드에서 로그를 남기면 이건 여러 방식으로 저장됩니다. 카프카에 쏠 수도 있고, STD Output에 남길 수도 있고, 서버 내에 있는 특정 파일에 남길 수도 있고, 슬랙에 쏠 수도 있고, 네트워크로 직접 쏠 수도 있고... 아무튼 이렇게 전송된 여러 로그들을 수집하고 가공하는 역할을 하는 게 Logstash입니다.

로그 스테이시 (Logstash)

 

이렇게 Logstash가 가공한 로그들은 Elastic Search (ES)로 보내서 처리를 합니다. 로그는 굉장히 비정형화된 데이터이기 때문에 인덱싱을 철저히 하지 않으면 간단한 거 찾는데도 매우 많은 시간이 소요됩니다. ES는 인덱싱을 굉장히 헤비하게 해서 용량은 많이 잡아먹지만 검색 속도가 매우 빠릅니다. 그래서 보통은 ES에는 로그를 오래 저장해 두지 않고 (2주 정도만 저장) 오래된 로그는 대용량 저장에 최적화 돼 있는 곳들로 옮깁니다. (Hadoop, S3 같은 게 대표적)

엘라스틱 서치 (Elastic Search)

 

아무튼 ES에서 인덱싱까지 끝나면 이걸 조회할 수 있을 텐데, 그 조회를 할 수 있게 UI를 제공해 주는 게 키바나 (Kibana)입니다.

키바나 (Kibana)

---

모니터링 (Monitoring) 도구들 간의 관계

로깅 도구들을 보면 역할 분담이 상당히 잘 돼 있습니다. 모니터링 도구들도 비슷합니다. 큰 그림을 보면 모니터링을 위해서는 아래와 같은 단계를 거칩니다.

1. 여러 모니터링을 제공하는 endpoint를 서버가 노출
2. 주기적으로 해당 endpoint를 호출해서 정보 수집하고 가공
3. (필요하다면) 2에서 수집하고 가공한 정보들을 더 길게 저장하기 위한 다른 저장소에 저장
4. 메트릭을 보기 위한 UI 제공

차례대로 알아보면 1번의 역할은 어떤 기술을 쓰냐에 따라 다릅니다. Spring 진영에서는 Micrometer라는 애를 사용해서 하고 다른 진영은 또 각자만의 기술이 있습니다. 이 라이브러리들의 역할은 자주 쓰이는 모니터링 지표를 기본으로 제공해 주고, 나만의 모니터링 지표들도 쉽게 사용할 수 있게 해 줍니다.

2번의 역할은 프로메테우스 (Prometheus)에서 담당합니다. 1번에서 잘 노출시켜 준 정보를 주기적으로 가져와서 저장하고 처리합니다. ES와 비슷하게 데이터를 저장하는 DB의 역할을 한다고 봐도 됩니다. 이 외에도 특정 지표가 정해둔 값을 넘으면 알려주는 알림 기능도 있습니다.

프로메테우스 (Prometheus)

ES와 비슷하게 프로메테우스는 리소스를 많이 차지하기 때문에 오래된 지표들은 타노스 (Thanos)를 사용해서 옮기기도 합니다. 오래된 모니터링 지표를 계속 저장하고 있어야 하지 않는 이상 (보통 비즈니스 지표가 아니면 오래 수집하지 않겠쬬? 🤔) 굳이 사용하지 않아도 됩니다.

타노스 (Thanos)

 

마지막으로 이렇게 수집된 정보들을 보기 위해 그라파나 (Grafana)를 사용합니다. 그라파나는 프로메테우스에 있는 여러 데이터로 그래프를 그릴 수 있게 도와줍니다.

그라파나 (Grafana)

---