InfluxDBで時系列データを長く安定して扱うには、「タグとフィールドの設計」「保持期間（リテンション）」「ダウンサンプリング」の3点を最初に決めておくことが大切です。この記事では、サーバーやWordPressサイトの監視データを例に、データの書き込み方、保持期間の設定、集計済みデータへの移し替え、バックアップまでの管理手順を解説します。読み終えるころには、データが増え続けても遅くならない構成を自分で組み立てられるようになります。
まずバージョンの違いを確認する
InfluxDBはメジャーバージョンごとに、クエリ言語や管理の単位が大きく異なります。手順を調べる前に、使っている（これから使う）バージョンを確かめてください。以下の整理は執筆時点の情報です（2026年10月現在）。
- InfluxDB 1.x：データベースと保持ポリシー（retention policy）で管理し、クエリは InfluxQL。継続クエリ（continuous query）でダウンサンプリングします。
- InfluxDB 2.x：組織（organization）とバケット（bucket）で管理し、バケットごとに保持期間を持ちます。クエリは Flux が中心で、定期処理はタスク（task）で書きます。認証はAPIトークンです。
- InfluxDB 3（Core / Enterprise など）：保存形式やエンジンが刷新され、クエリは SQL と InfluxQL が中心です。Flux は対象外とされているため、2.x の Flux 資産をそのまま移せない点に注意が必要です。
この記事のコマンド例は、情報がまとまっていて採用例も多い 2.x を中心にし、3 での書き方を補足します。どの版でも、提供元（InfluxData）のドキュメントで最新の仕様と制限を確認してから導入してください。
データモデル：タグとフィールドを正しく分ける
InfluxDBのデータは、1行が「measurement・タグ・フィールド・タイムスタンプ」で構成されます。書き込みには line protocol という形式を使います。
cpu,host=web01,region=tokyo usage_user=12.5,usage_system=3.1 1760745600
http_response,host=web01,site=blog status=200i,response_ms=184.2 1760745600- measurement（
cpu）：RDBのテーブルに近い単位です。 - タグ（
host=web01）：文字列でインデックスされ、絞り込みやグループ化に使います。 - フィールド（
usage_user=12.5）：実際の計測値です。整数は末尾にiを付けます。 - タイムスタンプ：省略するとサーバーの受信時刻になります。単位（秒・ミリ秒・ナノ秒）は書き込み時の精度指定と合わせます。
設計でいちばん重要なのは「何をタグにするか」です。タグの値の組み合わせごとに「シリーズ」が作られ、シリーズ数（カーディナリティ）が増えるほどメモリ使用量や検索負荷が増えます。ホスト名・リージョン・サイト名のように種類が限られる値はタグに、ユーザーID・リクエストID・URLのクエリ文字列のように無数に増える値はタグにしないのが基本です。後者はフィールドに入れるか、そもそも時系列DBに入れずログ基盤で扱います。
また、同じフィールド名に整数と小数を混在させると型の衝突で書き込みエラーになります。status=200i と status=200 を混ぜないよう、送信側で型を固定してください。
バケットと保持期間を設定する
時系列データは放っておくと増え続けます。「生データは何日残すか」を最初に決め、保持期間として設定しておきます。2.x では次のようにバケット単位で指定します。
# 生データ：30日で自動削除
influx bucket create --name metrics_raw --retention 30d
# 1時間平均の集計データ：400日保持
influx bucket create --name metrics_1h --retention 400d
# 設定の確認
influx bucket list保持期間を過ぎたデータは自動的に削除されます。期限を短く変更すると古いデータは戻せないため、変更前にバックアップを取ってください。保持期間の判断材料は「障害調査で何日前まで遡るか」「月次・年次の比較に何が必要か」です。細かい生データは短く、集計済みデータは長く残すと、容量と分析のしやすさを両立できます。
書き込みは CLI でも試せます。実運用では次の章のように Telegraf などの収集エージェントから送るのが一般的です。
influx write --bucket metrics_raw --precision s \
"cpu,host=web01,region=tokyo usage_user=12.5,usage_system=3.1 1760745600"収集はTelegrafに任せる
自作スクリプトで書き込むより、InfluxData の収集エージェント Telegraf を使うと、CPU・メモリ・ディスク・Nginx・MySQL などの入力プラグインをそのまま利用できます。出力先にInfluxDBを指定すれば、line protocol の組み立てや再送処理を任せられます。
[agent]
interval = "10s"
[[inputs.cpu]]
percpu = false
totalcpu = true
[[inputs.mem]]
[[outputs.influxdb_v2]]
urls = ["http://127.0.0.1:8086"]
token = "${INFLUX_TOKEN}"
organization = "your-org"
bucket = "metrics_raw"トークンは設定ファイルに直書きせず、環境変数から読み込む形にしておくと、設定ファイルをGitで管理しても秘密情報が残りません。トークンには書き込み先バケットへの書き込み権限だけを与え、管理者トークンを流用しないでください。
収集間隔も容量に直結します。10秒間隔なら1日あたり8,640点、1分間隔なら1,440点です。監視の目的に対して細かすぎないかを見直すだけで、データ量を大きく減らせることがあります。
ダウンサンプリングで長期データを軽くする
ダウンサンプリングとは、細かい生データを一定間隔の平均や最大値にまとめ、別のバケットへ保存することです。2.x では Flux のタスクで定期実行します。
option task = {name: "downsample_cpu_1h", every: 1h}
from(bucket: "metrics_raw")
|> range(start: -task.every)
|> filter(fn: (r) => r._measurement == "cpu")
|> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
|> to(bucket: "metrics_1h")このタスクは1時間ごとに直近1時間分の cpu を平均し、metrics_1h に書き込みます。平均だけでは瞬間的なピークが消えるため、障害分析に使う指標は fn: max のタスクも別に用意すると判断を誤りにくくなります。
タスクを作ったら、実行履歴にエラーが出ていないか、集計先バケットに想定どおりの点数が入っているかを確かめます。データの到着が遅れる環境では、range の開始を少し前にずらしたり、タスクの offset を設定したりして取りこぼしを防ぎます。
InfluxDB 3 ではクエリが SQL 中心になります。たとえば5分ごとの平均は次のように書けます。定期実行の仕組みは版や構成によって異なるため、公式ドキュメントで提供されている方法を確認してください。
SELECT
date_bin(INTERVAL '5 minutes', time) AS bucket,
host,
avg(usage_user) AS avg_user
FROM cpu
WHERE time >= now() - INTERVAL '1 day'
GROUP BY 1, host
ORDER BY 1;クエリの書き方で負荷を抑える
時系列DBでは、クエリの書き方が負荷を大きく左右します。次の3点を守るだけで、ダッシュボードの表示が安定しやすくなります。
- 期間を毎回短く区切る：Flux なら
range、SQL ならWHERE time >= ...を先頭に置き、全期間を走査しないようにします。 - タグで先に絞る：measurement とタグの条件を早い段階で指定すると、読み込むシリーズが減ります。
- 長期間は集計済みバケットを見る：1年分のグラフに生データを使わず、
metrics_1hなどを参照します。
可視化には Grafana がよく使われます。パネルごとに表示期間に応じた集計間隔を使う設定にしておくと、期間を広げたときに点数が膨らみすぎるのを防げます。
バックアップと運用の確認
2.x では influx backup と influx restore でバックアップと復元ができます。
influx backup /backup/influxdb/$(date +%Y%m%d)バックアップは取るだけでなく、別環境に復元して中身を確認するところまで定期的に行ってください。あわせて、ディスク使用量の推移、シリーズ数、書き込みエラーの有無も監視対象に加えておくと、カーディナリティの急増などに早く気付けます。設定変更やバージョンアップは、ステージング環境で試してから本番に反映するのが安全です。
まとめ
- InfluxDBは 1.x・2.x・3 でクエリ言語と管理単位が異なります。まず使うバージョンを確定させます。
- 種類が限られる値はタグ、計測値はフィールドにし、ユーザーIDなど無数に増える値をタグにしないことでシリーズ数を抑えます。
- 生データは短い保持期間、集計済みデータは長い保持期間のバケットに分けます。
- 収集は Telegraf に任せ、トークンは環境変数と最小権限で管理します。
- ダウンサンプリングは平均と最大値を分けて残し、実行結果を確認します。
- バックアップは復元テストまで行い、ディスクとシリーズ数を継続的に監視します。