Grafana + cloud watch로 서버 감시하기

 

개요

그라파나는 자체적으로 데이터를 저장하지 않고, 외부 메트릭/로그 저장소에 쿼리를 보내 결과를 가져와 대시보드로 시각화하는 방식으로 동작하는 오픈소스 모니터링·시각화 도구입니다.

그렇다면 이것을 왜 사용할까요?
사용자가 웹 UI에서 대시보드와 패널을 설정하면, 각 패널마다 데이터 소스와 쿼리를 정의해 시계열 그래프, 테이블, 게이지 등으로 데이터를 볼 수 있습니다. 인프라/백엔드 개발자가 한 번 서버와 애플리케이션 메트릭(CPU 사용량, 메모리 사용량, 네트워크 트래픽, 에러율 등)을 수집하고 대시보드를 만들어 두면, 기획자와 프론트엔드, 백엔드 개발자 모두가 동일한 화면에서 시스템 상태를 시각적으로 쉽게 확인할 수 있습니다. 덕분에 백엔드에 문제가 생겼을 때 매번 로그나 서버에 바로 접속하지 않고도, 누구나 먼저 대시보드를 보고 이상 징후를 확인할 수 있어 커뮤니케이션 비용을 크게 줄일 수 있습니다.

---

spring에서 설정

저는 저희 LinkU 프로젝트에서 cloud watch를 통해 grafana 그래프를 그리기로 했습니다.
CloudWatch Logs는 “형식 하나”로 고정돼 있는 것이 아니라, 서비스·에이전트에서 보내는 로그를 이벤트 단위로 받아서 저장하며, 기본 구조만 공통으로 갖습니다.

그룹: 로그 그룹(Log Group) 이름

스트림: 로그 스트림(Log Stream) 이름

필드:

    timestamp: 애플리케이션/시스템에서 찍힌 시간

    message: 실제 로그 문자열(원본 텍스트, JSON, CSV 등)

    그 외 메타데이터는 Insights에서 @timestamp, @message, @logStream, @log, @ingestionTime 같은 시스템 필드로 노출됨

{
  "timestamp": 1737102000123,
  "message": "INFO 2026-01-17 11:00:00,123 [UserController] GET /api/v1/users/123 200 OK userId=123 latency=45ms",
  "logStreamName": "my-app-prod-1",
  "logGroupName": "/aws/my-app/prod"
}

Spring(부트)에서 로그 포맷을 설계해서 한 줄씩 찍어 주면, 그 한 줄이 그대로 CloudWatch의 message가 되고  Grafana에서 상세 로그로 볼수 있습니다.

application.properties에  다음과 같이 설정하면 spring에서 로그를 포맷팅해서 stdout으로 찍어줍니다. 이렇게 애플리케이션이 콘솔(stdout)에 출력한 로그를 CloudWatch가 받아서 저장합니다.

# Logging 설정
logging.level.root=INFO
logging.level.com.umc.linkyou=DEBUG
logging.level.org.springframework.web=INFO
logging.level.org.hibernate=INFO
logging.pattern.console=%d{yyyy-MM-dd HH:mm:ss} - %msg%n
logging.pattern.file=%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n

---

grafana + cloud watch 설정하기

https://blog.omoknooni.me/58

Cloudwatch Agent로 EC2 모니터링

 
1. cloud watch 설정
1) IAM 설정

2) 권한추가

3) 역할 이름 정하고 생성합니다.

 
 
https://wlsdn3004.tistory.com/34

[Grafana] + AWS CloudWatch를 이용한 AWS 모니터링

 
2. Grafana
1) 먼저 회원가입, 로그인을 합니다.
https://grafana.com/

Grafana: The open and composable observability platform | Grafana Labs

 
2) 그러면 home에 들어갈 수 있습니다.

 
3) data sources에 들어가서 add new data source를 누릅니다.

 
3) 여기서 cloud watch를 추가해줍니다.

 
4) Access Key ID / Secret Access Key에 권한이 있는 AWS Credencials 정보와 default regioin을 넣어 줍니다.

 
5) save& test를 통해 정상적으로 연결되었는지 확인합니다.

 
6) 상단의 explore data를 통해 실제로 값을 잘 가져오는 지 확인 할 수 있습니다.

 
explore 탭에서 해당 datasource를 눌러 확인할 수 있습니다.

 
7) 간단히 AWS ApplicationELB 502 Count(502 Bad Gateway 에러의 발생 횟수)의 sum(총합) 비교해 보았습니다.
"AWS Application Load Balancer에서 발생한 502 오류의 총합을 기준으로, 특정 조건들 간의 발생량을 비교했다"는 의미입니다.
# AWS ApplicationELB: AWS의 Application Load Balancer (ALB)

 
- AWS/EC2 로 인스턴스 상태 감시하기
namespace 를 AWS/EC2로 선택하고 metric name을 CPUUtilization, NetworkIn등으로 설정합니다.

Namespace: AWS/EC2
    CPU 사용률: CPUUtilization
    네트워크 In/Out: NetworkIn, NetworkOut
    디스크: DiskReadBytes, DiskWriteBytes

- AWS/RDS로 주요지표 감시하기

Namespace: AWS/RDS
    CPUUtilization  : DB 인스턴스 CPU 사용률. 70–80% 이상 오래 지속되면 스케일업/쿼리 튜닝 고려.​

    FreeableMemory : 남은 메모리 양(Bytes). 100MB 이하로 자주 떨어지면 메모리 부족/스왑 위험.​

    DatabaseConnections : 현재 사용 중인 DB 커넥션 수. 커넥션 풀 설정이랑 비교해서 피크 때 max에 붙는지 확인.​

    FreeStorageSpace : 남은 디스크 용량(Bytes). 용량 거의 다 쓰면 성능 저하 + 장애 위험이라 미리 알람.​

    ReadIOPS / WriteIOPS, ReadLatency / WriteLatency : 초당 I/O 횟수와 I/O 지연. 디스크가 병목인지 볼 때 사용.​

    DiskQueueDepth : 디스크 대기열 길이. 1 이상으로 계속 높게 유지되면 I/O 병목 가능성.

 
8) CloudWatch Log group의 내용도 Logs Insights 쿼리를 사용하여 대시보드를 만들 수 있습니다.