0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

LogStashの設定ファイルに関する所感

Posted at

初LogStashです。

設定ファイルを書いていたときに、様々なサンプルを試したり、他の人の環境にも配慮して書いたり、これをそのまま本番に持っていける形にしたい、と色々調べていて、いい感じに出来そうだったので所感をメモします。

複数の設定を扱いたい場合はmultiple pipelinesを使う

複数の設定ファイルを扱いたくなる場合があります。単純に2つの異なるファイルを扱いたいときですね。
しかしpath.dataが競合している状態では2つ以上を同時に動かせません。

logstash -f foo.cfg &
logstash -f bar.cfg # エラー

この対処法としては3つぐらいあるようです。

  • 1つの設定ファイルに条件分岐を書く
    • inputでtagsを与え、if文でtagsを見てfilterやoutputの処理を分ける
    • 影響なく設定を足していくのは大変
  • 起動時に--path.dataを与えて競合が起きないようにする
    • Javaプロセスが2つ動くのでちょっと重い
  • multiple pipelinesを使う
    • pipelines.ymlの管理が必要(でも他と比べればマシ)

おすすめはmultiple pipelinesです。未来永劫1つの設定ファイルしか扱わないと決まっている場合以外は、たとえ1つからでもmultiple pipelinesで始めておいたほうが良いと思います。扱う設定ファイルが増えて嫌かもしれませんが、後からmultiple pipelinesに切り替えるよりは良いです。

--path.settings DIRで設定ファイルの置き場所を変更する

logstashはデフォルトはインストール方法やインストール先に依存したファイル構成をしています。
https://www.elastic.co/guide/en/logstash/current/dir-layout.html

これは最初に動かしてみる分には楽ですが、複数人で開発したりインスタンスを複数立てたくなった場合にこの構成は障壁になると思っています。

ところで、コマンドで --path.settings DIR を与えると、logstash.ymlの配置場所をデフォルトから変えることができます。logstash.ymlは他のデータ(上記のpath.dataやログなど)の配置先を明示できます。これを利用します。

以下は/path/to/directoryを起点に考えた場合の設定例です。

/path/to/directory/config/logstash.yml
path.data: ./data
path.logs: ./logs
/path/to/directory/config/pipelines.yml
- pipeline.id: foo
  queue.type: persisted
  path.config: ./config/foo.cfg
/path/to/directory/config/foo.cfg
input {
  exec {
    command => "echo hello"
    interval => 5
  }
}

output {
  stdout { codec => rubydebug }
}

起動コマンドは以下のようにします。

cd /path/to/directory
logstash --path.settings "./config"

ポイントはファイルの配置と実行の時以外で/path/to/directoryが出てこないところです。

設定ファイル内で相対パスを指定すると、現在の作業ディレクトリを基準に解決してくれるようです。(設定ファイルからの相対パスでないところが若干わかりにくいですね)
ただ、配置場所を気にしなくてよくなるので、各開発者の環境でgit cloneしたらそのまま実行ということができるようになりますし、既にデフォルトで入っている設定を汚すこともありません。
また、こうするとLinux/Windows問わない設定にできるので、Windowsで開発してLinuxで運用するというケースがある場合はこの形にしておくと楽だと思います。

設定ファイル内での変数の利用

環境によって微妙に値が違うときがあります。つまり変数を使いたくなる場合があると思いますが、環境変数が扱えます。
また、デフォルト値が設定できるので、いつもは環境変数無しで開発したりして、本番環境では環境変数を設定しておくという形が取れます。

処理の共通化について

input/filter/outputの設定を共通化したいという場合は次が参考になるかもしれません。

ただ私はフィルター処理がglobの順序性に依存するのはあまり良くない気がしています。あと、行き過ぎた共通化にも思えます。
こういったETLなツールで変に共通化にこだわると、処理の順序性が追いにくくなりかえって読みにくくなる、他に影響がないか怖くなる、という経験をしています。(私の書き方がよくないだけかもしれません)

なので今のところ、多少冗長でも1パイプライン1ファイルで書いたほうがいい気がしています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?