관측 가능성의 개념과 방향성
시스템을 운영하는 데 모니터링의 역할은 매우 중요합니다. 근래 들어서는 관측 가능성의 소개와 함께 분산 모니터링 솔류션을 통합하고 연계하는 것이 필요해졌습니다. 특히 분산 시스템인 클라우드와 마이크로서비스는 예전에 비해 기술 스택의 종류가 다양하고 복잡해졌으며 그로 인하여 과거의 모니터링으로 새로운 시스템과 아키텍처를 담아내기에는 역부족입니다.
관측 가능성의 세 가지 요소
모니터링과 차이점
관측 가능성(Observability)란 '시스템에서 외부로 출력되는 값만을 사용해서, 시스템의 내부 상태를 이해하고 예측하는 것'입니다.
관측 가능성은 모니터링을 대체하는 개념이 아닙니다. 하지만 유사한 점이 매우 많으며 위의 그림처럼 모니터링은 블랙박스와 화이트박스를 포함하지만 관측가능성은 화이트박스와 예측 영역을 포함합니다. 즉, 관측 가능성이 지향하는 목표는 내부 시스템에 대한 자세한 이해를 기반으로 미래에 발생할 이벤트를 예측하는 것이고, 이러한 예측을 바탕으로 IT운영을 자동화하는 것입니다.
ElasticSearch를 사용하여 로그를 관리하거나 Dynatrace APM을 사용해서 처리량과 지연시간을 모니터링하고, InfluxDB와 Telegraph, 다양한 에이전트를 통하여 메트릭을 수집하고 측정하는 등 이미 많은 회사들이 관측 가능성을 도입하고 사용해오고 있습니다.
관측 가능성에서 API 대신 tracing, Instrumentation(계측)과 Telemetry라는 용어를 범용적으로 사용합니다. exporter, collector등 어려운 용어로 인해서 관측 가능성을 새로운 개념으로 이해하곤하는데, Splunk는 Log, NewRelic은 성능 관리, Prometheus는 Metric에 전문성을 가지고 있습니다.
모니터링 대비 관측 가능성의 특징
- 관측 가능성은 화이트박스 모니터링을 포함하며 블랙박스 모니터링과 다릅니다. 블랙박스 모니터링이 제공하는 정보는 상세하지 못하므로 상세한 디버깅 정보로 활용하기 어렵습니다. -> 관측 가능성의 목적에 부합하지 않음
- 관측 가능성은 애플리케이션 내부의 상태를 디버깅할 수 있는 정보를 제공하므로 장애가 발생했을 경우 신속하고 수월하게 대응할 수 있습니다.
- 관측 가능성에서는 제공된 결과를 보고 이해하는 수준에 그치지 않고, 원하는 계측을 추가할 수 있습니다. 그걸 통해 보다 자세하게 이해할 수 있을 뿐 아니라 향후 발생할 가능성이 높은 장애에 대한 예측이 가능해집니다.
모니터링은 전체적인 시스템 상태를 이해하는 데 적합합니다. '모든 것을 수집하고 모니터링' 하기 보다는 가능한 샘플링을 사용하여 적은 데이터를 수집하더라도 의미 있고 에측 가능한 결과를 도출해 내는 것이 좋은 모니터링 방법입니다.
전톡적인 모니터링은 블랙박스 모니터링을 기본으로 핵심적인 애플리케이션과 시스템 메트릭에 집중합니다. 반면 관측 가능성은 클라우드 네이티브처럼 분산되고 복잡한 시스템에서 발생하는 이벤트에 대한 통할력, tag, log등을 결합해서 서비스에 대한 context 정보를 제공하는 것이 목표입니다. (관측 가능성은 세부적인 시스템 내용을 포함하고 있으므로 디버깅에 더 적합합니다.)
관측가능성은 기본적으로 API, SDK를 제공하며 다양한 언어를 사용해서 개발하고 구현할 수 있습니다. 특히, 클라우드 환경에서는 많은 장애와 에러가 네트워크로 인해서 발생하기 때문에 네트워크 이벤트와 신호를 수집하고 원인 분석과 문제 해결에 활용하는 방안을 마련해야 합니다.
인프라와 네트워크 레벨에서 문제 원인을 이해하고, 이를 해결하는 방법과 절차를 가시성(Visibility)라고 합니다. 예전부터 많은 기업들이 보안 정보와 이벤트 관리(SIEM)을 구축했는데, 가시성은 이벤트 관리를 보함하며 인프라와 네트워크 복원력을 강화합니다. 관측 가능성과 가시성은 서로 다른 영역이지만, 서로를 상호보완하며 밀접하게 영향을 끼치고 전체 IT 시스템 운영을 위한 청사진을 제공합니다.
관측 가능성 구성 요소
메트릭 데이터는 중요한 가용성 신호이며, 추적과 로그는 디버깅에 필수적인 데이터들입니다.
메트릭(Metric)
메트릭은 일정 시간 동안 측정된 데이터를 집계하고 이를 수치화합니다. 예를 들어 큐의 대기(Pending) 메시지 개수, 사용중인 CPU와 메모리의 크기, 서비스에서 초당 처리하는 개수등이 있습니다. 메트릭은 전체적인 시스템의 상태를 보고하는 데 유용하고, 일반적으로 히스토그램 또는 게이지등 차트를 이용하여 시각적으로 표현합니다. 애플리케이션에서 기본으로 제공해주는 메트릭 외에 커스텀 메트릭이 필요한 경우가 있습니다. 이를 위해서 계측 API와 SDK를 사용하여 커스텀 메트릭을 개발할 수도 있습니다.
로그(Log)
로그는 애플리케이션 실행 시 생성되는 텍스트 라인으로 JSON형식이나 text 형식으로 출력됩니다. 로그는 애플리케이션 에러와 경고를 확인하고, 문제점에 대한 정확한 원인을 이해하기 위해서 필요합니다. 로그는 시스템을 이해하는 기본적인 방법을 제공하며, 집계와 알람 중심의 메트릭 시스템이 지원해주지 못하는 세부적인 정보를 제공합니다.
추적(Tracing)
추적은 마이크로서비스가 시스템을 경유하며 트랜잭션을 처리하는 과정에서 발생하는 세부적인 정보를 보여줍니다. 또한, 트랜잭션이 시스템을 이동하는 경로, 트랜잭션을 처리하는 과정에서 발생하는 대기시간과 지연시간, 병목현상이나 에러를 일으키는 원인을 context와 Log, Tag등의 metadata에 출력합니다.
메트릭
구글의 골든 시그널
주요 SLO는 가용성, 지연, 에러가 있습니다. 구글 SRE팀에서는 메트릭을 수집할 때, 4가지 골든 시그널에 집중해야 한다고 강조합니다. 골든 시그널은 주로 네트워크에서 발생하는 이벤트와 많은 연관성이 있으며, 중요한 것에 보다 더 집중할 수 있도록 가이드라인(지연, 에러, 트래픽, 포화등)을 제공합니다.
SLO란?
SLO는 Service Level Objective의 약자로, 서비스 수준 목표를 의미하며, 특정 서비스가 사용자에게 제공될 때 기대되는 성능 및 가용성 수준을 명확하게 정의합니다. 예를 들어, "우리 웹사이트의 가용성은 99.9% 이상이어야 한다"라는 것이 하나의 SLO가 됩니다.
지연(Latency)
빈번하게 발생하는 지연은 에러가 아닌 경우가 많습니다. 시계열, 히트맵, 히스토그램 차트를 통해 지연을 시각화하여 에러와 구분해야 합니다. 사용자가 지연을 자주 경험하면 시스템이 정상적이지 않다는 것을 추론할 수 있습니다. 지연은 잠재적인 장애를 예측할 수 있는 유용한 신호로, 서비스 요청 후 완료까지 걸리는 시간을 측정합니다. 이때 지연이 증가하면 서비스 품질이 저하되는 것을 예측할 수 있습니다. 하지만 지연을 에러와 연관짓는 것은 주의를 기울여야 합니다. 예를 들어, 요청 처리 중에 애플리케이션이 신속하게 응답했지만, 에러가 발생했다고 가정해보면 지연은 짧지만, 기대한 결과가 아니게 됩니다. 에러는 지연없이 빠르게 처리되는 경향이 있고, 정상 응답은 지연을 포함하는 경우가 많기 때문입니다. 1초의 지연을 포함하는 정상응답과 60초의 지연을 포함하는 정상 응답을 동일하다고 판단할 수 없고 60초의 지연은 에러로 판단하거나 timeout으로 처리하는 것이 현명합니다.
에러(Error)
에러라고 판단할 수 있는 기준이 불분명한 경우가 많으므로 에러의 기준을 명확히 설정해야 합니다. 에러는 초기에는 정상(normal)이지만 처음 발견되면 대기(pending) 상태로 변하고 에러가 계속 활성(active) 상태를 유지할 경우 파이러링(firing) 상태로 변하고 알람을 전송합니다.
에러는 문제점과 에러 내용을 직접적으로 출력한다는 점에서 명시적입니다. 하지만 애플리케이션 개발에는 수십 개 유형의 에러가 발생할 수 있으며 이를 분류하고 그룹화하는 과정은 중의적이며, 개인의 경험에 따라서 다르게 판단할 수 있습니다. 즉, 개발자와 운영자의 주관이 개입될 수 있는 여지가 큽니다.
에러SLO을 계산하는 프로메테우스 PromQL
sum(rate(hotrod_frontend_http_requests_total{status_code="4xx"}[{{.window}}]))
/
total_quary: sum(rate(hotrod_frontend_http_requests_total[{{.window}}]))
트래픽(traffic)
트래픽은 발생하는 요청의 양을 뜻합니다. 관찰되는 시스템의 유형, 초당 요청의 수, 네트워크 입출력등에 따라 다양합니다.
트래픽 양이 적을 때는 문제가 없지만 양이 급격하게 많아지거나 임게치를 초과하거나 포화 상태가 되면 지연과 에러가 발생하며, 최종적으로 장애에 이르게 됩니다. 트래픽은 다른 신호와 연관이 많은데, 지연과 에러가 발생하며 중단 없이 적정 수준의 트래픽을 처리할 수 있는 시스템을 구축하는 것이 필요합니다. 나아가 골든 시그널의 원칙은 트래픽의 증가에 따른 지연과 에러를 최소화하고 최종적으로 장애에 이르지 않도록 설계하는 것입니다. 장애가 발생하더라도 사용자 서비스를 제공하기 위한 최소한의 트래픽은 처리해주는 것을 권고하고 있습니다.
네트워크 트래픽을 계산하는 프로메테우스 PromQL
irate(node_network_receive_packets_totla{instance="$ndoe", job="$job"}[$__rate_interval])
포화(saturation)
포화는 리소스가 '현재 얼마나 채워졌는지'와 '얼마나 가득 채울 수 있는지'를 나타내는 것입니다. 전체 총 대역폭과 처리 가능한 트래픽에 대비해서 현재 트래픽 혹은 대역폭이 어느정도 인지 이해할 수 있는 지표인 셈입니다. 포화를 통해 향후 트래픽이 증가했을 경우에 이용 가능한 자원 총 사용률을 예측할 수 있고, CPU, 메모리, 네트워크와 같이 제약이 큰 리소스에 주로 적용합니다.
CPU사용률, CPU 포화율 SLO를 계산하는 프로메테우스 PromQL
(
instance:node_cpu_utilizaion:rate5m{job="$node"}
*
instance:node_num_cpu:sum{job="$node}
)
/
scalar(sum(instance:node_num_cpu:sum{job="$node"}))
CPU 포화율을 계산하는 PromQL
instance:node_load1_per_cpu:ratio{job="node"}
/
scalar(count(instance:node_load1_per_cpu:ratio{job="node"}))
지연 증가는 종종 포화의 선행 지표가 됩니다. 오류와 재시도 메시지가 트래픽에 더해지면서 상황은 더욱 악화되고 이 사이클이 계속 반복되면서 확산해나가 결국 임계치를 넘게되어 트랜잭션이 실패하고, 정상 상태로 복귀했다가 다시 같은 패턴을 반복합니다. 그렇기에 포화 상태가 되지 않도록 시스템을 설계하는 것이 중요한데, 동적인 트래픽에 맞추어 스케일하는 방법(AutoSaciling, Sharding등)을 제공하는 것이 적합합니다. 특히, 네트워크와 시스템이 생성하는 신호는 다양하므로 이를 명확히 구분해야합니다. 신호가 에러, 지연, 정상, 오루, 버그인지 정의하는 작업이 추가로 필요합니다.
SLO 대시보드 개발 시 참고할 사항
- 필수적인 SLO는 에러율(error rate), 지연시간(latency), 가용성(availability)등이 있습니다.
- SLO 대시보드에는 오류 예산과 번 레이트(burn rate)를 다양한 윈도우(분, 시, 일, 월등의 주기)에 따라서 알람과 연계하여 출력해야 합니다.
- 프로메테우스 레코딩 규칙과 알람 규칙으로 구현할 수 있으며 이러한 규칙은 자동 생성 방식을 선호합니다.
- 쿠버네티스 API 서버와 core-DNS, AWS CloudWatch, Datadog등 다양한 데이터로부터 데이터를 수집할 수 있습니다.
클라우드 네이티브를 도입하기 이전 레거시 환경에서는 커스텀 메트릭을 개발하려는 요구 사항이 적었고, 주로 인프라 메트릭에 집중하는 미틀웨어, 데이터베이스 패키지와 관련한 메트릭은 벤더에서 제공받거나, 값 비싼 추가 개발 보수를 지불하고 메트릭을 추가하는 방식이었습니다. 하지만 쿠버네티스, 프로메테우스등 다양한 언어로 개발된 애플리케이션 모니터링등의 등장과 더불어 커스텀 메트릭을 필요로 하는 상황이 시작되었습니다.
관측 가능성과 가시성은 네트워크와 많은 관련이 있습니다. 하지만 네트워크에서 발생하는 데이터는 너무나 방대해서 운영자는 그것이 정상인지, 잡음인지 구분하지 못하는 경우가 대부분입니다. 또한, 최종 사용자가 문제점을 보고하거나 장애에 이르기 전까지 문제점과 방애 발생 가능성을 인식하지 못하는 경우가 발샐합니다.
메트릭 유형
메트릭을 수집하는 동안 모니터링하려고 하는 리소스에 가장 적절한 유형을 결정해야 합니다. 일반적으로 메트릭에는 카운터, 게이지, 요약, 히스토그램의 4가지 유형이 있습니다.
카운터(counter)
카운터는 모니터링하는 이벤트의 누적 개수 혹은 크기를 표현합니다. 일반적으로 rate 함수와 함께 이벤트를 추적하는 데 많이 사용되며, 증감할 수 있는 메트릭을 나타내는 데에는 카운터를 사용해서는 안되고 게이지를 사용해야 합니다.
게이지(gauge)
게이지는 카운터와 달리 증가하거나 감소하는 임의의 값을 나타내는 메트릭이고, '현재 상태'를 표현하는 메트릭 타입입니다.
- 데이터 베이스에 연결된 커넥션 개수
- 현재 동작하는 스레드 개수
- 사용률
요약(summary)
요약은 응답의 크기와 대기 시간을 추적하는 데에 사용하며, 측정한 이벤트의 합게와 카운트를 모두 제공합니다. 범위와 분포에 관계없이 백분위수가 필요하다면 요약이 적합합니다.
히스토그램(histogram)
히스토그램은 시간 경과에 따른 추세와 데이터가 단일 범주(category)에서 어떻게 분포되어 있는지를 나타냅니다. 분위수를 주로 사용하여 분포를 이해하는데, 분위수는 오름차순(혹은 내림차순)으로 정렬되어 있는 전체 자료를 특정 개수로 나눌 때 그 기준이 되는 수입니다.
시계열 데이터
관측 가능성에서는 시계열 데이터를 다루는데, 이를 차트로 표현하고 시각화해야 합니다. 정해진 시간 내의 분포와 변화를 출력하기 위해서 적합한 차트 형식은 히스토그램입니다. 그라파나 히스토그램은 각 범위 내에 있는 데이터 포인트의 수를 표시하여 숫자 데이터를 시각적으로 출력합니다.
로키(Loki)
로키는 히스토그램과 유사한 차트를 사용하며, 이를 통해 특정 시간 동안의 분포를 이해할 수 있을 뿐 아니라 '추적'의 Gantt 화면으로 전환할 수 있습니다.
프로메테우스의 히스토그램
히스토그램에서 버킷은 특정 범위를 의미하며, 이를 활용하면 특정 버킷에 속하는 측정값의 개수(빈도)를 계산할 수 있습니다.
- 히스토그램은 구성된 버킷 1개당 시계열을 생성하고, 관측한 횟수(_count가 붙어있는 시계열)와 관측한 값의 합계 (_sum이 붙어있는 시계열)에 대한 2개의 시계열을 추가로 생성합니다. 이를 통해 관측한 횟수와 관측한 값들의 합계를 함께 관리하기 때문에 관측한 값들의 평균을 계산할 수 있습니다.
- 히스토그램은 관측 결과를 샘플링합니다. 일반적으로 요청 지속 기간(request duration), 응답 크기(response size)를 수집하고 이를 버킷에 저장합니다.
- 히스토그램은 각 버킷마다 이전 버킷의 값에 현재 버킷의 값을 추가하는 형태로 누적됩니다.
- 히스토그램의 x축은 시간, y축은 요청 지속 기간, 응답 크기 등이며 데이터 포인트의 최소, 최대, 합, 평균, 분포등을 구할 수 있습니다.
- 히스토그램의 단점은 선택한 버킷이 수집될 것으로 예상되는 값의 범위와 분포에 적합해야 한다는 것이고, 버킷이 너무 적거나 잘못 선택하면 분위수 계산의 허용 오차가 늘어납니다.
- 그라파나 대시보드의 히스토그램 차트는 프로메테우스 버킷의 값과 일치하므로 히스토그램의 시각화를 쉽게 만들 수 있습니다.
지난 5분간의 요청 지속 시간의 평균을 계산하는 PromQL
rate(tns_request_duration_seconds_sum[5m])
/
rate(tns_request_duration_seconds_count[5m])
SLO는 요청의 95%를 0.1초(100ms)이내에 처리하고 이 수치가 0.95미만으로 내려가면 알람을 생성하는 PromQL
sum(rate(tns_request_seconds_bucket{le="0.1"}[5m])) by (job)
/
sum(rate(tns_request_seconds_count[5])) by (job)
여기서 프로메테우스 카운터 메트릭에 le라는 특수한 태그가 달려 있는데 le(less than or equal to)는 작거나 같다는 의미이고, 초 단위로 기록되며 이 값보다 작거나 같은 모든 샘플의 개수가 메트릭의 값으로 기록되며, 허용(허용치)되거나 목표(목표치)로 하는 요청 지속 시간입니다.
# 히스토그램 상한이 0.1초인 버킷을 구성
{le="0.1"}
# job마다 5분간 요청을 대상으로 비율을 계산
(([5m])) by (job)
# 요청 지속 시간은 tns_request_duration_seconds
rate(tns_request_duration_seconds_bucket)
목표 요청 지속 시간은 250ms이고, 허용 요청 지속 시간은 1.0초이다. job마다 지난 5분간의 Apex(사용자 만족도 특정) 점수를 출력하는 함수
(
sum(rate(tns_request_duration_seconds_bucket{le="0.25"}[5m])) by (job)
+
sum(rate(tns_request_duration_seconds_bucket{le="1.0"}[5m])) by (job)
) / 2 / sum(rate(tns_request_duration_seconds_count[5m])) by (job)
그렇다면 요약과 히스토그램의 차이점은 뭘까? 요약은 클라이언트 측에서 계산하고 분위수당 시계열을 생성하며 히스토그램의 분위수는 서버에서 계산하고 버킷당 시계열을 생성합니다.
250ms이내로 처리한 요청의 비율이 아니라, 요청의 95%가 몇 초 이내로 처리되었는지 표현하는 함수
histogram_quantile(0.95, sum(rate(tns_request_duration_seconds_bueckt[5m])) by (le))
히스토그램 버킷에서 백분위수를 계산할 때는 histogram_quantile함수를 이용해서 계산합니다.
매트릭 관리 방안
메트릭은 단순히 집계 모니터링에 그치지 않고 오토스케일링 등 다양한 분야와 연계되므로 여러 가지 추가적인 설정이 필요합니다. 실제 운영 환경에서는 기본 메트릭만으로는 부족하며, 복잡한 커스텀 메트릭을 사용해서 쿠버네티스 오토스케일링을 수행할 수 있습니다.
이때, 한번에 너무 많은 정보가 전달되지 않고 점진적으로 추론할 수 있게 설정해야 합니다. 즉, 상관 관계를 가지는 차트를 대시보드에 구성하고 도메인/서비스의 흐름대로 차트를 구성하는 것을 추천합니다.
또한, 가능하면 tag를 사용해 메트릭에 상황 정보를 포함해야 합니다. 환경, 테넌트의 태그는 메트릭과 연계할 수 있으며 예를 들어 테넌트 태그가 지정된 응답시간을 선택하거나 테넌트별로 값을 그룹화하여 특정 사용자 또는 특정 그룹의 사용자가 응답 시간의 증가를 경험하는지 등 상세하게 필터링해서 확인할 수 있습니다.
추적
추적 구성 요소
스팬(span)
전반적인 수행 시간 정보 뿐만 아니라, 각기 하위 동작의 시작과 소요 시간 정보를 알 수 있습니다. 스팬은 동작 정보, 타임라인과 부모 스팬과의 의존성을 모두 포함하는 수행 시간을 담고 있습니다. 또한, 스팬은 태그, 로그, 스팬 콘텍스트, 배기지 정보를 담고 있습니다.
스팬 콘텍스트(span context)
새로운 스팬을 생성하기 위해서는 다른 스팬을 참조해야 하는데, 스팬 콘텍스트는 이때 필요한 정보를 제공합니다. 스팬 콘텍스트로 표현된 메타데이터를 쓸 수 있는 Inject와 읽을 수 있는 Extract 메서드를 제공합니다. 즉, 스팬 콘텍스트는 주입과 추출을 통해 헤더에 전달되며, 전달된 스팬 콘텍스트에서 추출한 스팬 정보로 새로운 자식 스팬을 생성할 수 있습니다.
스팬 레퍼런스(span reference)
두 스팬 사이의 인과관계를 의미합니다. 스팬 사이의 인과 관계를 정의하고, 스팬들이 동일한 추적에 속한다는 것을 trace가 알게 하는 것 입니다. 스팬 레퍼런스에는 child of와 following from 두 가지 유형이 있으며, span A가 span B의 부모인 것을 의미하려면 span B는 span A의 child of이거나, span A의 following from이라고 정의할 수 있습니다.
배기지(baggage)
다수의 스팬에 전달되고 공유되고 있는 값으로 HTTP 헤더에 위치합니다.
캐리어(carrier)
내용물을 담는 공간을 의미하며, 반입하는 것을 주입(inject), 반출하는 것을 추출(extract)라고 표현합니다.
컨텍스트 전파(context propagation)
실제 전송은 HTTP와 같은 전송 프로토콜을 기반으로 이루어지며, 추적에서는 이를 콘텍스트 전파라고 합니다.
로그
로그 관리
로그 관리의 일차적인 목적은 시스템에 분산되어있는 로그를 한 곳에서 저장하여 다루기 쉽게 하는 것입니다. 일단 로그를 중앙 집중화하여 수집하고 관리하며, 다양한 로그 유형을 표준화하는 작업을 거쳐야 합니다.
로그 수집
로그 관리 시스템의 목적은 모든 서비스에서 로그 데이터를 수집하여 필요할 때 시스템의 동작을 추론하고 검색하는 것입니다.
로그 표준화
일관된 형식의 로그 데이터는 효과적으로 저장하고 가공하고 검색하는 데에 도움이 됩니다.
로그에 포함할 유용한 정보
- 타임스탬프
- 식별자
- 소스
- level or category
로그 표준화
오픈텔레메트리의 로깅 신호는 로깅 인터페이스 표준화와 관련이 없습니다. 많은 언어에서 이미 확립된 로깅 API가 있으며, 오픈텔레메트리 초기에 이러한 기존 도구를 활용했었습니다. 로깅을 생성할 수 있는 API는 제공하지만, 기존 로깅에 연결을 하려는 의도였습니다. 해당 로그를 다른 신호(메트릭과 추적)와 상관시키는 것에 초점을 맞추는 것이었습니다.
Emitter를 사용해서 로그로 전송하는 내용을 선택할 수 있고, Exporter를 사용해서 수신받는 로그의 내용을 선택할 수 있습니다.
LogEmitterProvider
하나 이상의 로그 emitter를 인스턴스화하는 메커니즘을 제공
LogEmitter
LogRecord 데이터를 생성
LogExporter
LogRecord를 사용하고 데이터를 백엔드로 보냄
로그 관리 요약
- 각 시스템에 분산되어 있는 로그를 어떻게 수집하고 통합, 관리할 것인지를 먼저 정해야 한다.
- 각 애플리케이션은 다른 로그 형태를 가지고 있으니, 어떻게 로그 형식을 표준화하고 단일화할 것인지가 중요하다.
- 구조적 로그는 JSON을 사용하는 것이 일반적이고, 레거시 시스템은 비구조적이고 단순한 텍스트 파일 형태로 구성되어 있다.
- 오픈텔레메트리 로그 개발 시에는 구조화된 로그를 생성하는 법과 오픈텔레메트리와 연계하는 것이 중요하다.
'스터디 이야기 > Observability' 카테고리의 다른 글
| 트래픽 관리 - 로드 밸런서 (1) | 2024.08.18 |
|---|
