Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例

Fluentdを
優しく見守る監視事例
2012/08/22
Fluentd Meetup #2

外道父@GedowFather
Copyright © DRECOM Co., Ltd All Rights Reserved. 1

自己紹介


自己紹介

■私は
外道父@GedowFather
■所属
ドリコム
■職種
インフラエンジニア
■ブログ
http://blog.father.gedow.net/
Copyright © DRECOM Co., Ltd All Rights Reserved.
3

目次

 動作環境
 ローカル監視
 リモート監視
・・・の３本くらいです
5

動作環境


IDC (2) IDC (3)
Agent

Agent
Agent
Agent

GLOBAL
 圧縮
 暗号化
☓ VPN
IDC (1)

Agent Collector HDFS

Agent

7

プラグイン

Agent 大事なログ flowcount log

 path に *
tail (改)  tag に basename
copy

forward (改) flowcounter
 圧縮／暗号化
flowcount log
Collector  復号化／解凍
 特定hostnameのtag改変（*test*）
forward (改)

copy
forest flowcounter
HDFS webhdfs
 path /logs/__TAG__/%Y%m%d-%H%M___HOSTNAME__.log

8

Fluentd

VS

Flume
OG
9

Flume OG
十分な
機能信頼の
（暗号化以外）
CDH付属

Javaだから
うんぬん
1

Flume OG 不安定
数百台規模で
MASTERが不安定
メモリ不足

Agentのキュー
からの再送が不安定
（タンス貯金現象）

不
安配送途中に余計な改行が
入ったり復号化にたまに

定失敗するもJavaは難しい
1

VS

Fluentd
一択
12

td-agent にした
方針としてパッケージ管理は大事
社内にRubyエンジニアだらけ
機能不足はプラグインでなんとかなる？

全機能を満たせた
インストール簡単で周知しやすい
少し頑張ったら満足いく安定度になった
13

ローカル監視


ローカル監視が必要な理由

プライベート
アラートメール
ネットワーク
グラフ作成でやる

ローカルで
プロセス操作
やるべき

15

管理制限 IDC (3)
Agent

Agent

サーバが社外管理の場合
 サーバ調査
 頻繁な設定変更
 プライベートネットワーク経由監視


ログ配送の注意点
ログを記録しているか
Agent
ログの内容が正しいか → ジョブで

td-agentが正しく起動しているか
Collectorに送っているか

Collector

td-agentが正しく起動しているか
HDFSに送っているか

HDFS HDFSに記録されているか → ジョブで

17

ローカル監視に monit 使ってます

プロセスの監視やリソース監視
HTTPリクエストのステータス条件
スクリプト実行の返り値条件 ※
 条件判定によるアクション実行
 起動スクリプト実行
 スクリプト実行
 アラートメール ※check program >= v5.3

18

monit でやってる監視内容

① td-agent 基本プロセス監視

② td-agent 重複デーモン対策

③ flowcounterで転送状態監視

19

monit (1) td-agent 基本プロセス監視
Memo
 常に起動している必要があり、主に人災対策

Check point
 Agentは check process によるチェック
（run/pidファイルのIDとプロセスの存在）
 Collectorはさらに LISTEN 24224

if failed
 /etc/init.d/td-agent restart

20

monit (2) td-agent 重複デーモン対策

Memo (1)

 fluentd は UDP/TCP の2プロセスで成る
 プロセスの過不足は異常とみなす
 １プロセスしかない
 ３プロセス以上ある
 run/pid のプロセス番号で動いていない

21

Check point
 プロセスの表示
ps w -C ruby -C td-agent --no-heading | ¥ ①
grep td-agent | ¥ ②
grep -v "¥]$“ ③
 プロセス数のカウントが２

Memo (2)
① プロセス名は td-agent v1.1.8 (fluentd v0.10.25)
から ruby でそれ以前は td-agent
② unicornなど他のrubyプロセスを除外
③ 瞬間的に出現する特権モード [td-agent] を除外

22

if failed
 /etc/init.d/td-agent stop ①
 pkill -KILL -f td-agent ②
 /etc/init.d/td-agent start

Memo (3)
① 可能な限り正常終了し
② 残りは名前を含むプロセスを強制終了

23


Memo (4)
 v1.1.7 までの td-agentの起動スクリプトに
はバグがあり、td-agent.conf の内容により
 start を実行した数だけデーモンが起動
 ファイルのIDが誤った値に変わる

 v1.1.8 で修復されたが、どのようなログ配送
システムにおいてもデーモンの正常性は確認す
べきである・・・でないと・・・
24

@mazgi事件

※@mazgi = プラグイン製作者
25

@mazgi事件～開発～
@mazgi
は、はぁ・・・
頑張ります

flumeアカンな～
fluentdの時代や
プラグインいるな
@mazgi先生の
こんな感じで出番やで
よろしく～

@GedowFather @matsuou1
26

@mazgi事件～導入～
@mazgi

できました！ pull request
送っちゃうぞ～

えぇ感じやん
さすが
１アプリに
@mazgi先生や
入れてみるわ

いいね、やるやん HDFSに
@mazgi 先生！きたきた

27

@mazgi事件～確認～
@mazgi
は、はぁ・・・
頑張ります
（マジわかんねぇ）
あれ？
ログ多くね？
Agent分より
18/16 倍くらい HDFSが多いね
に増えてる？

明日までに水増し
直しておいてね！プラグインや
28

@mazgi事件～次の日～
WEBサーバは
16台か・・・ @GedowFather 全台のプロセス
チェックしてみるか

ん？4プロセスの
サーバが2台ある！？ 2台で重複・・・
18 / 16 倍・・・

とりあえずプロセスを
正常化してみよう！
タ、ターンッ!!
29

@mazgi事件～解決～
@mazgi
そ、それはよかった

（マジこいつら・・・）

直ったっぽ！

行数一致した！
プラグイン万歳！
さすがの
@mazgi先生や
公開しようぜ

30

@mazgi事件
濡れ衣
完
31

monit (3) flowcounterで転送状態監視
目的
 アプリがログを記録している証明
 Fluentdがログを拾って配送している証明

☓ 部分的な記録ミスや極端な増減は無視
（アプリの事情は把握しきれない）
☓ やりすぎチェックはアラートが増えて
重要なアラートが埋もれる

32

<match **.log> Memo (1)
type copy
<store>  １時間に１回記録する
type forward
...snip...  １月１ファイルで十分
</store>

<store>
type flowcounter
count_keys *
unit hour
aggregate all
</store>
</match>

<match flowcount>
type file
path /var/log/td-agent/flowcount/flowcount.log
time_slice_format %Y%m
</match> Copyright © DRECOM Co., Ltd All Rights Reserved.
33


ｆlowcountログ
2012-08-06T20:44:21+09:00 flowcount
{"count":1302372,"bytes":474494367,"count_rate":361.77,"bytes_rate":131803.99}

2012-08-06T21:44:21+09:00 flowcount

2012-08-06T22:44:21+09:00 flowcount

 最新２時間分のカウントを利用する
34

Check point
 ２時間分のログに
 １つでも10以上のカウントがあればOK

 0だけじゃなく1～9 も無効値とした
 数時間に１度しかログが来ない場合、
ALERTとRECOVERYが繰り返され鬱陶い
 ２時間以上のメンテナンスや障害だとアラート
になるがそれはご愛嬌

35

if failed
 スクリプト内で原因をエラー出力 1>&2
 返り値を 1 にしてmonit に知らせる
 monitがアラートメール（エラー出力記載）

問題点
 copy なので forward に失敗しても
flowcounterのカウント記録は成功する
 Collectorが全部落ちたり、HDFSが落ちたら
flowcounterどころではないので問題ない！
36

ローカル監視まとめ

1. td-agent の強制起動
2. td-agent プロセスの正常性確認と自動
修正
3. ログ配送の正常性確認

• Fluentd＋monit だけで結構十分
• 足りなすぎず、やりすぎず適度な監視

37

リモート監視


リモート監視の目的

目的

 アラート／グラフ作成の集約
 状態の可視化
 特にCollectorのキャパシティ管理
 Agentにキャパシティの心配はほぼないが、
Collectorは増設対応が必要

39

アラートは Nagios＋nagios-nrpe-server

Agent monit
nrpe flowcounter.sh

Nagios

Collector monit
nrpe flowcounter.sh

 monit で実行しているスクリプトを nagios-
nrpe-server を通してNagiosに実行させる
 Collectorは必須、Agentも可能ならやる
40

グラフは Cacti とか＋snmpd

Agent
snmpd
Cacti

Collector
snmpd

 Collectorは必須、Agentは既に入ってるべ
 CPUとTrafficは最低限必要
 特殊なグラフは作っていない
41

Collectorの実際のグラフを紹介

Collectorの仕事 flowcounterより

 in_forward
 復号化  1行平均350byte
 解凍  毎秒500行
 flowcounter
 webhdfs

42

圧縮で受け取って平文でHDFSへ
Agent
flush / 10s
←0.7 Mbps
圧縮／暗号化
状態でINPUT

Collector

平文でHDFSへ
OUTPUT
←1.5 Mbps

HDFS
うわっ…この圧縮率、低すぎ・・・？
43

CPU利用率のキャパシティ

 in_forward
CPU 25%
 復号化
 解凍
 flowcounter
 webhdfs

・350 bytes / row
・500 rows / sec

 fluentdは 1vCPU 100% が限界
 最大であと4倍まで可能
 とすると 2000 rows / sec が１台の限界？

44

何が最もCPU利用率に影響するのか

波の形状が・・・？
CPUとトラフィックの
波の形状が一致しない！

まさかの・・・？
CPU利用率はログ量の
影響が低い！？

何が影響する？
Agentの数？
フラッシュ数？

45

こんなこといいな
できたらいいな


CollectorでAgentを把握したい

こ  様々な環境に散らばった大量のAgent
ん
な  何のAgentがいてどのAgentが正常なのか
こ
と
い  Collectorの位置でまとめて確認できるのが最
い
なも的確

で  NATだとsource address / port は使えない
き
た
ら  Agentからhostname / PrivateAddrを送り
い
い  hostname の prefix 等でグループ化
な
 １日以内に１度でも配送したAgentを確認
47

fin
監視の設定をしたら
ぐっすり眠ってね！！

Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例

Similar to Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例 (20)

Recently uploaded

Recently uploaded (8)

Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例