[Monitoring] Signoz

Observability? Monitoring?

• Observability
  • 시스템 외부 출력의 결과값에서 시스템 내부 상태를 얼마나 잘 추론하는지 나타내는 척도
• Monitoring
  • 대상을 감시, 관찰하는 뜻으로 대상의 상태나 가용성 변화를 감지하는것

→ 여러 Monitoring serivce들의 Observability를 비교하여 Monitoing system을 구축하자.

• Observability가 필요한 이유?
  1. 문제 원인을 파악하는 데이터는 무엇이고, 이는 어디에 있으며, 데이터를 어떻게 봐야하는가?
  2. 근본 원인을 어디서 찾아야하는가?
  3. 개발팀이 고객이나 지원,운영팀보다 서비스 이상 증상을 먼저 알려면 어떻게 해야하는가?
  4. 로그 또는 APM(Application Performance Monitoring)형태로 이를 확인할 수 있는가?

Signoz 정의

• Log, Metric, Traces 등의 시스템이 생성하는 데이터 항목을 기반으로 시스템의 현재 상태를 측정
• 엔지니어나 운영자는 Observability에서 생성된 데이터를 사용해 시스템 동작을 잘 파악하고 문제를 빠르게 감지할 수 있다.
• 애플리케이션 측정 데이터를 활용해 시스템 성능을 최적화할 수 있다.

Signoz 기능

• latency, requests per second, error rates같은 애플리케이션 지표를 모니터링 할 수 있다.
• CPU 이용이나 메모리 사용같은 인프라 지표도 관찰 가능
• 서비스 전반에 사용자 리퀘스트를 추적할 수 있다.
• 지표 알람 설정가능
• 문제를 일으키는 정확한 추적에 가서 문제 근본 원인을 찾을 수 있다.
• 개별 리퀘스트 추적의 자세한 flame 그래프도 볼 수 있다.

아키텍처

구성 요소

• Signoz Opentelemetry Collector (Agent, 수집기)
  • Jaeger Receiver
  • Kafka Receiver
  • OpenCensus Receiver
  • OTLP Receiver
  • Zipkin Reveiver
• ClickHouse
  • 데이터 저장소, OLAP 데이터베이스 관리 시스템
• Query Service
  • Frontend와 Clickhouse 사이의 인터페이스
  • 프론트엔드 애플리케이션에서 사용할 API를 제공하고 Clickhouse에 쿼리를하여 데이터를 처리
• Frontend
  • 리액트로 이루어진 UI로 고급 추적 및 범위 필터링 기능 등 다양한 기능 제공
• Alert Manager
  • 사용자가 설정한 규칙, 임계값을 초과하면 경고를 트리거 한다.

장점

단일 도구

• ELK (metric,file beats + Elasticsearch + Kibana) Prometheus Stack(Prometheus + Grafana + node exporter)
  위 두가지는 유지관리 가 어렵다.
• signoz는 여러 기능을 하나로 통합해 단일 애플리케이션에서 메트릭을 확인하고, 추적하는 단일 창을 제공

Opentelemetry 및 호환성

• signoz는 opentelemetry 표준을 사용하여 다양한 언어, 프레임 워크를 지원한다.
• OpenTelemetry를 통해 수집된 메트릭, 로그 등 데이터를 선택된 백엔드로 export할 수 있다.
• Grafana로 마이그레이션 하기 수월하게 구성함 (연동 가능)

자체 호스팅

• Datadog, Newrelic은 에이전트를 인프라에 설치하여 수집된 데이터를 중앙 서버에 보내는 saas형태로 서비스를 제공하고 해당 데이터를 외부로 노출할 수 없는 환경이지만
• signoz는 자체 호스팅을 통해 private 환경에서도 무료로 구축하여 사용할 수 있다.

기능

Services

• 애플리케이션 메트릭 정보 확인 가능
• 기본적으로 signoz-otel-collector를 통해 각 애플리케이션의 데이터를 수집하여 제공
• 메트릭 종류
  • Application Metrics, External Calls, Database calls
• 메트릭 정보
  • P99 latency(in ms): 애플리케이션이 가장 빠른 99%의 요청을 각각 처리하는데 소비하는 시간
  • Error Rate(% of total): 실패한 request의 백분율, 총 요청에 대한 오류 요청의 비율
  • Operations Per Second: 애플리케이션이 초당 처리하는 request 수

Traces

• 앞서 Services에서 측정된 애플리케이션의 데이터를 기반으로 분산추적 데이터 및 Span 구성
  (Span: 시스템에서 발생하는 작업 일부분을 나타내며, Span간의 관계를 통해서 요청의 전체 흐름을 파악할 수 있다.)
• 용어
  • Trace ID, Time, Focus, Main Content Area, Span Detail

Logs

• signoz는 Open Telemetry를 통해 수집된 데이터를 clickhouse에 저장하기 위해 OTLP 형식으로 데이터를 처리하고 전송한다.
• 수신 방식
  • OTLP Receiver
  • Filelog Receiver
  • Fluent Forward Receiver
  • TCP Receiver
  • UDP Reciever
  • Syslog Receiver

DashBoards

• 수집된 메트릭 정보를 바탕으로 대시보드를 생성하고 보여준다.
• 대시보드 및 패널을 설정할 수 있고 Query에 해당하는 메트릭이 존재하면 이를 출력한다.

Alerts

• 쿼리를 작성하여 Alert를 한다.
• Query Builder
  • 드롭다운에서 메트릭을선택하여 알림을 작성한느 DIY 방식
• PromQL
  • Prometheus 쿼리 언어를 사용하여 경고 알람 설정 가능
• Clickhouse Queries
  • Signoz 데이터 모델 및 형식을 준수하는 Clickhouse 쿼리를 작성 가능

Prometheus + Loki + Grafana Stack (PLG)

Agent

• Pull-Based Monitoring
  대상 서버에 설치된 Exporter가 메트릭 정보를 수집하고, 이 데이터는 수집 서버가 주기적으로 가져오는 구조
  즉, 서버가 클라이언트의 데이터를 수집하는 pull 방식
• Prometheus와 Exporter의 관계는 Prometheus가 주기적으로 Exporter에 요청을 보내서 metric을 수집하는 관계
• Loki는 Agent인 Promtail에게 요청을 보내는 대신 Promtail로부터 전송되는 로그를 수신, Grafana로부터 오는 로그 쿼리 요청에 대해 처리한 결과를 응답한다.

Metric

1. Node Exporter - Prometheus - Grafana (서버 Pull 방식)
2. Mimir
   1. 수평 확장이 가능하여 Block Storage에 데이터를 저장하는게 아닌 장기스토리지(S3, Minio)에 저장함으로써 비용 효율적으로 시계열 메트릭을 보관할 수 있다.
      다만, 장기스토리지이기에 성능 튜닝을 하지 않으면 느리고 OOM이 발생ㅇ할 수 있따.

Log

• Promtail - Loki - Grafana (Agent Push 방식)
• Loki
  • Full Text Search인 Elasticsearch는 Block storage에 샤딩하여 로그를 저장하기에 빠른 속도로 조회할 수 있지만 관리 및 유지보수에 힘들다.
  • Loki는 S3 path는 설정하면 끝이라 비용 효율적이고 간편하지만 Object Storage를 사용하기에 블록 스토리지보다 상대적으로 느리다는 단점이 있다.
  • 로그에 대한 메타데이터인 레이블을 인덱싱하여 사용해 속도를 조금이라도 빠르게 한다.

Trace

• LGTM: Loki(로그) + Grafana(시각화) + Mimir(메트릭) + Tempo(트레이스)
• Tempo
  • Object Storage를 사용한다.
  • 아직 초기 단계라 미성숙하다.

HA

• Thanos
  • 클러스터링 구조를 지원하지 않기 때문에 확장성 가용성을 위해 Prometheus의 메트릭을 장기 저장하고 HA 구성을 도와주는 오픈소스이다.

ELK Stack

Agent

Metric

• Metric beat

Log

• filebeat

Trace

• packet beat, Jaeger, zipkin

크기 비교

Resource TypeCpu RequestCpu LimitMemory RequestMemory Limit

FileBeat	100m	1000m	100Mi	200Mi
MetricBeat	100m	1000m	100Mi	200Mi
fluent-bit	5m	50m	10Mi	60Mi
fluentd	100m		200Mi	500Mi
Logstash	100m	1000m	1536Mi	1536Mi
Elasticsearch	1000m	1000m	2Gi	2Gi
Kibana	1000m	1000m	2Gi	2Gi
Prometheus	500m	500m	512Mi	512Mi
Grafana	100m	100m	128Mi	128Mi

Monitoring Push & Pull 방식

Pull 방식

• Prometheus, Datadog
• 에이전트 자체에 메트릭 정보가 포함되어 있다.
• 에이전트는 메트릭을 수집하며, 수집된 데이터는 중앙서버가 에이전트에서 긁어간다.
• 분산형 (중앙시스템은 에이전트가 보내주는 데이터를 긁어갈 수 있으며, 어떤 데이터를 수집할지 중앙에서 변경할 수 없다.)

Push 방식

• ELK, Nagios, Zabbix
• 메트릭은 중앙에서 정의되고 할당된 에이전트에 푸시한다. 수집된 데이터는 에이전트가 중앙 서버로 보낸다.
• 중앙집중형 (중앙 모니터링 시스템이 데이터 수집항목, 수집할 서버를 모두 관리하고 있다.)

수집대상이 Auto-scaling으로 가변적일땐 Push

• 새로운 수집 host가 추가될 경우 push방식은 전송된 데이터를 받기만 하면 되지만 Pull은 중앙서버가 pull해갈 host 목록들을 관리하여야 한다.

보안 측면은 Push

• pull 방식은 수집 대상 서버에서 중앙 폴러가 접근할 수 있는 포트, IP 등을 수신 대기해야한다.

HA 측면에서는 Pull

• 중앙 서버에 장애가 발생 시 pull은 수집 host에서 영향이 없지만 push는 데이터 전송 재시도 등 host에 영향이 생긴다.

Ps.

OLTP

• Online Transaction Processing
• 네트워크 상의 온라인 사용자들의 Database에 대한 일괄 트랜잭션 처리를 의미한다.
• 트랜잭션의 특징으로 그루핑된 연산의 실패시, Rollback이 지원된다.
• https://www.oracle.com/kr/database/what-is-oltp/

Transaction

• 데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위
• DML(Data Manipulation Language, SELECT, INSERT, UPDATE, DELETE)를 통해 데이터 베이스에 접근하는것을 의미한다.
• AICD
  • Atomicity: 트랜잭션이 데이터베이스에 모두 반영되거나 아니면 반영되지 않아야한다.
  • Consistency: 트랜잭션의 작업 처리 결과가 일관성이 있어야한다.
  • Isolation: 트랜잭션이 동시에 실행되는 경우 어떤 하나의 트랜잭션이라도, 다른 트랜잭션의 연산에 끼어들 수 없다.
  • Durability: 트랜잭션이 성공적으로 완료된 경우 결과는 영구적으로 반영되어야한다.

참고

https://insight.infograb.net/blog/2023/05/25/gitlab-korea-observability/

https://www.youtube.com/watch?v=4vFkyY86FBY&t=302s