1. EKS Console
- 쿠버네티스 API를 통해 리소스 정보 확인 가능
클러스터 ARN : arn:aws:eks:ap-northeast-2:662551666207:cluster/myeks (블로그 포스팅 시점엔 이미 제거 완료)
2. EKS Logging
- Amazon Elastic Kubernetes Service (EKS)에서 로그 관리를 위해 제공되는 기능이다.
EKS Logging의 세 가지 주요 구성 요소
1. Control Plane Logging
2. Node Logging
3. Application Logging
Control Plane Logging
- EKS 클러스터의 Kubernetes 컨트롤 플레인 구성 요소에서 생성되는 로그를 관리
- Kubernetes 컨트롤 플레인은 클러스터 관리, 스케줄링, 네트워킹 등의 작업 담당
- Control Plane 로그는 클러스터의 Health 상태, 이벤트, 오류 등에 대한 정보를 제공
Node Logging
- EKS 클러스터 내의 각 워커 노드에서 생성되는 로그를 관리
- 워커 노드는 애플리케이션 컨테이너를 실행하고 관리하는 역할을 수행
- Node 로그는 애플리케이션 및 노드 수준의 이벤트, 오류, 성능 지표 등을 포함
Application Logging
- EKS 클러스터 내에서 실행되는 애플리케이션 컨테이너에서 생성되는 로그를 관리
- 애플리케이션 로그는 개발자가 정의한 메시지, 이벤트, 상태 등을 포함
- 애플리케이션 로그는 로깅 에이전트 또는 로깅 라이브러리를 사용하여 수집되고, 중앙 집중식 로그 관리 도구에 전송되어 분석 및 모니터링에 활용
위와 같이 기본값으로 비활성화 되어있으며, 수집된 컨트롤 플레인 로그는 CloudWatch에서 볼 수 있다.
로그 이름( /aws/eks/<cluster-name>/cluster )
1. Kubernetes API server component logs (`**api**`) – `kube-apiserver-<nnn...>`
2. Audit (`**audit**`) – `kube-apiserver-audit-<nnn...>`
3. Authenticator (`**authenticator**`) – `authenticator-<nnn...>`
4. Controller manager (`**controllerManager**`) – `kube-controller-manager-<nnn...>`
5. Scheduler (`**scheduler**`) – `kube-scheduler-<nnn...>`
# 모든 로깅 활성화
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
# 로그 그룹 확인
aws logs describe-log-groups | jq
# 로그 tail 확인 : aws logs tail help
aws logs tail /aws/eks/$CLUSTER_NAME/cluster | more
# 신규 로그를 바로 출력
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --follow
# 필터 패턴
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --filter-pattern <필터 패턴>
# 로그 스트림이름
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix <로그 스트림 prefix> --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-controller-manager --follow
kubectl scale deployment -n kube-system coredns --replicas=1
kubectl scale deployment -n kube-system coredns --replicas=2
# 시간 지정: 1초(s) 1분(m) 1시간(h) 하루(d) 한주(w)
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --since 1h30m
# 짧게 출력
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --since 1h30m --format short
CloudWatch Log Insights
# EC2 Instance가 NodeNotReady 상태인 로그 검색
fields @timestamp, @message
| filter @message like /NodeNotReady/
| sort @timestamp desc
# kube-apiserver-audit 로그에서 userAgent 정렬해서 아래 4개 필드 정보 검색
fields userAgent, requestURI, @timestamp, @message
| filter @logStream ~= "kube-apiserver-audit"
| stats count(userAgent) as count by userAgent
| sort count desc
#
fields @timestamp, @message
| filter @logStream ~= "kube-scheduler"
| sort @timestamp desc
#
fields @timestamp, @message
| filter @logStream ~= "authenticator"
| sort @timestamp desc
#
fields @timestamp, @message
| filter @logStream ~= "kube-controller-manager"
| sort @timestamp desc
로깅 끄기
# EKS Control Plane 로깅(CloudWatch Logs) 비활성화
eksctl utils update-cluster-logging --cluster $CLUSTER_NAME --region $AWS_DEFAULT_REGION --disable-types all --approve
# 로그 그룹 삭제
aws logs delete-log-group --log-group-name /aws/eks/$CLUSTER_NAME/cluster
3. Container Insights metrics in Amazon CloudWatch & Fluent Bit (Logs)
- CloudWatch Container Insight : 노드에 CW Agent 파드와 Fluent Bit 파드가 데몬셋으로 배치되어 Metrics 와 Logs 수집
- [수집] 플루언트비트 Fluent Bit 컨테이너를 데몬셋으로 동작시키고, 아래 3가지 종류의 로그를 CloudWatch Logs에 전송
1. /aws/containerinsights/`Cluster_Name'/application : 로그 소스(All log files in `/var/log/containers`), 각 컨테이너/파드 로그
2. /aws/containerinsights/`Cluster_Name`/host : 로그 소스(Logs from `/var/log/dmesg`, `/var/log/secure`, and `/var/log/messages`), 노드(호스트) 로그
3. /aws/containerinsights/*`Cluster_Name'/dataplane : 로그 소스(`/var/log/journal` for `kubelet.service`, `kubeproxy.service`, and `docker.service`), 쿠버네티스 데이터플레인 로그
- [저장] : CloudWatch Logs 에 로그를 저장, 로그 그룹 별 로그 보존 기간 설정 가능
- [시각화] : CloudWatch 의 Logs Insights 를 사용하여 대상 로그를 분석하고, CloudWatch 의 대시보드로 시각화한다.
CloudWatch Container Insight 설치
FluentBitHttpServer='On'
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
FluentBitReadFromTail='On'
curl -s https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml | sed 's/{{cluster_name}}/'${CLUSTER_NAME}'/;s/{{region_name}}/'${AWS_DEFAULT_REGION}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl apply -f -
# 설치 확인
kubectl get-all -n amazon-cloudwatch
kubectl get ds,pod,cm,sa -n amazon-cloudwatch
kubectl describe clusterrole cloudwatch-agent-role fluent-bit-role # 클러스터롤 확인
kubectl describe clusterrolebindings cloudwatch-agent-role-binding fluent-bit-role-binding # 클러스터롤 바인딩 확인
kubectl -n amazon-cloudwatch logs -l name=cloudwatch-agent -f # 파드 로그 확인
kubectl -n amazon-cloudwatch logs -l k8s-app=fluent-bit -f # 파드 로그 확인
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo ss -tnlp | grep fluent-bit; echo; done
# cloudwatch-agent 설정 확인
kubectl describe cm cwagentconfig -n amazon-cloudwatch
Name: cwagentconfig
Namespace: amazon-cloudwatch
Labels: <none>
Annotations: <none>
Data
====
cwagentconfig.json:
----
{
"agent": {
"region": "ap-northeast-2"
},
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "myeks",
"metrics_collection_interval": 60
}
},
"force_flush_interval": 5
}
}
BinaryData
====
Events: <none>
# CW 파드가 수집하는 방법 : Volumes에 HostPath를 살펴보자! >> / 호스트 패스 공유??? 보안상 안전한가? 좀 더 범위를 좁힐수는 없을까요?
kubectl describe -n amazon-cloudwatch ds cloudwatch-agent
...
ssh ec2-user@$N1 sudo tree /dev/disk
...
# Fluent Bit Cluster Info 확인
kubectl get cm -n amazon-cloudwatch fluent-bit-cluster-info -o yaml | yh
apiVersion: v1
data:
cluster.name: myeks
http.port: "2020"
http.server: "On"
logs.region: ap-northeast-2
read.head: "Off"
read.tail: "On"
kind: ConfigMap
...
# Fluent Bit 로그 INPUT/FILTER/OUTPUT 설정 확인 - 링크
## 설정 부분 구성 : application-log.conf , dataplane-log.conf , fluent-bit.conf , host-log.conf , parsers.conf
kubectl describe cm fluent-bit-config -n amazon-cloudwatch
...
application-log.conf:
----
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
multiline.parser docker, cri
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
[FILTER]
Name kubernetes
Match application.*
Kube_URL https://kubernetes.default.svc:443
Kube_Tag_Prefix application.var.log.containers.
Merge_Log On
Merge_Log_Key log_processed
K8S-Logging.Parser On
K8S-Logging.Exclude Off
Labels Off
Annotations Off
Use_Kubelet On
Kubelet_Port 10250
Buffer_Size 0
[OUTPUT]
Name cloudwatch_logs
Match application.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/application
log_stream_prefix ${HOST_NAME}-
auto_create_group true
extra_user_agent container-insights
...
# Fluent Bit 파드가 수집하는 방법 : Volumes에 HostPath를 살펴보자!
kubectl describe -n amazon-cloudwatch ds fluent-bit
...
ssh ec2-user@$N1 sudo tree /var/log
...
# (참고) 삭제
curl -s https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml | sed 's/{{cluster_name}}/'${CLUSTER_NAME}'/;s/{{region_name}}/'${AWS_DEFAULT_REGION}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl delete -f -
로그확인
AWS CloudWatch 를 통해 다양한 방법으로 로그를 확인할 수 있다.
4. Metrics-server & kwatch & botkube
Metrics-server 확인
-> kubelet으로부터 수집한 리소스 메트릭을 수집 및 집계하는 클러스터 애드온 구성 요소이다.
- cAdvisor : kubelet에 포함된 컨테이너 메트릭을 수집, 집계, 노출하는 데몬
# 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl get pod -n kube-system -l k8s-app=metrics-server
kubectl api-resources | grep metrics
kubectl get apiservices |egrep '(AVAILABLE|metrics)'
# 노드 메트릭 확인
kubectl top node
# 파드 메트릭 확인
kubectl top pod -A
kubectl top pod -n kube-system --sort-by='cpu'
kubectl top pod -n kube-system --sort-by='memory'
kwatch 소개 및 설치
kwatch는 Amazon EKS에서 실행되는 Kubernetes 클러스터를 모니터링하고 디버깅하기 위한 도구이다. kwatch는 터미널 기반의 인터페이스를 제공하여 Kubernetes 리소스의 상태, 이벤트, 로그 등을 실시간으로 볼 수 있도록 도와준다.
- 리소스 모니터링: kwatch를 사용하여 클러스터의 노드, 포드, 서비스 등의 Kubernetes 리소스의 상태를 실시간으로 모니터링할 수 있다. 이를 통해 리소스의 상태를 신속하게 파악하고 문제가 있는 리소스를 식별할 수 있다.
- 이벤트 및 로그 조회: kwatch를 통해 클러스터 내에서 발생하는 이벤트를 확인하고, 각 리소스의 로그를 실시간으로 조회할 수 있다. 이를 통해 애플리케이션의 동작을 추적하고, 오류 또는 문제를 진단할 수 있다.
- 리소스 필터링 및 검색: kwatch는 리소스를 필터링하고 특정 리소스를 검색하는 기능을 제공한다. 이를 통해 특정 포드, 노드 또는 네임스페이스와 관련된 리소스를 신속하게 찾을 수 있다.
- 인터랙티브한 사용자 인터페이스: kwatch는 터미널 기반의 인터랙티브한 사용자 인터페이스를 제공하여 사용자가 쉽게 클러스터를 모니터링하고 탐색할 수 있도록 도와준다. 사용자는 키보드를 사용하여 다양한 작업을 수행하고 리소스 간 이동할 수 있다.
# configmap 생성
cat <<EOT > ~/kwatch-config.yaml
apiVersion: v1
kind: Namespace
metadata:
name: kwatch
---
apiVersion: v1
kind: ConfigMap
metadata:
name: kwatch
namespace: kwatch
data:
config.yaml: |
alert:
slack:
webhook: 'https://hooks.slack.com/<Slack URL>
title: $NICK-EKS
#text:
pvcMonitor:
enabled: true
interval: 5
threshold: 70
EOT
kubectl apply -f kwatch-config.yaml
# 배포
kubectl apply -f https://raw.githubusercontent.com/abahmed/kwatch/v0.8.3/deploy/deploy.yaml
잘못된 이미지 파드 배포 및 확인
# 터미널1
watch kubectl get pod
# 잘못된 이미지 정보의 파드 배포
kubectl apply -f https://raw.githubusercontent.com/junghoon2/kube-books/main/ch05/nginx-error-pod.yml
kubectl get events -w
# 이미지 업데이트 방안2 : set 사용 - iamge 등 일부 리소스 값을 변경 가능!
kubectl set
kubectl set image pod nginx-19 nginx-pod=nginx:1.19
# 삭제
kubectl delete pod nginx-19
kwatch 삭제
kubectl delete -f https://raw.githubusercontent.com/abahmed/kwatch/v0.8.3/deploy/deploy.yaml
5. 프로메테우스-스택
주요 기능
- 메트릭 이름과 키/값 쌍에 의해 식별되는 다차원의 데이터 모델을 가지고 있다. 이 모델은 시계열 데이터(=TSDB, 시계열 데이터베이스)를 사용한다.
- 이러한 다차원 데이터 모델을 활용하기 위해 유연한 쿼리 언어인 PromQL을 제공한다.
- 분산 저장소에 의존하지 않으며, 단일 서버 노드는 자체적으로 동작한다.
- 시계열 데이터 수집은 HTTP를 통한 pull 모델을 사용한다.
- 중간 게이트웨이를 통해 시계열 데이터를 푸시하는 것도 지원한다.
- 타겟은 서비스 디스커버리 또는 정적 설정을 통해 발견된다.
- 다양한 그래프 및 대시보드 지원 모드가 있다.
구성요소
- 주요 구성 요소는 Prometheus 서버이다. 이 서버는 시계열 데이터를 가져와 저장한다.
- 클라이언트 라이브러리는 응용 프로그램 코드를 계측하는 데 사용된다.
- 푸시 게이트웨이는 일시적인 작업을 지원하는 데 사용된다.
- 특수 목적의 익스포터는 HAProxy, StatsD, Graphite 등과 같은 서비스를 위해 사용된다.
- 알림 관리자는 알림을 처리하는 데 사용된다.
Prometheus 오퍼레이터 소개
Prometheus 오퍼레이터는 Kubernetes에서 Prometheus 서버를 배포, 구성 및 관리하기 위한 툴이다.
EKS 환경에서 Prometheus 오퍼레이터를 사용하면 쉽게 Prometheus 서버를 구성하고 모니터링 리소스를 관리할 수 있다.
Prometheus 오퍼레이터는 Kubernetes의 컨트롤 플레인과 통합되어 자동으로 서비스 디스커버리, 구성 관리, 스케일링 등을 수행한다.
타노스 소개
타노스는 Prometheus 오퍼레이터와 함께 사용되는 알림 관리 도구이다.
Prometheus에서 생성된 경고(alerts)를 처리하고, 사용자에게 경고를 전달하는 역할을 수행한다.
타노스는 유연한 경고 룰 설정, 경고 그룹화, 알림 전달 채널 지원 등 다양한 기능을 제공하여 모니터링 운영을 용이하게 해준다.
EKS에서 Prometheus 오퍼레이터 및 타노스 설정하기
EKS 클러스터에 Prometheus 오퍼레이터 및 타노스를 배포하고 구성하기 위한 단계를 안내한다.
Prometheus 오퍼레이터의 Helm 차트를 사용하여 간편하게 배포할 수 있으며, 타노스 구성 파일을 작성하여 경고 관리를 설정할 수 있다.
프로메테우스-스택 설치
- 모니터링에 필요한 여러 요소를 단일 차트(스택)으로 제공 ← 시각화(그라파나), 이벤트 메시지 정책(경고 임계값, 경고 수준) 등
.
# 모니터링
kubectl create ns monitoring
watch kubectl get pod,pvc,svc,ingress -n monitoring
# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN
# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
# 파라미터 파일 생성
cat <<EOT > monitor-values.yaml
prometheus:
prometheusSpec:
podMonitorSelectorNilUsesHelmValues: false
serviceMonitorSelectorNilUsesHelmValues: false
retention: 5d
retentionSize: "10GiB"
ingress:
enabled: true
ingressClassName: alb
hosts:
- prometheus.$MyDomain
paths:
- /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
grafana:
defaultDashboardsTimezone: Asia/Seoul
adminPassword: prom-operator
ingress:
enabled: true
ingressClassName: alb
hosts:
- grafana.$MyDomain
paths:
- /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
defaultRules:
create: false
kubeControllerManager:
enabled: false
kubeEtcd:
enabled: false
kubeScheduler:
enabled: false
alertmanager:
enabled: false
# alertmanager:
# ingress:
# enabled: true
# ingressClassName: alb
# hosts:
# - alertmanager.$MyDomain
# paths:
# - /*
# annotations:
# alb.ingress.kubernetes.io/scheme: internet-facing
# alb.ingress.kubernetes.io/target-type: ip
# alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
# alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
# alb.ingress.kubernetes.io/success-codes: 200-399
# alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
# alb.ingress.kubernetes.io/group.name: study
# alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT
cat monitor-values.yaml | yh
# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 45.27.2 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring
# 확인
## alertmanager-0 : 사전에 정의한 정책 기반(예: 노드 다운, 파드 Pending 등)으로 시스템 경고 메시지를 생성 후 경보 채널(슬랙 등)로 전송
## grafana : 프로메테우스는 메트릭 정보를 저장하는 용도로 사용하며, 그라파나로 시각화 처리
## prometheus-0 : 모니터링 대상이 되는 파드는 ‘exporter’라는 별도의 사이드카 형식의 파드에서 모니터링 메트릭을 노출, pull 방식으로 가져와 내부의 시계열 데이터베이스에 저장
## node-exporter : 노드익스포터는 물리 노드에 대한 자원 사용량(네트워크, 스토리지 등 전체) 정보를 메트릭 형태로 변경하여 노출
## operator : 시스템 경고 메시지 정책(prometheus rule), 애플리케이션 모니터링 대상 추가 등의 작업을 편리하게 할수 있게 CRD 지원
## kube-state-metrics : 쿠버네티스의 클러스터의 상태(kube-state)를 메트릭으로 변환하는 파드
helm list -n monitoring
kubectl get pod,svc,ingress -n monitoring
kubectl get-all -n monitoring
kubectl get prometheus,servicemonitors -n monitoring
kubectl get crd | grep monitoring
삭제
# helm 삭제
helm uninstall -n monitoring kube-prometheus-stack
# crd 삭제
kubectl delete crd alertmanagerconfigs.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com
kubectl delete crd podmonitors.monitoring.coreos.com
kubectl delete crd probes.monitoring.coreos.com
kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd thanosrulers.monitoring.coreos.com
6. 그라파나
그라파나(Grafana)는 시각화 및 대시보드 도구로, 여러 데이터 소스에서 가져온 데이터를 사용자에게 시각적으로 표현해준다. 다양한 데이터 소스를 지원하며, 그래프, 표, 알림 등 다양한 방식으로 데이터를 표현할 수 있다. 그라파나는 사용자 친화적인 인터페이스와 다양한 주요 기능을 제공한다.
주요 기능
- 다양한 데이터 소스 연동: 그라파나는 여러 데이터 소스와 연동하여 데이터를 가져올 수 있다. 예를 들어, 프로메테우스, 그래파이트, 인플럭스DB 등의 데이터 소스를 지원한다.
- 유연한 대시보드 구성: 그라파나를 사용하면 사용자가 원하는 대시보드를 유연하게 구성할 수 있다. 그래프, 표, 알림, 템플릿 등을 사용하여 데이터를 시각화하고 원하는 형태로 표현할 수 있다.
- 시각화 기능: 그라파나는 다양한 시각화 옵션을 제공하여 데이터를 직관적으로 이해할 수 있게 도와준다. 그래프, 게이지, 히트맵 등 다양한 시각화 형식을 지원한다.
- 대시보드 공유 및 협업: 그라파나에서는 대시보드를 다른 사용자와 공유하고 협업할 수 있다. 대시보드를 공유 링크로 전달하거나 팀원과 함께 대시보드를 편집할 수 있다.
- 경고 및 알림 기능: 그라파나는 데이터에 기반한 경고 및 알림 기능을 제공한다. 사용자가 설정한 조건에 따라 경고를 생성하고, 이를 이메일, 메신저 등으로 알림으로 받을 수 있다.
- 템플릿 기능: 그라파나에서는 템플릿 기능을 제공하여 대시보드를 유연하게 구성할 수 있다. 템플릿을 사용하여 동일한 형식의 여러 대시보드를 쉽게 생성하고 관리할 수 있다.
접속 정보 확인(기본 계정: admin / prom-operator)
기본 대시보드 확인
- Search dashboards : 대시보드 검색
- Starred : 즐겨찾기 대시보드
- Dashboards : 대시보드 전체 목록 확인
- Explore : 쿼리 언어 PromQL를 이용해 메트릭 정보를 그래프 형태로 탐색
- Alerting : 경고, 에러 발생 시 사용자에게 경고를 전달
- Connections : 설정, 예) 데이터 소스 설정 등
- Administartor : 사용자, 조직, 플러그인 등 설정
'AWES[1기](Amzaon EKS Study)' 카테고리의 다른 글
[AWES] 6주차 - EKS Security (0) | 2023.06.01 |
---|---|
[AWES] 5주차 - EKS Autoscaling (0) | 2023.05.25 |
[AWES] 3주차 - EKS Storage & Node 관리 (0) | 2023.05.10 |
[AWES] 2주차 - EKS Networking (0) | 2023.05.03 |
[AWES] 1주차 - Amzaon EKS 설치 및 기본 사용 (4) | 2023.04.27 |