pdnsを適当にチューニング
pdnsのチューニングは以下のページが参考になる。
https://doc.powerdns.com/md/authoritative/performance/
細かくやればきりがないと思うけど、receiver-threadsが一番効果がでそうなので、そこからやってみる。
チューニングのきっかけとしては、バックエンドのmysqlへのレイテンシーが非常に大きい環境があり、
その環境にあるDNSサーバがパンクしかけていたことだった。
レイテンシーが大きい場合は並列数を増やすことが効果的だと思ったのだ。
まずは設定値を変えてみる。デフォルトはreceiver-threads=1となっている。
$ sudo diff pdns.conf pdns.conf.20160908 251d250 < receiver-threads=3
以下のシェルスクリプトを使って検証を実施。
gist.github.com
receiver-threadsを上げてテストすると12ぐらいで最良の結果が得られた。
検証の方法が正しいかは保証できないが、適当にチューニングするぐらいならこれでよいのではないかと思う。
上記の公式ページだとreceiver-threadsは3,4ぐらいが適切と書いてあるが、
DBに対する通信のレイテンシーが大きい環境ではそうではないようだ（当たり前か）
2016-01-30 更新
`dnsperf`が大変便利なのでこんなシェル要らないことに気づいた。
pythonのsftpserverを試す
pythonで書いているバッチのテスト用にsftpサーバを簡単に立ち上げたかった。
探してみるとちょうどよいsftpseverというものを見つけたので使い方を含めてメモ。
GitHub - rspivak/sftpserver: A simple single-threaded SFTP server
ニフティクラウドのロードバランサをAnsibleから操作できるようにしてみた
AWSならbotoと連携するモジュールをAnsibleが正式に提供しているが、
ニフティクラウドのSDKがそもそもPythonに対応していないので、Ansible対応は難しい。
ということでAnsibleに対応するために2点実装した。
（１）botoをニフティクラウド用に修正
（２）Ansible用のモジュール作成
（１）はやり始めると途方がないので、ロードバランサからインスタンスの装着/取外しができるところまで実装した。
以下の様なplaybookを書くと動く
gist.github.com
（１）
github.com
（２）
gist.github.com
implementation of smtpd always returning 500 error.
常に500エラーを返すSMTPサーバを実装した。テスト等に使えるはず。
gist.github.com
工夫ポイント： エラーコードの返し方がsmtpdのドキュメントにはなかったので、ソースから特定した。
ログ監視ツール比較
ログ監視を行いたいが、どのツールがよいのか検討したので、簡単にメモする どのツールが良いかというのは、既存環境との組み合わせや、そもそも既存のツールで完結させたいとかそういう要望次第なのでなんとも言えない。 あくまで自分視点で比較をする。
調べた限り以下のツールが出てきた。
- logmon
- swatch(simple log watcher)
- Zabbix
- fluentd
- logwatch
logmon
github: https://github.com/moomindani/logmon
IBM製のツール。シンプル。サンプルコードとして提供されている。
正規表現を書いて、一致する行が出てきたら即刻メールが飛んでくる。 ファイル名のパターンや正規表現に関する機能もシンプルなので、細かいところに手が届かない。
所詮サンプルなのでカスタマイズが必要
- 言語： perl
- 動作形態： デーモン
swatch(simple log watcher)
URL: https://sourceforge.net/projects/swatch/
イメージ的にはlogmonを改良したもの。 正規表現に一致する行があった時の動作はメールもしくはパイプで任意のコマンドを実行できる。 例えば、以下の記事のようにfluentdと連携することが可能。
http://kyudy.hatenablog.com/entry/2016/06/22/181907
- 言語： perl
- 動作形態： デーモン
Zabbix
URL: https://www.zabbix.com/documentation/2.2/jp/manual/config/items/itemtypes/log_items
logmonと変わらないぐらいシンプル。 単純なログ監視をする場合、かつ既にZabbixを運用しているのなら有用かもしれない。
- 言語： なし（Zabbixのアイテム・トリガー）
- 動作形態： Zabbixの付属機能
fluentd（grep Filter Plugin等）
URL: http://docs.fluentd.org/articles/filter_grep
grepのfilterとfluent-plugin-mailなどを使えば高度なログ監視が実現できるかもしれない。 fluentdが既に入っているなら良いかもしれない。
ただ、正規表現を追加することを想定する場合には、fluentdのリロードが必要なのが少し気持ち悪い気がした。
要件によっては自分でpluginを書いて見てもよいかも。
※ ただの個人の所感です。
- 言語： なし（fluentdの設定で記載する）plugin書く場合はruby
- 動作形態： fluentdの機能の組み合わせ。
logwatch
URL: https://sourceforge.net/projects/logwatch/files/
/var/log以下のログを整形して毎日レポートをくれる。 一般的なsyslogに対応していて、何か起きているとわかりやすく記載してくれるようだ。 内容としては例えばpostfix等でどのぐらいrejectしていたのかなど。
エラーログが出たときにすぐ知りたい、という使い方には対応できない。 他のツールとはその点が大きく異る。
独自アプリのログに対応させるには自分でスクリプト書かないと行けない。
- 言語： perl
- 動作形態： cronで定期実行
swatchをfluentdに連携させる
swatch(Simple Log Watcher)は昔からあるログ監視ツールらしい。
詳細は置いておいて、このswatchの出力をfluentdに送りたい。なぜならばデフォルトでswatchが出力できるのはmailと標準出力なので、サーバの台数が増えてくると管理できなくなる（メール100通とか毎日見たくないし、標準出力をターミナル100個見続けるとか無理）
幸いswatchは出力をpipeすることができる。
このpipeとfluent-catを組み合わせることでswatchの出力をfluentdに送出できる。
実際に動かすところまで実践してみたので、設定内容をメモする。
pipeの引数にforward_fluent.shを指定している。
このシェルは下記の通り、受けた標準出力をfluent-catに渡すものだ。
tagを指定するのと、swatchの出力をfluent-catの入力フォーマット（デフォルトではjson)に変換する必要があるので、シェルを一つかましている。
forward_fluent.sh
実行
$ swatch --daemon -c swatch.conf -f test.log --pid-file=pid
実行すると、echoもしているので色分けされた出力が標準出力に表示される。
また、同時にfluentdにも送信されているのを確認した。
以上
