InfluxDBの2.0を試してみる
InfluxDBの2.0、出てからまだ日が浅いってこともあるのか日本語の情報が少ないので導入方法を記録していく。
とはいえ、InfluxDB自体のこともよくわかってないので、まずは本家で色々情報収集から。
InfluxDBはInflux社のプロダクトでGo言語にて書かれている。
また、v1.0系列ではTICKスタックと呼ばれる構成で構築されることが多かったが、v2.0からはTI-ckとなりckが不要になってる模様。
この情報になかなかたどり着けず、v1.0の頃の情報を頼りに Chronegraf
と Kapacitor
もまとめて docker-compose
で構築しようとして結構回り道をしてしまった。
結果的にはそれらは不要で Telegraf
とInfluxDB
だけで事足りるようになってる。
もっと言うと、 InfluxDB
にもTelegraf
と同じような機能が備わっているのでそれすら不要だが、クライアント側では Telegraf
使ったほうが良さそう。
v2.0からは Chronograf
と Kapacitor
は不要だよっていう情報はなかなか探し出せなかったけど、公式Blogのこの部分が該当する感じかな。
Easy to deploy and secure by default
For anyone familiar with our existing open source offerings (lovingly referred to as the TICK Stack — short for Telegraf, InfluxDB, Chronograf, and Kapacitor), the first thing you might notice is that there’s only one binary to download and install.The new InfluxDB now contains everything you need in a time series data platform in a single binary. This simplifies the deployment and setup experience all while maintaining the power and flexibility of individual components.
A single binary means it’s also much easier to secure, and so we made InfluxDB secure by default. Every request to InfluxDB is accompanied by an authentication token that can be revoked, and the built in user interface is secured with a username and password.
With these changes, you never have to worry about accidentally exposing data stored in InfluxDB to the public internet.
Easy to deploy, simple to manage, secure by default. Developers expect these things from modern development platforms, and InfluxDB is no different.
DeepLでの自動翻訳
既存のオープンソース製品(TICK Stack - Telegraf、InfluxDB、Chronograf、Kapacitorの略)に慣れ親しんできた方にとって、最初に気づかれるのは、ダウンロードしてインストールするバイナリが1つしかないということでしょう。
新しいInfluxDBには、時系列データプラットフォームに必要なものがすべて1つのバイナリに含まれています。これにより、個々のコンポーネントのパワーと柔軟性を維持しながら、デプロイとセットアップを簡単に行うことができます。
単一のバイナリであるということは、安全性の確保も非常に容易であることを意味し、InfluxDBはデフォルトで安全性を確保しています。InfluxDBへのすべてのリクエストには、失効可能な認証トークンが添付され、内蔵されたユーザーインターフェースはユーザー名とパスワードで保護されます。
これらの変更により、InfluxDBに保存されているデータが誤って公衆インターネットに公開されることを心配する必要はありません。
導入が簡単、管理が簡単、デフォルトで安全。開発者はこれらのことを最新の開発プラットフォームに期待しており、InfluxDBも同様です。
まあ、この手のものはエコシステムが重要だし、おまけにまだ開発継続中のv1.0系列用となる Chronograf
も Kapacitor
も自社開発なので、なかなか対応は難しいんだろうね。
同一ソースからクロスコンパイルできるGo言語で書かれているというのはかなり重要で、バイナリ一つがあればいろいろな環境のメトリクスを取得することができる。
会社のサーバー関係は長らくSensu + Graphite + Grafanaな環境で監視しているが、LinuxはともかくWindowsマシンではありがたい。
環境はMacOS、とりあえずはDockerで起動させてみる。
↑を見るといろいろな起動方法があるけど、今から新規にV2.0を利用するなら以下の方法でOK。
docker run -d -p 8086:8086 \
-v $PWD/data:/var/lib/influxdb2 \
-v $PWD/config:/etc/influxdb2 \
-e DOCKER_INFLUXDB_INIT_MODE=setup \
-e DOCKER_INFLUXDB_INIT_USERNAME=user \
-e DOCKER_INFLUXDB_INIT_PASSWORD=pass \
-e DOCKER_INFLUXDB_INIT_ORG=org \
-e DOCKER_INFLUXDB_INIT_BUCKET=default \
--name influxdb
influxdb:2.0-alpine
DataとConfig保存領域は自動で作られ、そのData領域に default
なBucketが作られる。
ポート 8086
ではDashboardとAdminページが組み合わさったサービスが立ち上がり、 user
と pass
でログインできる。
このポート、Browserでアクセスするとサービス画面が開くが、Telegrafでアクセスするとデータの登録ができるようになってる。
GETとPOSTで分けてるんだと思うんだけど、複数のポートを開く必要がなくていい感じ。
DOCKER_INFLUXDB_INIT_MODE
が setup
となっているように、Data領域にデータ管理用のファイルが作成されているかチェックし初回起動時にだけセットアップモードで動くようになっている。
ちなみに、時系列データは独自開発DBへ保存されるようだが、メタデータはBoltで管理される模様。
話は前後するが、日本語でのInfluxDBの基本については以下のPDFが詳しい。
ただ、内容的にはv1.0時代の説明が主なので少し注意が必要。
また、その最後にある InfluxDB IOx
新コアエンジンを開発中
というところは注目しておきたい。
ちらっと調べたところ、日本語の情報は以下にみつけた。
v2.0で大きな変化があったうえ、コアエンジンもまた変わるのか?と思うと「まだv1.0を使ったほうがいいのかな?迷走してるのかな?」って感じもするけど、後方互換性は確保されそうなのでv2.0採用してみても大丈夫そう。
ところで、Rustは触ったこと無いんだけど、本体で採用しているGo言語ではなくRustを選ぶってのはやっぱりいろいろ理由があるのかな?
さて、InfluxDB
はDockerで起動できたので、次はデータを突っ込む側の Telegraf
の準備。
Telegraf is a plugin-driven server agent for collecting and sending metrics and events from databases, systems, and IoT sensors. Telegraf is written in Go and compiles into a single binary with no external dependencies, and requires a very minimal memory footprint.
With 200+ plugins already written by subject matter experts on the data in the community, it is easy to start collecting metrics from your end-points.
Telegrafは、データベースやシステム、IoTセンサーからメトリクスやイベントを収集・送信するためのプラグイン駆動型のサーバーエージェントです。TelegrafはGoで書かれており、外部依存関係のない単一のバイナリにコンパイルされ、必要とするメモリフットプリントは非常に小さいものとなっています。
コミュニティでデータに関する主題専門家によって書かれた200以上のプラグインがすでに用意されており、エンドポイントからのメトリクス収集を簡単に始めることができます。
Telegraf
もDockerで入れることもできるけど、いろいろインタラクティブに操作したいので今回はバイナリを利用する。とはいえ、Go言語なのでバイナリ一つなのでインストールも楽ちん。
とはいえ、Homebrewとか使うのがもっと楽ちん。
Telegraf
のインストールが済んだら、実際にMacOSのメトリクスを取得して InfluxDB
に突っ込んで見る。
適当なフォルダで
telegraf \
-sample-config \
--input-filter cpu:mem \
--output-filter influxdb_v2 > telegraf.conf
すると、 telegraf.conf
ファイルが出来上がる。
膨大な行な設定ファイルだが、とりあえずは書き換えるのは以下のところのみ。
## The URLs of the InfluxDB cluster nodes.
##
## Multiple URLs can be specified for a single cluster, only ONE of the
## urls will be written to each interval.
## ex: urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"]
urls = ["http://127.0.0.1:8086"]
## Token for authentication.
token = ""
## Organization is the name of the organization you wish to write to; must ex$
organization = ""
## Destination bucket to write into.
bucket = ""
同じマシンだったら urls
はそのまま、 organization
bucket
は先のInfluxDB起動時に設定した org
bucket
を指定する。
token
についてはWebブラウザで管理画面にログインして、 Data → Tokens
から確認できる。
設定ファイルの編集が完了したら、おもむろに以下のコマンドを実行させる。
telegraf --config telegraf.conf
そうすると、
2021-04-17T01:34:49Z I! Starting Telegraf 1.18.1
2021-04-17T01:34:49Z I! Loaded inputs: cpu mem
2021-04-17T01:34:49Z I! Loaded aggregators:
2021-04-17T01:34:49Z I! Loaded processors:
2021-04-17T01:34:49Z I! Loaded outputs: influxdb_v2
2021-04-17T01:34:49Z I! Tags enabled: host=xxx.local
2021-04-17T01:34:49Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"xxx", Flush Interval:10s
な感じで立ち上がり、10sec間隔でデータ取得して同じく10s間隔でデータ送信するよって情報が表示され、無事に起動できたことが確認できる。
また、無事にデータが記録できてるかは、管理画面から Explorer → FROM → default
と操作すると Filter
に cpu
mem
の行があるかで確認できる。
ここらへんの情報は以下にある公式ドキュメントだけで、ほぼ事足りる。
Influx社のプロダクトはドキュメントも豊富で、好印象。
ここで削除方法を確認しておく。
まずは起動している InfluxDB
と Telegraf
を停止させる。
先の方法で起動させた Telegraf
であれば Ctrl-C
で、Dcokerで起動させた InfluxDB
は docker stop influxdb
で停止。
作られたデータの階層はこんな感じ↓
ディレクトリツリー
tree ./data
.
├── engine
│ ├── data
│ │ └── c0586745311d1efd
│ │ ├── _series
│ │ │ ├── 00
│ │ │ │ └── 0000
│ │ │ ├── 01
│ │ │ │ └── 0000
│ │ │ ├── 02
│ │ │ │ └── 0000
│ │ │ ├── 03
│ │ │ │ └── 0000
│ │ │ ├── 04
│ │ │ │ └── 0000
│ │ │ ├── 05
│ │ │ │ └── 0000
│ │ │ ├── 06
│ │ │ │ └── 0000
│ │ │ └── 07
│ │ │ └── 0000
│ │ └── autogen
│ │ └── 1
│ │ ├── fields.idx
│ │ └── index
│ │ ├── 0
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ ├── 1
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ ├── 2
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ ├── 3
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ ├── 4
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ ├── 5
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ ├── 6
│ │ │ ├── L0-00000001.tsl
│ │ │ └── MANIFEST
│ │ └── 7
│ │ ├── L0-00000001.tsl
│ │ └── MANIFEST
│ └── wal
│ └── c0586745311d1efd
│ └── autogen
│ └── 1
│ └── _00001.wal
└── influxd.bolt
ざっくり、メタデータは influxd.bolt
で管理されてて、実データは engine
の下に、WALデータは wal
の下に作られるっぽい。
(engine/data
以下でBucket別?に管理され、 _series
にFieldデータが入って autogetn
にはTabデータが入る感じなのかな?)
なので、新しく作り直したいということだったら data
と config
を削除すれば良い感じ。
(新しく作り直すとTokenが変わってしまうので注意が必要)
で、任意のBucketだけを削除するときは?というと、管理画面から Data → Buckets
と進み削除したいBucketにカーソルを合わせると Delete Bucket
というボタンが出てくるのでそれをクリック。
(新しく作る場合は同じ画面の Create Bucket
が利用できる)
次はCSVデータをインポートしたい。
CSVファイルインポート方法その1. telegraf
コマンド
クライアントからCSVデータを送り込みたいときや、Import前に値の調整を行いたいときに使う感じかな。
CSVファイルインポート方法その2. Inflex
コマンド
InfluxDBサーバーでCLIツールが使えるとき。Docker経由の起動だと結構難しいかも。
CSVファイルインポート方法その3. 管理画面からインポート
FLUX言語を使ってCSVファイルをインポートできる。インポートしながらデータをグラフ化するときに便利そう。
ちなみに、FLUX言語はまだ殆ど触ってないが、SQLとの比較は以下のページが詳しい。
CSVファイルインポート方法その4. HTTP API 経由でインポート
大量データのインポートについては以下のようなページも見つかる。
You mention this is already prepared in line protocol format, correct?
It would probably be easier to write some bash script to chunk the file and send it over the HTTP API.
Telegraf probably isn’t the best tool for one off large imports, due to the way to consumes / reads the file (I’ll need to double check the code).
DeepLによる自動翻訳
これはすでにラインプロトコル形式で準備されているとのことですが、そうですか?
おそらく、ファイルをチャンクしてHTTP APIで送信するbashスクリプトを書く方が簡単だと思います。
Telegrafは、ファイルの消費/読み取り方法のために、1回限りの大規模なインポートには最適なツールではないでしょう(コードを再確認する必要があります)。
CSVファイルインポート方法の使い分けとしては、
- それほど大きくないCSVファイルをクライアントから定期的に送り込むとき
- 何らかの方法でサーバー側にCSVファイルをコピーできるとき
- インタラクティブにCSVファイルを分析したいとき
- 他システムから履歴などの大量データを送り込みたいとき
となるのかな?