mackerel-agent-plugins に PR を送った話

Mackerel Advent Calendar 2018 - Qiita の 11日目です。昨日は id:koudenpa さんの.NET で動くアプリケーションを Mackerel で監視できるかな？ でした。

今回は mackerel-agent-plugin の mackerel-plugin-squid を使おうとしたところ、運用上欲しいメトリックが対象となっていなかったので、エイやと機能を追加して、取り込んでもらったので、その体験談です。

メトリックとして欲しい項目を考える

今回は既存の plugin に欲しい項目を付け加えるので、コードを読んでみました。

squid には各種情報をとるためのインターフェースがいくつか用意されていて、mackerel-plugin-squid では mgr:info を情報源にしていました。どのような情報が取れるかはリンク先を参照してもらうとして、今回、僕が是非とも加えたいと思ったのは、以下の項目です。

• squid プロセスが使用した CPU 時間
• squid が握っている FD の情報
• squid のキャッシュストレージの使用状況
• squid のメモリ確保状況

それぞれ、mgr:info から取得するには以下の項目を参照すれば良さそうです。

• squid プロセスが使用した CPU 時間
  • Resource usage for squid: の CPU Usage, 5 minute avg:
• squid が握っている FD の情報
  • File descriptor usage for squid: あたりを丸ごと
• squid のキャッシュストレージの使用状況
  • Cache information for squid: の Storage Swap size: や Storage Mem size: あたりが使えそう
• squid のメモリ確保状況
  • Memory accounted for: の memPoolAlloc calls: と memPoolFree calls: あたりが使えそう

修正箇所を考える

mackerel-agent-plugin の書き方は整備されたドキュメントが公開されているので、そこを参考に書き方を調べます。

今回は既存の plugin に修正するので、既存のコードを眺めます。ポイントはグラフ定義部分とメトリック値を入れているところです。

グラフ定義部分は GraphDefinition() という関数の中で graphdef を返しているだけなので、graphdef を眺めてなんとなく雰囲気を掴みます。今回は Memory accounted for: の memPoolAlloc calls: と memPoolFree calls: の値はカウンター値なので、そこだけ気をつけてあげれば良さそうです。

また、メトリック値を取得しているところは僕が最初に確認した時は FetchMetrics() の中で TCP ソケットを開いて GET cache_object://localhost:3128/info HTTP/1.0\n\n というような文字列を直接流し込んでいました。最近の squid だと localhost:3128 など cache_manager のポートに HTTP 通信をさせると、取得できるのですが、このプラグンが最初に作られた時は squid 2 系についても考慮する必要があったので、TCP ソケットと直接通信させる必要があったようです。また、値については応答内容を愚直に regexp.MustCompile() で正規表現で拾い上げているようでした。

あと、コードを読みながら気づいたのですが、このプラグインにはテストが書かれていなかったので、テストが書きやすい構造に直してあげる必要がありそうです。

パッチを書いたら PR を出す

というわけで、諸々で書いた結果以下のような PR が出来上がりました。

https://github.com/mackerelio/mackerel-agent-plugins/pull/534

今までの PR の内容をみつつ、雰囲気を感じながら拙い英語で PR を出したところ、わりとさっくりとマージしてもらえました。

mackerel-plugin-squid は go-mackerel-plugin-helper を使っています。このライブラリはレポジトリの README.md に書かれている通り、現在は go-mackerel-plugin の使用が推奨されています。実際に最初に参照した開発向けドキュメントでも go-mackerel-plugin の使用を前提としてます。修正するときに一緒にライブラリも変更しようかと思いましたが、今回はあまり時間がとれなかったので、ライブラリの変更を見送ったのが心残りです。

mackerel-agent だけでなく、mackerel-agent-plugins も Apache License, Version 2.0 で公開されているので、自分が欲しい機能などがあれば積極的に PR を送っていきたいですね!

ubuntu で Dtrace が使える MySQL バイナリを作る

とあることで MySQL さんの働きっぷりを dtrace で追いかけようと思ったけど、ubuntu が提供しているバイナリでは、dtrace 向けのオプションが付いていない状態でビルドされていた。

$ sudo /usr/share/bcc/tools/tplist -l `which mysqld`
$

MySQL :: MySQL 5.7 Reference Manual :: 2.9.4 MySQL Source-Configuration Options を見ると cmake に -DENABLE_DTRACE=1 を渡せば良いらしい

というわけで、deb パッケージの作り方をググりながら MySQL を作り直してみた、というメモです。

まずはビルドに必要な最小限のパッケージを取ってくる

$ sudo apt install build-essential devscripts systemtap-sdt-dev
$ sudo apt build-dep mysql-server

で、ubuntu のレポジトリから MySQL パッケージを作成するために必要なファイル1式を取ってくる

$ mkdir tmp
$ cd tmp
$ apt source mysql-server

この状態で作業用ディレクトリには以下のようにファイルとディレクトリが生成されているはず。

$ ls -F
mysql-5.7-5.7.23/   mysql-5.7_5.7.23-0ubuntu0.16.04.1.debian.tar.xz  mysql-5.7_5.7.23-0ubuntu0.16.04.1.dsc  mysql-5.7_5.7.23.orig.tar.gz
$

deb パッケージ作成時にしようする cmake のオプションは mysql-5.7-5.7.23/debian/rules に書いてあるので、修正してあげる。

ここまできたら以下を実行して deb パッケージが作れるはず

$ cd mysql-5.7-5.7.23
$ debuild -uc -us -b

出来上がったバイナリを tplist -l で確認すると以下のようにそれっぽい感じになっている。わーい。

$ sudo /usr/share/bcc/tools/tplist -l mysql-5.7-5.7.23/builddir/sql/mysqld  | wc -l
56
$

unbound-anchor で DNSSEC 向けトラストアンカーを更新すると EXIT CODE 1 で終了する

趣味活動で unbound の dnstap とか EDNS Client Subnet の挙動を確認したかったので、unbound のコンテナイメージを作っていたんだけど、最後に /usr/local/etc/unbound 以下の環境を作るところで、エラー終了してホゲーとなっていた。問題になっていたのは以下の RUN 命令部分。

 RUN addgroup unbound && adduser -S -G unbound unbound && \
     /usr/local/sbin/unbound-control-setup && \
     /usr/local/sbin/unbound-anchor -a /usr/local/etc/unbound/root.key && \
     mkdir -p /usr/local/etc/unbound/dnstap && \
     chown unbound:unbound /usr/local/etc/unbound/dnstap

で、ブログの表題でほとんどネタバレしているんだけど、原因になっていたのは /usr/local/sbin/unbound-anchor -a /usr/local/etc/unbound/root.key && \ の部分。unbound を運用している人にとっては当たり前かもしれないけど、unbound-anchor でトラストアンカーを更新した時は終了コードが1になるらしい。unbound-anchor のマニュアルにも以下のようにキッチリ明示されている。

EXIT CODE This tool exits with value 1 if the root anchor was updated using the certificate or if the builtin root-anchor was used. It exits with code 0 if no update was necessary, if the update was possible with RFC5011 tracking, or if an error occurred.

   You can check the exit value in this manner:
        unbound-anchor -a "root.key" || logger "Please check root.key"
   Or something more suitable for your operational environment.

しかも、解決方法も書いてあるし...

とりあえず、以下のように手元の Dockerfile を書き直して最後まで完走できることは確認した。

RUN addgroup unbound && adduser -S -G unbound unbound && \
    unbound-control-setup && \
    /usr/local/sbin/unbound-anchor -a /usr/local/etc/unbound/root.key || echo "hoge" && \
    mkdir -p /usr/local/etc/unbound/dnstap && \
    chown unbound:unbound /usr/local/etc/unbound/dnstap

mkr の emacs-helm インターフェースを作ってみた

helm て何

世間では k8s が流行ているので、helm といったら、k8s のパッケージシステムの helm が一般的になりつつあって少し残念な気分になっています。

emacs の世界で helm というと、こちら。僕も emacs で生活しているので、しょっちゅう helm のお世話になっている。helm が使えなくなると、仕事の効率が激しく落ちてしまうレベルで依存しています。ここでは helm というと混乱しそうなので、emacs-helm と記述することにします。

mkr の出力を emacs-helm でも扱いたい

対して、mackerel.io も無くなったら途方にくれるレベルで仕事に使っているので、emacs の中から mackerel.io に登録しているホストのメトリクス情報や監視結果を参照できるようにしたいなー、と思っていた。

mackerel.io には mkr というナイスな CLI ツールがあるので、この出力を emacs-helm に食べさせてよしなに扱えればとりあえず目的は達成できそう。mkr は結果を json 形式で出力してくれる。emacs で json データの扱い方がわからなかったので、そのままにしていたんだけど、ある日、helm-aws というパッケージを見ていると、そのものズバリな感じで扱っていたので、やる気が出てきた。

作った

というわけで、エイヤーと作ってみたので、github.com に公開してみます。melpa.org には登録していないので、以下のように emacs の load-path が通ったところにレポジトリごと git clone してください。

git clone https://github.com/nabeo/helm-mkr.git path/to/emacsd/site-lisp/helm-mkr

mkr を使える環境を整えて、~/.emacs.d/init.el とかに以下のように書いておいてください。

(require 'helm-mkr)
(setq mkr-org "your mackerelio org name")

mkr-org は mackerel.io の URL にはオーガニゼーションの文字列が含まれるので、自身のアカウントが所属しているオーガニゼーション名をいれておく必要があります。

ここまで準備が整ったら、M-x helm-mkr で *helm-mkr* バッファに mackerel で管理しているホストの一覧が出ててきます。

今の所、デフォルトのアクションは選択したホストのホスト名をコピーします。アクションの候補として、browse-url 経由で選択したホストで収集されたメトリクスページに移動できるアクションを登録しています。

現状ではこんな感じだけでど、アラートのリストまで取れるようになったら(あと、要望とかあれば)、mepla.org とか emacs のパッケージ配布サイトに登録して手軽に使えるようにしたい。

infrataster-plugin-dns で DNS サーバの検査をする

DNS サーバの挙動をテストする

インフラの挙動をテストするためのフレームワークである infrataster という仕組みがあります。サーバ構築時のテストフレームワークは Serverspec が有名ですが、対象をインフラにしたものという乱暴な理解です。

で、インフラといえば DNS なんですが、僕は小心者なので DNS サーバの設定でしくじったりすると、被害が甚大なので、小さな修正でもドキドキしながらオペレーションをしています。また、設定直後はうまく動いているように見えて、実は他のエントリを書き換えてしまい後から障害になってしまう、ということも考えられます。まさに自分が自宅の内部ネットワークのメンテ時に凡ミスして一時的に名前解決ができなくなってツライ目にあってしまったので、infrataster の復習がてら、infrataster-plugin-dns を使ってみたので、そのメモを残しておこうと思います。

infrataster そのものは DNS サーバのテストはできませんが、infrataster-plugin-dns はその名前のとおり infrataster のプラグインとして作成されて、特定の DNS サーバを対象にしてクエリ応答のテストができます。

準備

infrataster は rspec の仕組みのうえに構築されているので、rspec --init で rspec 的な準備をしておきます。

spec/spec_helper.rb には以下のように検査したい DNS サーバを定義します。

require 'infrataster/rspec'
require 'infrataster-plugin-dns'

Infrataster::Server.define(:exapmle_com, 'a.iana-servers.net')

ここでは例として example.com の権威サーバの a.iana-servers.net を :example_com として定義しています。

テストケースは spec/example.com_spec.rb とかに書いていきます。

require  'spec_helper'

describe server(:exapmle_com) do
  # ここにテストケースを書いていく
end

頑張ってテストケースを書く

ここからは運用している DNS サーバに登録している内容をひたすら列挙していく作業です。

infrataster-plugin-dns の README.md にも書かれていますが、基本的に rspec 的なマッチャーは rspec-dns をベースにしているので、そちらを参照していきます。さらに、rspec-dns は内部的に Dnsruby を呼び出しているので、各 RR の応答を検査するときは Dnsruby::RR クラスのドキュメントを読みながら空気を察する必要があります。

というわけで、いくつか例をあげておきます。

NS レコード

example.com. の NS の場合は dig で確認すると以下のように応答がありました。

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

この場合は Dnsruby::RR::NS を見ながら書くとこんな感じになります。

describe dns('example.com.') do
  it 'NS RR : a.iana-servers.net' do
    is_expected.to have_entry.with_type('NS').
                     and_ttl(86400).
                     and_domainname('a.iana-servers.net')
  end
  it 'NS RR : b.iana-servers.net' do
    is_expected.to have_entry.with_type('NS').
                     and_ttl(86400).
                     and_domainname('b.iana-servers.net')
  end
end

SOA レコード

example.com の SOA は dig で確認すると以下のようになっています。

;; QUESTION SECTION:
;example.com.                   IN      SOA

;; ANSWER SECTION:
example.com.            3600    IN      SOA     sns.dns.icann.org. noc.dns.icann.org. 2018013047 7200 3600 1209600 3600

で、NS の時と同じように Dnsruby::RR::SOA のアトリビュートとRR応答の仕様を見比べながら書いていきます。

describe dns('example.com.') do
  it 'SOA RR' do
    is_expected.to have_entry.with_type('SOA').
                     and_ttl(3600).
                     and_mname('sns.dns.icann.org').
                     and_rname('noc.dns.icann.org').
                     and_refresh(7200).
                     and_retry(3600).
                     and_expire(1209600).
                     and_minimum(3600)
  end
end

その他の RR

基本的に Dnsruby::RR のドキュメントや infrataster-plugind-dns や rspec-dns の例を見ておけば、なんとなく雰囲気は察することができると思いますし、代表的な RR については例があるのでわかりやすいと思います。

最後に書きながらハマったところをメモがてら残しておきます。

DNSEC 周りの応答には Base64 でエンコードしたデータが含まれていますが、そのまま and_signature に渡すとテストに失敗します。Base64.decode64 で符号化を解いた状態でマッチャーに渡してあげましょう。コードの中身まで追っていませんが、Dnsruby の処理でそのようになっているような気がします。例えば、example.com の DNSKEY の1つは以下のように応答があります。

example.com.            3600    IN      DNSKEY  256 3 8 AwEAAblDjCPejMhknWXZqbwBEUPI6Lkwjvp0XlUNTBqW2glZrgf3MXjJ ZBXl8rhYoTkrov7jmbBaBOPTkqlQAbfOKFNoG+U+boGG6Zmy00l2XRP1 nckVMpJ2TxiDVcXJqs78MetC1Ztu4p6bj4VrJCYTmv3ZULSrWleMSWtv YXqY0S23

この場合は最後の公開鍵部分が Base64 でエンコードされているので、以下のようにするとテストできます。

describe dns('example.com.') do
  it 'DNSKEY RR' do
    is_expected.to have_entry.with_type('DNSKEY').
                     and_key(Base64.decode64('AwEAAblDjCPejMhknWXZqbwBEUPI6Lkwjvp0XlUNTBqW2glZrgf3MXjJZBXl8rhYoTkrov7jmbBaBOPTkqlQAbfOKFNoG+U+boGG6Zmy00l2XRP1nckVMpJ2TxiDVcXJqs78MetC1Ztu4p6bj4VrJCYTmv3ZULSrWleMSWtvYXqY0S23'))
  end
end

このようにあらかじめテストケースを網羅的に用意して、履歴を管理することで、思わぬ事故を防ぎ、家庭の平和(と父親の威厳)を守りたいものです。

トンネルを掘る

自宅で使っている RTX810 くんを眺めていたら、L2TP/IPsec で VPN トンネル掘らない?と問いかけられたので、掘ってみた。

設定サンプルがヤマハネットワークのサイトがあったので、ほぼそのまま持ってきている。

まずは LAN 側のインターフェースでトンネルの向こう側にいるクライアントに LAN 側の arp リクエストを代理応答するように設定を入れておく

ip lan1 proxyarp on

次に L2TP 接続を受け入れるためのインターフェースを作る

pp select anonymous
pp bind tunnel1
pp auth request chap-pap
pp auth username <L2TPユーザ> <ユーザのパスワード>
ppp ipcp ipaddress on
ppp ipcp msext on
ip pp remote address pool 192.168.11.226-192.168.11.237
ip pp mtu 1258
pp enable anonymous

pp auth username は L2TP 接続をするクライアントの数だけ記述する。今回は僕が外出先から繋げれればいいので、1つだけで十分。ip pp remote address で L2TP クライアントに払い出すアドレスをレンジで確保しているのは、将来的に増えることを見越して、多めにとっている。

次に L2TP/IPsec で VPN トンネルを作るための設定を入れる。

tunnel select 1
tunnel encapsulation l2tp
ipsec tunnel 1
ipsec sa policy 1 1 esp aes-cbc sha-hmac
ipsec ike keepalive use 1 off
ipsec ike local address 1 <lan1のアドレス>
ipsec ike nat-traversal 1 on
ipsec ike pre-shared-key 1 text <IPsec の事前共有鍵>
ipsec ike remote address 1 any
l2tp tunnel disconnect time off
l2tp keepalive use on 10 3
l2tp keepalive log on
l2tp syslog on
ip tunnel tcp mss limit auto
tunnel enable 1

l2tp syslog on しているのは、設定中にどハマって、あるぇ?となることを見越して、L2TP 周りのログを syslog で吐くようにしておいた。

次に IPsec のトランスポートモードを設定しておく

ipsec auto refresh on
ipsec transport 1 1 udp 1701

あとはフィルターを書いて、必要なパケットが通過できるようにしておく。

ip filter 200080 pass * <lan1のアドレス> esp * *
ip filter 200081 pass * <lan1のアドレス> udp * 500
ip filter 200082 pass * <lan1のアドレス> udp * 1701
ip filter 200083 pass * <lan1のアドレス> udp * 4500

で、このフィルタを PP インターフェースの in に追加しておく。

ip pp secure filter in <設定しているフィルターの番号> 200080 200081 200082 200083

あとは PP インターフェースの nat descriptor に L2TP/IPsec 用の設定をいれておく。

nat descriptor type 1 masquerade
nat descriptor address outer 1 ipcp
nat descriptor address inner 1 auto
nat descriptor masquerade static 1 1 <lan1のアドレス> esp
nat descriptor masquerade static 1 2 <lan1のアドレス> udp 500
nat descriptor masquerade static 1 3 <lan1のアドレス> udp 4500

ここまで来たら、RTX810 側の受け入れ準備は完了しているので、端末からトンネル掘って、show status l2tp とかして、様子を見る。

というわけで、出先でホームシックになっても、少なくともネットワーク的にはお家に帰れるようになって幸せになれました。

あとは、テンプレート機能をつかって2つ目以降は手数を少なくしてトンネル開通できるらしいので、新しいラップトップを入手するための家庭内稟議を通す努力をしたいと思います。

株式会社はてなに入社して1ヶ月が経ちました

3/1付けで株式会社はてなに入社して、1ヶ月経ちました。というわけで、4/1のエントリですが、本当です。職種は Web オペレーションエンジニアです。つまり、サーバとかインフラ周りのお守りをしています。

「...で、誰?」とか言われそうですが、ちゃんとアウトプットして、1日でも早くインターネットで認識されるようになりたいです。

で、アウトプットの1発目としてこの1ヶ月を振り返ってみます。