ガバメントクラウドへの移行後、システム運用経費は増加見込み──東京都は5月28日、日本政府の共通クラウド基盤「ガバメントクラウド」への移行後のシステム運用経費を巡り、国に対して声明を発表した。移行後の経費削減を目指すと国が掲げる一方、都の調査の結果では、移行前と比べて約1.6倍に経費が増える見込みだと主張。国に対して速やかに実効性のある措置を講じるよう求めている。
ガバメントクラウド移行後、経費は減らず1.6倍に増加──東京都、国に“具体的な試算根拠”など要請 - ITmedia NEWS
地方公共団体の基幹業務システムの標準化を巡っては、原則2025年度末までに、義務として「国が定める標準的な仕様に適合」させる必要があり、さらに努力義務としてガバメントクラウドへの移行を求めている。これにより国は「標準化移行後のシステム運用経費は18年度比で少なくとも3割の削減を目指す」と掲げている。
ガバメントクラウド移行後、経費は減らず1.6倍に増加──東京都、国に“具体的な試算根拠”など要請 - ITmedia NEWS
しかし、都の調査結果では、都内自治体の運用経費は、移行前と比べて全体で約1.6倍に増える見込みと主張。また国は、クラウドを最適化することで中長期的には、ほとんどのケースでコスト削減を見込めると説明していたが、これについても「その試算根拠や実現に要する期間、条件などは具体的に示されていない」と都は指摘している。
ガバメントクラウド移行後、経費は減らず1.6倍に増加──東京都、国に“具体的な試算根拠”など要請 - ITmedia NEWS
⇧ まぁ、度重なる「仕様変更」を行っても肝心な部分は「ベンダー」に丸投げしてきた「総務省」や「経済産業省」、「デジタル庁」が、実効性のある措置についての詳細な見積もりを作れるとは思えないが...
「ベンダー」が撤退してるというのも納得ですな...
ここで、「運用経費」の削減などの対応を取って「ベンダー」への対価が減るようなことが起これば、「ベンダー」の離脱が加速しそうな気はしますな...
とは言え、当初の見積もりで「ハードウェア」など（今回だと「クラウドサービスプロバイダー」の「サービス」で実現してると思われる）のコストを最適化とかしているのであれば、コスト削減できる余地は残っていないような気がするのだが...
「沈みゆく泥船」からは逃げる以外に手はないとは言いますが、もし「都の調査結果」が誤りでないのであれば、状況を打開できそうな起死回生の一手は出てこないような気がしますな...
Rsyslogがサポートしているインプットのインタフェースの全量と制約が知りたいのだが...
ちょっと、古い情報しか見当たらないのだが、
⇧ 左側が「インプット」としてサポートされている「インタフェース」の全量になるということなんですかね？
一応、公式のドキュメントで「Input Modules」なるものが用意されているようだ。
Input Modules
Input modules are used to gather messages from various sources.
They interface to message generators.
They are generally defined via the input configuration object.
https://www.rsyslog.com/doc/configuration/modules/idx_input.html
⇧ 上記によると「Input」の設定として定義されたものが「Input Modules」ということらしい。
「Input」はというと、
Input
The input object, as its name suggests, describes message input sources. Without input, no processing happens at all, because no messages enter the rsyslog system. Inputs are implemented via input modules.
The input object has different parameters:
-
those that apply to all input and are generally available for all inputs. These are documented below.
-
input-specific parameters. These are specific to a certain type of input. They are documented by the input module in question.
General Input Parameters
Note: parameter names are case-insensitive.
type <type-string>
Mandatory
The <type-string> is a string identifying the input module as given it each module’s documentation. For example, the UDP syslog input is named “imudp”.
⇧ とあり、「Input」が持つ「parameter」は「Input Module」に依存するようだ。
とりあえず、公式のドキュメントの情報でまとめてみた。
図が2013年のものらしいので、今現在が2025年ということで、12年あまり経過してるわけだが、9個ほど図に該当しないと思われる「Input Module」があるようなので、サポートしている「インタフェース」が増えたということなんですかね？
「Rsyslog」が対応してる「OS（Operation System）」が分からないのだが、
⇧ 一般的な「Linuxディストリビューション」であれば対応していると思って良いのだろうか？
Rsyslogでsyslogを受信した際のTIMESTAMPに対する制御が困難という話
前に、
⇧ 上記で触れたのだが、「Rsyslog」で重要そうなことが仕様としてドキュメントに記載されていなくて、何故か「FAQ（Frequently Asked Questions）」で仕様について記載されているということで激震が走ったのだが、
What is the difference between timereported and timegenerated?
Each message that is received by rsyslog is usually available with two timestamps. They can be accessed by using the properties “timereported” and “timegenerated”.
https://www.rsyslog.com/what-is-the-difference-between-timereported-and-timegenerated/
“timegenerated” is always the time when rsyslog generated the message object on the local machine. That actually means it is the time when the message was received (either via the oscall layer or on some inputs based on information the OS provides).
https://www.rsyslog.com/what-is-the-difference-between-timereported-and-timegenerated/
“timereported” is what the sending device reports as time. This is taken from the appropriate syslog header field. If and only if the syslog date header cannot properly be parsed, “timereported” is populated with the same value as “timegenerated”.
https://www.rsyslog.com/what-is-the-difference-between-timereported-and-timegenerated/
⇧ 上記にあるように、「Rsyslog」の内部で、
- timegenerated
- timereported
のどちらかで「TIMESTAMP」が処理されてしまうのだが、
『 If and only if the syslog date header cannot properly be parsed, “timereported” is populated with the same value as “timegenerated”.』
の条件がハッキリしない...
そもそも、「syslog date header」がどこの部分を意図しているのかがハッキリしないのだが、
syslog parsing in rsyslog
We regularly receive messages asking why rsyslog parses this or that message incorrectly. Of course, it turns out that rsyslog does the right thing, but the message sender does not. And also of course, this is not even of the slightest help to the end user experiencing the problem ;). So I thought I write this paper. It describes the problem source and shows potential solutions (aha!).
⇧ 公式のドキュメントによると、「Rsyslog」の問題ではなく送信元の問題で「syslog」のパースに失敗していると仰っていますな。
つまり、正しい「syslog」のフォーマットで送信してきてくれないからパースが上手くできないよ、ということらしい。
仕様を「FAQ（Frequently Asked Questions）」に記載しているぐらいだから、完全に「Rsyslog」側の落ち度というような気もするが...
とりあえず、「Rsyslog」の内部的な処理が「ブラックボックス」になっている以上、「Rsyslog」で受信する「syslog」について、
のフォーマットに準拠させるぐらいしかないと。
つまり、「Rsyslog」が稼働している「サーバー」側で対応できることは無いに等しいと。
ちなみに、
⇧ 上記の記事の時に触れたのだが、「Rsyslog」は、
- サーバー
- クライアント
の両方の役割を持ちますと。
話を「Rsyslog」が処理する「syslog」のフォーマットに戻すと、
に対応しているということらしいのだが、「Rsyslog」側のドキュメントで具体的なフォーマットについては、言及してくれていないので、「RFC 3164」や「RFC 5424」を確認する感じになるのだが、こやつらは仕様であって実装ではないはずなんよね...
「Rsyslog」側で許容する実装をドキュメントに明記すべきな気はするのだが...
「Rsyslog」側は、「インタフェース（IF：InterFace）定義書」とサンプルをドキュメントに載せるべきな気がするのよね...
で、「RFC 3164」や「RFC 5424」に準拠するには、「syslog」の構造について把握する必要があるのだが、
⇧ 上記サイト様が詳しいです。
なのだが、そもそも、
のどちらにも対応させるには？
What are message parsers?
Well, the quick answer is that message parsers are the component of rsyslog that parses the syslog message after it is being received. Prior to rsyslog 5.3.4, message parsers where built in into the rsyslog core itself and could not be modified (other than by modifying the rsyslog code).
In 5.3.4, we changed that: message parsers are now loadable modules (just like input and output modules). That means that new message parsers can be added without modifying the rsyslog core, even without contributing something back to the project.
How are message parsers used?
In a simplified view, rsyslog
-
first receives messages (via the input module),
-
then parses them (at the message level!) and
-
then processes them (operating on the internal message representation).
Message parsers are utilized in the second step (written in italics). Thus, they take the raw message (NOT frame!) received from the remote system and create the internal structure out of it that the other parts of rsyslog need in order to perform their processing. Parsing is vital, because an unparsed message can not be processed in the third stage, the actual application-level processing (like forwarding or writing to files).
⇧ 上記の説明によると、「message parser」は、「parses」で処理させるらしい。
公式の情報では無さそうだが、
⇧ 上図の処理フローの概要図を見た限りでは、「Input Module」から連携されるということなんですかね？
Where are parser chains used?
We now know what parser chains are and how they operate. The question is now how many parser chains can be active and how it is decided which parser chain is used on which message. This is controlled via rsyslog’s rulesets.
In short, multiple rulesets can be defined and there always exist at least one ruleset. A parser chain is bound to a specific ruleset. This is done by virtue of defining parsers via the $RulesetParser configuration directive (for specifics, see there). If no such directive is specified, the default parser chain is used. As of this writing, the default parser chain always consists of “rsyslog.rfc5424”, “rsyslog.rfc3164”, in that order. As soon as a parser is configured, the default list is cleared and the new parser is added to the end of the (initially empty) ruleset’s parser chain.
The important point to know is that parser chains are defined on a per-ruleset basis.
⇧ 上記によると、「ruleset」で「parser chain」が実現できるらしいのだが、肝心の「ruleset」の一覧についての説明が無いという...
一応、
$RulesetParser
Type: ruleset-specific configuration directive
Parameter Values: string
Available since: 5.3.4+
Default: rsyslog.rfc5424 followed by rsyslog.rfc3164
Description:
This directive permits to specify which message parsers should be used for the ruleset in question. It no ruleset is explicitly specified, the default ruleset is used. Message parsers are contained in (loadable) parser modules with the most common cases (RFC3164 and RFC5424) being build-in into rsyslogd.
https://www.rsyslog.com/doc/configuration/ruleset/rsconf1_rulesetparser.html
⇧ デフォルトで、
の両方をサポートしているらしい。
肝心の「$RulesetParser」なのだが、
⇧ 上記で「Rsyslog」に組み込まれているってことなんかな？
話が脱線しましたが、結局のところ、「Rsyslog」側で「Input Module」が決められていようと、外部から送られてくる「syslog」のフォーマットが「syslog」のフォーマットに準拠していない場合は、
- timegenerated
- timereported
の内、「timegenerated」で処理されてしまうと「FAQ（Frequently Asked Questions）」では言っているのだが、実際に、「Rsyslog」の内部でどのように判定されているか分からないので、何とも言えない...
「Rsyslog」側も、ハッキリとパース可能な「syslog」のフォーマットを明示してくれないのが良くないと思うのだが...
つまり、
- パース可能なsyslogのフォーマット
- パース不可能なsyslogのフォーマット
を明示してくれれば、
『We regularly receive messages asking why rsyslog parses this or that message incorrectly. Of course, it turns out that rsyslog does the right thing, but the message sender does not.』
という問題も起きない気がするのだが...
つまり、「Rsyslog」側が、予めドキュメントに記載しておけば、問い合わせは減ると思うのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
