netfilterを利用したDSP監視

手軽にできるL4監視

おおかわ　かずひとKauli, Inc.

なぜDSPを監視する必要があるか● DSPへのビッドリクエストが詰まる、大量にタイムアウトする

● RTBの処理に時間がかかるとbusy processが増える

● やがて上限に達してフロントのnginxからのリクエストに応答できなくなる

↓

配信事故になりかねない

黎明期の対策方法

● SSPのレスポンスタイムを監視して閾値を越えたらアラートを上げる

● エラーログから問題のあるDSPを特定する

● 設定ファイルを手で書き換えて問題のDSPへのリクエストを減らす

設定ファイルを書き換えて本番にデプロイできる人しか対応できない

アラートがあがった時点で配信が不安定な状態寸前

現在の対策方法

● 全てのRTBリクエストをさばいているvyattaの通信状態を監視

● 異常なTCPステータスの上昇を検知したらアラートをあげる

● アラートの内容、エラーログを確認して異常なDSPを特定する

● 問題のあるDSPの配信レートを操作する

ステータスの監視方法

● これにnetfilterのconntrack tableを活用

● conntrack tableにはvyattaを通過するすべての通信がリアルタイムで動的に保持

される

● conntrack tableは多いときで10万近いリストになることも

● conntrack tableを活用した監視方法はiptables(ip masquarede)をつかっている

副産物

netfilterとは● 安川情報システムじゃないよ(学校向けフィルタリングソフト)

● カーネルのパケット処理をhookしてユーザランドで制御できるようにしたものなので、

ユーザ側で操作、参照しやすい形態

● iptablesが有名だけどコンポーネントの一つ、他にもいくつかある

● conntrack, ulogd, ip6tables, arptables, ebtables等

● netfilterプロジェクトの一つがiptablesなだけ、支援パッチも多数存在

http://en.wikipedia.org/wiki/Netfilterhttp://www.netfilter.org/

conntrack table● connection tracking(追跡)の略ですべての通信がリアルタイムに記録される

● TCPの通信が終了した場合でも、設定されたタイムアウトまで蓄積される

● タイムアウトするとconntrack tableから破棄される

● つまりリアルタイムの通信以外の情報もconntrack tableには記録されている

● 監視する場合は上記の要素を排除しないといけない

● conntrack entry(中身)で見分けることが可能

● src dst IPとPortのtupleをhash化して高速に処理している(hash table)

conntrack table entry● [ASSURED] [UNREPLIED] のconntrack statusで有効なconntrackなのか判別す

る

● [ASSURED]は破棄されず、[UNREPLIED]はtimeoutか上限数に達すると破棄され

る

● conntrackのprotocol status、TCPなら SYN_SENT, ESTABLISHED,

CLOSE_WAIT, TIME_WAITなど

世間一般のconntrack table fullとは[ASSURED]が上限値に達したときの現象

conntrack entryのみかた

● cat /proc/net/nf_conntrack でも見れるけど時代的には古い

● 最新のカーネルだとprocfs自体から消えていたりする

● conntrack-toolsを使う、catより10倍以上早いしオプションも豊富

● cat /proc/net/nf_conntrack(6sec) → conntrack -L(0.5sec)

判定ロジック　その1● [ASSURED] + SYN_SENTが増える(SYN_ACKが帰ってこない)

● HALF-ASSUREDが増える([ASSURED][UNREPLIED]に遷移しない])

↓

コネクション要求に失敗している

その1をグラフでみると

SYN_SENTが増加

コネクション要求は通るけど、応答が戻ってこない状態

SYN_SENTだけは通るので、ロードバランサーやその先のリアルサーバの問題の可能性

その1をグラフでみると

HALF-ASSUREDが増加

コネクションオープンまたは、クローズの要求に応答が戻ってこない状態

NW的に疎通不可能か、レスポンスが極端に低下している状態

判定ロジック　その2● [ASSURED] + ESTABLISHEDが増える(終了しない通信が増える)

↓

コネクションは確立しているがレスポンスがない

その2をグラフでみると

CLOSEが増加

コネクションは確立したけど、レスポンスがないため開きっぱなしのコネクションが増加

リアルサーバからレスポンスがなく通信がFINへ遷移しないコネクションが増加している状態

逆SYN flood状態

値の取得方法

● vyattaのconntrack tableをperlスクリプトでパース

tcp_ss:68 tcp_sr:0 tcp_e:1035 tcp_fw:1638 tcp_cw:2736 tcp_la:225 tcp_tw:30220 tcp_c:5163 tcp_a:33064 tcp_u:5273 tcp_ha:12 tcp_tot:38349 udp_a:91 udp_u:2 udp_ha:4844

udp_tot:4937 icmp_u:0 icmp_ha:1 icmp_tot:1 igmp_u:0 igmp_ha:0 igmp_tot:0 other_a:0 other_u:7 other_ha:0 other_tot:7 tot_a:33155 tot_u:5282 tot_ha:4857 tot:43294

● http://forums.cacti.net/post-187384.html cacti forumのpluginを利用

● パースした値をsnmp経由で監視サーバが取得

● 自作nagios pluginで閾値監視、cactiでグラフ化

まとめ

● netfilterを利用することによりL4の通信がリアルタイムで可視化できる

● conntrack-toolsにより可視化のリソースコストが激減

● ASICと比べると遅いけどユーザランドなので柔軟性が高い

● netfilterのソースを読めばなにをしているかわかる

おわり

フランちゃんウフフなインフラエンジニアかもしれないよ