Grafana 를 사용하여 알람을 구성 하였는데, 그라파나 알람 에서 DatasuourceError 가 자주 발생한다

 - 위 알람은 Grafana 의 DataSource 가 정상적로 연동되지 않았을 경우 발생

 - 저의 경우 EKS 에서 기동중인 Prometheus가 Datasource 인데 EKS를 주기적으로 재기동 하는경우가 이에 해당 한다

 

만약 위 알람이 주기적으로 발생하고 알람에 대한 조치가 필요 없는 경우 아래와 같이 처리할 수 있다

 

1. Grafana 에서 주기적으로 발생하는 알람에 대하여 silence 를 걸어서 알람 제어

2. Grafana 에서 SNS를 발송하기 전에 Lambda 코드를 통해 DataSourceError 일경우는 SNS 발송을 하지 않기

 


 

1번 의 경우 silence 를 매일 다시 수정 해 주어야 하는 번거로움이 있어서 2번을 통해 진행

관련된 코드는 아래와 같으니 참고하여 적절한 내용으로 수정해서 도움이 되었으면 좋겠습니다

 

import json
import boto3

def lambda_handler(event, context):
    #send_sns(event)    
    alerts_info(event)
    print(event)
##alert 정보 변수 설정
def alerts_info(event):
    
    for i in event['detail']['alerts']:
        
        alert_name = i['labels']['alertname']
        alert_time = i['startsAt']
        if alert_name != "DatasourceError":
            alert_value = i['values']['C']
            sns_main = "Alert Name : " + alert_name + "\n" +  "Alert Time : " + alert_time + "\n" + "Alert Value :" +  json.dumps(alert_value)
            
            client = boto3.client('sns')
            client.publish(
            TopicArn='arn:aws:sns:ap-northeast-2:#########:cloudwatch',
            Message = sns_main,
            Subject = alert_name
            )

 

Grafana 는 모니터링한 데이터를 시각화 해주는 툴중 대표주자로 자리잡고 있다. 여러 모니터링 툴이 있지만 Grafana 의 레퍼런스가 월등히 많고, 매년 새로운 버전이 나온다는 점을 감안 했을때 상당히 매리트가 있다. 특히 AWS 를 사용하는 입장에서 Cloudwatch / API Gateway 등을 사용하여 알람 연동이 가능하다는 점을들을 상당히 편리하게 사용 하고 있다

 


 

EKS 뿐 아니라 k8s 를 사용하다보면 클러스터 / 노드 / 파드 의 데이터를 분석하기위해 많은 도구들이 필요하다

대표적으로 사용 할 수 있는 서비스가 Prometheus 이며, Prometheus 는 Grafana 와 마찬가지로 오픈소스로 사용 할 수 있다. Prometheus 는 메트릭 수집으로써의 강점을 가지고 있으며, 각종 exporter 를 사용하여 노드, 파드 뿐아니라 Application 의 데이터도 수집이 가능하다

 

Prometheus 의 단점은 데이터를 장기간 보관하기 힘들다는 점이다. 장기간 보관이 가능할 지라도 HA 구성을 하기 위해서는 특별히 많은 설정을 진행 해 주어야 한다. 이를 해결하기 위한 방법으로 등장한 서비스가 Thanos 이다. Thanos 는 여러 컴포넌트를 가지고 있으며, Prometheus 의 부족한 부분을 보완해 주는 기능을 맡고 있다. 대표적으로 사용하는 Thanos 는 Bitnami 이미지를 사용하며상당히 잘 구성되어 있다. 또한 AWS 를 사용하는 입장에서 Prometheus 데이터를 S3 에 저장하고, Thanos 가 S3에 있는 Prometheus 데이터를 읽는 구성으로 진행하게되면 데이터 장기간 보관 및 HA 구성 또한 가능하기에 편리하게 사용 할 수 있다.

 


Thanos 와 Prometheus 를 사용하다보면 개념적으로 어려운 부분이 있다.

간략하게 컴포넌트별로 설명하면 다음과 같다

 

1. Prometheus 에서 데이터 수집

2. Prometheus 에 Thanos Sidecar 를 주입하여  데이터 수집된 결과를 외부 저장소에 저장(AWS S3 를 주로 사용 하였음)

3. Thanos StoreGateway 를 사용하여 S3 데이터를 읽어오고 Grafana 와 연동

 

기타 설명

1. Alertmanager : Prometheus 설치 시 같이 설치 할 수 있으며, 데이터 수집된 부분에대하여 알람룰을 설정할 수 있는 환경을 제공 Alertmaneger 를 Grafana 와 연동시 Grafana Alarm 구성을 보다 편리하게 할 수 있다

2. Thanos Frontend : Prometheus 의 web 페이지와 동일한 화면을 Thanos 에도 보여주는 화면 / 데이터 수집 결과 확인 가능

3. Thanos Query / Thanos Ruler / Thanos Compactor 등은 사용해본 적이 없어서 상세하게 내용을 알지 못함

 

※참고자료

Prometheus Install : https://tistory-cloud.tistory.com/59

 

Prometheus Install

환경구성 EKS 1.28 + ebs csidriver Add-on Prometheus v2.47.2 작업내용 helm repo add Git clone prometheus 경로에서 values.yaml 수정 Chart.yaml 수정 Chart.yaml 수정한 내용을 바탕으로 의존성 업데이트 Prometheus Install 확인

tistory-cloud.tistory.com

Prometheus Operater : https://tistory-cloud.tistory.com/60

 

Prometheus 에서 Thanos 사용을 위한 kube-prometheus-stack 설치

환경구성 EKS 1.28 기존에 설치 되어 있는 Prometheus : https://tistory-cloud.tistory.com/59 작업 내용 1. prometheus-operator-crd 설치 2. kube-prometheus-stack 설치 상세 작업 내용 1. prometheus-operator-crd 설치 Thanos 사용을

tistory-cloud.tistory.com

Prometheus Thanos 연동 : https://tistory-cloud.tistory.com/61

 

Prometheus 와 Thanos 연계를 위한 Thanos 설치

환경구성 EKS 1.28 Prometheus Prometheus Operater Bitnami Thanos 작업 내용 1. bitnami helm Chart Install 2. S3 연계를 위한 Secret 생성 3. values.yaml 수정 4. helm insatll 상세 작업 내용 1. bitnami helm Chart Install 2. S3 연계를

tistory-cloud.tistory.com

 

Thanos bitnami Image: https://github.com/bitnami/charts/tree/main/bitnami/thanos

Thanos Homepage : https://thanos.io/

 

Thanos

Thanos - Highly available Prometheus setup with long term storage capabilities

thanos.io

 

 

 


 

환경구성

EKS 1.28 + ebs csidriver Add-on

Prometheus v2.47.2

 


 

작업내용

 

  1. helm repo add
  2. Git clone
  3. prometheus 경로에서 values.yaml 수정
  4. Chart.yaml 수정
  5. Chart.yaml 수정한 내용을 바탕으로 의존성 업데이트
  6. Prometheus Install
  7. 확인하기

 


 

상세 작업 내용

 

 

1. helm repo add

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm repo list

 

2. Git clone

git clone https://github.com/prometheus-community/helm-charts

 

3. prometheus 경로에서 values.yaml 수정

  • 652 service type 변경 NodePort 
  • 1090 alertmanager  false 로 변경
  • 1226 prometheus-pushgateway false 로 변경

 

4. Chart.yaml 수정

  • Chart 에서 사용할 dependencies 만 남기고 제외
  • kube-state-metrics 는 EKS 의 Pod 의 데이터를 수집할 수 있다(cAdvisor 데이터도 포함)
  • node-exporter 는 EKS 의 Node 의 데이터를 수집할 수 있다
  • alertmanager 는 prometheus 에서 알람을 지정할 수 있지만 이번에는 사용하지 않음
  • pushgateway 는 특정한 경우에만 사용한다고 공식문서에 나와 있는데 어떤기능인지 몰라 사용하지 않음

 

5. Chart.yaml 수정한 내용을 바탕으로 의존성 업데이트

helm dependency update

 

6. Prometheus Install

  • helm 에서 따로 수정을 하지 않을경우 데이터 저장은 EBS CSI Driver 를 사용하여 EBS 에 저장됨
  • 다른 옵션을 사용해야 하는 경우 추가로 설정 해주면됨(EFS 등)
helm install prometheus -f values.yaml ./

 

7. 확인 하기

  • 생성된 LB 의 주소로 접속하면 Prometheus 화면을 확인 할 수 있다
kubectl get po
kubectl get svc

 

 

 

 

 

※참고자료

Prometheus Install : https://tistory-cloud.tistory.com/59

Prometheus Operater : https://tistory-cloud.tistory.com/60

Prometheus Thanos 연동 : https://tistory-cloud.tistory.com/61

Prometheus Image

https://quay.io/repository/prometheus/prometheus?tab=tags&tag=latest

 

Quay

 

quay.io

 

 

Grafana 사용중 보안에 취약한 TLS 알고리즘을 사용으로인한 조치 권고가 있어, 해당 내용을 공유 하고자 한다

 

TLS 알고리즘 조치방법에는 크게 두가지가 있다.

1. Grafana 인입을 NLB로 하고 있고, NLB의 ACM 을 사용 하고 있기에 NLB 의 TLS 알고리즘을 변경하여 조치가 가능하다

2. Nginx Ingress 등을 사용하여 TLS 알고리즘 조치 가능하다(사용해본 적은 없음)

 


 

AWS 에서는 아래와 같이 보안 정책에 따라 허용되는 알고리즘을 명시해 놓았다

위 항목이 정확하게 적용이 되어 있는지 확인을 해보자

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/create-https-listener.html#tls13-security-policies

 

Application Load Balancer용 HTTPS 리스너 생성 - Elastic Load Balancing

Application Load Balancer에 대한 TLS 1.3 정책은 새로운 EC2 환경에서만 지원됩니다. 이전 EC2 환경을 사용하는 경우 TLS 1.3 정책을 선택할 수 없습니다.

docs.aws.amazon.com


순서 요약

1. 그라파나 repo pull

2. 그라파나 옵션 수정

3. 그라파나 설치

4. TLS 알고리즘 조회

 

※테스트 환경에는 LB Controller 가 설치되어 있습니다. LB 생성 전에 설치 후 진행 하시는것을 권고 드립니다

https://tistory-cloud.tistory.com/57


상세 설명

1. 그라파나 repo pull

  • 아래 명령어를 사용하여 그라파나를 다운로드
helm repo add grafana https://grafana.github.io/helm-charts
helm pull https://grafana.github.io/helm-charts

 

2. 그라파나 옵션 수정

  • 1번에서 다운로드한 repo 압축을 풀고 폴더에 들어가면, values.yaml 파일이 존재
  • 해당 파일 아래와 같이 수정
 ##value.yaml 파일의 185번째 줄 부터 아래와 같이 수정
 ##194 : LB 생성될 서브넷
 ##196 : acm 의 arn
 ##197 : SSL policy
 
 
 
 185 service:
 186   enabled: true
 187   type: LoadBalancer
 188   port: 443
 189   targetPort: 3000
 190     # targetPort: 4181 To be used with a proxy extraContainer
 191   ## Service annotations. Can be templated.
 192   annotations:
 193     service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
 194     service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-XXXXXX, subnet-XXXXXX
 195     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 196     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:ap-northeast-2:XXXXXX:certificate/XXXXXX
 197     service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS13-1-2-2021-06"

 

3. 그라파나 설치

#그라파나 설치
helm install grafana -f values.yaml ./

 

4. TLS 알고리즘 조회

  • NLB 생성 후 DNS로 접근가능 여부 확인 후 아래 명령어 수행
nmap --script ssl-enum-ciphers [LB DNS] -p443 -unprivileged

위 결과 내용을 확인해 보면, AWS 문서에 기재된 알고리즘과 동일하다는 것을 알 수 있다.

다른 알고리즘으로 변경하여 동일한 명령어 기재하면 다양한 알고리즘이 나오게 된다.

그라파나 Cloudwatch 대시보드 role assume 시 찾는 dns

 

sts endpoint 찾음

- sts 다음으로는 logs endpoint / monitoring endpoint 를 찾음

 

다른 리전을 찾을경우는 공인 ip를 찾게되어 있음

+ Recent posts