Rsyslogの%TIMSTAMP%の値は結局どうなるのか。FAQで済ませるの止めて欲しい...

　ETC通信を遮断すると料金所でのエラー表示はなくなるので、システム障害を原因とする衝突事故は回避できますが、ETC専用レーンはまったく使えなくなります。それと同時に、料金請求に必要な通行履歴がまったく取得できなくなるので、利用車は一般レーン（有人レーン）に殺到することになります。

ETC大規模障害の混乱を拡げた“ある判断”あきらかに対応策は「表示器に目隠し」って？ - (2) | 乗りものニュース

　もしETC通信を遮断しなければ、すべてのETC車の通行履歴を残すことができます。その中には正常に決済できる車両もあります。未決済の車両があっても後日、通行履歴に基づき、高速道路会社が通行料金をクレジットカードから引き落とす（決済する）ことが可能です。影響を最小限にする余地はあったのです。

ETC大規模障害の混乱を拡げた“ある判断”あきらかに対応策は「表示器に目隠し」って？ - (2) | 乗りものニュース

⇧ まぁ、

障害発生時の復旧ルールが定義されていない
「ETC通信」を「遮断」せずに対応する方法が定義されていない

という状況だったと思うので、今回の障害で「IT事業継続計画（IT-BCP：Information Technology - Business Continuity Plan）」のようなものが作成されたと思うので、「ETC」の「システム」の「開発」、「保守・運用」に携わる「エンジニア」の精神的負担が多少は軽減されるのかな？

「爆弾処理班」と違って「人命」に直結することは稀だとは思いますが、既存の「システム」に与える「影響範囲」が分からない中での「開発」は相当なストレスだと思うのよね...

障害の原因は、

画像ギャラリー | ETC大規模障害の混乱を拡げた“ある判断”あきらかに対応策は「表示器に目隠し」って？ | 乗りものニュース

⇧ とあるのだが、既存の「システム」が継ぎ接ぎで「機能」追加されていった結果、「変更容易性」が低い状況になっていたとは思うのだが、「本番環境（Production）」とほぼ同じ環境の「ステージング環境（Staging）」で動作確認ができていれば、障害が起こる前に気付けたのかな？

「開発環境」が整備されていないと、「開発」に意識を注力できない気がしますな...

そもそも、「要件」漏れという気もしますな...

昨今、「アジャイル」の「スクラム」で「開発」する話が多い気がしますが、「ウォーターフォール」だと、

www.ipa.go.jp

https://www.ipa.go.jp/archive/digital/iot-en-ci/ent.html

⇧ 上図のような形で、「要件定義」で合意した内容は「テスト」するので、「テスト」によって、

要件
1. 機能
2. 非機能

が担保されると思うのだが、「テスト」が無い文化だと「機能」「非機能」が実現できてきているかの確認がされないので、「障害」が発生したとしても致し方ない気はする...

「テスト駆動開発（TDD：Test Driven Development）」で、且つ、常に「本番環境（Production）」に近い形で「動作確認」が実施できて、「エビデンス」を残せるような環境が構築できるようになっていれば「開発」もし易いとは思いますけどね...

Rsyslogの%TIMSTAMP%の値は結局どうなるのか。FAQで済ませるの止めて欲しい...

前回、

ts0818.hatenablog.com

⇧ 上記の記事の時に、「Rsyslog」が、

Server
Client

の両方の機能を持つことが分かったのだが、

www.rsyslog.com

https://www.rsyslog.com/doc/configuration/templates.html#standard-template-for-forwarding-to-a-remote-host-rfc3164-mode

■Standard Template for Forwarding to a Remote Host (RFC3164 mode)

template(name="ForwardFormat" type="list") {
    constant(value="<")
    property(name="pri")
    constant(value=">")
    property(name="timestamp" dateFormat="rfc3339")
    constant(value=" ")
    property(name="hostname")
    constant(value=" ")
    property(name="syslogtag" position.from="1" position.to="32")
    property(name="msg" spifno1stsp="on" )
    property(name="msg")
    }

■The equivalent string template

template(name="forwardFormat" type="string"
         string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
        )

⇧ で、「%TIMESTAMP%」はどこから取得してくるのかがサッパリ分からない...

公式のドキュメントによると、

www.rsyslog.com

https://www.rsyslog.com/doc/configuration/properties.html

⇧ とある。

msg: the MSG part of the message (aka “the message” ;))

https://www.rsyslog.com/doc/configuration/properties.html

timegenerated

timestamp when the message was RECEIVED. Always in high resolution

timereported

timestamp from the message. Resolution depends on what was provided in the message (in most cases, only seconds)

timestamp

alias for timereported

https://www.rsyslog.com/doc/configuration/properties.html

Special care needs to be taken in regard to time-related system variables:

timereported contains the timestamp that is contained within the message header. Ideally, it resembles the time when the message was created at the original sender. Depending on how long the message was in the relay chain, this can be quite old.
timegenerated contains the timestamp when the message was received by the local system. Here “received” actually means the point in time when the message was handed over from the OS to rsyslog’s reception buffers, but before any actual processing takes place. This also means a message is “received” before it is placed into any queue. Note that depending on the input, some minimal processing like extraction of the actual message content from the receive buffer can happen. If multiple messages are received via the same receive buffer (a common scenario for example with TCP-based syslog), they bear the same timegenerated stamp because they actually were received at the same time.

https://www.rsyslog.com/doc/configuration/properties.html

⇧ 説明が分り辛い...

、と思うのは自分だけでは無いようで、「FAQ（Frequently Asked Questions）」で、

『What is the difference between timereported and timegenerated?』

という話が出てくる程度には分かりにくいということかと。

www.rsyslog.com

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"

“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"

“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/

■"timereported"と"timegenerated"の違い

Assuming that all systems in a relay chain use valid syslog format, “timereported” will be the same on all relay machines, whereas “timegenerated” reflects the local time of message reception and thus is different on each relay machine.

https://www.rsyslog.com/what-is-the-difference-between-timereported-and-timegenerated/

⇧ とあり、無茶苦茶に重要な部分を、何故に公式のドキュメントの『https://www.rsyslog.com/doc/configuration/properties.html』のページに載せていないのか...

つまり、「syslog」の「syslog header」に含まれる「timestamp」がパースできない形になっていると、「timegenerated」の「日時」が「%TIMESTAMP%」の値に設定されるということらしい。

重大な情報な気がするのに、「FAQ（Frequently Asked Questions）」で済ませるのはどうなんだろうか...

と言うか、「送信元」の「マシン」と「Rsyslog」がインストールされている「マシン」とで「timezone」が異なっている場合、「日時」がズレる気がするんだが...

ネットの情報を漁っていたところ、

www.oresamalabo.net

Syslog 形式とメッセージフォーマット（CEF、LEEF） - おれさまラボ

milestone-of-se.nesuke.com

■RFC 3164

【図解】syslogプロトコル再入門 ~フォーマット(BSD/IETF形式),Facility/Severity一覧,Ciscoの設定~ | SEの道標

■RFC 5424

【図解】syslogプロトコル再入門 ~フォーマット(BSD/IETF形式),Facility/Severity一覧,Ciscoの設定~ | SEの道標

⇧ 上記サイト様にありますように、

RFC 3164
RFC 5424

のいずれかに準拠しているのであれば、「syslog」には必ず「TimeStamp」は存在しますと。

ちなみに、「Rsyslog」の公式のドキュメントによると、

www.rsyslog.com

https://www.rsyslog.com/doc/configuration/templates.html

RSYSLOG_SyslogProtocol23Format - the format specified in IETF’s internet-draft ietf-syslog-protocol-23, which is very close to the actual syslog standard RFC5424 (we couldn’t update this template as things were in production for quite some time when RFC5424 was finally approved). This format includes several improvements. You may use this format with all relatively recent versions of rsyslog or syslogd.

https://www.rsyslog.com/doc/configuration/templates.html

⇧「RFC 5424」で転送したい場合は、『RSYSLOG_SyslogProtocol23Format』の「Template」を利用する設定を追加する必要があるってことなのだとは思うのだが、「RFC 5424」に完全に準拠できてはいないらしい...

そもそも、

www.rsyslog.com

https://www.rsyslog.com/doc/configuration/templates.html#the-template-object

⇧「Rsyslog」の「Template」の仕組みがいまいちよく分からないのだが、

No	Rsyslog Template name	内容
1	ForwardFormat	Standard Template for Forwarding to a Remote Host (RFC3164 mode)
2	RSYSLOG_SyslogProtocol23Format	the format specified in IETF’s internet-draft ietf-syslog-protocol-23, which is very close to the actual syslog standard RFC5424 (we couldn’t update this template as things were in production for quite some time when RFC5424 was finally approved). This format includes several improvements. You may use this format with all relatively recent versions of rsyslog or syslogd.