概要

http://www.rsyslog.com/doc/queues.html
http://www.rsyslog.com/doc/dev_queue.html
をざっくり訳してみた

http://www.rsyslog.com/doc/queues.html

2つのactivesが接続を必要とするため、rsyslogdではqueueを利用している・
このドキュメントでは内部の動きを紹介する。

現在、キューはメッセージキューとactionsに利用されている。
rsyslog内部に[main message queue]が存在している。
入力モジュールはそれぞれここにメッセージを届ける。
[main message queue]はrsyslog.confで設定されたフィルターをもとに
メセージを振り分け[action queues]へ送る。[action queues]へ送られたメッセージは[main message queue]から削除される

さまざまな[action queues]があり、動作が定義されている。デフォルトではdirectモードで動作する(non-queueing)
[action queues]は様々な設定をすることが可能。将来的には別の場所でキューを動作させることも可能になるはず。

設定ファイルでは”MainMsg” or “Action”といった設定の仕方を実施。例えばシャットダウン時は以下のように設定する。
$MainMsgQueueSaveOnShutdown on

同じパラメーターのものは一番最後のものが反映されます。
設定をすべて読み込んでから、[main message queue]は作成されます。
セレクタが指定されるごとにキューが作成される。

ただし、すべての設定が反映されるわけではない、例えばoutput module はmulti-threadingをサポートしていない。

Queue Modes

Rsyslogにはさまざまなqueueモードがある。適切なモードを選択するべし。ディレクティブ的にはQueueTypeを指定する。

Direct Queues

non-queue。キューもバッファーも利用しない。生産者から消費者へ直接渡す。メリットも大きい。

Disk Queues

Disk queues use disk drives for buffering.
バッファリングのためにディスクを利用する。いつもディスクを利用し、バッファメモリは使用しない。
キューは信頼性がとても高いが、遅いモードとなる。絶対に失ってはならないデータの場合は有効であり、それ以外は推奨しない。

In-Memory Queues

キューデータはメモリ上に保持される。つまり高速。そしてもちろん、システムやOSが停止した場合はログは消失する。
ログが大切なモノである場合、UPSなどの設置が必要。

注意すべきは、ログサーバがダウンした時、メモリ上にすべてのデータがのるが
データをメモリから移動させる必要はない。(長期間メモリに保持されないようになっている？意味がわからん。。)

in-memoryには、LinkedListとFixedArrayモードがある。
ユーザー的には同じ動きであるが、内部的には違った動きをする

FixedArray
あらかじめ領域を予約しておく。予約された領域は、ほとんどがデータで、残りがポインタ配列。キューが空だったとしてもポインタ配列のためにメモリを消費する。動的な動作やhousekeeping構造が必要でないときは、もっともCPU使用率が低く最良の動作をする。
キューの要素が低く、パフォーマンスを重視する場合はこのモードが最適。
キューに入れられるメッセージ数は10,000が限界です。

LinkedList
全く逆。housekeeping構造で、動的にメモリを許可する。(名前の通り)
多少のオーバーヘッドを要求するが、それが必要な時に割り当てられることを保証する。
より多くの要素を順番で待つ必要がある時に、よく動作する。
ただし、時々メッセージが破損する。例えば、メモリを200,000メッセージまでと制限していた場合。
ただしこのような場合は、FixedArrayキューはもっと多くの静的メモリを必要とする。

迷ったときはLinkedListの選択を推奨する。

FixedArrayと比較したとき、処理オーバーヘッドと、それよりもメモリの使用率が気になるかもしれません。
ほとんどが使用しないポインタとなる時は動的メモリよりも遅くなる。

Disk-Assisted Memory Queues
in-memory queuesであるときに、QueueFileNameを指定した時に自動的に”disk-assisted” (DA).モードとなる
データは必要に応じてディスクに記載されるようになる。

このモードは、メモリキュー：primary queueとディスクキュー：DA queueが同時に動くようになる。
DA queueはprimary queueが満タンもしくはシャットダウン時に利用される。
Disk-Assisted queueは純粋なキューとディスクキューを組み合わせたもの。基本的にメモリだけで動作し、
ディスクに触れることはない。

無制限の量をバッファすることができる。(実際に自由なディスクスペースによって制限される)
rsyslogdが動作している限りはログを保守する。

DA queueでは、ディスク特有とメモリ特有のパラメータをセットできる。
ここまで聞くと、DA queueは完璧かと。

DA queuesは長期間の運用や、高い信頼性がある。例えば、tcpにてデータを送信することが推奨されている。
DA queuesについて、メモリキューがいっぱいになったらすべてをdiskに書き込むべきではない。
そのためにより賢いアルゴリズムとして、”high watermark”と”low watermark”がある。
これらはキューアイテムの量を表す。

“high watermark”に達すると、diskを利用する。”low watermark”に達すると、diskの利用をやめ、diskは空になっていき、
最終的にin-memoryモードのみで動作する。”low watermark”付近の場合は、メモリへ記載する。もし”high watermark”に達していなければdiskへの記載は行わない。
このアルゴリズムは不必要なディスク書き込みを防ぐだけでなく、追加バッファ(緊急用のバッファ)を残すことが可能となる。
“high watermark”など、しっかり設計しないとディスクアクセスが多く発生します。

ウォーター・マークは”$