2019年05月11日(土) - 12:26 | カテゴリ:
Linux
PowerDNSのDNSクエリログや、ローカル出力したテキストをログとしてリモート転送する時、
syslog形式に変換してログとして転送したいケースがそれなりにある。
そんな時、普通ならrsyslog/syslog-ngとログをフックする仕組みを使ったり、
Fluentdなどのログ収集デーモンを追加する事で、リアルタイム取得を行いつつ再転送する事が出来るが、
全体の仕組みが複雑になったり、そもそも構成・設定変更をやりたく無いなどの理由で没になる。
| ( ´ Д｀) |
「もっと簡単に、生ログをリアルタイムで取得しつつ、syslog変換したいな～」 |
| ( ﾟ Дﾟ )φ |
「一人(筆者)が思っている位だから、似たような事を思っている人は多い筈…」 |
| (｡・Д・) |
「有料ソフトある位だし、それなりに需要は多そうだな……」 |
| (｀・ω・´) |
「意外と簡単そうだから作っちゃうか！」 |
と思い至ったので、スクリプトを自作して “ns-lab BB” のLinuxサーバに組み込んで実際に使ってみた。
全体概要は上の通り。裏ではtailを使ってリアルタイムにログ取得を行いつつ、
logger経由でローカルのsyslogにログ出力し、rsyslog/syslog-ngを使ってリモート転送も可能にした。
tailについてはオプションを指定する事で、tail対象のログがローテートされた場合でも、
順応しながらログを取得し続ける様にしてみた。
- 利用方法
nowsky system-lab memo > logger
“ns-lab BB” では、iptablesのAccept/Denyログ・auditログのfacilityを変更しつつ、
ログサーバに再転送する用途で利用している。
他にも、PowerDNSのDNSクエリログ転送、dnsdistのsyslog化などにも利用出来る為、
今後は利用箇所を増やしていく予定。
本来、ログ集約を行うならFluentdなどのログ集約エージェントを使うべきなのだが、
既存環境に新しいプログラムを入れたくなかったり、使い慣れたsyslogで集約したい事は多い筈。
今回作成したスクリプトは『インストール』とは言ってもビルドする様な物ではなく、
OSに初期インストール(されている筈)の物を組み合わせて使っている為、
導入などは比較的行いやすいと思う。
使い方次第で応用出来る所はそれなりに多いので、
ローカルの生ログをリモート転送したい場合に是非使ってみて欲しい。
………
～ お ま け ～
syslogとしては下記の “facility/severity” 算出方法に従い数字を出しつつ、
生ログの先頭に “<数字>” の様なメッセージをsyslogサーバにtelnetレベルで直接送信すると、
syslogサーバでパケットを解釈してログを処理をしてくれる。
なので、syslog用パケット生成とTCP/UDP接続・送信を行う処理をアプリに組み込めば、
(仕様準拠は置いといて)syslogとしてログ出力が可能となる。
ちなみに、解説サイトでsyslogフォーマットとして『Priority＝Emergencyなどの値』と記載している事が多いが、
大元のRFCとしては『FacilityとSeverityのCodeを掛け合わせた1～3桁の数字がPriority』なので注意。
ただ、アプリケーションによっては『SeverityとPriorityを同等の物』として扱う事もあるので、
設定レベルの細かい事については、各アプリのドキュメントを参照して下さい。
| Code |
Facility |
|
Code |
Severity |
| 0 |
kernel messages |
0 |
Emergency |
| 1 |
user-level messages |
1 |
Alert |
| 2 |
mail system |
2 |
Critical |
| 3 |
system daemons |
3 |
Error |
| 4 |
security/authorization messages |
4 |
Warning |
| 5 |
messages generated internally by syslogd |
5 |
Notice |
| 6 |
line printer subsystem |
6 |
Informational |
| 7 |
network news subsystem |
7 |
Debug |
| 8 |
UUCP system |
- 『Priority＝（Facility×8）＋Severity』
- 算出したPriorityを “<>” で囲みつつ、
ログの先頭に付与して送信すると、
syslog受信側でsyslogとして処理出来る
- kernelメッセージ・Emergencyログの時、
Priorityは「0」となる
- Local0メッセージ・Noticeログの時、
Priorityは「133」となる
|
| 9 |
clock daemon |
| 10 |
security/authorization messages |
| 11 |
FTP daemon |
| 12 |
NTP subsystem |
| 13 |
log audit |
| 14 |
log alert |
| 15 |
clock daemon |
| 16 |
local use 0 |
| 17 |
local use 1 |
| 18 |
local use 2 |
| 19 |
local use 3 |
| 20 |
local use 4 |
| 21 |
local use 5 |
| 22 |
local use 6 |
| 23 |
local use 7 |
という事で、syslogはシンプルな仕様となっているので、
腕に自信がある人は自力でアプリケーションを組む事も視野に入れてみて欲しい (｀・ω・´)
« 続きを隠す
2019年05月05日(日) - 22:34 | カテゴリ:
Linux
以前、gdnsdとnginxリバースプロキシ機能を使って、
可用性を維持したグローバルロードバランサ(GSLB)を構築したのだが、
“gdnsd+nginx” 構成で1年運用した所、”ns-lab BB” では次の様な問題が出てきた。
- 可用性が高すぎて縮退メンテナンスが面倒
メンテの為にサクッとGSLBの権威DNSから外したい場合、
上位DNSサーバでサブドメイン委譲設定を変更する必要があった。
エンタープライズなら委譲設定変更(NSレコード削除)も実施するが、
自鯖用途だと大げさにせずサクッと外したい場合が出てきた。
- DNSクエリログを取得出来ない
nginxリバプロ構成の場合、クライアントからのDNSクエリはnginxが処理する為、
nginxでクエリログを取得する必要がある。
ただし、nginxの仕様でUDPリバースプロキシでパケットログ取得が出来ないので、
別途構築したログ監視などが出来なかった。
という事で、課題を解決すべくオープンソースカンファレンスでネタを探したり、
twitter上で技術情報も追いかけていた所、dnsdistを使うとDNSに特化したリバプロを構築出来る事が判った。
『善は急げ！』という事で、テスト環境で実際に構築した上で『コレは行けるな！』と感触も得られたので、
休みを使って “ns-lab BB” のインターネット向けGSLB環境にdnsdistを組み込んでみた。
- 構築手順
nowsky system-lab memo > gdnsd
nowsky system-lab memo > dnsdist
構成変更後の構成は下の通り。変更前は「たすき掛け」で負荷分散を行っていたが、
変更後は「シングル」に変更して、DNSクエリが飛んでくる経路を敢えて単純化した。
ただし、いつ何時「たすき掛け」に戻すか判らないので、
dnsdistでもたすき掛けに変更出来る様にもしてみた。
ロギングについては、dnsdistで受けたDNSクエリをローカルログ出力をした上で、
自作プログラムを使ってリアルタイムでsyslog変換しつつ、リモート転送も行う様にした。
結果、DNSクエリログの集約化と監査も可能となり、課題となっていた項目を解決出来た。
1週間稼働させつつテストもしたが、実際のケースで秒間100～500クエリを捌きつつ、
ログ取得・リモート転送も問題無く動いている。
この構成を取ると、gdnsdの弱点であったロギングを補う事も出来る為、
GSLBをOSSで構築したい場合には重宝する構成例になるかも知れない。
ぶっちゃけ、GSLBをOSS使ってまで自前構築するケースは相当稀だと思うが、
アプライアンスを使えなかったり、インターネットと疎通が出来ない様な環境ではRoute53とかを使えないので、
自前で全て構築するケースは多々存在する。
既にあるシステムを使ったとしても、裏の仕組みを把握しているか否かで全体の理解度も変わってくる為、
GSLBを弄っている人については、一度OSSで自前構築してみるのをオススメしたい。
« 続きを隠す
2019年05月01日(水) - 21:19 | カテゴリ:
Linux
結論から書くと、Linux系OSはglibc等のパッケージアップデートと時刻環境変数の設定、
Windows系OSは「月次のロールアッププレビュー」を適用すると令和表記に対応する。
一応、物は試しでWindowsServer2012R2に令和パッチ(KB4493443)を適用しない状況で、
日付を和暦表示に変更した所、想定通りに『平成31年5月1日』表記となった。
元号ネタは既出なので使い古した感もあるが、自鯖の状況を把握する良い機会なので、
稼働している本番系Linux鯖と同じバージョンの検証環境を用いて元号対応状況を確認してみた。
“ns-lab BB” で稼働しているLinuxサーバOS(ディストリビューション)は下記の通り。
ディスク装置として使っているQNAP製NASもLinuxの一種だが、
対応を見据えてアップデートすると全仮想サーバを停止させる必要がある為、今回は割愛した。
そして、実際の確認結果は下記の通り。
全ディストリで対応済と思っていたら、以外とそうでも無かった (´・ω・｀)
| OS (version) |
glibc (version) |
$ LC_TIME=”ja_JP.UTF-8″ date +’%Ex’ |
| CentOS 6.10 |
2.12-1.212 |
令和元年05月01日 |
| CentOS 7.6.1810 |
2.17-260 |
令和元年05月01日 |
| openSUSE 15.0 |
2.26-lp150.11.17.1 |
令和元年05月01日 |
| Debian 9.9 |
2.24-11+deb9u4 |
05/01/19 |
| Raspbian 9.9 |
2.24-11+deb9u4 |
平成31年05月01日 |
もしかしたら、利用しているglibcのバージョンによって結果が変化するかもしれないが、
サクッとコマンドを叩いた限りでは実行結果に差が出た。
なんとなく、RPM系・APT系で実行結果に差が出ている気もするが、
ソースレベルの詳細まで追いかけていないのでなんとも言え無い所…
ただ、サーバ用途だと元号などの和暦を使わず、インストール時から “en_US.UTF-8” する事が多いし、
Linuxで元号を使うケースは稀だと思うので、今後修正が入るのを筆者は待とうと思う。
« 続きを隠す
