ほほほのほ - serverapp:logging

Fluentd

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Dec 2020 08:19:37 +0000

Fluentd

logの収集を行う手法には様々あるが、UNIX系OSでは、標準的にはsyslogを利用することが多いと思われる。

しかし、syslogdでは、logの正規化などの処理をうまく行うには大幅な仕掛けが必要なため、今更ながら fluentd を利用することにした。

What is fluentd

fluentdはrubyで動作するlog収集・管理ツールである。その特徴を以下に挙げる。

さまざまなソースからのイベントをさまざまな媒体に出力できる
ログの種類はタグで管理される
ログの内容はJSON形式

これにより、データのDBへの入出力や検索などを楽にすることができる。

本記事で想定する fluentd 利用方法

今回は、以下のような形式でfluentdを利用する。

各サービスサーバーからlogging system(以下log server)へは、syslogを利用してlogを転送する
log serverでは、fluentdがsyslog portを利用してlogを待ち受ける
fluentdは、受診したlogを/zdata/fluentdにfileとして書き出す
- 将来は、PostgreSQL等に書き出すことも考慮するが、今はfileに書き出す。
Service Serverには、原則として追加となるdaemonやProgram/Scriptは設置しない
log serverは二重化するが、同期はしない。二重化は、syslog側で、複数台にlogを飛ばすことで行う

Install fluentd on FreeBSD

fluentdを(例によって) FreeBSD で作成したVMにInstallしてみる。

OSの準備

VMの諸元は以下の通り

CPU	vCPU x2
Memory	2G
Disk 0	20G	Boot disk
Disk 1	100G	Data Disk
NIC 0		Management I/F
NIC 1		Logging I/F
OS	FreeBSD	11.2-p4 (2018/10/15)

通常通り、minimum installを行う

fluentdは、大量のFileを扱うことがあるので、limitによる制限を外す必要がある。

/etc/sysctl.conf にkern.maxfiles=65536及びkern.maxfilesperproc=65536を追加する

Disk1(/dev/ada1) をZFSにして、/zdataとしてmountする。

gpart show
- ここで、ada1が表示された場合、何らかのformatがなされていることになるので、確認する。
- ada1を完全に消去する前提なら、gpart destroy -F /dev/ada1を実行
gpart create -s gpt /dev/ada1
- これで、ada1にGPT Partitionを作成する
gpart add -t freebsd-zfs -l log-data /dev/ada1
- -t で partition type を、-lで label を指定する
zpool create -O atime=off -O compression=lz4 -O normalization=formD zdata disk /dev/ada1
- ZFS poolを作成し。/zdataとしてmountする。
- ここでは、macOSに合わせて normalization form を form-D にし、 lz4 で圧縮するようにしている
必要に応じて、/etc/rc.confに、zfs_enable=“YES”とzfsd_enable=“YES”を追加する

基盤の準備

FluentdはRubyを利用する。Rubyの環境は、(個人的に)保守がとても面倒なので、RubyEnvを利用することにする

rbenvのInstall

rbenvを導入するためにgitとbashが必要
- あんまり余計なものは入れたくないのだが…仕方がないか。
- pkg install git bash
- FreeBSDの標準のUIDを設定する
  - vipw で、fluentd:*:963:963::0:0:fluentd user:/nonexistent:/usr/sbin/nologinを追加
  - vi /etc/group を実行し fluentd:*:963:を追加

githubからrbenvを引っ張ってくる

# cd /usr/local
# git clone git://github.com/sstephenson/rbenv.git
# mkdir /usr/local/rbenv/plugins
# cd /usr/local/rbenv/plugins
# git clone git://github.com/sstephenson/ruby-build.git

個人の.profile等に以下を追加

# for rbenv...
export RBENV_ROOT="/usr/local/rbenv"
export PATH="${RBENV_ROOT}/bin:${PATH}"
eval "$(rbenv init -)"

もちろん、以下の作業前に source しておくこと

RubyのInstall
1. まず、InstallできるRubyのVersionを確認する
  - rbenv install –list
2. RubyをInstallする
  - sudo rbenv install 2.5.1
  - sudo rbenv rehash
3. System WideにDefaultを設定する
  - sudo rbenv global 2.5.1
4. 実行されるrubyのVersionを確認する
  - ruby -v

これで、FreeBSD上に rbenv+ruby 2.5.1を実行できる環境が完成する。 ただし、ruby関連の実行バイナリーは/usr/local/rbenv/bin配下にあるので注意

fluentdの準備

fluentdのInstallに関する情報はここを参照

```
gem install fluentd -N
```

これだけで、fluentdはinstallされる。

fluentdで収集したlog dataは、/zdata/fluentd配下に蓄積する。

# cd /zdata
# mkdir fluentd
# cd fluentd
# fluentd --setup ./fluent
# fluentd -c ./fluent/fluent.conf -vv &

これで、fluentdにメッセージが送れるようになったので、fluentdを停止する

pkill -f fluentd

動作確認が取れたところで、一度cleaningする

rm -rf /zdata/fluentd && mkdir /zdata/fluentd && chown fluentd:fluentd /zdata/fluentd && chmod 755 /zdata/fluentd

起動script

FreeBSDのPORTSから拝借した。/usr/local/etc/rc.dに配置する

/usr/local/etc/rc.d/fluentd

fluentd

#!/bin/sh
 
# $FreeBSD: head/sysutils/rubygem-fluentd/files/fluentd.in 366153 2014-08-25 21:16:56Z swills $
#
# PROVIDE: fluentd
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# fluentd_enable (bool):        Set to NO by default.
#                               Set it to YES to enable fluentd.
# fluentd_config (path):        Set to %%PREFIX%%/etc/fluentd/fluent.conf
#                               by default.
# fluentd_flags (str):          Set to "" by default.
 
. /etc/rc.subr
 
name=fluentd
rcvar=fluentd_enable
extra_commands="init"
 
load_rc_config $name
 
: ${fluentd_enable:="NO"}
: ${fluentd_config="%%PREFIX%%/etc/fluentd/fluent.conf"}
: ${fluentd_dir="%%PREFIX%%/etc/fluentd"}
: ${fluentd_user="%%USER%%"}
: ${fluentd_group="%%GROUP%%"}
: ${fluentd_flags:=""}
 
PATH="${PATH}:/usr/local/bin"
# for rbenv...
export RBENV_ROOT="/usr/local/rbenv"
export PATH="${RBENV_ROOT}/bin:${PATH}"
eval "$(rbenv init -)"
 
start_precmd="fluentd_start_precmd"
 
command=/usr/local/rbenv/shims/${name}
pidfile=/var/run/${name}/${name}.pid
#command_interpreter="/usr/local/rbenv/shims/ruby"
stop_cmd='pkill -f fluentd'
 
command_args="-d $pidfile -c $fluentd_config"
 
fluentd_start_precmd()
{
    install -d -o ${fluentd_user} -g ${fluentd_group} -m 775 ${fluentd_dir}
    install -d -o ${fluentd_user} -g ${fluentd_group} -m 775 /var/run/fluentd
}
 
run_rc_command "$1"

/etc/rc.conf.localに以下を追記する

fluentd_enable="YES"
fluentd_config="/zdata/fluentd/fluent.conf"
fluentd_dir="/zdata/fluentd"
fluentd_user="fluentd"
fluentd_group="fluentd"
fluentd_flags=""

fluentdの設定と試験

設定の細かい部分はここを参照

fluentdでsyslogを受ける

Fluentdは syslog/UDP に来たsyslogメッセージを受け付けることができる。

<source>
  type syslog
  format none
  port 514
  bind 0.0.0.0
  tag syslog
</source>

受け取ったメッセージをファイルに書き出す

ここでは、上記syslogで受け取った “syslog” tagのついたメッセージを、/zdata/fluentd/syslog下に書き出す。

Syslogの場合、メッセージの構成が “Tag.facility.level“となっているので、match構文もそれに合わせる必要がある。

<match syslog.*.*>
  @type       file
  buffer_type file
  path        /zdata/fluentd/syslog
</match>

実際にsyslogを送信してみる

fluentdを起動する
- service fluentd start
- psコマンドでfluentdが起動されていることを確認する
- service fluentd stop
- psコマンドでfluentdが終了していることを確認する
- 再度fluentdを起動する
localhostからloggerコマンドでlogを送付
- logger -h 127.0.0.1 “Syslog message test from local
- このメッセージが設定に記載されているlogファイルに記載されればOK
remoteからloggerコマンドでlogを送付
- logger -h logger-host “Syslog message test from local
- このメッセージが設定に記載されているlogファイルに記載されればOK

落穂拾い

fluentdのDocumentation

plugin 全般

Fluentdは大量のpluginを持っている。pluginを管理するには、fluent-gemを利用する。

fluent-plugin-grepを導入
- fluent-gem install fluent-plugin-grep

syslog plugin

Fluentdのsyslog pluginは、標準で2048 byteまでしかメッセージを受け付けない。これを拡張するには、fluent.confのsyslog設定の中で、message_length_limit 8192などとする。

<source>
  @type               syslog
  #....
  message_length_limit 8192
</source>

syslog pluginは、標準では、送信元の情報を出力しない。これを出力するには include_source_host trueをsourceセクションに追記する

Update fluentd on FreeBSD

fluentdの更新

FluentdのUpdateは、gemを更新するだけで良い。

gem outdated : 更新が必要なgemを探す
gem update / gem update [gem name] : gemを更新する

つまり、gem outdatedしてgem update すればOK

RubyのVersion up

本環境の場合、ruby自体の更新を行う場合、以下の作業が必要になる。

# cd /usr/local/rbenv
# git pull
# cd /usr/local/rbenv/plugins/ruby-build
# git pull
# rbenv install [target version]
# rbenv rehash
# rbenv global [target version]

これで、Ruby自体のVersionが上がる。しかし。この状態では、ruby環境全てを更新してしまったので、当然fluentdは起動できなくなる。そこで、以下の作業を実行し、fluentdをinstallする

# gem install fluentd -N

これで、service fluentd stop; service fluentd start を実行すれば、fluentdが更新されるはず。

syslog Server

anonymous@undisclosed.example.com (Anonymous) — Fri, 19 Oct 2018 09:24:19 +0000

syslog Server

Last modified: 2014/06/05

syslogについて。

syslogは、相当初期の頃から存在するLog収集用Daemonであって、その設定方法等は様々な場所に大量に記述されている。ここでまとめなおしても意味が無いかもしれないが、久しぶりすぎてハマってしまったので、自分の理解の範囲でまとめておくことにする。

前提: NetBSD 6のsyslogd

syslogは非常に昔から実装されている為、様々なVariantがある。また、syslog-ng等の実装もある。
本稿では、NetBSDのDistributionに入っているsyslogd用のsyslog.confを解説する物とする
でも全部はかけないよ

参考:

syslog.confの設定

syslog は、Daemon やその他の一般アプリケーションの状態や問題などの記録を残すための仕掛けである。この syslog を受け取り記録する為の Daemon が syslogd である。 syslogd の設定ファイルが syslog.conf であり、多くの Unix 系システムでは /etc/ 配下に設置されていることが多い。

syslog.conf には、「logの分類(Selector)」と「syslogメッセージの送付先(Action)」を記載する必要がある。従って、syslog.confは以下の形式になる。

1: Facility.Level	(Tab)	送付先	: 基本形
2: fac.lv;fac.lv	(Tab)	送付先	: 複数のSelectorからのメッセージを、送付先に一括で送る
3: Facility		(Tab)	送付先	: Levelを省略
4: fac,fac		(Tab)	送付先	: Levelを省略した複数のSelectorからのメッセージを、送付先に一括で送る

上表に示したように、Selectorは

Selector は Facility.Level の形式をしている
Selector は “;” で区切ることで複数記載できる
Selector が Facility のみで構成される場合、“,”で区切ることで複数を連結して記載できる

という構造になっている。そのFacilityとLevelの内容を下表に記載する。

Facility	主な用途
auth	認証システムからのlog。login(1), su(1), getty(8) など
authpriv	authと同様。システムによって流儀が異なる。初期設定ではauthと差がない
cron	cron(8) 用
daemon	システムのdaemon用。routed(8)など。このFacilityは、様々なdaemonが利用する
ftp	ftpd(8) 用
kern	kernel用。userland processからのメッセージは含めない
lpr	プリンター用(本来はLine Printer Daemon用)。lpr(1), lpc(8), lpd(8) など
mail	メール用
news	NetNews用。現在では、利用されることは稀
syslog	syslogd(8) 用
user	様々なユーザープロセスからのメッセージ用。Facilityを指定しない場合のdefault
uucp	uucp用。現在では、利用されることはまずない
local[0-7]	自由に利用できるFacility。local0〜local7まである
*	全てのFacilityを意味する

Level	意味
emerg	Panicの状態。システム全域に影響があると考えられる場合に利用される
alert	即時対応すべき状態。SystemのDBが壊れた場合等に利用される
crit	致命的な状態。HDDの故障等の場合に利用される
err	エラー。アプリケーション停止等の際に原因等を出力するのに利用される
warning	警告。
notice	通知。エラー等の状況ではないが、何らかの対処が望ましい場合に利用される
info	情報。何らかの情報を記録しておく為等に利用される
debug	デバッグ。いわゆるデバッグの為に必要な詳細情報等を出力する為に利用される
none	このLevelが指定された場合、指定されたFacilityは全て除かれる。
*	このLevelが指定された場合、none以外の全てのLevelのメッセージを対象とする

FacilityのauthとauthprivはNetBSDのDefault設定では差がない。もし分けるなら、Console系のlogin/su/getty等をauthに、Network系のssh等をauthprivにするのも一案である。

Actionには、syslogメッセージの送付先を記述する。送付先には

log file
他のsyslog server
何らかのprogram

を記載できる。

Selectorの記述において、Levelを指定した場合、指定したレベルを含む、それよりも重要度の高いメッセージは全て含まれる。
例として、Selectorに“mail.err”を指定した場合、syslogdがActionに送るのは、“mail.err”だけではなく、“mail.crit”, “mail.alert”, “mail.emerge”のメッセージになる。
もし、指定したLevelのみを記録するのであれば、Levelに“=“を付記する。つまり、前の例で言えば、”mail.=err”と指定した場合、“mail.err”のメッセージのみ送付先に送られる。
もし、指定したLevelのみを記録しないのであれば、Levelに“!=“を付記する。つまり、前の例で言えば、”mail.!=err”と指定した場合、“mail.err”のメッセージ以外が送付先に送られる。

Level指定	意味	例	例の意味
Level	Level 以上	mail.err	mail の err 以上を記録する
=Level	Level だけ	mail.=debug	mail の debug だけを記録する
!=Level	Level 以外	mail.!=emerg	mail 全てのうち emerg 以外を記録する
.none	この Facility は全て除く	mail.none	mail.* は除く
.*	この Facility の全て	mail.*	mail Facilityに所属する全てを記録する

ここまでを理解すれば、System付属のsyslog.confは読めるようになる。

拡張

Security保護の観点やlog分析の観点から、logはどこかにまとまっていることが望ましい場合が多い。
例えば、Security保護を考えた場合、あるServer等が乗っ取られた場合に、侵入者は乗っ取りの痕跡を消す行為を行う場合がある。侵入者は、まずlogの改竄を視野に入れる。このとき、logが別マシンにあれば、書き換えることは当然困難になる。 Log分析を考えると、大量のアクセスがある複数のWeb Serverが存在する場合にlogの分析を個別に実施していたのでは、様々な解析を行う際に不便になる。

このような場合に、logを一カ所にまとめてしまえば、log改竄の可能性が減らせ、分析も(少しは)簡単になる。 syslogは、このような局面において、外部のsyslogホストに対してlogを送付することが可能である。

syslogにおけるFacilityは有限であり、これを拡張することは難しい。その状況において、非常に大量のlogを出力するプログラムと、あまりlogを出力しないプログラムが同じFacilityを利用している場合に、かつ、それぞれのプログラムで定義されているFacilityを(設定等で)変更することが困難な場合の為に、送付元のprogramやhostを選別してActionを変えることが可能になっている。

Selector側でのlogの分離(program編)

例えば、snmpdやroutedはlogのFacilityとしてdaemon.*を利用する。仮にsyslog.confで以下のように設定してあるとすると、routedのlogとsnmpdのlogが混ざってしまう。

daemon.*	/var/log/daemon.log

しかし、snmpdとroutedでは、log分析の意味が異なる。こういう場合に、daemon毎にlogを分離したい場合がある。

logの分離の為には、以下のように記述する

!-snmpd,routed				←snmpdとroutedを除外
daemon.*	/var/log/daemon.log

!snmpd					←snmpdのlogのみを扱う
daemon.*	/var/log/snmpd.log

!routed,gated				←routedとgatedのlogのみを扱う
daemon.*	/var/log/routing.log

Selector側でのlogの分離(host編)

別のホストから送られてくるlogを分離したい場合には、以下のように記載する。

自分自身のlogを/var/log/localhost以下に記録
web1から送られてきたlogを/var/log/web1以下に記録
dialerから送られてきたpppのlogを/var/log/dialer以下に記録

する例を記載する

+@					# ←localhostからのlogを記載するセクション
*.err;kern.*;auth.notice;authpriv.none;mail.crit        /dev/console
*.info;auth,authpriv,cron,ftp,kern,lpr,mail.none        /var/log/messages
kern.debug                                              /var/log/messages
auth,authpriv.info                                      /var/log/authlog
cron.info                                               /var/log/cron
ftp.info                                                /var/log/xferlog
lpr.info                                                /var/log/lpd-errs
mail.info                                               /var/log/maillog
#uucp.info                                              /var/spool/uucp/ERRORS

!*					# ←全てのsyslog通信を受け取る

+web1					# ←web1からのlog
*.err;kern.*;auth.notice;authpriv.none;mail.crit        /var/log/web1/console
*.info;auth,authpriv,cron,ftp,kern,lpr,mail.none        /var/log/web1/messages
kern.debug                                              /var/log/web1/messages
auth,authpriv.info                                      /var/log/web1/authlog
cron.info                                               /var/log/web1/cron
ftp.info                                                /var/log/web1/xferlog
lpr.info                                                /var/log/web1/lpd-errs
mail.info                                               /var/log/web1/maillog
*.*							/var/log/web1/other.log

!pppd					# ←pppdからのlog
+dialer					# ←dialerからのlog
*.*							/var/log/dialer/pppd.log

なお、ここでホスト名(web1,web2等)を記載しているが、ホスト名の代わりにIP Addressでも構わない。ホスト名を利用する場合は、DNSを使わず、/etc/hostsに記載しておくことを推奨する。これは、DNS Serverを用いた名前解決が失敗した場合に、logがなくなるからである。

Selector側での分離の文法

上記分離の記法は、以下のルールに従う。

Stringで指定されたホスト名、Program名、もしくは文字列に一致する情報のみを、Selector Actionの集合に適用する。
- ```
#!+String1,String2
!+String1,String2
#+String1,String2
#!String1,String2
!String1,String2
```

Stringで指定されたホスト名、Program名、もしくは文字列に一致しない情報のみを、Selector Actionの集合に適用する。
- ```
#!-prog1,prog2
!-prog1,prog2
#-prog1,prog2
```

全てのプログラム、ホスト、文字列を取り扱う
- ```
!*
```

なお、ホスト名に“@“を指定した場合、localhostの意味になる。

記号等について以下にまとめる。

文字	意味
(TAB)	「Selector」と「Action」の区切
;	「Selector」をつなぐ
=	「Level」を限定する
!=	それ以外の「Level」
@	自機
+	ホスト名、プログラム名の指定したものを加える
-	ホスト名、プログラム名で指定したものを除外する
!	プログラム名、ホスト名、文字列の指定
#	通常は注釈。!や+,-と組み合わせた場合、ホスト名・プログラム名、文字列の指定に使う
,	Facilityをつなぐ
*	全て。何でも
.	「Facility.Level」のように「Facility」と「Level」をつないで、「Selector」を作る
none	除外

Actionへの記述

Actionには、Logを出力する先のファイル名、Logを送りつけるホスト名、Log処理を実行するプログラム、loginしているユーザー等を記載できる。

以下、Actionの例

1. ファイルに出力する場合
cron.info	/var/log/cron					→送られてきたメッセージを/var/log/cronに追記する
2. 他のホストに転送する場合
cron.info	@loghost					→送られてきたメッセージをloghostに対して送る
3. 他のホストに転送する場合(TLSを使う場合。試験していないので間違いがあるかも)
cron.info	@[loghost]:1234(fingerprint="SHA1:01:02:...")	→loghostの1234番ポートにTLSでメッセージを送る。
								　fingerprint以下は認証に利用する
4. プログラムを利用してlogを加工する
cron.info	|exec /usr/local/sbin/cronfilter		→送られてきたメッセージを/usr/local/sbin/cronfilterで処理する
5. loginしているrootとuser1に対して送る
cron.info	root,user1
6. loginしている全ユーザーに対して送る
cron.info	*
7. システムのコンソールに出力する
cron.info	/dev/console

注意点

syslogdは、出力先のファイルを自身で作成しない。そのため、touch /var/log/daemon.log等を実行して、事前に出力先ファイルを作成する必要がある。
syslogdに設定ファイルを再度読み込ませるには、HUPシグナルを送る。つまり、kill -HUP [syslogdのPID]を実行すれば良い
syslog.confをdebugしたい場合には、syslogdに-d -vをつけて起動すれば良い

現時点では、wtmp/wtmpx/lastlog/lastlogx をremoteに転送する方法が不明。
- これらは、BinaryのDatabase Fileで、login(1)等が直接記録する。そのため、syslogの仕組みを利用していない。
- 現在は、pam_lastlogがこの辺を制御しているのだが、pamを利用してremoteにlogを飛ばすことは(今のところ)やり方が解らない(or できない)
同様に accounting (accton(8))の機能が出すlogもremoteに飛ばす方法が不明。
syslogではなく、rwhodやewhodを使って擬似的に収集する方策があることが判明。これはこれから調査

logのrotate

syslogは、自身では、logメッセージを「追記するだけ」なので、放っておくとlogファイルが巨大になる。これでは困るので、logをrotateするべきである。

logをrotateさせるのがnewsyslogで、その設定ファイルが/etc/newsyslog.confである。

こちらは、それほど難しくないので、詳細はman newsyslog.confを参照のこと。