반응형
SMALL
프로메테우스(Prometheus)
- 메트릭 기반의 오픈소스 모니터링 시스템이다.
- 단순하지만 강력한 데이터 모델과 쿼리 언어(PromQL)를 통해 애플리케이션과 인프라의 성능을 분석할 수 있다.
- 메트릭 이외의 문제는 더 적절한 다른 도구가 처리하도록 남겨둔다.
- 2012년 몇 명의 개발자가 사운드클라우드(SoundCloud) 사에서 개발을 시작한 후, 관련 커뮤니티와 생태계는 꾸준히 성장해 왔다.
- 주로 Go 언어로 작성되었으며 Apache 2.0 라이센스를 따른다.
- 2016년 클라우드 네이티브 컴퓨팅 재단(CNCF, Cloud Native Computing Foundation)의 두 번째 멤버가 되었다.
- 간단한 텍스트 형식을 통해 쉽게 메트릭을 게시할 수 있다.
- 데이터 모델은 이름뿐 아니라 레이블로 불리는 키-값 쌍으로 이뤄진 비정렬 세트로도 모든 시계열을 구별하고, PromQL 쿼리 언어로 이러한 레이블 중 일부를 집계할 수 있다.
- 분석 결과는 그라파나(Grafana) 같은 대시보드 시스템에서 그래프로 표시할 수 있다.
- 프로메테우스 서버는 구성 파일과 함께 사용하는 정적으로 링크된 단일 바이너리다.
- 모든 컴포넌트는 컨테이너에서 실행할 수 있으며, 컨테이너는 구성 관리 도구를 방해하는 복잡한 작업은 하지 않는다.
모니터링의 종류
1. 알림(Alerting)
- 문제가 발생한 시기나 시점을 파악하는 것이 모니터링에서는 가장 중요하며, 문제가 생기면 모니터링 시스템은 책임 운영자를 호출할 수 있어야 한다.
2. 디버깅(Debugging)
- 운영자는 문제의 근본 원인을 규명하고, 문제가 무엇이든 간에 반드시 해결해야 한다.
3. 추세 파악(Trending)
- 알림과 디버깅은 보통 몇 분부터 몇 시간까지 시간 단위로 발생한다. 긴급하지 않은 문제인 경우에는 시스템이 어떻게 사용되고 시간에 따라 변화하는지를 확인할 수 있는 기능도 유용하다. 추세 파악은 용량 계획 같은 설계 결정과 프로세스에 영향을 미칠 수 있다.
4. 플러밍(Plumbing)
망치를 갖고 있으면, 모든 것이 못처럼 보이기 시작한다.
- 결국 모든 모니터링 시스템은 데이터 처리 파이프 라인이다. 때로는 맞춤형 솔루션을 만들기 보단 모니터링 시스템의 일부를 다른 목적으로 적절하게 사용하는 편이 더 좋다.
모니터링의 범주
대부분의 모니터링은 이벤트에 대한 것이다.
- 모든 이벤트에는 컨텍스트가 있기 때문에 컨텍스트를 파악하면, 디버깅에 큰 도움이 되고 기술적인 관점과 비즈니스 관점 모두에서 시스템의 수행 방법을 이해할 수 있지만, 처리 및 저장해야 하는 데이터 양이 늘어난다.
- 데이터의 양을 감소시킬 수 있는 방법에는 네 가지가 있다.
1. 프로파일링(Profiling)
제한된 기간의 일부 컨텍스트를 가질 수 있다.
- Tcpdump는 지정된 필터를 기반으로 네트워크 트래픽을 기록할 수 있다.
- 바이너리의 디버그 빌드는 유용한 정보를 제공하지만, 모든 함수 호출의 타이밍 같은 정보를 모두 수집하는 것은 성능에 영향을 미친다.
- 리눅스 커널의 eBPF(enhanced Berkeley Packet Filters)는 파일시스템부터 네트워크 기호까지 커널 이벤트에 대해 상세하게 프로파일링할 수 있다.
2. 트레이싱(Tracing)
- 모든 이벤트를 살펴보는 것이 아니라, 관심 기능을 통과하는 특정 이벤트에만 집중한다.
- 스택 트레이스에서 관심 있는 부분의 함수들을 기록하고, 때때로 이러한 함수들이 얼마나 오랫동안 수행되었는지도 기록한다.
- 트레이싱 시스템 중 일부는 관심 지점에서 스택 트레이스에 스냅샷을 수집하는 대신, 관심 있는 함수 하위의 모든 함수 호출을 추적하고 타이밍을 기록한다.
- 분산 트레이싱은 원격 프로시저 호출에서 한 프로세스에서 다른 프로세스로 전달되는 요청에 고유한 ID를 추가해서, 해당 요청이 추적되어야 하는지 여부 등 프로세스 전반에 걸친 작업을 추적한다. 기술로는 오픈집킨(OpenZipkin)과 예거(Jaeger)가 있다.
- 트레이싱에서 데이터 볼륨 유지 및 계측 성능에 영향을 미치는 것은 샘플링이다.
3. 로깅(Logging)
- 제한된 이벤트 집합을 살펴보고 각 이벤트에 대한 컨텍스트 일부를 기록한다.
- 가장 큰 장점은 일반적으로 이벤트에 대한 샘플링이 없다는 것이다. 따라서 필드 개수를 제한하더라도, 시간이 오래 걸리는 요청이 특정 API 엔드포인트와 통신하는 특정 유저에게 얼마나 영향을 미치는지를 판단해야 한다.
- ELK 스택과 그레이로그(Graylog) 등이 있다.
※ 로깅의 4가지 범주
- 트랜잭션 로그 : 어떠한 대가를 치르더라도 영원히 안전하게 보관해야 하는 중요한 비즈니스 기록
- 요청 로그 : 모든 HTTP 요청이나 데이터베이스 호출을 추적하는 경우의 로그
- 애플리케이션 로그 : 시작 메시지, 백그라운드 유지보수 작업, 그 밖에 프로세스 수준의 로그들
- 디버그 로그 : 주로 매우 협소한 디버깅 상황에만 사용되며, 데이터의 양 때문에 프로파일링의 특성을 띤다.
4. 메트릭(Metric)
- 컨텍스트를 대부분 무시하고 다양한 유형의 이벤트에 대해 시간에 따른 집계를 추적한다.
- 애플리케이션의 각 서브시스템에서의 대기 시간과 처리하는 데이터양을 추적해서 성능 저하의 원인이 정확히 무엇인지 손쉽게 알아낼 수 있다.
반응형
LIST