쿠버네티스 모니터링

클라우드/Kubernetes

쿠버네티스 모니터링

Cloud_Park 2020. 2. 4. 18:45

모니터링

쿠버네티스에 모니터링을 보면 많은 툴과 지표들이 있어서 혼돈하기 쉬운데 , 먼저 모니터링 컨셉에 대한 이해를 할 필요가 있다.

쿠버네티스 기반의 시스템을 모니터링하기 위해서는 크게 1. host, 2. container, 3. app, 4. kubernetes 4가지를 모니터링 해야 한다.

1. host : 쿠버네티스 컨데이너를 실행하는 하드웨어 호스트 , 노드에 대한 지표 모니터링이 필요하다. 노드의 cpu , 메모리, 디스크, 네트워크, 사용량과 노드 os와 커널에 대한 모니터링

2. container : 노드에 기동되는 각각의 컨테이너에 대한 정보이다. 컨테이너의 CPU,메모리, 디스크, 네트워크 사용량을 모두 모니터링한다.

3. application : 컨테이너에서 구동되는 개별 어플리케이션에 대한 컨테이너이다. ex) 컨테이너에서 기동되는 node.js기반의 애플리케이션의 http 에러 빈도등

4. kubernetes : 컨테이너를 컨트롤하는 쿠버네티스 자체에 대한 모니터링한다. 쿠버네티스의 자원인 서비스나 pod 계정 정보등이 해당된다.

쿠버네티스 기반의 시스템 모니터링에 대해서 혼동이 오는 부분중 하나가 모니터링이라는 개념이 포괄적이 때문이다. 여기서 다루는 모니터링은 자원에 대한 지표 대한 모니터링이다. 포괄적인 의미 모니터링은 로그와 에러 모니터링등 다양한 내용을 포괄한다.

쿠버네티스 로링

지표 모니터링과 함께 중요한 모니터링 기능 중 하나는 로그 수집 및 로그 모니터링이다.

로그 수집 및 로그 모니터링 방법은 여러가지 방법이 있지만 오픈소스 로그 수집 모니터링 조합인 (Elastic search + FluentD + kibina) 스택을 사용하는 경우가 대표적이다. EFK방식은 보다 최근엔 prometheus등 다양한 모니터링 아키텍처가 후보로 고려되어진다.

개인적인 의견으로는 직접 모니터링 솔루션을 구축해서 사용하는 것보다 비용은 약간 들지만 클라우드 밴더에서 제공하는 모니터링도구나 데이타톡스와 같은 전문 모니터링 솔루션을 사용하는 것을 추천한다.

직접 모니터링 솔류션을 구축할 경우 구축과 운영에 드는 노력도 크고 또한 어떠한 지표를 모니터링에 넣어야할지 등에 대한 추가적인 노하우가 요한다 . 또한 cAdvisor, heapster, protheus조합은 호스트 , 컨테이너 그리고 쿠버네팃에 대한 모니터링은 제공하지 않지만 애플리케이션 지표에 대한 모니터링과 로깅 기능은 제공하지 않기 때문에 별도의 구축이 필요하다. 이런 노력을 들이는 것 보다는 모든 기능이 한번에 ㄱ제공되는 운영을 대해해주는 데이타톡스나 클라우드에서 제공해준ㄴ 모니터링 솔루션을 사용하는게 편하다라는 말이다.

heapster 기반 모니터링 아키텍처

이러한 모니터링 요건을 지원하기 위해서 쿠버네티스는 자체적인 컴포넌트를 가지고 잇는데 그 구조는 다음과 같다.

cAdvisor

에이전트로 각노드마다 설치되어 노드에 대한 정보와 컨테이너에 대한 정보를 수집하여 k8s에 전달한다.

Heapster

cAdvisor에 의해 수집되는 heapster라는 중앙집중화된 지표 수집 시스템에 모이게되고 , heapster는 수집된 지표를 스토리지 백엔드에 저장한다.

Storage backend

heapster가 지표에 저장하는 베이터베이스를 스토리지 백엔드라 하는데 heapster는 확장성을 위해서 다양한 스토리지 백엔드를 플러그인 구조를 선택하여 연결할수잇다.

현재 제공되는 대표적인 스토리지 백엔드는 구글클라우드의 모니터링 시스템인 스택드라이버, 오픈소스 시계열 데이타베이스인 인플럭스 디비를 지원한다.

그래프 대쉬보드

이렇게 저장된 모니터링 지표는 그래프와 같은 형태로 시각화 될 필요가 잇는데, 스토리지 백엔드를 지원하는 다양한 시각화 도구를 사용할 수 있다. 구글의 모니터링 시스템인 스택드라이버의 경우에는 자체적인 대쉬보드 및 그래프 인터페이스가 있고, 인플럭스 디비나 프로메테우스의 경우에는 오픈소스 시각화 도구인 그라파나를 사용할 수있다.

쿠버네티스 대시보드

다른 방법으로는 쿠버네티스를 모니터링하고 관리할 수 있는 쉬운 방법이 하나 있는데, 쿠버네티스 대시보드를 사용하는 방법이다. 쿠버네티스는 기본적으로 kubectl이라는 커맨드라인 인터페이스를 사용하는데 추가적인 웹 기반의 관리 콘솔을 제공한다. 이를 쿠버네티스 대시보드라고 한다.

설치방법

# kubectl  create -f

https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

불러오는 중입니다...

구글클라우드 쿠버네티스 엔진일 경우 권한 문제로 에러가 발생할 수 있다.

$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user $(gcloud config get-value account)

으로 cluster-admin롤을 풀어준다.

로컬머신에 http 서비스가 접근가능하게 하려면 프록시 명령을해준다

$kubectl proxy

명령을 해주면 localhost:8001 포트를 통해 쿠버네티스 클러스터로 트래픽을 프록시해준다.

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

대쉬보드를 사용하기 위해 사용자인증이 필요한데, 간단하게 인증을 위한 토큰 사용하는 방법은 이용해보자

admin-user.yaml파일생성

apiVersion: v1

kind: ServiceAccount

metadata:

 name: admin-user

 namespace: kube-system

admin-rolebinding.yaml 파일 생성

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRoleBinding

metadata:

 name: admin-user

roleRef:

 apiGroup: rbac.authorization.k8s.io

 kind: ClusterRole

 name: cluster-admin

subjects:

- kind: ServiceAccount

 name: admin-user

 namespace: kube-system

토큰값알아오기

$ kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

토큰값으로 로그인하면 노드 pod 서비스등 쿠버네티스의 자원 대부분이 보인다.

재미있는 기능중 하나는 아래 그림과 같이 특정 Pod의 컨테이너를 선택하면, 웹콘솔상에서 해당 컨테이너로 SSH 로그인이 가능하다.

프로메테우스(prometheus)

프로메테우스는 sound Could에서 개발된 모니터링 툴로 CNCF에 오픈소스로 기부되었다. 지표 수집을 통한 모니터링을 주요 기능으로 하고있다.

쿠버네티스 모니터링뿐만아니라 애플리케이션이나 서버 os등 다양한 대상으로부터 지표를 수집하며 모니터링할 수 있는 범용 솔루션으로 아래와 같은 구조를 가집니다.

데이터 수집 부분

프로메테우스는 수집을 pulling 모델을 사용한다. 모니터링 대상이되는 자원이 지표 정보를 ㅍ프로메테우스로 보내는 것이 아니라, 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽어 오는 모델을 사용한다.

모니터링 대상이 프로메테우스 데이타 포멧을 지원할 경우 바로 읽어 올 수 있고, 만약에 지원하지 않는다면 별도의 에이전트를 설치해서 지표를 읽어올 수 있는데, 이를 exporter라고한다. exporter는 mysql,nginx, redis와 같은 패키지는 미리 개발된 export가 있어서 다양한 서비스의 지표까지 쉽게 읽어올 수 있다. 이런 패키지 어플리케이션이 아니라 java나 node.js와 같은 사용자 애플리케이션의 경우에는 exporter를 사용하는 방법 말고도 프로메테우스 클라이언트 라이브러리를 사용하게 되면 바로 지표를 프로메테우스 서버로 보낼수 있다.

마지막으로 push gateway를 사용하는 방법이 있는데 배치나 스케쥴 작업 같은 경우에는 항상 서비스가 떠있는 것이 아니라 필요한 경우에만 떠 있다가 작업이 끝나면 사자리는 경우이다. 그래서 이런서비스를 pulling으로 지ㅍ를 얻어오기가 어려울 수 있는데, 이를 보완하기 위해서, 이런 서비스들이 push->push gateway에 지표를 쏴주면 push gateway가 지표를 보관했다고 있다가 프로메테우스 서버가 pulling을 하면 저장된 지표 정보를 리턴하도록 한다.

서비스 디스커버리

그러면 프로메테우스는 모니터링 대상을 어떻게 알 수 있을까 ? 당연히 모니터링 대상목록을 유지하고, 대상에 대한 ip나 기타 정보를 설정 파일에 주면 , 그정보를 기반으로 프로메테우스 서버가 모니터링 정보를 읽어온다.

그러나 오토스케일을 많이 사용하는 클라우드 환경이나 쿠버네티스와 같은 컨테이너환경에서는 모니터링 대상의 ip가 동적으로 변경되는 경우가 많기 때문에 이를 일일이 설정 파일에 넣는데 한계가 있다. 이런한 문제를 해결하기 위해서 프로메네테우스는 디스커버리를 사용하는데 모니터링 대상이 등록되어 있는 장소에서 목록을 받아서 그 대상을 모니터링하는 형태이다.

프로메테우스는 DNS나 consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해서 자동으로 모니터링 대상의 목록을 가지고 올 수 있습니다.

저장 및 시각화

수집된 지표 정보들은 프로메테우스 내부의 시계열 데이터베이스에 저장되고, 프로메네우스 웹콘솔을 이용하여 시각화되거나 또는 api를 외부에 제공해서 grafana와 같은 시각화 툴을 통해서 지표를 시각화 해서 볼 수 있다.

알림서비스

부가지능중 하나로 alerting 컴포넌트는 지표에 대한 규칙을 걸어놓고 그 규칙을 위반할 경우에는 알림을 보낼 수 있는 기능을 가지고 있다. 알림을 보내는 대상은 이메일이나 gagerduty와 같은 notification서비스 등과 연동이 가능하다.

쿠버네티스 연동 아키텍처

쿠버네티스와 프로메테우스는 어떻게 연동이 되는지 알아보자. 프로메테우스는 범용 모니터링 솔루션으로 프로메테우스가 지표정보를 읽어올 수 만 있다면 거의 모든 정보를 읽어올 수 있는 구조이기 때문에, 쿠버네티스 연동에 있어도 자유도가 매우 높다.

단 레퍼런스 할 수 있는 구성은 있는데 아래와 같다.

프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리 메카니즘이 필요한데, 이를 위해서 쿠버네티스 api를 호출해서 자원들의 목록(pod,node,ingress,endpoint등)의 목록을 라벨 셀렉터를 이용하여 수집한다.

다음 수집된 모니터링대상에 대해서모니터링을 수행하는데 , 쿠버네티스는 apiserver에서 /metric이라는 url을 통해서 기본적인 지표 정보를 리턴하기 때문에 쿠버네티스 자원들에 대한 모니터링은 이 api를 통해서 수집하게된다.

아랫단에 아드웨어 즉 node에 대한 정보는 api를 통해서 수집하기가 어렵기 때문에 node에 node exporter를 설치해서 하드웨어와 os에 대한 정보를 수집한다. 컨테이너에 대한 정보는 node 별ㅗ 배포되어 있는 cAdvisor가 이를 수집하여 프로메테우스에 제공한다

컨테이너 내에서 기동되는 애플리케이션에 대한정보는 필요한 경우 클라이언트 sdk나 솔루션에 맞는 exporter를 이용해서 수집한다.

쿠버네티스 연동하기

실제로 프로메테우스를 설치해서 쿠버네티스 클러스터를 모니터링하려면 alert server,exporter,prometheus server 등 설치 해야하는 서버들이 많아서, 일일이 설치하는 것이 쉽지 않다. 여러가지 설치방법이 있지만 여기서는 쿠버네티스의 패키지 매니저인 helm을 이용해서 프로메테우스를 설치하도록한다. helm은 리눅스에 rpm개념이나 node.js의 npm같이 소프트웨어 스택을 명령으로 손쉽게 설치할 수 있또록 해주는 패치지 매니저의 개념으로 생각해두자

1. helm 인스톨

helm은 클라이언트와 서버 두개의 모듈로 나눠진다.

인스톨은 어렵지않은데 클라이언트 os에 따라 약간에 차이가 있다 . 자세한 인스톨 방법은https://docs.helm.sh/using_helm/

---리눅스

1. https://github.com/helm/helm/releases에서  다운로드하고

2. tar xvfz [파일 이름]    //압축풀기

3. mv  [파일   /usr/local/bin/helm  // 파일이동

helm help로 확인해보기

--mac

brew install helm

--window

choco install kubernetes-helm

구글 클라우드 쿠버네티스 엔진 (GKE) 환경에서 인스톨

GKE 환경은 약간 설치 방법이 다른데, 보안적인 이슈로 인해서 계정에 대한 권한 컨트롤을 상대적으로 까다롭게 하기 때문이다.

(참고 : https://cloud.google.com/solutions/continuous-integration-helm-concourse )

아래 명령을 이용하면 kube-system 네임 스페이스에 tiller라는 이름으로 서비스 어카운트를 생성할 수 있다.

% kubectl create clusterrolebinding user-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)

% kubectl create serviceaccount tiller --namespace kube-system

% kubectl create clusterrolebinding tiller-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

다음 Tiller를 생성할때, --service-account=tiller 옵션을 줘서 tiller 가 실행될때, 해당 서비스 어카운트의 권한을 가지고 실행되도록 한다.

헬름 서버 (Tieller) 인스톨

./helm init --service-account=tiller./helm update

이렇게 설치 하지 않으면 Tiller 자체는 설치가 될 수 있지만, Tiller에 의해서 인스톨 되는 패키지들이 권한 오류로 인해서 제대로 설치되지 않을 수 있다

Helm Chart를 이용한 Prometheus 설치

Helm이 준비되었으면 프로메테우스 를 설치해보자

% git clone https://github.com/kubernetes/charts

명령을 이용하여 Helm chart를 다운 받는다. Helm chart는 npm 파일과 같이 인스톨 스크립트를 모아놓은 것으로 생각하면 된다. 프로메테우스외에도 다양한 설치 스크립트가 있다.

$ cd charts/stable/prometheus

를 이용해서 프로메테우스 디렉토리로 들어간 후에, 아래 명령을 이용하면 prometheus 네임스페이스에 프로메테우스가 설치된다.

$ helm install -f values.yaml stable/prometheus --name prometheus --namespace prometheus

설치가 끝났으면 이제 프로메테우스가 제대로 작동해서 지표를 수집하고 있는지 확인하자. 프로메테우스 서버는 디폴트로 9090 포트를 통해서 웹 인터페이스를 제공한다. 프로메테우스 서버를 외부 서비스로 expose 하지 않았기 때문에 포트 포워딩을 이용해서 프로메테우스 서버의 9090 포트를 포워딩 해보자

%kubectl get pod -n prometheus

명령을 이용해서 prometheus 네임스페이스에 있는 pod 목록을 다음과 같이 가지고 온다.

prometheus의 pod 명이 “prometheus-server-5695758946-gdxjx” 인것을 알았으면,localhost:9090을 이 pod의 9090포트로 포워딩하도록 설정한다.

%kubectl port-forward -n prometheus prometheus-server-5695758946-gdxjx 9090

포트 포워딩이 설정되었으면 localhost:9090으로 접속하여 프로메테우스의 웹 콘솔을 접속해보자

처음에는 아무것도 나오지 않을텐데, metric을 PQL (프로메테우스 쿼리)를 이용해서 선택하면 아래와 같이 해당 지표에 대한 값이 나오는것을 볼 수 있다. 아래는 node의 disk_io 정보를 살펴보는 쿼리이다.

이 메뉴에서 지표를 모니터링 하거나 또는 모니터링된 지표를 Graph 탭을 눌러서 그래프로 시각화 할 수 있다. 메뉴를 조금더 둘러보면 상단의 Status 메뉴에서 Service Discovery 메뉴를 눌러보면 다음과 같은 결과를 얻을 수 있다.

모니터링해야 하는 자원들의 목록으로 node, node-cadvisor, pods, services 등에 대한 정보를 모니터링할 수 있는 것을 확인할 수 있다.

Target 메뉴를 클릭하면 다음과 같은 정보가 나오는데,

어디로 부터 지표들을 수집해오는지 URL등을 확인할 수 있다. apiserver의 URL, node metric 정보 수집 URL node cAdvisor 수집 URL등을 확인할 수 있다.

Helm Chart를 이용한 Grafana 설치

프로메테우스를 설치했으면 이를 시각화 하기 위해서 Grafana를 설치해서 연동해보도록 하자.

Helm chart 디렉토리에서 stable/grafana 디렉토리에 values.yaml 파일이 있는데, 이 부분에서 adminPassword 부분을 찾아서 admin 사용자의 비밀 번호를 세팅하도록 하자.

adminUser: adminadmin
Password: mypassword

다음 Helm chart를 이용해서 Grafana를 설치한다.

stable/grafana 디렉토리에서 앞에서 수정한 values.yaml 파일을 이용한다.

%helm install -f values.yaml stable/grafana --name grafana --namespace grafana

설치가 종료되었으면 Grafana 콘솔에 접속해보자.

%kubectl get pod -n grafana

%kubectl get pod -n grafana

명령을 이용해서 grafana 서버의 pod 명을 알아낸다.

Grafana 서버는 외부 서비스로 Expose 되지 않았기 때문에, 포트 포워딩을 이용해서 해당 서버에 접속하도록 한다. Grafana는 3000번 포트로 웹 접속을 허용한다.

% kubectl port-forward -n grafana grafana-679cdd7676-zhwnf 3000

명령을 이용하면 localhost:3000을 Grafana 웹 서버로 포워딩 해준다.

localhost:3000에 접속해보면 다음과 같은 로그인 창이 나온다.

로그인창에서, 사용자명을 admin으로 입력하고, 비밀번호는 앞의 설정에서 입력한 비밀번호를 설정한다.

다음으로 프로메테우스 서버를 데이타 소스로 설정해야 하는데, grafana 메뉴에서 Configuration > Data source 메뉴를 선택한다.

Data source를 추가하기 위해서는 프로메테우스 서버의 URL 을 알아야 하는데, 프로메테우스 서버는 내부 IP를 가지고 있는 서비스로 Expose 되어 있다. 서비스명을 알기 위해서 다음 명령어를 실행한다.

%kubectl get svc -n prometheus

다음과 같이 서비스명이 prometheus-server이고 cluster-IP가 10.102.173.250 인것을 확인할 수 있다.

HTTP URL은 http://prometheus-server.prometheus.svc.cluster.local 게 된다.

그러면 이 정보를 Grafana datasource 쪽에 추가한다.

데이타소스 명은 Kuberentes로 지정하고, 타입은 Prometheus로 지정한다. 그리고 HTTP URL은 위의 http://prometheus-server.prometheus.svc.cluster.local 를 사용하고 Access 타입은 Server를 선택한다.

이 과정이 끝나면, 프로메테우스를 Grafana의 데이타 소스로 사용할 수 있다.

이 데이타 소스를 이용해서 대쉬 보드를 구성해야 하는데, 수동으로 일일이 구성할 수 도 있지만 Grafana 커뮤니티에는 이미 미리 구성되어 있는 대쉬보드 템플릿이 많다. 이 템플릿을 그대로 import 해서 사용해보도록 하겠다.

Grafana 메뉴에서 아래와 같이 Create > Import 메뉴를 선택한다.

다음 대쉬보드 설정 JSON을 넣을 수 있는데, 또는 Grafana.com에 등록된 대쉬보드 템플릿 번호를 넣을 수 도 있다. 여기서는 쿠버네티스 클러스터 모니터링 템플릿을 사용하도록 하겠다. 이 템플릿의 ID는 1621번이기 때문에 아래와 같이 템플릿 ID를 입력한다.

이 템플릿 이외에도, 노드 모니터링을 위한 템플릿등 여러 종류의 대쉬 보드 템플릿이 있기 때문에 용도에 맞게 선택해서 사용하면 된다.

템플릿 ID를 선택하면 다음 화면에서 데이타 소스를 선택해줘야 하는데, 아래 그림과 같이 Prometheus 부분을 앞에서 만든 데이타 소스 이름인 Kubernetes를 선택한다.

설정이 끝난후에 대쉬보드를 확인하면 아래와 같이 쿠버네티스에 대한 전반적인 모니터링 정보가 나오는 것을 확인할 수 있다.

구글 드라이버를 이용한 쿠버네티스 모니터링

쿠버네티스 모니터링 시스템을 구축하는 다른 방법으로는 클라우드 서비스를 사용하는 방법이 있다. 그중에서 구글 클라우드에서 제공하는 스택 드라이버 쿠버네티스 모니터링에 대해 소개하고자한다.

현재 베타상태로 구글 클라우드 쿠버네티스 서비스에서만 지원되며 쿠버네티스 버전 1.10.2 와 1.11.0 또는 상위버전에서만 지원되고 모니터링 뿐만아니라 쿠버네티스 서비스에 대한 로깅을 스택 드라이버로 로깅 스비스를 이용해서 함께 제공한다.

스택드라이버 쿠버네티스 모니터링을 설정해보자 .

additional features 항목에서 ''try the new Stackdriver deta monitoring amd logging experience' 항목을 체크하면된다.

클러스터 생성한 후에, 구글 클라우드 콘솔에서 monitoring 메뉴를 선택한 후

스택드라이버 메뉴에서 resource 메누 아래와 그림과 같이 kubernetes 메뉴를 선택하면 쿠버네티스 모니터링 내용을 볼 수 있다.

모니터링 구조

스택드라이버 쿠버네티스 모니터링의 가장 큰 장점 중의 하나는 단순한 단일 뷰를 통해서 대부분의 리소스 모니터링과 이벤트에 대한 모니터링이 가능하다는 것이다.

스택드라이버 모니터링 화면인데 '2' 라고 표시된 부분이 시간에 따른 이벤트이다. 장애들이 발생하였을 경우 아래 그림과 같이 그림과 붉은 색으로 표현되고 3부분을 보면 여러가지 뷰로

각 자원들을 모니터링할 수 있다. 장애가 난 부분이 붉은 색으로 표시된 것을 확인

timeline에 incident 가 붉은 색으로 표시된 경우 상세 정보를 볼 수 있는데 timeline에서 붉은 색으로 표시된 부분을 누르면 아래 그림과 같이 디테일 이벤트가 나온다.

이 카드를 통해서 메모리 cpu등 이벤트에 대한 상세 내용을 확인 할 수있다.

개념구조

쿠버네티스 모니터링중 난관은 어떤 계층 구조로 자원을 모니터링하는것이다. 이런점을 해결하기 위해 구글 스택드라이버 쿠버네티스 모니터링은 3가지 계층 구조에 따른 모니터링을 제공한다

infrastructure, workloads, service 와 같이 세가지 탭이 나오는 것을 볼 수 있다.

어떤 관점에 클러스터링을 모니터링 할 것인가?

1 . 인프라구조: 하드웨어 자원, node를 기준으로 하는 뷰, 클러스터 > 노드 > 파드 > 컨테이너

2. 워크로드: 워크로드 기준 deployment기준으로 클러스터> 네임스페이스>워크로드(deployment)> 파드> 컨테이너

3. 서비스 : 어플리케이션 중심으로 하는 뷰 , 클러스터> 네임스페이스 > 서비스 >파드 > 컨테이너

Alert 에 대한 상세 정보

각 계층 뷰에서 리소스가 문제 없을 경우 앞의 동그라미가 붉은색으로 표시가 되는데 해당버튼을 누르게 되면 alert에 대한 상세정보 카드가 나타나 확인할 수 있다.

Alert 에 대한 상세 정보

멋진 대쉬 보드를 만드는 것도 중요하지만 모니터링과 로깅은 시스템을 안정적으로 운영하고 장애전에 그 전조를 파악해서 대응하고, 장애 발생시에는 해결과 향후 예방을 위한 분석 및 개선 활동이 일어나야 한다. 이를 위해서 모니터링과 로깅은 어디까지나 도구일 뿐이고, 어떤 지표를 모니터링 할것인지 (SLI : Service Level Indicator), 지표의 어느값까지를 시스템 운영의 목표로 삼을 것인지 (SLO : Service Level Object)를 정하는 프렉틱스 관점이 더 중요하다. 이를 구글에서는 SRE (Site Reliability Engineering)이라고 하는데, 이에 대한 자세한 내용은 https://landing.google.com/sre/book.html 를 참고하기 바란다.

위 글을 조대협블로그를 참고하였습니다.https://bcho.tistory.com/1255

저작자표시