スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Windows ServerのDHCPログが腐っている話 

Windows Server(ここでは2012ね)のDHCPサーバは、珍しくテキストファイルでログを出力する。これ自体はいいことで、イベントビューアのようなGUIでもCUIでも取り扱いの極めて面倒くさいログ形式ではないのは、腐ったガラクタの山の中にひと鉢の花が咲いているように感じられる。とはいえこれはMSがそうしたくてそうしたというのではないように思える。きっとどこかから持ってきた(フリーの)DHCPサーバソースコードを改造してWindows用のDHCPサーバにしたんじゃないだろうか、そしてログ出力部分までは書き換えるなかっただけではないだろうか。だから元々のテキストファイルへの出力ということになっているんではないだろうか。まぁ、どんな出自だろうがDHCPサーバは問題なく動作しているので、それはプログラムとして一番素晴らしいことではある。御託を並べてがたがた言うよりもきちんと動作してみせるのが一番いい。

しかしながらWindowsという腐りきったOSにおいては、テキストログといえどもマトモな形式ではない。生えているのは美しいバラの花ではなく、ジメジメした暗い場所に生える見た目の悪いゼニゴケだ。

なにせこのログファイル、ファイル名からして腐っている。

DhcpSrvLog-Mon.log
DhcpSrvLog-Tue.log
DhcpSrvLog-Wed.log
 :



という様にファイル名に曜日を含めて自動的に出力先ファイルを切り替えやがる。どうやってもログの保存期間は1週間を超えることができないではないか。何が嬉しくてこんな馬鹿な形式にしたんだよ。どうして1週間以上のログファイル保存は不要だと仕様で決めたのか、決めた奴の頭を叩いてやりたい。

せめてDhcpSrvLog-YYYYMMDD.logにしておけばいいだろうに。古いログを自動で削除することができないとかですか? それってあまりにヘボい理由だよね……

ログファイルの中身もヘボい。日本語で書いてあるのでスクリプトで処理するのが異常に面倒臭い。日本人だってログ出力に日本語を使うのなんてのは少ないぜ? 日立製とかのプログラムは日本語で出力するのかもしれないけれどさ、拝承。

中身はCSVなんだけど、カラムの並び順もおかしい。まずIDが出現する。IDというのはDHCPサーバで起きたイベントの種類を表すイベントIDなんだけど、どうしてこれを1番最初のカラムに持ってくるのか? 普通は日時だろ?
IDの次には日付、時刻がきて、その次にはいきなり説明だよ! どうして説明なんだよ!? フリーフォーマットの説明はさ、一番最後のカラムに持ってくればプログラムで処理しやすいし、テキストを人間の目で見た時にもカラムがずれにくくて見やすいのに、どうして前半に持ってくるのか?

次がIPアドレス、ホスト名、MACアドレスと来るんだけど、これもまずMACアドレス、次にIPアドレス、最後にホスト名とするべきじゃないのか? 感覚的にもそうだけれど、ホスト名が一番書式の自由度が高く、文字数が多くなったり少なくなったりするので、後ろに持ってきたほうが見やすくもなるのだ。
その後はよくわからないカラムが続く。トランザクションID、QResult、プロベーション時刻、相関ID、DHCID。そもそもここらへん具体的な説明はどこかに存在しているんだろうか? 妙なカタカナにしちゃうからよくわからないんだよな、日本人は"プロベーション"なんてカタカナ使わないぜ? カタカナだから英語ではどんな綴りなのかすぐにはわからないじゃないか。

もうちょっと運用するときのことを考えた作りにするのが当然だと思うのだが、Windowsだから仕方ない。いつだってこんな感じだし、これからだって改善されることはないだろう。だって奴ら、自分たちでは作って売るだけで、自分たちで運用しないんだもの。そういうところを改善する動機がないんだよな。

スポンサーサイト

net-toolsおじさんなのでブチ切れた話 

最近、緊急の障害対応でMACアドレスを調べる必要が発生した。

$ arp -an
net-tools コマンドはもう非推奨ですよ?おじさんなんじゃないですか? Use `ip n`
$



ブチ切れそうになったが、「非推奨になったネットワークコマンド養成ギプス」を導入しようとaliasを自分で設定したのでなんとか我慢した。
続いてIPアドレスを再度確認しようとした。

$ ifconfig -a
net-tools コマンドはもう非推奨ですよ?おじさんなんじゃないですか? Use `ip a`, `ip link`, `ip -s link`
$


癇癪を起こしそうになった。
俺の小宇宙は爆発寸前だぜ!
早くnet-tools小父さんを卒業しなければ死ぬ。

journaldがキモい(と感じられる) 

CentOS7でjournaldが導入されている。

日経BPのサイトでjournaldの使い方を軽く紹介されていたので読んだのだけれど、journalctlでログを参照しないといけないとか、その引数がかなりキモいとか、嫌な方向に変わっていくと思った。

[r]syslogの取りこぼしについて 

時々、ブログで[r]syslogは取りこぼして使いものにならない、的なことを言っている人がいます。本当にそうなんでしょうか。
[r]syslogdのやることなんてとってもシンプルで簡単な事じゃないですか、UDPパケットが届いたら事前に決められていたファイルへ追記する、メインはこれだけじゃないですか。
これで取りこぼしが出るような(r)syslogが、OS標準でついてくるのが当たり前っていうのはおかしいと思うんだよね。だから、取りこぼすにはなにか理由があって、それは使い方/設定内容のせいではないかなと想像していたわけ。

自分のところであった症状
そんなことを考えていたある日、10秒に1件程度しか出力されていないログが、どうやらrsyslogサーバで捨てられているらしいことが分かった。2台の機械から同じようなテンポでログが出力されているはずなのに、どちらか片方からのログしか記録されないんだよね。本当はもっと頻繁にログ出力されているのに違いない。

名前逆引きの失敗が原因なんじゃないの
困るんで調べてみたんだけれども、rsyslogdが標準では受信したsyslogパケットの送信元IPアドレスを逆引きして名前解決しているらしい。syslogの送信元機器IPアドレスは/etc/hostsにもDNSにも登録されていなかったので名前解決にタイムアウト、失敗してようやくログがファイルへ出力される。失敗が確定するまでに時間がかかり、他のパケットが捨てられている、ということらしい。

ログを送ってくる機械をrsyslogdの動作している機械の/etc/hostsへ書いてあげた所、トラブルは直った。原因はやはり名前解決の失敗だったらしい。


で、rsyslogを使うときに機器の名前登録なんかそもそもしたくない場合がある。そういう場合にはオプション-xを付けてやればよい。これで受信したsyslogパケットの送信元IPアドレスを逆引きしなくなる。CentOS6で設定を行う場合には

[/etc/sysconfig/rsyslog]

SYSLOGD_OPTIONS="-c 5"
 ↓
SYSLOGD_OPTIONS="-c 5 -x"



と変更して、(オプション"-c 5"はオプションの先頭にないといけないので注意)

service rsyslog restart



とする。多分 service rsyslog reload ではうまく反映されない。変更点がコマンドライン引数だから。
もちろん、ログに残されるログ送信元はホスト名ではなくてIPアドレスになってしまうのは仕様です。ホスト名で記録したければDNS登録なり、/etc/hosts登録なりして下さい。ただ、syslogサーバにsyslogを投げてくるマシン全部もれなく名前登録してやらないといけないんじゃないかなぁ。

ということをしないままログを取りこぼす、とか言っているんじゃないだろうかなぁと推測してみたり。
本当はどこまで問題なくログを処理できるのか、リモートからabみたいなのを使ってベンチマークすべきなんだろうけども、どうやるのが正しいんだろう? perlでsyslogを直接投げるスクリプトを作成、ループで回すんだけども、ループごとにミリ秒単位でウェイトを入れてみる、とかやればいいのかな?

ファイル書き出しをバッファしていないじゃないの
それでもsyslogが思いとか、ロスるとか言っている場合には、ファイルへの書き出しが同期書き出しになっているんじゃないのか。

daemon.info /var/log/daemon.log


とかって設定になっていたりするのを、ファイルパスの先頭に'-'をつけることでsyslogdがファイルへ書き出す際にバッファしてディスクへの書き出し負荷が小さくなるようにしてくれる。

daemon.info -/var/log/daemon.log


それでもうまく行かない場合であっても、[r]syslogdの実装を疑うより、何か他の原因を探した方が短時間で幸せになれると思うけどな。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。