설치·설계
에디션 선택, 패키지·Docker 설치, 스토리지(로컬/객체) 설계, 스키마·카디널리티 설계.
InfluxDB
서버·설비·IoT·애플리케이션 지표처럼 시간에 따라 쌓이는 데이터를 위한 InfluxDB. 버전 선택(2.x / 3 Core / 3 Enterprise)부터 Telegraf 수집, 보존·다운샘플링, 백업, Grafana 시각화까지 설계합니다.
Pipeline
대표적인 TIG(Telegraf · InfluxDB · Grafana) 파이프라인입니다.
Telegraf 에이전트가 서버·DB·네트워크·설비 지표를 수집해 InfluxDB로 전송하고, Grafana가 대시보드와 알림을 제공합니다. 장기 보관이 필요한 데이터는 다운샘플링해 별도 버킷·데이터베이스로 옮겨 저장 비용과 조회 시간을 줄입니다.
Versions
같은 이름이지만 2.x와 3.x는 저장 엔진·쿼리 언어·운영 방식이 크게 다릅니다.
| 구분 | InfluxDB 2.x OSS | InfluxDB 3 Core | InfluxDB 3 Enterprise |
|---|---|---|---|
| 라이선스 | 오픈소스 | 오픈소스 | 상용 |
| 쿼리 | Flux, InfluxQL | SQL, InfluxQL | SQL, InfluxQL |
| 기본 포트·CLI | 8086 · influx | 8181 · influxdb3 | 8181 · influxdb3 |
| 데이터 단위 | Organization / Bucket | Database / Table | Database / Table |
| 보존 기간 | 버킷별, 변경 가능 | DB 생성 시 지정, 이후 변경 불가 | 변경 가능, 테이블별 보존 지원 |
| 백업 | influx backup / restore | 내장 명령 없음 — 객체 스토리지 파일 사본(정해진 순서) | 객체 스토리지 기반 |
| 고가용성 | 단일 노드 | 단일 노드 | HA · 읽기 복제본 등 클러스터 기능 |
influxdb:latest 태그가 3 Core를 가리키도록 바뀌었으므로, 2.x를 쓰는 환경은 버전 태그를 명시하세요. 버전·기능은 자주 바뀌므로 도입 시점에 공식 문서를 재확인합니다.Scope
에디션 선택, 패키지·Docker 설치, 스토리지(로컬/객체) 설계, 스키마·카디널리티 설계.
입력 플러그인 구성, outputs.influxdb_v2 / outputs.influxdb_v3 출력, 버퍼·배치 튜닝.
원본·집계 보존 정책, 2.x Task(Flux) 또는 3.x 처리 엔진 플러그인 기반 집계.
2.x CLI 백업, 3.x 객체 스토리지 사본 절차(서비스 중지 후 역순 복구) 수립과 테스트.
3 Enterprise 클러스터 구성 또는 OSS 환경의 이중 수집·복제 대안 설계.
쓰기 배치·압축, 쿼리 시간 범위·태그 필터, 메모리·캐시 설정, 고카디널리티 해소.
데이터 소스 구성(3.x는 SQL 권장), 대시보드·알림 규칙, 운영 지표 패널.
1.x/2.x → 3.x 이관 계획, 쿼리(Flux → SQL/InfluxQL) 전환, 병행 운영.
Examples
# 보존 기간은 생성 시에만 지정 가능 (Core)
influxdb3 create database --retention-period 30d \
--token "$INFLUXDB3_AUTH_TOKEN" sensors
# 보존 없이(무기한) 생성
influxdb3 create database --token "$INFLUXDB3_AUTH_TOKEN" sensors_raw# Telegraf 1.38+ : InfluxDB 3 전용 출력 플러그인
[[outputs.influxdb_v3]]
urls = ["https://influx.example.internal:8181"]
token = "${INFLUX_TOKEN}"
database = "sensors"
[[inputs.cpu]]
percpu = false
totalcpu = trueFAQ
SQL 기반 분석과 객체 스토리지를 원하면 3.x, 기존 Flux 자산과 검증된 2.x 운영 방식을 유지하려면 2.x가 현실적입니다. 보존 정책 변경 필요성, HA 요구(Enterprise 여부), 기존 대시보드를 함께 보고 결정합니다.
2026년 10월 기준 3 Core에는 내장 백업 명령이 없어, 공식 문서가 안내하는 순서대로 객체 스토리지(또는 로컬 저장 경로)의 파일을 복사하는 방식으로 백업합니다. 복구는 서비스를 멈춘 상태에서 역순으로 진행합니다.
Grafana의 InfluxDB 데이터 소스에서 SQL(또는 InfluxQL) 쿼리 언어를 선택해 연결합니다. 3.x에서는 Flux를 사용하지 않습니다.
태그 값 조합(시리즈) 수가 지나치게 많은 상태입니다. 사용자 ID·요청 ID처럼 값이 무한히 늘어나는 항목을 태그로 쓰면 성능·메모리 문제가 생길 수 있어 필드로 옮기는 등 스키마를 조정합니다.
사용 중인 클라우드·DB 버전·구성과 고민을 알려주시면 진단 범위와 진행 방식을 제안드립니다.