📜

OpenTelemetry CollectorでSyslogを受信

2023/09/21に公開

Splunk

OpenTelemetry

tech

はじめに

もう全部Otel Collectorだけでいいんじゃないかな。

syslog receiverを検証してみたというお話です。
これまではsyslog受信のためにsyslog-ngやrsyslogなんかでsyslogサーバーを立てていた訳ですが、それも不要になっていくようです。

結論としては「UDPで大量にSyslog受信する（数万件/秒レベル）場合はおとなしくsyslog_ng、常識的な？受信量（数件から数百件/秒）だったりTCPであれば良さそう」です。

普通のログ取り込みはこちらをどうぞ。

syslog receiver

詳細はこちら。

現状で設定可能なことを簡単にまとめると：
・UDP/TCPで受信可能、証明書も使用可
・rfc3164、rfc5424のフォーマットであれば自動パースされる
・exporter先がダウンしていた場合はリトライも可能（デフォルト無効）

当然、ProcessorやExporterで様々な拡張が簡単にできます。

やってみる

rfc3164 (BSD Syslog)

RFC3164の詳細はこちら。

フォーマット：

RFC3164 format

<PRI> TIMESTAMP HOSTNAME TAG: MSG

サンプル：

RFC3164 sample

<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8

Otel Collectorで受信設定しましょう。
UDPで10514番ポートで待ち受けてみます。TCPの場合はudpをtcpに変えるだけです。
exporterはお好きなログバックエンドにしてください。
これだけでSyslog受信できるので楽ですね。

agent_config.yaml

receivers:
  syslog/rfc3164_test:
    udp:
      listen_address: "0.0.0.0:10514"
    protocol: rfc3164
    location: UTC

service:
  pipelines:
    logs:
      receivers: [syslog/rfc3164_test]
      processors: []
      exporters: [<log_backend>]

試しに別ホストから送ってみます。

echo -n "<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8" | nc -u -w1 <IP ADDRESS> 10514

今回はSplunkに送ってみました。確認してみると：

素晴らしいですね。
Syslogメッセージが適切にパースされてattributeとして付与されています。
Severityもちゃんと計算してcritと表記してくれていますね。
Processorではresourcedetectionも入れ込んでいたので、このホストが稼働しているEC2の情報も自動で拾ってくれています。

rfc5424 (IETF Syslog)

RFC5424の詳細はこちら。

フォーマット：
STRUCTURED-DATA（構造化データ）はオプションです。

format

<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG

サンプル：

構造化データなしsample

<34>1 2023-09-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8

構造化データありsample

<165>1 2023-09-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMAn application event log entry...

Otel Collectorで受信設定しましょう。
UDPで20514番ポートで待ち受けてみます。

agent_config.yaml

receivers:
  syslog/rfc5424_test:
    udp:
      listen_address: "0.0.0.0:20514"
    protocol: rfc5424

service:
  pipelines:
    logs:
      receivers: [syslog/rfc5424_test]
      processors: []
      exporters: [<log_backend>]

試しに別ホストから送ってみます。

echo -n "<34>1 2023-09-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8" | nc -u -w1 <IP_ADDRESS> 20514

echo -n "<165>1 2023-09-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut=\"3\" eventSource=\"Application\" eventID=\"1011\"] BOMAn application event log entry..." | nc -u -w1 <IP_ADDRESS> 20514

Splunkで確認してみると：

構造化データなし

問題無くSyslogメッセージが適切にパースされてattributeとして付与されています。

構造化データあり

※構造化データの中身もパースしていますが、これはSplunkが自動で行っていることで、syslog receiverとしてはstructured_data (map[exampleSDID@32473:map[eventID:1011 eventSource:Application iut:3]])の抽出まで。

どれぐらいさばける？

環境

vCPU 2, 8 GiB RAMのUbuntu 20.04
Pythonで大量送信（UDP）

結果

1,000件/秒は取りこぼしなくいけました。

なお、これは送信ごとに1/1,000秒をWaitをかけています。
全力投球した場合は0.02秒で1,000件（50,000件/秒）送信し、その場合は3/10ほど取りこぼしが発生しました。
syslog-ngでは全件取得できたのでOS側の問題ではなさそうです。

TCPの場合は問題なく全件取得できます。
全力投球して約25,000件/秒取り込めSplunkへの送信も完了しました。

その他

負荷分散・フェイルオーバー

Otel Collector自体には負荷分散・フェイルオーバーの仕組みはないので、どうしても必要な場合は前段にロードバランサーを仕掛ける必要があります。

ログのメトリクス化

ログ自体の分析までは不要で、エラーとか特定キーワードを含むログ件数だけをメトリクスで取りたいんだ！と言う場合、なんとOtel Collectorだとそれもできちゃいます。
詳細はこちらの記事を参照。

まとめ

ちょっとしたSyslogも取りたい、だけどSyslogサーバー立てるのだるい、な場合はOtel Collectorでいけちゃいます。

もう全部Otel Collectorだけでいいんじゃないかな。な世界が近づいているのではないでしょうか。