DigiLoog

PC関係の事なら何でもいけるそんな処

syslog転送出来ないログを、リアルタイムでsyslogに変換してみた

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
  1. 『Priority=(Facility×8)+Severity』
     
  2. 算出したPriorityを “<>” で囲みつつ、
    ログの先頭に付与して送信すると、
    syslog受信側でsyslogとして処理出来る
     
  3. kernelメッセージ・Emergencyログの時、
    Priorityは「0」となる
     
  4. 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はシンプルな仕様となっているので、
腕に自信がある人は自力でアプリケーションを組む事も視野に入れてみて欲しい (`・ω・´)





  • 応援中

    はじめるセカイの理想論 -goodbye world index-