Syslog サーバーを docker-compose の OpenObserve でたててみた

## 目的
 ネットワーク機器の検証などで多数の機器のログを纏めて見たいため

## 方針
 長時間運用を考えず、必要なときに作っていらなくなったら壊す運用

## できたもの
  これ
  
  https://github.com/jp-yen/openobserve-syslog/tree/main/syslogng-fluentd-openobserve
  
  名前は `syslog-ng` ➡ `Fluentd` ➡ `OpenObserve` とデータが流れるので並べてみた。
  その後、`Fluentd` を外して `syslog-ng` ➡ `OpenObserve` に変更しました。

## 使うに当たって変更が必要な箇所
 OpenObserv へブラウザからログインするための e-mail addr, password
 を設定してください。
 また、fluentd が OpenObserv ログを投げるときにもその email-addr, password
 を使いますので fluentd.conf にも同じものを設定してください。
 
openobserve/.env の以下の部分
```bash:.env
ZO_ROOT_USER_EMAIL=root@root.root  👈
ZO_ROOT_USER_PASSWORD=root         👈
```

fluentd/conf/fluent.conf の以下の部分
```config:fluent.conf
  <auth>
    method basic
    username root@root.root    👈
    password root              👈
  </auth>
```

Fluentd を経由せず OpenObserve にデータを投げるときは
syslog-ng/conf/syslog-ng.conf の以下の部分
```config:syslog-ng.conf
destination d_openobserve {
  openobserve-log(
    url("http://openobserve")
    port(5080)
    stream("syslog-ng")
    user("root@root.root")     👈
    password("root")           👈
```
見ての通り、syslog-ng から OpenObserve へ投げるプリセットが用意されているので、syslog だけで済むのなら Fluentd は要らなかったかもしれない。

## 起動方法
 docker-compose.yml のあるディレクトリで `docker compose up -d` で
 コンテナをダウンロードし、起動します。
停止は同じディレクトリで`docker compose down`。これでコンテナも削除されます。

## データの流れ
```mermaid
graph TB
  A("ネットワーク機器や
  サーバなど")-->|"
  514/udp, 514/tcp - syslog"| S[[syslog-ng]]

subgraph ".  docker-compose"
  S-->|5140/udp - syslog| F[[fluentd]]
  
  F-->|5080/tcp - json| O[(OpenObserv)]
end

  B(ブラウザ) -->|"5080/tcp - http"| O
```

ログを見るにはブラウザで docker が動いている機械の 5080 番ポートへ
アクセスしてください。
ユーザ名とパスワードは
openobserve/.env と fluentd/conf/fluent.conf で書き換えたものです

## 使っている永続ボリューム
一部、コンテナからホストへデータやログを書き込んでいます。そのため、コンテナを再起動してもデータは消えませんが、手動で消さない限り残り続けてしまいます。

1. syslog-ng
起動すると syslog-ng のログが `syslog-ng/conf/log/current` に吐かれます。`syslog-ng.conf` の設定ミス確認などに使えるため残していますが、不要であれば
ボリュームの設定部分
```
    volumes:
      - ./syslog-ng/conf/:/config/
```
を
```
    volumes:
      - ./syslog-ng/conf/syslog-ng.conf:/config/syslog-ng.conf
```
等に変更してください。
長期稼働させるとログが膨らむ可能性がありますので注意。

2. OpenObserve
OpenObserve のデータも `openobserve/data/` 以下に保存されます。
使い終わったら消しましょう。

## 作ってみて
実際作ってみたら、ログが出て表示まで10秒～1分以上かかり、順番も入れ替わってしまうためリアルタイムでの確認用途には向いていないことがわかりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/2d4cee18-8009-60f0-dd31-565c475f3a10.png)
メッセージ部分がメッセージを生成した時刻、タイムスタンプはどこか分からないけど、どこかのアプリケーションで受信した時刻。

syslog-ng.conf を↓のように追加して直接ファイルを吐かせ、tail -f で見た方がずっと良い。
```config:
destination d_test {            # 👈 以下 3行追加
  file("/config/log/test.log"); # 👈
};                              # 👈

log {
  source(s_tcp);
  source(s_udp);
  source(s_internal);
  destination(d_fluentd);
  destination(d_test);          # 👈 追加
};
```
もう少し高速化の方法はないものか。
OpenObserve は速度よりも圧縮を書けて大量のログを蓄積できるのが売りなので用途が違うんでしょうね。

うちの部署では 3CDaemon を使ってる人も居るレベルなので職場でこれを広めるのは「遅い」、「取り回しが悪い」と、無理だろうな。...(せめて TFTPD64 にして欲しい)


## どうも反映が遅いので
fluentd を経由せず syslog-ng から直接 OpenObserve へ投げてみる。 
```mermaid
graph TB
  A("ネットワーク機器や
  サーバなど")-->|"
  514/udp, 514/tcp - syslog"| S[[syslog-ng]]

subgraph "docker-compose"
  
  S-->|5140/tcp - syslog| F[[fluentd]]
  
  F-->|"5080/tcp - json
  stream : default"| O[(OpenObserv)]
  S-->|"5080/tcp - json
  stream : syslog-ng"| O[(OpenObserv)]
end

  B(ブラウザ) -->|"5080/tcp - http"| O
```
ルート1 : 機器 → syslog-ng → Fluentd → OpenObserv (ストリーム : default)
ルート2 : 機器 → syslog-ng → OpenObserv (ストリーム : syslog-ng)

↓この設定時点のハッシュ

https://github.com/jp-yen/openobserve-syslog/tree/c89605f9597173d925e1ceb0ec894eda2fe8125c/syslogng-fluentd-openobserve

それぞれのスクリーンショット
Fluentd 経由の場合、メッセージ内の時刻と OpenObserve のタイムスタンプが 20分ぐらいずれている。➡ 20分前のログが表示される。 (1日経つと 2時間ぐらいずれる)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/89cf5d17-0365-e017-ad39-3ff892ba6389.png)

syslog-ng から直接 OpenObserve へ送信した場合、タイムスタンプがほぼ同じで表示もそれほど遅れない。(1日経っても 3秒ぐらい)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/fa50dc08-61c3-5788-9b08-9a7d99224c72.png)

そして、Fluentd 経由だとログの件数が少ない。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/0df69020-6528-7f60-2b23-3b233d4754b7.png)

その後、1日ほど経過し 3時間近くずれてました😖
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/c8b805d0-f140-75db-1029-5cfc8e644bf6.png)

Fluentd って難しいですね。

その後の Flentd 経由のログ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/fb42176c-69bb-18da-d2a3-43da5c9a09ae.png)
1日以上遅れ、長時間バッファリングされるため順番もバラバラ。何が悪いんでしょうねぇ。

その後の syslog-ng 直送のログ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/ac767d52-a544-495d-3af1-e7517f107d7e.png)
タイムスタンプはメッセージを読み取ったものという気もするが、発生から表示までの遅延は数秒程度。


## めも
特定の文字列を除外する検索方法。(SQL)
FROM "default" は実際のストリーム名を指定してください。
```
SELECT * FROM "default" where NOT (match_all('除外したい文字列')) ORDER BY _timestamp DESC
```