설치한 prometheus 메인 config yaml 파일에 recording_rules.yml, alertiing_rules.yml 항목이 data 필드로 존재하는 것을 확인했으며 해당 부분에 주요 major라고 생각하는 메트릭을 추가해보았다.
추가한 recording_rules 는 다음 항목과 같았다.
recording_rules.yml: |
groups:
- name: core_metric
rules:
- record: instance:cpu_usage
expr: sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)
- record: node_memory_bytes_total
expr: sum(node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Buffers_bytes - node_memory_Cached_bytes)
- record: node_disk_io_time_seconds_total
expr: sum(rate(node_disk_io_time_seconds_total[5m])) by (device)
- record: node_network_receive_bytes_total
expr: sum(rate(node_network_receive_bytes_total[5m])) by (device)
- record: node_network_transmit_bytes_total
expr: sum(rate(node_network_transmit_bytes_total[5m])) by (device)
- record: node_cpu_seconds_total
expr: sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (mode)
- record: node_filesystem_avail_bytes
expr: sum(node_filesystem_avail_bytes) by (device)
- record: node_filesystem_size_bytes
expr: sum(node_filesystem_size_bytes) by (device)
- record: node_filesystem_free_bytes
expr: sum(node_filesystem_free_bytes) by (device)
- record: node_filesystem_used_bytes
expr: sum(node_filesystem_size_bytes - node_filesystem_free_bytes) by (device)
다음은 알럿과 연관된 alert 룰이다.
data:
alerting_rules.yml: |
groups:
- name: core_alerts
rules:
- alert: HighCpuUsage
expr: sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) > 0.9
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage detected"
description: "CPU usage is above 90% for at least 5 minutes."
- alert: HighMemoryUsage
expr: (node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Buffers_bytes - node_memory_Cached_bytes) / node_memory_MemTotal_bytes > 0.9
for: 5m
labels:
severity: warning
annotations:
summary: "High memory usage detected"
description: "Memory usage is above 90% for at least 5 minutes."
각각 정의한 네임인 core_metric과 core_alerts 가 다음과 같이 배포되어 프로메테우스 페이지에서 확인되었다.
배포는 메인 컨피그 yaml 파일을 kubectl apply -f config.yaml 식으로 배포하였고, 배포하면 running 중인 pod에 반영이 되는데 테스트하다가 pod를 재생성하려고 delete를 하였다. pod 삭제 후 기본 설정에 따라 pod 하나와 container 두개가 새로 생성되었지만 해당 nlb 타겟그룹에서 unhealthy로 기록되었다.
아래는 grafana 배포관련 캡처이지만 비슷한 상태였던것 같다.
pod description을 보니 아이피가 바뀐 것을 확인하고 해당 파드의 보안그룹을 허용해주고, 그 파드 안에서 프로세스를 확인해보니 9090 포트로 계속 TIME_WAIT 가 나고 connection refused가 나는 것을 확인했다.
메인 컨피그 yaml에서 다음 항목을 줄여주고, 해당 배포 pod ec2에서 sysctl 설정을 업데이트 하였다.
main_config.yaml
terminationGracePeriodSeconds: 60 (300에서 60)
pod 서버 (내 경우는 ec2노드의 pod)에서
/etc/sysctl.conf 편집하여 다음 항목 추가:
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1저장 후 나와서 sudo sysctl -p 커맨드 입력 (위 ipv4.tcp_tw_reuse 값 설정은 timeout wait 상태의 소켓 수를 줄이고 포트를 더 빨리 풀어줌. tw_recycle은 리눅스 커널 버전 4.12 이후 deprecated)
netstat 으로 9090 포트 확인9090 포트의 target 서버 ip로 요청 및 정상적으로 응답오는 것을 확인 (location 헤더에 /graph 라고 보임) 후,해당 Prometheus 의 AWS NLB 타겟 그룹에 기존에 명시적으로 들어가있던 아이피 대신 타겟 아이피 register, healthy로 바뀌는 것을 확인하였다.아직 상태는 미흡하지만 프로메테우스로 어디까지 커스텀 가능한지 지속해서 확인해봐야겠다.
kubectl로 prometheus 확인 시 유용했던 명령어 정리:
kubectl logs -f prometheus-pod-name -n namespaceofpm -c prometheus-containername | more (해당 pod에 컨테이너 여러개일때 특정 컨테이너 지정하여 로그 확인 방법)
kubectl get pods <prometheus-pod-name> -n <namespace> -o jsonpath="{.spec.containers[*].name}" (해당 pod의 컨테이너를 찾을때)
kubectl describe configmap fluentd-config
kubectl get configmap -n <namespace> -l app=fluentd -o yaml (app이 fluentd인 configmap yaml파일 찾기)
kubectl kill -s HUP <prometheus-pod-name> -n <namespace> (안먹을때도 있음 버전따라)
kubectl rollout restart deployment/<grafana-deployment-name> -n <namespace> (apply 후 pod 삭제 없이 deploy)
kubectl get deployments -n <namespace> (deployment 이름 찾기)
'aws > k8s, eks study' 카테고리의 다른 글
| EKS PV issues (0) | 2023.03.17 |
|---|---|
| EKS CNI issue - network plugin is not ready: cni config uninitialized (2) | 2023.03.15 |
| How to set the keep-alive setting on EKS pod (0) | 2023.03.06 |
| eks-controller ingress reconciler error with 403 response code (0) | 2023.03.02 |
| Delete EKS pod and deploy again with pulled image (0) | 2023.02.28 |
