Fluentdのin_forwardに流れているレコードをtcpdumpで見る
本番環境で動いているFluentdのin_forwardに何が流れているのかを知りたい、けど設定を触りたくない…みたいな場合に流れているタグやレコードを見る方法です。特にFluentdに限った話ではないですが、備忘録として書いておきます。
1. tcpdumpでキャプチャ
調べたいサーバ上で、tcpdumpを使ってパケットキャプチャを取ります。in_forwardのポート番号などを指定してキャプチャします。
$ sudo tcpdump -i eth0 -w fluentd.pcap port 24224 and tcp
2. tcptraceでTCPストリームのデータだけ吐き出す
tcptraceは-eオプションを渡すと、TCPストリームごとのデータをファイルに吐いてくれるのでこれを利用します。なお、tcptraceはHomebrewやaptで入ると思います。
$ tcptrace -e fluentd.pcap
1 arg remaining, starting with 'fluentd.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
494 packets seen, 494 TCP packets traced
elapsed wallclock time: 0:00:00.005602, 88182 pkts/sec analyzed
trace file elapsed time: 0:00:25.927472
TCP connection info:
1: host1:53633 - host2:24224 (a2b) 213> 213< (reset)
2: host1:53668 - host2:24224 (c2d) 1> 1< (reset)
3: host1:53669 - host2:24224 (e2f) 17> 17< (reset)
4: host1:53670 - host2:24224 (g2h) 1> 1< (reset)
5: host1:53671 - host2:24224 (i2j) 15> 15< (reset)
Warning : some extracted files are incomplete!
Please see -l output for more detail.
$ ls *_contents.dat
a2b_contents.dat e2f_contents.dat i2j_contents.dat
3. Fluentdのin_forwardに流す
あとは*.datファイルをFluentdのin_forwardに流し直すだけです。
たとえば、out_stdoutに吐くだけのFluentdを起動して、
$ cat fluentd.conf <source> @type forward </source> <match **> @type stdout </match> $ fluentd -c fluentd.conf
ncで先ほどのdatファイルを食わせると、
$ cat *_contents.dat | nc localhost 24224
こんな感じでタグやレコードを見られます。
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"574da95b-23f1-42eb-8738-d646588b5639"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"0b585265-72de-4277-91bb-99c94e2e745b"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"7c4a1b43-5c04-4bfc-8532-1f9533bc7828"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"10b24574-f74c-465b-b2fa-92f124fcf85e"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"064ad535-764b-4eaa-a67c-4dda4b0982ba"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"76d67398-0f55-473e-abe3-a13ce14b31ad"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"b499a04b-3d0d-4a88-8fdd-e5d8eb501d2e"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"a7dcfbe6-fbfc-45d8-9702-fdc7ac9993d5"}
追記 2016/02/24
上記の手順でpcapファイルを変換するスクリプトを書いた
fluentd-pcap-converter.rb · GitHub
$ ls host1.pcap $ ruby fluentd-pcap-converter.rb host1.pcap $ ls host1.pcap host1.pcap.output.20160224_0.log
tracking branchのremote URLをみるpropen
zsh 用関数の propen、これ便利です。コマンドラインからプルリクを開く https://t.co/msRZcEVNap pic.twitter.com/jA4HXxOJlx
— Naoya Ito (@naoya_ito) 2016, 1月 4で知ったGitHub - 作業中ブランチのプルリクエストをブラウザで開く - Qiitaがとても便利なんですが、origin以外にpushしているとプルリクの作成ができない（すでにプルリクがある場合はリダイレクトされる）ので、tracking branchのremote urlを参照するやつを書いた
function propen() { local current_branch_name=$(git symbolic-ref --short HEAD | xargs perl -MURI::Escape -e 'print uri_escape($ARGV[0]);') local remote=$(git branch -vv | grep '^*' | awk '{ print $4 }' | cut -d/ -f1 | sed -e 's/^\[//') local repo_url=$(git remote show -n $remote | grep 'Push URL' | grep -E -o '[^ ]+$' | sed -e 's|^https://||' -e 's/^git@//' -e 's/\.git$//' -e 's|:|/|') open "https://${repo_url}/pull/${current_branch_name}" }
$ git remote add fork git@github.com:ryotarai/itamae.git $ git push -u fork awesome-feature $ propen
とか叩くと、https://github.com/ryotarai/itamae/pull/awesome-featureが開く
re:dash + BigQueryでクエリのコスト上限が指定できるようになった
昨日に引き続きre:dashネタです。BigQueryはクエリが処理したデータ量に応じて課金されます。使った分だけ払えばいい反面、高額クエリを流すとたいへんなことになります…。Custom Quotasで1日のコスト上限を設定できるようになりましたが、これは10TBの倍数でしか設定できず、一撃10TB（= $50）のクエリは流れてしまう可能性があります。
Total MByte Processed Limit
Feature: BigQuery: limit amount of MB processed per query by ryotarai · Pull Request #710 · getredash/redashがマージされ、データ量（BigQueryのAPIでいうtotalBytesProcessed）の上限を設定できるようになりました。
Data Sourceの設定画面で"Total MByte Processed Limit"を設定しておくと、
クエリ実行前にdry run実行が行われ、指定した上限を超えた場合にエラーになります。
うっかり高額クエリを流さないためにご活用ください
（あくまで、1クエリのコストを制限出来るだけなので、Custom Quotasも併用しておくことをおすすめします）
re:dashをDockerで動かす
re:dashというデータ可視化ツールがあります。MySQL、Redshift、TDなどからデータを引っ張ってグラフ化できたりして、非常に便利なんですが、今まではHighchartsというライブラリに依存しており、ライセンスの関係で利用できる用途が限られていました。先日、Feature: replace HighCharts with Plotly by alonho · Pull Request #687 · getredash/redashでPloylyという別のグラフ描画ライブラリに移行されたので、Dockerで動かしてみました。
Dockerイメージ
masterブランチにDockerfileが含まれていますが、そのままdocker buildするとアセットがインストールされません。docker build前にmake depsを実行しておく想定っぽいですが、ビルドするホストにnodeやBowerなどをインストールするのは厳しいのでDockerイメージをビルドする際にインストールします。
プルリクは出してありますがまだマージされていませんので、フォークした https://github.com/ryotarai/redash/tree/bower-in-dockerfile ブランチを使ってビルドをします。ビルド済みのイメージもあります。
設定する
re:dashの動作にはPostgreSQLとRedisが必要なので適当に用意します。で、いくつかの設定を環境変数で設定します。
$ cat envfile REDASH_STATIC_ASSETS_PATH=../rd_ui/app/ REDASH_DATABASE_URL=postgresql://user:password@hostname/database REDASH_GOOGLE_APPS_DOMAIN=example.com REDASH_GOOGLE_CLIENT_ID=foobarbaz.apps.googleusercontent.com REDASH_GOOGLE_CLIENT_SECRET=foobarbaz REDASH_REDIS_URL=redis://hostname:6379/0 REDASH_COOKIE_SECRET=foobarbaz
REDASH_DATABASE_URLはPostgreSQL以外のDB（MySQL）とか使えそうな雰囲気を感じますが、コードを見る限り無視されるっぽいREDASH_GOOGLE_CLIENT_ID,REDASH_GOOGLE_CLIENT_SECRETはGoogleのDeveloper Consoleから取得しますREDASH_GOOGLE_APPS_DOMAINはオプショナルですが、Google Appsを使っていてログインできるドメインを絞りたい場合に指定しますREDASH_COOKIE_SECRETは適当に生成した文字列を設定します
DBにテーブルをつくる
必要なテーブルをPostgreSQLに作成します。
$ docker run --env-file=envfile ryotarai/redash:bower-in-dockerfile ./manage.py database create_tables
起動する
$ docker run --env-file=envfile -p 5000:5000 ryotarai/redash:bower-in-dockerfile
5000番でHTTPサーバが起動するので、適宜ポートをpublishします。
Adminユーザをつくる
初期状態ではユーザがいないので、管理者用にAdminユーザを作成します。Adminユーザはデータソースの設定ができます。
Googleアカウントでのログインを使う場合
DOCKER_HOST:5000にアクセスして、Googleアカウントでログイン- 以下のコマンドでAdmin権限を付与
$ docker run --env-file=envfile ryotarai/redash:bower-in-dockerfile ./manage.py grant_admin example@gmail.com
Adminユーザは他のユーザのAdmin権限をWeb UIから付与することが可能なので、一度CLIから設定してしまえば後はGUIで設定できます。
Googleアカウントでのログインを使わない場合
$ docker run --env-file=envfile ryotarai/redash:bower-in-dockerfile ./manage.py users create --admin --password admin "Admin" "admin"
admin / adminでログインできるようになります。
はてなブログに引っ越した
いままでOctopressでブログを書いていましたが（といっても最後の記事は去年の4月…）、もろもろ面倒なのではてなブログに引っ越すことにしました。
過去記事は移行せずそのままの予定: blog.ryotarai.info
