Amazon Managed Grafana + Timestream 연동 실전 — 데이터 소스 + SAML + Telegraf on ECS

• AMG 워크스페이스에 Timestream 데이터 소스 연결, Azure AD SAML 인증 설정, ECS에서 Telegraf 컨테이너로 SNMP/Ping 메트릭 수집 → Timestream 적재
• 적용 환경: Amazon Managed Grafana (Grafana 9+) / Amazon Timestream for LiveAnalytics / Amazon ECS / Azure AD (SAML 2.0) / 1차 검증 시점: 2024-11-03
• GitHub 저장소: https://github.com/20eung/aws-grafana-timestream

1. 이 구조로 가능해지는 것

네트워크 장비(SNMP)와 일반 호스트(Ping)에서 메트릭을 수집해 시각화하는 일은 Grafana로 충분히 가능합니다. 다만 일반 Grafana를 직접 EC2에 올리면 인증·백업·업그레이드를 모두 직접 운영해야 하고, Timestream 같은 AWS 데이터 소스 연결도 plugin 설치 + IAM 키 관리를 직접 해야 합니다.

Amazon Managed Grafana (AMG) + Timestream 조합은 이 운영 부담을 AWS에 맡기고, 데이터 수집은 Telegraf 컨테이너로 분리한 패턴입니다.

• 시각화: AMG — SAML 인증, AWS SSO, plugin 자동 관리
• 데이터 소스: Timestream (LiveAnalytics) — 시계열 데이터베이스, 매트릭/디멘션 모델
• 수집: Telegraf container on ECS — SNMP/Ping input → Timestream output
• 설정 업데이트: S3 버킷에서 Telegraf 설정 변경, ECS task가 자동으로 reload
• 로그: CloudWatch Logs

원본 repo의 구성은 이 모든 조각을 AWS 자원으로 어떻게 묶는지를 보여주는 아키텍처 청사진 입니다.

이 글의 사연은 컨테이너 기반 Grafana 운영에서 출발합니다. 저는 기존에 Grafana, InfluxDB, Telegraf 를 각각 Docker container 로 EC2 한 대에 띄워 운영했었습니다. 트래픽이 늘면 컨테이너 메모리·CPU 가 빠르게 한계에 다다랐고, InfluxDB 의 TSM 파일이 누적되면 디스크 사용량을 주기적으로 체크해서 compaction 을 걸어야 했습니다. 컨테이너 하나가 죽으면 연쇄로 의존 서비스들이 영향을 받는 점도 운영 부담이었습니다. 이 모든 것을 EC2 사이즈 조정 + 디스크 관리 + 컨테이너 재기동 스크립트 + 백업 정책으로 직접 관리하는 게 한계에 와서, 인프라 운영 부담을 AWS 에 맡기는 방향으로 테스트를 시작했습니다.

이 글과 다음 글 (post-08) 은 같은 AMG + Telegraf on ECS 골격에 데이터 백엔드만 다르게 적용한 두 가지 시도입니다. AWS native 서비스만으로 Grafana 운영을 자동화하려는 목적은 같고, AWS Tokyo 리전의 Timestream 제약 때문에 데이터 백엔드를 OpenSearch 로 재구성한 다음 글로 이어집니다.

2. AMG에서 Timestream 데이터 소스 연결

AMG 워크스페이스에 Timestream을 데이터 소스로 등록하는 가장 빠른 경로는 AWS data source configuration 옵션입니다. AWS 계정에 이미 있는 Timestream database/table을 자동으로 발견하고 IAM 기반 인증을 자동 구성합니다.

2.1 AWS 공식 문서 기준 설정 옵션

Amazon Managed Grafana — Timestream settings 기준 설정 항목:

2.2 두 가지 연결 경로

• AWS data source configuration (권장): 워크스페이스 콘솔에서 클릭 몇 번으로 등록. 기존 Timestream 계정을 자동 발견하고 자격증명 자동 구성
• Manual configuration: self-managed Grafana와 동일한 방식으로 수동 설정. Assume Role ARN을 직접 입력해 인증 자격증명 구성

3. Azure AD SAML 인증 설정

AMG 워크스페이스 인증은 두 가지 옵션이 있습니다.
– AWS IAM Identity Center (SSO): AWS 조직 내 사용자
– SAML 2.0: Azure AD, Okta, OneLogin, Ping Identity, CyberArk 등 외부 IdP

원본 repo는 Azure AD를 IdP로 사용하는 SAML 인증을 가정합니다.

3.1 SAML 흐름 (SP-initiated)

Use SAML with your Amazon Managed Grafana workspace 기준:

1. 사용자가 AMG 워크스페이스 Grafana 콘솔에 접속
2. “Log in using SAML” 클릭
3. AMG 워크스페이스가 SAML 설정을 읽고 IdP(Azure AD) 로그인 페이지로 redirect
4. 사용자가 IdP에서 자격증명 입력
5. IdP가 SAML assertion 발급 후 다시 AMG로 redirect
6. AMG가 SAML assertion 검증 후 세션 생성

사용자 → AMG 콘솔 → "Log in using SAML" 클릭
        ↓
       IdP 로그인 페이지로 redirect
        ↓
       자격증명 입력 → IdP 인증
        ↓
       SAML assertion 발급
        ↓
       AMG가 assertion 검증 → 세션 생성

3.2 Azure AD 설정 단계

Configure Amazon Managed Grafana to use Azure AD 기준:

1. AMG 워크스페이스 생성 시 Authentication 탭에서 SAML 선택
2. Setup SAML 클릭
3. Azure AD Enterprise application 등록 (Gallery에서 “Amazon Managed Grafana” 검색)
4. SAML SSO 구성에서 Identifier(Entity ID), Reply URL(ACS URL) 입력
5. Azure AD 그룹/역할을 AMG 팀/역할에 매핑 (예: Developer 역할 → Grafana Admin)

워크스페이스 생성 시 인증을 구성한 IAM principal에는 AWSGrafanaAccountAdministrator policy가 부착돼 있어야 합니다. 워크스페이스가 생성된 후에는 해당 principal이 더 이상 필요하지 않습니다.

3.3 IdP → AMG 역할/그룹 매핑

IdP에 정의된 조직 역할(예: Developer, SRE, Viewer) 을 AMG 워크스페이스의 Grafana Admin/Editor/Viewer 역할에 매핑할 수 있습니다.

이 매핑을 통해 IdP의 사용자 프로비저닝이 변경되면 AMG 워크스페이스의 권한도 자동 갱신됩니다. Grafana 사용자별로 일일이 권한을 관리할 필요가 없습니다.

4. Telegraf on ECS — 메트릭 수집 → Timestream 적재

원본 repo의 Telegraf container 구조:

Telegraf container (ECS task)
├── Input: SNMP    (네트워크 장비 메트릭)
├── Input: Ping    (host reachability)
├── Output: Timestream
├── Config update: S3 버킷에서 자동 reload
└── Logging: CloudWatch Logs

4.1 Telegraf의 plugin 구조

Telegraf Documentation 기준 Telegraf는 300+ input plugins + 다수의 output plugins를 가진 plug-and-play 메트릭 수집 에이전트입니다. AMG/Timestream 스택에서 자주 쓰는 plugin:

4.2 Timestream output plugin 설정

Telegraf 설정 파일 (/etc/telegraf/telegraf.d/timestream.conf):

[[outputs.timestream]]
  region = "ap-northeast-2"
  database_name = "network_metrics"
  table_name = "snmp_metrics"
  describe_database_on_start = true
  create_table_if_not_exists = true
  ## 측정값 단위로 매트릭 분리
  measure_name_for_field = "_measurement"
  dimension_name_for_tag = "name"

  ## write 성능 튜닝
  batch_size = 5000
  batch_timeout = "5s"
  max_retries = 3

4.3 SNMP input plugin 예시

네트워크 장비 인터페이스 트래픽 수집:

[[inputs.snmp]]
  agents = [ "10.0.1.1:161", "10.0.1.2:161" ]
  version = 2
  community = "public"
  retries = 3
  timeout = "5s"

  [[inputs.snmp.field]]
    name = "ifHCInOctets"
    oid = "1.3.6.1.2.1.31.1.1.1.6"
  [[inputs.snmp.field]]
    name = "ifHCOutOctets"
    oid = "1.3.6.1.2.1.31.1.1.1.10"

  [[inputs.snmp.table]]
    name = "ifTable"
    inherit_tags = [ "hostname" ]
    [[inputs.snmp.table.field]]
      name = "ifDescr"
      oid = "1.3.6.1.2.1.2.2.1.2"
      is_tag = true
    [[inputs.snmp.table.field]]
      name = "ifOperStatus"
      oid = "1.3.6.1.2.1.2.2.1.8"
      is_tag = true

4.4 Ping input plugin 예시

[[inputs.ping]]
  urls = [ "8.8.8.8", "1.1.1.1", "10.0.1.1" ]
  count = 5
  ping_interval = 1.0
  timeout = 2.0
  method = "exec"

5. ECS task definition + S3 기반 설정 자동 reload

Telegraf container가 단일 ECS task로 동작하고, 설정 파일은 S3 버킷에서 가져옵니다. 설정 변경 시 ECS task를 redeploy하지 않고 S3에서 새 설정을 자동으로 reload하는 패턴입니다.

5.1 ECS task definition 핵심 부분

{
  "containerDefinitions": [
    {
      "name": "telegraf",
      "image": "telegraf:latest",
      "essential": true,
      "command": [
        "--config-directory", "/etc/telegraf/telegraf.d",
        "--watch-config", "s3"
      ],
      "environment": [
        { "name": "AWS_REGION", "value": "ap-northeast-2" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/telegraf",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "telegraf"
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "telegraf-config",
      "managedEBSVolume": {
        "roleArn": "arn:aws:iam::ACCOUNT_ID:role/ecs-task-ebs-role",
        "filesystemType": "ext4"
      }
    }
  ]
}

--watch-config s3 옵션이 핵심입니다. Telegraf v1.21+ 부터 S3 버킷의 설정 변경을 감지해 자동으로 reload합니다. ECS task를 redeploy할 필요가 없습니다.

5.2 S3 → Telegraf 설정 동기화 흐름

운영자가 S3에 새 telegraf.conf 업로드
  ↓
Telegraf agent가 s3:GetObject 버전/etag 변경 감지
  ↓
자동 reload — 새 설정으로 메트릭 수집 재개
  ↓
ECS task 자체는 계속 동작 (재시작 없음)

6. 자주 발생하는 오류와 해결법

7. 마치며

Amazon Managed Grafana + Timestream + Telegraf on ECS 조합은 운영 부담을 AWS에 맡기면서 메트릭 수집은 그대로 직접 제어하는 균형 잡힌 패턴입니다. AMG가 Grafana 업그레이드/인증/백업을 처리하고, Timestream이 시계열 데이터의 압축·쿼리 성능을 처리하고, Telegraf만 ECS에서 돌아가면 됩니다. 원본 repo는 이 구조의 아키텍처 청사진을 bullet list로 보여주며, 이 글의 AWS 공식 문서 인용이 각 조각의 실제 설정 옵션을 보강합니다.

다만 이 글의 Timestream 구성을 끝까지 운영하기엔 한 가지 결정적 제약이 있었습니다. Amazon Timestream 은 한국 리전에서 서비스하지 않고 Tokyo 리전에서만 제공됩니다. 메트릭이 많아질수록 리전 간 트래픽 비용이 누적되고, Grafana → Timestream 쿼리 지연도 무시 못 합니다. 운영 데이터가 모이는 버퍼 역할이라면 국외 리전 한 곳을 감수할 수도 있지만, Grafana 대시보드의 응답성을 직접 체감하는 구성에서는 사실상 단일 리전에 묶이는 게 유리합니다. 그래서 같은 AMG + Telegraf on ECS 골격 위에 데이터 백엔드만 OpenSearch 로 바꾼 다음 글 (post-08) 로 재구성했습니다. 두 글의 AWS 콘솔/CLI 차이를 같이 보면 인프라 운영 자동화에 AWS native 서비스를 어떤 조합으로 묶을지 판단하기 쉬워집니다.

추가로, Timestream 의 한국 리전 제공 여부는 AWS 측 로드맵에 따라 변경될 수 있는 영역입니다. 이 글 작성 시점(2024-11-03)에는 한국 리전 미제공이었지만 현재는 다를 수 있으므로 재현 전 Timestream 리전 가용성 페이지 최신판을 확인하시기 바랍니다.