2026年8月10日

InfluxDBの時系列データ管理方法（タグとフィールドの設計・保存期間・ダウンサンプリング）

データベースサーバー

InfluxDB で時系列データを無理なく管理するには、「タグとフィールドを正しく使い分けてシリーズ数を抑える」「保存期間を決めて古いデータを自動で消す」「長期保存が要るデータは粗い粒度に集約してから残す」の 3 点が要になります。この記事では、WordPress サーバーの応答時間やリクエスト数を記録する例で、データの設計、書き込みと問い合わせ、保存期間とダウンサンプリングの設定、バックアップまでを説明します。

版による違いを先に確認する

InfluxDB は版によって問い合わせ言語や管理の仕組みが大きく異なります（2026年10月現在）。

1.x: InfluxQL（SQL に似た言語）で操作。保存期間は「リテンションポリシー」、集約は「継続クエリ」で行う
2.x: 組織（org）・バケット・API トークンで管理。問い合わせは Flux が中心で、集約は「タスク」で行う
3 系（InfluxDB 3 Core / Enterprise など）: 新しい保存方式に作り直された版で、問い合わせは SQL と InfluxQL。Flux には対応していない

これから新しく始める場合でも、手元の Grafana や Telegraf の設定、既存のダッシュボードがどの版を前提にしているかで選び方が変わります。3 系は機能の追加が続いているため、保存期間などの細かな仕様は使う版の公式ドキュメントで確認してください。この記事では、利用の多い 2.x の手順を中心に、3 系の書き方も併記します。

データモデル: measurement・タグ・フィールド

InfluxDB の 1 件のデータ（ポイント）は、次の 4 つで構成されます。

measurement: データの種類。テーブル名に近いもの（例: nginx_requests）
タグ: 絞り込みやグループ化に使う文字列の属性。索引が作られる（例: host=web01）
フィールド: 実際に記録する値。数値・文字列・真偽値など（例: resp_time=0.084）
タイムスタンプ: 記録時刻

書き込みには「ラインプロトコル」という 1 行 1 ポイントの書式を使います。measurement とタグはカンマでつなぎ、空白のあとにフィールド、さらに空白のあとにタイムスタンプを書きます。整数のフィールドには末尾に i を付けます。

nginx_requests,host=web01,site=example.com count=125i,resp_time=0.084 1792281600

タイムスタンプを省略すると、受け取った時刻が使われます。書き込み時に精度を指定しない場合、タイムスタンプはナノ秒として解釈されるため、秒単位の値を送るときは精度の指定を忘れないようにします。

タグとフィールドの使い分けがもっとも重要

measurement とタグの値の組み合わせ 1 つ 1 つを「シリーズ」と呼びます。InfluxDB はシリーズごとに索引を持つため、シリーズの数（カーディナリティ）が増えるほど、メモリ使用量が増え、書き込みと問い合わせが遅くなります。特に 1.x と 2.x ではこの影響が大きく、設計の失敗がそのまま性能問題になります。

タグにしてよいもの: 種類が限られ、絞り込みに使う値。ホスト名、サイト名、リージョン、HTTP メソッド、ステータスコードの区分など。

タグにしてはいけないもの: 値の種類が際限なく増えるもの。

リクエスト ID、セッション ID、ユーザー ID
クエリ文字列付きの URL や、記事ごとの URL
IP アドレス
タイムスタンプや乱数を含む値

これらは記録が必要ならフィールドに入れます。フィールドには索引がないため、フィールドの値で絞り込むと全件を調べることになりますが、シリーズ数は増えません。「URL ごとの集計を長期間したい」といった要件は、アクセスログ解析向きのツール（Elasticsearch など）に任せるほうが適しています。

数値もタグにしないのが基本です。タグは常に文字列として扱われ、平均や合計の計算に使えません。

書き込みと問い合わせ

2.x の場合

バケットは、保存期間を指定して作成します。

influx bucket create --name wp_metrics --retention 30d
influx write --bucket wp_metrics --precision s \
  "nginx_requests,host=web01,site=example.com count=125i,resp_time=0.084 1792281600"

Flux での問い合わせは、バケット・期間・条件を順に絞り込み、最後に集約します。

from(bucket: "wp_metrics")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "nginx_requests" and r._field == "resp_time")
  |> filter(fn: (r) => r.host == "web01")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)

range は省略できず、期間を狭くするほど速くなります。

3 系の場合

3 系では、データベースを作り、SQL で問い合わせます。コマンドの実行には管理用に発行したトークンが必要です。

influxdb3 create database wp_metrics
influxdb3 write --database wp_metrics \
  "nginx_requests,host=web01,site=example.com count=125i,resp_time=0.084"
influxdb3 query --database wp_metrics \
  "SELECT date_bin(INTERVAL '5 minutes', time) AS t, avg(resp_time) AS avg_resp
   FROM nginx_requests
   WHERE time >= now() - INTERVAL '1 hour' AND host = 'web01'
   GROUP BY 1 ORDER BY 1"

実際の運用では、手でデータを書くことはほとんどありません。Telegraf を使い、Nginx・PHP-FPM・MySQL などの値を一定間隔で集めて書き込みます。Telegraf の出力先の設定は、1.x・2.x・3 系で項目が異なります。

保存期間（リテンション）を決める

時系列データは放っておくと増え続けます。「どの粒度のデータを、どれだけの期間残すか」を最初に決めます。例えば次のような考え方です。

10 秒ごとの生データ: 障害調査に使うので 14〜30 日
5 分ごとの平均: 傾向を見るので 1 年
1 日ごとの集計: 長期の比較用に、必要な期間だけ

2.x では、バケットに保存期間を設定しておくと、期間を過ぎたデータが自動で削除されます。既存のバケットの期間も変更できます。

influx bucket list
influx bucket update --id <バケットID> --retention 14d

1.x では、データベースにリテンションポリシーを作ります。

CREATE RETENTION POLICY "two_weeks" ON "wp_metrics" DURATION 14d REPLICATION 1 DEFAULT

削除は一定の間隔でまとめて行われるため、期間を過ぎた直後に消えるとは限りません。また、期間を短くすると、すでに保存されている古いデータも削除対象になります。変更前に、必要なデータが残っているかとバックアップを確認します。

ダウンサンプリングで長期データを軽くする

生データを長く残すと容量も問い合わせ時間も増えるため、粗い粒度に集約したものを別のバケットに保存します。これをダウンサンプリングと呼びます。2.x ではタスクを使います。

option task = {name: "downsample_resp_time_5m", every: 1h}

from(bucket: "wp_metrics")
  |> range(start: -task.every)
  |> filter(fn: (r) => r._measurement == "nginx_requests" and r._field == "resp_time")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
  |> to(bucket: "wp_metrics_1y")

このタスクは 1 時間ごとに、直近 1 時間の応答時間を 5 分平均にまとめ、保存期間 1 年のバケット wp_metrics_1y に書き込みます。集約先のバケットは事前に作っておきます。平均をとると最大値の山が消えるため、障害の検知に使う値は max でも別に集約しておくと安心です。

1.x では継続クエリ（CREATE CONTINUOUS QUERY）、3 系では処理エンジンのプラグインなど、版ごとに仕組みが異なります。どの方法でも、集約の処理が止まっていないかを定期的に確認します。2.x なら influx task list と、タスクの実行履歴で失敗がないかを見ます。

不要なデータの削除とシリーズ数の確認

誤って書き込んだデータは、期間と条件を指定して削除できます（2.x の例）。

influx delete --bucket wp_metrics \
  --start 2026-10-01T00:00:00Z --stop 2026-10-02T00:00:00Z \
  --predicate '_measurement="nginx_requests" AND host="test01"'

削除は元に戻せないため、条件を --predicate で十分に絞り、先にバックアップを取ります。

シリーズ数が想定より増えていないかは、定期的に確認します。2.x では Flux の influxdb.cardinality()、1.x では SHOW SERIES CARDINALITY で調べられます。急に増えていたら、タグに ID や URL が入り込んでいないかを Telegraf の設定から見直します。

安全に運用するための設定

公開範囲: API のポート（1.x・2.x の既定は 8086）をインターネットに開けず、ファイアウォールで接続元を Grafana や Telegraf のサーバーに限定します。
トークン: 2.x と 3 系では、書き込み用・読み取り用に権限を絞ったトークンを用途ごとに発行します。管理者のトークンを Telegraf や Grafana に設定しないようにし、トークンは環境変数や設定ファイルで渡して Git に含めません。
バックアップ: 2.x では influx backup /backup/influxdb-20261018 で取得し、influx restore で戻せます（管理者権限のトークンが必要）。3 系は保存先（ローカルディスクやオブジェクトストレージ）ごとにバックアップの方法が異なるため、公式ドキュメントの手順に従います。いずれの場合も、別の環境に戻せることを一度試しておきます。

まとめ

版によって言語と管理方法が違う。1.x は InfluxQL、2.x は Flux とバケット、3 系は SQL
タグは絞り込み用の種類の限られた値だけにし、ID や URL はフィールドへ。シリーズ数が性能を左右する
書き込み時はタイムスタンプの精度を合わせる
保存期間を粒度ごとに決め、バケットやリテンションポリシーで自動削除する
長期データはダウンサンプリングして別のバケットに残し、集約処理の失敗を監視する
ポートを公開せず、権限を絞ったトークンを使い、バックアップの復元を試しておく