Observability란?

Tracing vs Monitoring vs Observability

Tracing

프로그램의 실행 과정을 상세히 남기는 것이다.

• 호출하는 메소드의 시작 시간과 끝 시간을 남겨서 걸린 시간을 계산할 수 있게 하는 것.
• 에러 발생시 Stacktrace
• network ping 의 router trip 경로

Tracing 정보는 상세히 남길수록 어플리케이션이나 시스템에 부하를 주거나, 데이터를 많이 사용하게 되므로 무분별하게 사용하거나 남기면 안된다.

Monitoring

에러, 다운타임, 비정상 상태 등을 감지하기 위해서 이벤트, 메트릭 정보들 남기고 추적하는것을 말한다. 모니터링의 방식은 크게 메트릭 모니터링과 로그 모니터링으로 나눌 수 있다.

• Metric monitoring

특정 기간이나 범위의 성공/실패 상태를 모니터링
목표치 대비 성능의 상태나 관계를 모니터링
메모리 사용, 초당 요청, 활성 연결, 흐름, 오류 수

• Log monitoring

관심 있는 이벤트 데이터를 남기고 구체적 내용을 살피는 방식.
이벤트 데이터를 분석
filter → aggregation → metric
텍스트 검색, 필터 검색

Observability

최초에는 시스템의 내부 상태에 대해서 직접 들어가서 확인하는 것이 아니라, 쌓여있는 데이터를 연결하고 추론해서 확인할 수 있게 한다는 개념으로만 쓰였다.
최근에는 IT시스템이 복잡해지면서 여러 구성요소들간에 상호작용 하는 가운데, 각 컴포넌트의 범위를 넘어서서 HW, OS, SW, Cloud infra 등의 모든 데이터를 활용해서 어플리케이션의 상태부터 시스템 전체의 상태를 확인, 이상감지, 원인 추론까지 하는 것을 포괄하는 개념을 쓰이고 있다.

Observability 가 가능하기 위해서는 세가지 성격의 데이터가 필요하다.

1. Trace: 데이터의 흐름에 대한 정보를 파악하기 위한 데이터
2. Log: 이벤트 정보
3. Metric: 일정 기간 걸쳐 측정된 성능, 수치 데이터

Observability 를 위해 필요한 것

운영 데이터의 중요성

모든 시스템은 어떤 기능이나 서비스를 하기 위해서 동작하고, 그 목적을 달성하는 지를 지속적으로 관찰할 필요가 있다.
실제로 서버가 죽었는데도, 아니면 배포버전이 다른데도 며칠 동안 모르고 운영되는 시스템들이 많다. 코드를 개발하는 것 만큼이나 운영하면서 데이터로 확인하는 것도 중요하다.

Tracing, Monitoring, Observability 무엇이든 그것을 하려면 데이터가 남아야 확인할 수 있다. 데이터가 있어야 분석할 수 있고, 데이터가 남아야 자동화를 할 수 있다.
작은 시스템이라도 그 시스템의 개발자가 운영하면서 어떤 데이터가 필요할지를 고민하고, 그것을 어떤 도구를 통해서든 남기도록 개발이 되어야 한다.
이미 데이터를 수집하는 통합된 시스템이 있다면, 그것에서 수집할 수 있는 채널(port, path, agent설치 등)을 열어둘 수 있도록 최소한의 설정이 필요하다.

지속적인 데이터 observability 경험

데이터를 남겼으면 지속적으로 확인해야한다. 이상이 있는데 데이터로 확인이 안되는 경우가 있다. 이런 경우에 어떤 데이터가 필요한지 정의하고 추가로 데이터를 남길 수 있도록 개발해야 한다. 지속적으로 데이터를 남기고 확인하다 보면, IT 시스템 전체에 대한 이해가 높아질 뿐만 아니라 문제 해결과정 또한 빨라진다.

시스템에 대한 이해

좋은 Observability를 위해서는 필요한 데이터가 조회하기 적절한 형태로 남아야한다. 그렇기 위해서는 구축되어있는 IT 시스템, 각 어플리케이션의 내부 구조, 로직, 사용 목적이나 용도에 따라서 데이터를 남겨야 한다. 그러기 위해선 결국 그 시스템이 어떻게 구성되어있는지 어떤 과정으로 기능하는 지를 알아야 어떤 데이터를 확인할 수 있는 지 알게 된다. 따라서 제대로 된 모니터링, observability 를 하려면 사용하는 시스템에 대한 조금 더 깊은 이해, 데이터에 대한 사용이 같이 이루어 질 수 밖에 없다. 이것이 어렵다면, 각 시스템마다 모니터링까지 갖추어진 관리형 도구를 비싼 비용을 내면서 쓸 수 밖에 없다.

대표적인 Observability 도구들

Observability 도구가 갖춰져야 Observability 가 가능하다고 할 수는 없다. 이미 제각기 남기고 있는 데이터로 본능적으로 Observability 활동을 하고 있을 수도 있다.
여기서 소개하는 도구는 Tracing, Log, Metric 데이터를 남기거나 수집할 수 있는 도구를 갖추고, 통합된 분석 환경을 제공하는 것을 꼽았다.

Opentelemetry

• 오픈소스로 만들어지는 통합 observability 스택이다.

• Tracing, Metric, Logs 수집해서 통합된 모니터링, 분석 환경을 제공한다.

• 여러 언어별로 instrument sdk 를 제공하고, 여러 인프라 환경(또는 제품)별로 collector 또한 개발되어 있다.

• 전용 OpenTelemetry protocol (OTLP) 프로토콜을 정의해 놓았다. 이 프로토콜에 맞추어 직접 agent, collector등을 구현할 수 있다. opentelemetry 를 중심으로 통합된 수집, observability 환경을 구성할 수 있다. (호환성, 확장성)

• 비교적 큰 규모의 observability 환경을 구축하고자 할 때 선택하기 가장 좋은 대안이다.

Datadog

• Cloud에서 운영되는 Observability 제품이다.

• AWS, Azure, GCP 등에 쉽게 integration 할 수 있다.

• 각 언어나 플랫폼 별로 데이터 수집을 위한 agent 들도 제공하고 설치도 쉽다. - 웹, 앱부터 백엔드까지 통합해서 모니터링하고 병목이나 장애지점을 진단할 수 있는 것이 큰 장점이다.

Dynatrace

• 오래전 APM분야부터 시작한 회사이다. Java Tracing 도구들의 기능이 더 상세하고 성능이 좋은 편이다.

• Datadog 와 마찬가지로 Full stack observability 를 제공하거나 제공하려고하고 있다.

• Cloud 뿐만 아니라 On-premise 도 부분적으로 제공한다.

모니터링 해야할 대상

host machine (물리적인 컴퓨터)

모든 프로그램은 컴퓨터에서 돌아간다. 기본적으로 해당 컴퓨터의 상태를 모니터링 할 수 있어야 한다. 아래 내용은 Physical machine, Virtual Machine, Container 환경에 모두 적용된다.

• running 여부
• cpu usage (cpu 사용 정도)
• memory usage (메모리 사용 정도)
• disk usage (디스크 사용 정도)
• network I/O (IOPS)

OS 상태

개발자가 개발한 프로세스는 자원을 운영체제로부터 할당받아서 사용한다. 운영체제가 가용한 자원이 없다면 내 프로세스가 영향을 받는다. 반대로 내 프로세스가 운영체제의 자원을 너무 많이 사용하면 다른 프로세스에 영향을 미친다.
데이터 엔지니어는 분산시스템을 많이 사용하고, 대용량 처리를 위해서 리소스 매니저 등을 사용하기 때문에 OS 상태지표에 대한 관심이 필요하다.

• FD(File Descriptor) count

FD가 많이 열려있으면 connection이 너무 많이 물려있어서 시스템에 좋지 않다.

• socket status and count
• cpu,memory,disk per cgroup(container group)

Process/Application 상태

개발한 프로세스의 상태를 확인할 수 있어야 한다. 여기에는 이벤트 로그, 메트릭, 트레이스 모두 포함된다.

• cpu, memory, disk usage of process
• open FD count in process
• 사용하는 프레임워크 레벨에서 진단이 필요한 정보
• 내 어플리케이션의 로직이나 상태를 확인하기 위한 정보

인프라 환경 정보

분산 리소스 매니저를 쓴다면, 내 어플리케이션은 해당 인프라에 종속되어있기 때문에 해당 인프라의 환경을 확인할 수 있어야 한다.
예를 들어, 내 어플리케이션이 시작되지 못하는 이유가 리소스가 부족해서 일 수 있지만 해당 시스템이 운영체제나 machine 과 버전이 안맞거나 crash 가 나는 것으로 process가 영향 받을 수도 있다.
대표적으로 Yarn, kuberentes 등이 있다. 이것은 해당 시스템의 아키텍처나 구성요소에 따라서 남아야할 정보가 다르다.
기본적으로는 해당 시스템이 내 프로그램에 할당한 id 정보는 필수로 같이 남아야 한다.