windowsにて、特定のファイルパス以下にある、csvファイルの作成日時と現在時刻を比較して、5分以上開きがあるとアラート検知するようにしたい
コミュニティーの皆様
お世話になります。
TT2018と申します。
お手数おかけしますが、ご教授の程よろしくお願いいたします。
【実施環境】
zabbix Server 3.4.7
OS red hat（バージョンは分かりません）
zabbix agent 3.4.7
OS windows Server 2016
【実施したいこと】
windowsの特定のフォルダに、1分毎にlog_yyyymmddhhmmss.csv（例：log_20180819154544.csv）のログが生成されます。
logファイルの数は、時間経過と共にフォルダの中で増えてゆきます。
作成日時が最も新しいlogファイルと現在時刻を比較して、
5分以上開きがあると、アラート検知するためには、どのような設定が必要でしょうか。
※
特定のフォルダ C:\Users\test\AppData\Roaming\test\log
【補足情報】
外部サイトで、今回やりたいことのやり方と思われる情報を見つけ、実施しました。
http://q.hatena.ne.jp/1506047625
しかし、何かしらの不備があるため、実施出来ておりません。
現在時刻とlogに開きがなくても下記のようなメッセージを検知します。
==================
1. test ログ監視 (Trade Production:logrt["C:\Users\test\AppData\Roaming\test\log*",,SHIFT_JIS,,,,]): *UNKNOWN*
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
==================
【現在設定】
『アイテム』
タイプ Zabbixエージェント（アクティブ）
キー logrt["C:\Users\test\AppData\Roaming\test\log*",,SHIFT_JIS,,,,]
データ型 ログ
更新間隔 60s
ヒストリ保存期間 90d
ログの時間の形式 空白
アプリケーションの作成 空白
アプリケーション なし
『トリガー』
条件式 {hostPR:logrt["C:\Users\test\AppData\Roaming\test\log*",,SHIFT_JIS,,,,].nodata(300)}=1
yk_taiko - 投稿数: 184
現在のアイテムの設定では
フォルダ「C:\Users\test\AppData\Roaming\test」の中の
「log」が付くファイル名を監視する内容となっています。
フォルダが「C:\Users\test\AppData\Roaming\test\log」ということは、
実際のファイルパスは「C:\Users\test\AppData\Roaming\test\log\log_yyyymmddhhmmss.csv」
でしょうか。
そうであるなら、アイテムは
logrt["C:\Users\test\AppData\Roaming\test\log\^log_.*",,SHIFT_JIS,,,,]
となります。
※ファイル名が「log_」で始まるものに絞る為、「^」を付けました。付けない場合は途中に含むもの(abclog_ とか)も対象となります。
また、正規表現では「*」はワイルドカードではありません。「.*」がワイルドカードとなります。
尚、アイテムキー"logrt" とトリガー関数"nodata" で確認できるのは、ログファイルのデータ(中身)が
規定時間の間に存在するかどうかとなり、ファイル名自体の確認は行いませんが、問題ないでしょうか。
純粋にファイル名の確認を行いたい場合、Zabbix の標準アイテムではなく、
Userparameter などを使用して最新のファイル名(の時間)を抽出し、
トリガー関数の date や time と付け合せる必要があると思います。
TT2018 - 投稿数: 10
yk_taiko様
ご丁寧にありがとうございます。
教養がない人間にも大変分かりやすかったです。
記述方法の間違い、訂正して対応いたします。
＞＞ファイル名自体の確認は行いませんが、問題ないでしょうか。
⇒問題ありません。
最新のログファイルの作成日時と現在時刻の差で監視したいので。
特定アプリの一部機能が使用出来るかログファイルの作成状況から判断するために監視を行いたいと考えております。
ご教授いただいた内容しっかり理解して動作確認を実施いたします。
TT2018 - 投稿数: 10
↓の設定で、ログファイル、「log_yyyymmddhhmmss.csv」の作成日時と現在時刻の開きが5分未満であっても、
メッセージを検知しました。
『アイテム』
logrt["C:\Users\test\AppData\Roaming\test\log\log_.*",,SHIFT_JIS,,,,]
※「^」は意図的に外しております。
フォルダの中には、「log_ユニークな番号_yyyymmddhhmmss.csv」のデータのみが格納されます。
『トリガー』
{hostPR:logrt["C:\Users\test\AppData\Roaming\test\log\^log_.*",,SHIFT_JIS,,,,].nodata(300)}=1
『メッセージ』
==================
1. test ログ監視 (Trade Production:logrt["C:\Users\test\AppData\Roaming\test\log\^log_.*",,SHIFT_JIS,,,,]): *UNKNOWN*
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
==================
【ご相談】
どこの認識を改めれば、最新のログファイル作成時刻とOSの現在時刻との開きでチェック可能でしょうか。
※
上記設定で、フォルダ直下にある、「log_」という言葉を含むファイルを監視出来る理解でいます。
また、nodata(300)}=1とすることで、
最新の「log_」ファイルの中にあるデータが、いつ記述されたか作成時刻とOSの現在時刻の開きが300秒以内かチェック出来る理解でいます。
尚、「log_」ファイルの中には、幾つかの日本語文字が含まれます。（番号、ペアなど）
お手数おかけしますが、よろしくお願いいたします。
yk_taiko - 投稿数: 184
トリガーには”log_”の前に「^」が入ってますが、同一アイテムに紐付いた設定でしょうか。
また、Zabbix 上にデータは取り込んでいますでしょうか。
最新データのヒストリにデータがあるかご確認ください。
後、zabbix_server.log や監視対象の zabbix_agentd.log、アイテムの設定画面にエラーか何か出ていませんでしょうか。
※nodataですが、正確には「作成された時間」ではなく、「Zabbix で該当のログを取り込んだ時間(ヒストリのタイムスタンプ)」と「Zabbixサーバの現在時刻」を比較します。
karna - 投稿数: 60
まず、ログ監視自体ができているか(ヒストリが記録されているか)どうかというのが前提になりますが、どうでしょうか?
メッセージのマクロが標準のままであるとすると、ログ取得ができていないように思われます。
(監視ができていない。→ヒストリ（データ)がない。→トリガーに合致する。→アラート)
ログ監視ができているのであれば、1行目の ”*UNKNOWN*” の部分(マクロの{ITEM.VALUE1})に何かしら文字列が入るはずです。
(2行目、3行目は*UNKNOWN*で問題ありません)
参考(アクション、デフォルトのメッセージから抜粋)：
1. {ITEM.NAME1} ({HOST.NAME1}:{ITEM.KEY1}): {ITEM.VALUE1}
なお、トリガーに記述する(ホスト+) キーでアイテムを指定しますので、アイテムのほうで ＾を外すのであれば、合わせなければいけません。
追記：
logrt[] の場合、対象ファイル、フォルダ(Windowsの場合)がなくても、取得不可アイテムにはならないようです。
https://www.zabbix.com/documentation/3.4/manual/config/notifications/act...
TT2018 - 投稿数: 10
yk_taiko様、karna様
ご教授ありがとうございます。
アドバイスを基に確認させていただいた所、アイテムのステータスが「取得不可」になっていました。
表示されているメッセージを基に、あれこれ調べていますが、イマイチ理解出来ていません。
確認結果
==================
＞トリガーには”log_”の前に「^」が入ってますが、同一アイテムに紐付いた設定でしょうか。
⇒すみません。紐付いておりませんでした。
同一アイテムに紐付いた設定にして試しましたが同様にメッセージ検知しました。
＞最新データのヒストリにデータがあるかご確認ください。
⇒ヒストリカルデータはありませんでした。
＞後、zabbix_server.log や監視対象の zabbix_agentd.log、アイテムの設定画面にエラーか何か出ていませんでしょうか。
⇒アイテムの設定画面で、該当アイテムのステータスが「取得不可」になっていました。
「Invalid second parameter.」というメッセージがポップで表示されていました。
⇒zabbix_agentd.logは、直近は下記のようになっていました。
==================
2196:20180818:185359.211 Zabbix Agent stopped. Zabbix 3.4.6 (revision 76819).
2488:20180818:185433.925 Starting Zabbix Agent [hostPR]. Zabbix 3.4.6 (revision 76819).
2488:20180818:185433.925 **** Enabled features ****
2488:20180818:185433.925 IPv6 support: YES
2488:20180818:185433.925 TLS support: NO
2488:20180818:185433.925 **************************
2488:20180818:185433.925 using configuration file: C:\zabbix_kanshi\zabbix_agentd.conf
2488:20180818:185433.925 agent #0 started [main process]
2532:20180818:185433.925 agent #3 started [listener #2]
2524:20180818:185433.925 agent #1 started [collector]
2536:20180818:185433.925 agent #4 started [listener #3]
2528:20180818:185433.940 agent #2 started [listener #1]
==================
⇒zabbix_server.logは諸事情により見れておりません。
＞まず、ログ監視自体ができているか(ヒストリが記録されているか)どうかというのが前提になりますが、どうでしょうか?
⇒ヒストリに記録されていませんでした。
監視データ
最新データ
==================
yk_taiko - 投稿数: 184
アイテムキーの引数で怒られているようですね...
試しにアイテムを複製し、エンコードより後ろの「,」を削除して登録してみてください。
取得不可になったら、もう一度エージェントのログを見てみてください。
(同じかもしれませんが...)
karna - 投稿数: 60
監視ができていないと意味がないので、トリガーはひとまず置いておきましょう。
zabbix_agentd.log にアクティブチェックのログがないのが気になります。
アクティブモードのエージェントが起動すると、
～ agent #n started [active checks #1]
のようなログが、ほかのagentプロセスとほぼ同時に記録されます。
zabbix_agentd.log と zabbix_agentd.conf を再度確認してみてください。
TT2018 - 投稿数: 10
yk_taiko様、karna様
お世話になっております。
【現在状況】
zabbix_agentd.confもしくは、zabbix_server.confに何かしらの不備がありそうという所まで分かりました。
現在、各種サイトを参照しながら、値が妥当か確認を行う予定です。
【途中状況】
・logrtの監視を行いたいサーバーに設置している「zabbix_agentd.conf」を確認。
⇒server=に#がついていたので＃を外しました。
Server=■■（zabbixサーバーのIPアドレス 例：11.222.333.444）
ListenIP=0.0.0.0
ServerActive=■■（zabbixサーバーのIPアドレス 例：11.222.333.444）
・zabbix_agentd.conf変更後に、Zabbix_Agentのサービス再起動を実施。
⇒「zabbix_agentd.log」に下記メッセージを確認
active check configuration update from [■■.■■■.■■■.■■■:10051] started to fail (cannot connect to [[■■.■■■.■■■.■■■]:10051]: (null))
・zabbix UIの管理画面を参照すると、
zabbix severに設置しているagentが無効状態になっていることが関係ないか確認する予定。
（添付画像が該当箇所の抜粋になります）
・zabbix serverのアクセス方法、データ退避方法が分かったので、
confの設定に不備がないか確認を行う予定。
yk_taiko - 投稿数: 184
ログ監視は「ServerActive」の設定を使用しますので、Server が設定されていなくても動作します。
また、「zabbix サーバ上のzabbix エージェント」の起動有無は、他のサーバのデータ取得に関係ありません。
zabix_agentd.conf に出力されているメッセージは、「監視対象→Zabbixサーバの10051ポートに接続できない」旨のログで、これが原因です。
監視対象とZabbixサーバ間のFW設定や、IPが合っているかなど、ネットワーク周りの設定を確認してみてください。
TT2018 - 投稿数: 10
yk_taiko様、karna様
お世話になっております。
お陰様で、該当アイテムのステータスが「取得不可」から「有効」になりました。
ありがとうございます。
所得不可の原因は２つありました。
アドバイスいただいた通りのものでした。
①Zabbixサーバのポートが解放されていなかった。
⇒対処としてポート解放を実行した。
==================
firewall-cmd --add-port=10051/tcp --zone=public --permanent
systemctl restart firewalld
firewall-cmd --add-port=10050/tcp --zone=public --permanent
systemctl restart firewalld
==================
※下記URLの「３．firewalldの設定」参照
https://qiita.com/atanaka7/items/294a639effdb804cfdaa
②「zabbix_agentd.conf」の「Hostname=」に不備があった。
⇒severの名前を設定していた。
agentの名前を設定した。
==================
・Zabbix-Agentの設定
Server = Zabbixサーバ or ZabbixProxy のIPアドレス
hostname = エージェントをインストールしたホストのホスト名
ServerActive = Zabbixサーバ or ZabbixProxy のIPアドレス
==================
※下記URLの「Zabbix-Agentの登録の定義」参照
https://qiita.com/gitya107/items/b891af8c5d796a2329e7
設定後にZabbix_Agentのサービス再起動を実施。
下記ログメッセージを確認。
==================
5608:20180828:025329.531 Zabbix Agent stopped. Zabbix 3.4.6 (revision 76819).
6800:20180828:025330.609 Starting Zabbix Agent [■■agentのコンピューター名■■]. Zabbix 3.4.6 (revision 76819).
6800:20180828:025330.609 **** Enabled features ****
6800:20180828:025330.609 IPv6 support: YES
6800:20180828:025330.609 TLS support: NO
6800:20180828:025330.609 **************************
6800:20180828:025330.609 using configuration file: C:\■■\zabbix_agentd.conf
6800:20180828:025330.609 agent #0 started [main process]
6624:20180828:025330.609 agent #3 started [listener #2]
1204:20180828:025330.609 agent #2 started [listener #1]
6564:20180828:025330.625 agent #5 started [active checks #1]
5752:20180828:025330.625 agent #1 started [collector]
4700:20180828:025330.625 agent #4 started [listener #3]
==================
TT2018 - 投稿数: 10
該当アイテムが有効になった結果、下記のようなメッセージがメールで通知されてきました。
問題点として、現在時刻と、フォルダの中にある最新ログの作成日付を比較して、
300秒以上（5分以上）開きがあると異常として検知したいのですが、
5分異常（2日程開きがある）開きがあるのに、異常として検知されませんでした。
何か使い方がいけなかったということでしょうか。
==================
Trigger: test_■■■.■■.■■.■■■
Trigger status: OK
Trigger severity: High
Trigger URL:
Item values:
1. test ログ監視 (host:logrt["C:\Users\test\AppData\Roaming\test\log\log.*",,SHIFT_JIS]): ※logの中に含まれる日本語の項目名が複数列挙される。
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
==================
※今回通知された内容とlogを比較した限りでは、監視先のパス、ログの中に含まれる項目名に不備はありませんでした。
==================
アイテム
logrt["C:\Users\test\AppData\Roaming\test\log\log.*",,SHIFT_JIS]
トリガー
{hostPR:logrt["C:\Users\test\AppData\Roaming\test\log\log.*",,SHIFT_JIS].nodata(300)}=1
==================
yk_taiko - 投稿数: 184
nodata は、「Zabbixが取り込んだ時刻」が判定に使用されることになります。
"現在時刻" と "Zabbixが読み込んでいるログの時刻" に差があるうちは、想定されている挙動にはなりません。
一点確認を忘れてましたが、該当ファイルの出力量はどの程度でしょうか。
デフォルト状態では、毎秒20～80行のログを読み込みます。
量が多いようであれば zabbix_agentd.conf の MaxLinesPerSecond (またはアイテムのmaxlines) の変更を検討ください。
https://www.zabbix.com/documentation/3.4/manual/appendix/config/zabbix_a...
TT2018 - 投稿数: 10
yk_taiko様
お世話になっております。
該当ファイルの出力量は、多くても1ファイルあたり10行程度になります。
データサイズで言いますと、1kb～3kb程度のデータサイズになります。
また、お陰様で無事に「Zabbixが取り込んだ時刻」を用いて、
当初やりたかった監視が行えることを確認出来ました。
（前回どうして2日前のログを取り込んでＯＫが出たのか原因は分かっておりませんが・・・。）
新規のログが生成されると、ＯＫが出て。
意図的にログが出力されないようにすると、5分後以降にアラートメッセージを検知する。
以上の挙動を確認出来ました。
また、お手数ですが、最後に今回設定したアイテムとトリガーの挙動について再確認させてください。
下記の理解であっておりますでしょうか？
『アイテム』
logrt
正規表現を用いて、特定ワードを含んだファイルを監視する。（監視条件に合致したファイルを監視する）
今回なら「log.*」。「log」という名前を含むファイルを監視する。
http://unam.hatenadiary.jp/entry/2018/02/15/220132
『トリガー』
nodata
zabbixがアイテムを取り込んだ時刻をチェックする。（今回の場合ならlogrt)
今回なら300秒(5分）以上開きがあると異常として通知する。
ttps://www.zabbix.com/documentation/2.2/jp/manual/appendix/triggers/functions
『不明点』
・zabbixの監視は、監視対象がいつ新規作成されたのかでチェックしているのではなく、
監視対象を発見した時刻を用いて監視を行っているということでしょうか。
・監視対象のフォルダに、監視条件に合致するファイルが複数存在する場合、
どうやって、新規作成されたファイルなのか、既存のファイルなのか判断しているのでしょうか。
※
何かしらの方法で、監視を行ったファイル名を保持して新規か既知か判断しているということでしょうか。
監視条件に合致する見慣れないファイル（新規ファイル）を検知したら、zabbixがアイテムを取り込んだ時刻が更新されて、
トリガー条件で異常ないかチェックする。
yk_taiko - 投稿数: 184
>・zabbixの監視は、監視対象がいつ新規作成されたのかでチェックしているのではなく、
> 監視対象を発見した時刻を用いて監視を行っているということでしょうか。
ご認識の通り、Zabbixとして該当のログを取り込んだ時刻が判定基準に使用されます。
尚、正確に言うと「該当のファイルを発見した時刻」ではなく、「該当ファイル内の合致する行を読み込んだ時刻」です。
>・監視対象のフォルダに、監視条件に合致するファイルが複数存在する場合、
> どうやって、新規作成されたファイルなのか、既存のファイルなのか判断しているのでしょうか。
Zabbixのログ監視では、最終更新時刻、ログファイルサイズ、inode番号やファイルインデックス等のファイル識別子を使用してログファイルの判断を行っています。
詳細な情報は、マニュアルのログ監視のページの下部(Important notes)に記載されています。
- https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/l...
今回、2日前でもokと出たのは、
メールが送付される少し前にアイテムが正常に動き出し、
2日前の該当ログをZabbixが読み込み、判定を行ったからだと思います。
karna - 投稿数: 60
>・監視対象のフォルダに、監視条件に合致するファイルが複数存在する場合、
> どうやって、新規作成されたファイルなのか、既存のファイルなのか判断しているのでしょうか。
ざっくり言うと、
”前回、ログ取得した時間(t)” と、”前回読んだバイト数(B)” を記録しておいて、
監視対象ファイルの中で、更新タイムスタンプがより新しいものをピックアップ&ソートして、
前回見たログの、”読んだバイト数” 以降のものを順次取り込む。という処理になります。
ログローテーションをターゲットにしているので、前回のファイル名は考慮されません。
(ローテーション時にナンバリングされたり、日付が付与されたりして変更されるのが一般的なので)
ex.
log_a(古い)、log_b(新規)、log_c(前回 Bバイトまで取得) というファイルがあったとして、タイムスタンプが ahttp://kodai74.blogspot.com/2012/02/zabbixloglogrt.html
Ver.1.8と、古い時点の情報ですが、概要は変わっていないはずです。
正確には yk_taiko さんのおっしゃるように、マニュアルでご確認ください。
yk_taiko - 投稿数: 184
>ログローテーションをターゲットにしているので、前回のファイル名は考慮されません。
>(ローテーション時にナンバリングされたり、日付が付与されたりして変更されるのが一般的なので)
一応補足です。
2.2 や2.0 の時代に、ファイルに振られる番号をエージェントで保持して考慮するようになっています。
以下マニュアルの「重要な注意事項」の1つ目に書いてあります。
https://www.zabbix.com/documentation/2.2/jp/manual/config/items/itemtype...
TT2018 - 投稿数: 10
yk_taiko様、karna様
ご丁寧にありがとうございます。
マニュアルを拝見させていただきました。
お陰様でやりたい監視方法と、どういった挙動で成り立っているのか理解出来ました。
今回の方法で監視を行いたい箇所については、
同様に定期的にログファイルを定期的に生成してもらい監視を行える形にしたいと思います。
繰り返しになりますが、温かいご助言ありがとうございます。
TT2018 - 投稿数: 10
本トピックのまとめ
【やりたいこと】
windowsの特定のフォルダに、1分毎にlog_yyyymmddhhmmss.csv（例：log_20180819154544.csv）のログが生成される。
logファイルの数は、時間経過と共にフォルダの中で増えてゆく。
作成日時が最も新しいlogファイルと現在時刻を比較して、
5分以上開きがあると、アラート検知するようにしたい。
【実現方法】
下記、アイテム、トリガー設定を行うことで、ほぼ類似の監視可能。
logrtで正規表現で、条件に合致したファイル（アイテム）を監視可能。
監視条件（トリガー）は、nodataを使用。
zabbixが監視対象のファイル（アイテム）をいつ新規で取り込んだか（発見したか）の日時と、
現在時刻の差で監視を行う。
※
設定を行ってから、動作確認は暫く待つこと。
監視対象のファイルにある、過去ログが読み込まれたりするので、
最初は意図しないメッセージ通知があったりする。（条件の時間を過ぎたファイルで回復メッセージを検知したりとか）
※
監視するにあたり、誤差が数秒で問題ないなら、この方法で問題なし。
動作確認のテストを行った限りでは、極端に遅い、誤差があるということはなかった。
『アイテム』
logrt
正規表現を用いて、特定ワードを含んだファイルを監視する。（監視条件に合致したファイルを監視する）
今回なら「log.*」。「log」という名前を含むファイルを監視する。
http://unam.hatenadiary.jp/entry/2018/02/15/220132
例： logrt["C:\Users\test\AppData\Roaming\test\log\log.*",,SHIFT_JIS]
『トリガー』
nodata
zabbixがアイテムを取り込んだ時刻をチェックする。（今回の場合ならlogrt)
今回なら300秒(5分）以上開きがあると異常として通知する。
ttps://www.zabbix.com/documentation/2.2/jp/manual/appendix/triggers/functions
例： {■監視ホスト名■:logrt["C:\Users\test\AppData\Roaming\test\log\log.*",,SHIFT_JIS].nodata(300)}=1
【実行できない場合の考えられる原因】
・アイテムのステータスが「取得不可」になっている。
「監視対象→Zabbixサーバの10051ポートに接続できない」
①Zabbixサーバのポートが解放されていなかった。
⇒対処としてポート解放を実行した。
==================
firewall-cmd --add-port=10051/tcp --zone=public --permanent
systemctl restart firewalld
firewall-cmd --add-port=10050/tcp --zone=public --permanent
systemctl restart firewalld
==================
※下記URLの「３．firewalldの設定」参照
https://qiita.com/atanaka7/items/294a639effdb804cfdaa
・agent側の設定に不備がある。
②Zabbix-Agentの設定例
==================
Server = Zabbixサーバ or ZabbixProxy のIPアドレス
hostname = エージェントをインストールしたホストのホスト名
ServerActive = Zabbixサーバ or ZabbixProxy のIPアドレス
==================
※下記URLの「Zabbix-Agentの登録の定義」参照
https://qiita.com/gitya107/items/b891af8c5d796a2329e7
「参考情報」
Zabbix-Agentに不備があるかどうかは、「zabbix_agentd.log」参照。
不備がある場合
↓のメッセージがあった。
active check configuration update from [■■.■■■.■■■.■■■:10051] started to fail (cannot connect to [[■■.■■■.■■■.■■■]:10051]: (null))
正常な場合
特に異常を表すメッセージは出てこない。
==================
5608:20180828:025329.531 Zabbix Agent stopped. Zabbix 3.4.6 (revision 76819).
6800:20180828:025330.609 Starting Zabbix Agent [■■agentのコンピューター名■■]. Zabbix 3.4.6 (revision 76819).
6800:20180828:025330.609 **** Enabled features ****
6800:20180828:025330.609 IPv6 support: YES
6800:20180828:025330.609 TLS support: NO
6800:20180828:025330.609 **************************
6800:20180828:025330.609 using configuration file: C:\■■\zabbix_agentd.conf
6800:20180828:025330.609 agent #0 started [main process]
6624:20180828:025330.609 agent #3 started [listener #2]
1204:20180828:025330.609 agent #2 started [listener #1]
6564:20180828:025330.625 agent #5 started [active checks #1]
5752:20180828:025330.625 agent #1 started [collector]
4700:20180828:025330.625 agent #4 started [listener #3]
==================