InfluxDB

InfluxDB 시계열 데이터 플랫폼 구축·운영

서버·설비·IoT·애플리케이션 지표처럼 시간에 따라 쌓이는 데이터를 위한 InfluxDB. 버전 선택(2.x / 3 Core / 3 Enterprise)부터 Telegraf 수집, 보존·다운샘플링, 백업, Grafana 시각화까지 설계합니다.

Pipeline

수집에서 시각화까지

대표적인 TIG(Telegraf · InfluxDB · Grafana) 파이프라인입니다.

Telegraf 에이전트가 서버·DB·네트워크·설비 지표를 수집해 InfluxDB로 전송하고, Grafana가 대시보드와 알림을 제공합니다. 장기 보관이 필요한 데이터는 다운샘플링해 별도 버킷·데이터베이스로 옮겨 저장 비용과 조회 시간을 줄입니다.

  • 측정값(measurement)·태그·필드 설계로 카디널리티 관리
  • 원본/집계 데이터의 보존 기간을 분리 설계
  • 수집 주기와 배치 크기로 쓰기 부하 조절
  • 토큰 권한 최소화와 TLS 적용
그림. Telegraf–InfluxDB–Grafana 참조 파이프라인

Versions

버전 선택 가이드 (2026년 10월 기준)

같은 이름이지만 2.x와 3.x는 저장 엔진·쿼리 언어·운영 방식이 크게 다릅니다.

InfluxDB 주요 에디션 비교
구분InfluxDB 2.x OSSInfluxDB 3 CoreInfluxDB 3 Enterprise
라이선스오픈소스오픈소스상용
쿼리Flux, InfluxQLSQL, InfluxQLSQL, InfluxQL
기본 포트·CLI8086 · influx8181 · influxdb38181 · influxdb3
데이터 단위Organization / BucketDatabase / TableDatabase / Table
보존 기간버킷별, 변경 가능DB 생성 시 지정, 이후 변경 불가변경 가능, 테이블별 보존 지원
백업influx backup / restore내장 명령 없음 — 객체 스토리지 파일 사본(정해진 순서)객체 스토리지 기반
고가용성단일 노드단일 노드HA · 읽기 복제본 등 클러스터 기능
출처: docs.influxdata.com (2026년 10월 확인). Docker influxdb:latest 태그가 3 Core를 가리키도록 바뀌었으므로, 2.x를 쓰는 환경은 버전 태그를 명시하세요. 버전·기능은 자주 바뀌므로 도입 시점에 공식 문서를 재확인합니다.

Scope

InfluxDB 서비스 범위

설치·설계

에디션 선택, 패키지·Docker 설치, 스토리지(로컬/객체) 설계, 스키마·카디널리티 설계.

Telegraf 수집

입력 플러그인 구성, outputs.influxdb_v2 / outputs.influxdb_v3 출력, 버퍼·배치 튜닝.

보존·다운샘플링

원본·집계 보존 정책, 2.x Task(Flux) 또는 3.x 처리 엔진 플러그인 기반 집계.

백업·복구

2.x CLI 백업, 3.x 객체 스토리지 사본 절차(서비스 중지 후 역순 복구) 수립과 테스트.

고가용성

3 Enterprise 클러스터 구성 또는 OSS 환경의 이중 수집·복제 대안 설계.

튜닝

쓰기 배치·압축, 쿼리 시간 범위·태그 필터, 메모리·캐시 설정, 고카디널리티 해소.

Grafana

데이터 소스 구성(3.x는 SQL 권장), 대시보드·알림 규칙, 운영 지표 패널.

이관

1.x/2.x → 3.x 이관 계획, 쿼리(Flux → SQL/InfluxQL) 전환, 병행 운영.

Examples

구성 예시

InfluxDB 3 Core — 데이터베이스 생성 (보존 30일)
# 보존 기간은 생성 시에만 지정 가능 (Core)
influxdb3 create database --retention-period 30d \
  --token "$INFLUXDB3_AUTH_TOKEN" sensors

# 보존 없이(무기한) 생성
influxdb3 create database --token "$INFLUXDB3_AUTH_TOKEN" sensors_raw
Telegraf → InfluxDB 3 출력 (telegraf.conf)
# Telegraf 1.38+ : InfluxDB 3 전용 출력 플러그인
[[outputs.influxdb_v3]]
  urls     = ["https://influx.example.internal:8181"]
  token    = "${INFLUX_TOKEN}"
  database = "sensors"

[[inputs.cpu]]
  percpu = false
  totalcpu = true
3 Core의 보존 기간은 나중에 바꿀 수 없으므로(새 DB 생성 후 이관 필요) 원본/집계 데이터베이스를 처음부터 분리해 설계하는 것이 안전합니다.

FAQ

자주 묻는 질문

지금 새로 시작하면 2.x와 3.x 중 무엇이 좋을까요?

SQL 기반 분석과 객체 스토리지를 원하면 3.x, 기존 Flux 자산과 검증된 2.x 운영 방식을 유지하려면 2.x가 현실적입니다. 보존 정책 변경 필요성, HA 요구(Enterprise 여부), 기존 대시보드를 함께 보고 결정합니다.

InfluxDB 3 Core도 백업 명령이 있나요?

2026년 10월 기준 3 Core에는 내장 백업 명령이 없어, 공식 문서가 안내하는 순서대로 객체 스토리지(또는 로컬 저장 경로)의 파일을 복사하는 방식으로 백업합니다. 복구는 서비스를 멈춘 상태에서 역순으로 진행합니다.

Grafana에서 3.x를 어떻게 연결하나요?

Grafana의 InfluxDB 데이터 소스에서 SQL(또는 InfluxQL) 쿼리 언어를 선택해 연결합니다. 3.x에서는 Flux를 사용하지 않습니다.

카디널리티가 높다는 건 무슨 뜻인가요?

태그 값 조합(시리즈) 수가 지나치게 많은 상태입니다. 사용자 ID·요청 ID처럼 값이 무한히 늘어나는 항목을 태그로 쓰면 성능·메모리 문제가 생길 수 있어 필드로 옮기는 등 스키마를 조정합니다.

클라우드와 데이터베이스, 지금 상태부터 함께 점검해 보시겠어요?

사용 중인 클라우드·DB 버전·구성과 고민을 알려주시면 진단 범위와 진행 방식을 제안드립니다.