본 포스팅은 "Opentelemetry로 Kubernetes Observability 확보하기" 시리즈의 2번째 글입니다. 저번 포스팅에서 Opentelemetry를 사용해 Logging에 대한 가시성을 확보하는 방법에 대해 알아봤습니다. 이번에는 Three pillars of observability의 Logging, Metric, Tracing 중 Metric에 대한 가시성을 Opentelemetry로 확보하는 방법에 대해 알아보도록 하겠습니다. 기존에는 Metric을 수집,관리하기 위해 CNCF 재단의 Opensource 도구인 Prometheus를 주로 사용했는데요, 이번 포스팅에서는 Prometheus가 아닌 Grafana에서 출시한 Mimir를 사용해서 Metric을 관리해보겠습니다. 그래서 ..
Observability를 확보하는 것은 시스템 및 소프트웨어를 유지하는데 필수적인 행위입니다. Three pilars of Observability로 불리는 Log, Metric, Trace 3가지 Telemetry 데이터를 수집하고 관리하는 것이 Observability를 잘 확보한 것이라 할 수 있는데요. 이렇게 3개의 요소들을 바탕으로 Observability를 확보하고자 할때 허들이 되는 요소 중 하나는, Telemetry 데이터의 프로토콜이 Observability 서비스 및 플랫폼마다 다르다는 것입니다. 이 때문에 Corrleation이라고 하는, Telemetry 데이터 간 연동이 힘들고 수집한 데이터들을 한 곳에서 가공 및 관리하는 것이 불가능했었습니다. 이러한 문제를 해결하기 위해 벤더..
Prometheus는 CNCF의 몇 안되는 graduate 프로젝트 중 하나인 시계열 모니터링 시스템입니다. 이런 Prometheus는 일반적인 VM 환경에서도 사용할 수 있지만 Kuberenetes에서 사용하는 MSA 구성에도 사용할 수 있다는 장점 이 있는데요. 하지만 Kubernetes 환경은 비영구적이고 임시적인 Pod를 기반으로 이루어져 있기 때문에 Prometheus를 구성하는 요소와 Prometheus의 메트릭 수집 대상들을 관리하기가 힘들다는 특징이 있습니다. 게다가 Prometheus는 시스템 내부의 yaml Config 파일을 기준으로 설정을 유지하는데, 이는 컨테이너 내부의 파일을 변경하기가 번거로운 Kubernetes 환경에서 Prometheus 관리를 더 힘들게 하는 원인이었습니다..
우리가 관측 가능성(Observability)에 대해서 말할때, 보통 시계열의 수치 데이터를 뜻하는 메트릭(Metric)이나 인간이 읽을 수 있는(human-readable) 형태로 상태를 출력하는 로그(Log)를 떠올릴 것입니다. 하지만 관측 가능성의 3개 기둥(Three pilars of observability)라고 하는 3개 주요 관측 가능성 요소 중에는 메트릭,로그와 함께 트레이스(Trace)가 존재합니다. 이 트레이스가 무엇인지, 또 어떻게 트레이스에 대한 관측 가능성을 확보할 수 있는지 대표적인 트레이싱 OSS 도구인 Grafana tempo와 함께 알아보겠습니다. 1. 트레이스가 뭐지? 트레이스는 메트릭, 로그와 함께 관측가능성의 3개 주요 요소 중 하나입니다. 하지만 트레이스에 대해서는 ..
EFK stack이란 Elasticsearch, Fluentd, Kibana를 얹은 스택을 말합니다. 기존의 ELK stack과는 로그 파이프라인 역할을 하던 Logstash를 Fluentd로 대체했다는 차이점이 있습니다. 그럼 Fluentd를 사용한 EFK stack은 ELK stack과 어떤 점이 다른지, 각자 어떤 장단점이 있는지 살펴보겠습니다. 그리고 Kubernetes 환경에서 EFK stack을 구축해 컨테이너 로그를 중앙화하는 실습도 함께 보도록 하겠습니다. 1. Fluentd란? 우선 Fluentd가 어떤 툴인지 먼저 알아봐야 겠습니다. 가장 먼저 Fluentd를 만나볼 수 있는 곳은 CNCF 프로젝트인데요. fluentd는 몇 안되는 CNCF의 graduated project 중 하나입니..
AWS, GCP, Azure 등의 퍼블릭 클라우드를 사용하다보면 마주하게 되는 꼭 난감한 상황이 있습니다. 내가 어떤 클라우드 리소스를 생성했는지, 어디에 어떤 리소스를 추가했는지 파악하지 못하는 경우가 있다는 것입니다. 특히 관리해야 하는 퍼블릭 클라우드 리소스의 규모가 크고 방대할수록 이 문제는 심화되는데, 퍼블릭 클라우드는 리소스의 사용량만큼 비용을 지불해야 하는 구조이기 때문에 이는 재정적으로 큰 문제로 다가올 수 밖에 없습니다. 이같은 문제는 보통 내가 관리하는 퍼블릭 클라우드 리소스의 Observability, 즉 관측가능성을 확보하지 못할 때 발생하게 됩니다. 즉 관측가능성이 어플리케이션이나 인프라에서 말하는 메트릭, 로그, 트레이스 뿐만 아니라 클라우드 리소스에도 통용될 수 있다는 말입니다..
멀티 클라우드 환경이 점점 대세가 되어가면서 자연스럽게 다양한 클라우드 플랫폼의 로그 및 메트릭을 중앙화하려는 시도들이 많아지고 있습니다. 각 클라우드 벤더마다 사용하는 로깅, 혹은 모니터링 환경(AWS의 Cloudwatch, GCP의 Operations)이 다르기 때문에 각기 다른 환경을 통일해야만 통합된 관측 가능성을 확보할 수 있기 때문입니다. 이런 각기 다른 관측 가능성 환경을 통합하는 도구로 주로 사용되는 것이 Elastic 사의 Elasticsearch입니다. Elasticsearch는 주로 데이터 처리 파이프라인인 Logstash와 데이터 시각화를 이용한 대쉬보드 도구인 Kibana와 같이 사용되어 이 세 가지 도구를 ELK Stack이라고도 부릅니다. ELK Stack은 OSS이고 컨테이너..
본 포스팅은 GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(2)에서 이어지는 글입니다. GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(2) GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(1) 이번 GKE에서 관측 가능성 확보하기 시리즈의 마지막 포스팅입니다. 지금까지 GKE Cluster의 다양한 메트릭을 수집할 수 있는 Prometheus와 이 메트릭을 대쉬보드 형태로 구성해주는 Grafana까지 설치를 마쳤습니다. 이로 인해 시계열 데이터(Time-series data)에 대한 관측 가능성을 확보하는 성과를 이루었습니다. 하지만 마지막으..
본 포스팅은 GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(1)에서 이어지는 글입니다. GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(1) 저번 포스팅에서 우리는 GKE Cluster의 관측 가능성을 확보하기 위해 Kubernetes 모니터링 툴인 Prometheus를 설치하고 사용해봤습니다. 이번 포스팅에서는 Prometheus에서 수집한 다양한 메트릭들을 보기 쉽도록 데이터 시각화(Data visualization) 툴인 Grafana를 이용해 대쉬보드를 구성해보겠습니다. 물론 저번 포스팅에서 봤듯이 Prometheus만으로도 메트릭을 기반으로 한 데이터 시각화는 가능했지만, Grafana의..
MSA 구조를 운영하고자 할 때 가장 힘든 것은 수 많은 마이크로 서비스에 대한 관리와 운영일 것입니다. 하지만 리소스가 어떤 상태인지 모르고 관리와 운영을 한다는 것은 어불성설이겠죠. 그래서 Kubernetes 등의 MSA 구조를 운영하고자 할 때 "관측 가능성(Observability)"을 확보하는 것이 무엇보다 중요합니다. 특히 현재 가장 대중화된 디플로이 환경인 Kubernetes의 관측 가능성을 확보할 수 있는 툴들이 많이 등장했는데요. 이번 포스팅에서는 Kubernetes의 모니터링과 로깅을 위해 가장 많이 선택하는 Prometheus + Loki + Grafana 스택을 구성해보겠습니다. 구성하는 환경은 GCP의 관리형 Kubernetes 서비스인 GKE를 기반으로 하지만 바닐라 Kubern..
