Observability
Observability is a property of a system that describes the degree to which its internal state can be inferred from external outputs.
Observability는 시스템의 내부 상태를 외부 출력으로부터 추론할 수 있는 정도를 나타내는 시스템의 속성입니다. 특히 마이크로서비스 아키텍처와 같은 현대 분산 시스템에서 Observability는 시스템 동작을 이해하고, 장애를 진단하며, 성능을 최적화하는 데 매우 중요합니다. 이는 모든 가능한 시나리오에 대해 미리 대시보드나 알림을 정의할 필요 없이 시스템에 대한 임의의 질문을 할 수 있는 능력을 제공함으로써 기존 모니터링을 뛰어넘습니다. Observability의 세 가지 주요 기둥은 다음과 같습니다: 1) Logs: 시스템 내에서 발생하는 개별 이벤트의 타임스탬프가 찍힌 기록입니다. 2) Metrics: 시간 경과에 따른 시스템 성능의 수치적 표현 (예: CPU 사용량, 요청 지연 시간, 오류율). 3) Traces: 분산 시스템을 통한 요청의 여정을 엔드투엔드로 표현하며, 여러 서비스에 걸친 흐름과 타이밍을 보여줍니다. 이러한 데이터 소스를 상관시킴으로써 엔지니어는 복잡한 상호 작용에 대한 깊은 통찰력을 얻고, 성능 병목 현상을 식별하며, 찾기 어려운 오류를 디버깅하고, 변경의 영향을 이해할 수 있습니다. 효과적인 Observability는 고차원 데이터를 방출하기 위해 애플리케이션과 인프라를 계측하고, 이러한 다양한 데이터 유형을 수집, 저장, 쿼리 및 시각화할 수 있는 도구를 사용하는 것을 필요로 합니다. 트레이드오프에는 포괄적인 계측 구현의 비용 및 복잡성, 대량의 텔레메트리 데이터 관리, 효과적인 분석 워크플로우 구축에 필요한 엔지니어링 노력 등이 포함됩니다.
graph LR
Center["Observability"]:::main
Rel_scalability["scalability"]:::related -.-> Center
click Rel_scalability "/terms/scalability"
Rel_service_mesh["service-mesh"]:::related -.-> Center
click Rel_service_mesh "/terms/service-mesh"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 5살도 이해할 수 있게 설명
Observability는 컴퓨터 시스템에 대한 초능력 X-ray 비전과 같습니다. 복잡한 시스템에서도 내부에서 정확히 무슨 일이 일어나고 있는지 볼 수 있게 해주어 문제를 신속하게 찾아 해결할 수 있습니다.
🤓 Expert Deep Dive
Observability enables effective debugging and performance analysis in complex, dynamic environments by allowing engineers to formulate hypotheses about system behavior and test them using telemetry data. While monitoring focuses on known unknowns (predefined alerts and dashboards), observability addresses unknown unknowns by providing rich, contextual data. Distributed tracing, often implemented using standards like OpenTelemetry, is key for understanding request lifecycles across microservices, revealing latency contributions and failure points. High-cardinality metrics and structured logging are essential complements. The 'three pillars' model is a useful heuristic, but the goal is unified analysis. Architectural trade-offs include the choice between vendor-specific solutions and open-source stacks, the cost of data storage and processing, and the engineering investment in instrumentation quality and data [governance](/ko/terms/data-governance). Potential vulnerabilities lie in insufficient instrumentation, data sampling strategies that miss critical events, and the complexity of correlating disparate data sources effectively.