syslog とかログ基盤とか Fluentd / Fluent Bit とか調べる
nukopysyslog とは
syslogはIPネットワーク上でログメッセージを転送する標準規格でありクライアント/サーバ型プロトコル。syslog送信側（Ciscoルータなど）はsyslog受信側（Linuxサーバなど）にログ情報をテキストメッセージで送信します。syslogメッセージはUDPまたはTCPポート番号の514を使用してsyslogサーバに送信されます。
引用元：ネットワークエンジニアとして - syslog とは
CiscoルータやCatalystスイッチなどの「デバイス上の動作状況の記録」をログと言いますが、このログを取得することで、そのデバイスで何が起きているのかを把握できます。Cisco機器などのネットワーク機器はsyslogプロトコルにより、Ciscoデバイスで発生する各種イベントをログとしてsyslogサーバに送信できます。
いわゆる「syslog サーバを立てる」ってのはこの syslog 受信側のサーバを立ててログを収集することを言ってるのね。
そもそも「ログ」とは
ログは「タイムスタンプが記録された、時間の経過とともに起こったイベントの記録」のことを表す。
引用元：Amazon CloudWatchの概要と基本 AWS Black Belt Online Seminar
この意味では、手書きの日記も立派なログ。システム開発の文脈では、「時間の経過とともに "システム内に起こった" イベントの記録」を意味する。一般的には、テキストファイルやデータベースに保存することが多い。
「ログ」は何に使うか？
「システムで何が起こっているか」というシステムの状態、振る舞いを解析するのに使用する。現在のシステムの挙動やメトリクスを参考に⾒るべきログを特定し、該当時間帯のアプリケーションのログを確認することで何が起こっているか把握する。
ログ基盤の構成の主流
自分が Fluentd / Fluent Bit というかログ基盤の必要性を知ったのは働き始めてシステム運用し始めて監視の必要性を知ってから。
下記の 2020/05 の Twitter での投稿では既に Fluentd が主流になっているみたいなので、2017 年くらいからはログ基盤の重要性とか構築のためのツールが整い始めてたのかな。
ちなみにここ数年はlogrotateはログでサーバーのディスクが溢れないように定期削除していくだけの役割だからファイル名の日付とかどうでもよくて、リアルタイムに出力されているログをfluentd使って別の場所でログ分析&バックアップ&永続化できるようにするのが主流になってるよね
nukopyClaude 3 Opus 君に聞いてみる。
Q. syslog ってなんですか？
syslog は「ログメッセージを収集、格納、転送するための標準的なプロトコルおよびサービス」なんだね。ログを扱うためのプロトコルってことね。
syslog は、様々なシステムプロセスやアプリケーションからのログメッセージを収集、格納、転送するための標準的なプロトコルおよびサービスです。Unix 系のオペレーティングシステム（Linux、macOS など）で広く使用されています。
syslog の主な役割は以下の通りです：
- ログの生成
システム上の様々なプロセスやアプリケーションが、syslog を使ってログメッセージを生成します。これらのメッセージには、通常、イベントの重要度（優先度）とファシリティ（メッセージの発信元を示すカテゴリ）が含まれます。- ログの収集
syslog デーモン（syslogd, rsyslogd, syslog-ng など）が、システム上の様々なソースからログメッセージを収集します。- ログの格納
収集されたログメッセージは、通常、ローカルのファイルシステム上のログファイルに格納されます。ログファイルは通常、ファシリティや優先度に基づいて分割されます。- ログの転送
syslog デーモンは、収集したログメッセージを、ネットワーク上の他のホスト（ログサーバなど）に転送することもできます。これにより、複数のシステムからのログを中央のサーバで一元管理することができます。syslog は、システムの状態監視、問題の診断、セキュリティイベントの検出などに広く使用されています。多くのログ管理システムやSIEMシステムが、syslog を入力ソースの一つとしてサポートしています。
ただし、従来の syslog プロトコルにはセキュリティ面や信頼性の面で一部課題があったため、最近では syslog よりも高機能な syslog-ng や rsyslog が使われることも多くなっています。また、systemd の導入によって、一部のLinuxディストリビューションでは従来の syslog が systemd-journald に置き換えられつつあります。
syslog は古いプロトコルで、最近はあまり使われてないのかな。どうなんだろ。
nukopyQ. Linux ディストリビューションは systemd の導入前後でどのように変わりましたか？
systemd の導入は、Linux ディストリビューションに大きな変化をもたらしました。主な変化は以下の通りです：
- init システムの置き換え
従来の System V init システムが systemd に置き換えられました。systemd は、より高速なブート処理、より豊富な機能、より良好な並列処理などを提供します。- サービス管理の改善
systemd は、サービスの起動、停止、再起動などを簡単かつ効率的に管理するためのコマンド（systemctl）とユニットファイルの仕組みを提供します。これにより、サービス管理が大幅に改善さ>れました。- cgroups の積極的な活用
systemd は Linux カーネルの cgroups（コントロールグループ）機能を積極的に活用し、リソース管理や分離を行います。これにより、システムの安定性と保護が向上しました。- ログ管理の変更
従来の syslog の代わりに systemd-journald が導入されました。journald は構造化されたバイナリ形式でログを保存し、システム全体のログを一元的に管理します。ただし、必要に応じて従来の syslog にログを転送することもできます。- ネットワーク管理の変更
systemd-networkd というネットワーク管理デーモンが導入され、ネットワークデバイスとその設定をシステム全体で一元管理できるようになりました。- その他のシステムコンポーネントの統合
systemd は、時刻同期（systemd-timesyncd）、ログインユーザーの管理（systemd-logind）、DNSの解決（systemd-resolved）など、様々なシステムコンポーネントを統合しました。これらの変更は、Linux システムの管理を簡素化し、効率を向上させることを目的としています。ただし、一方で systemd の複雑性やシステムへの深い統合に対して批判もあります。
systemd は現在、ほとんどの主要な Linux ディストリビューション（Red Hat Enterprise Linux, CentOS, Fedora, Ubuntu, Debian など）で採用されています。ただし、Gentoo Linux のように systemd を必須としないディストリビューションもあります。
今はサービス管理のためのソフトウェアとして systemd が主流なんだね。また、システムログの管理には syslog → systemd-jornald が使われる。
nukopy補足：systemd でのサービスの定義方法
1 つのサービスは 1 つの Unit ファイルで定義される。Unit ファイル内ではサービスの起動、停止、再起動、ログ出力の設定などを行う。Unit ファイルの例を示す。Unit ファイルの項目については下記を参考。
[Unit]
Description=sample-web-server
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/forever start /var/opt/nukopy/server.js
ExecStop=/usr/local/bin/forever stop /var/opt/nukopy/server.js
Restart=always
StandardOutput=append:/var/log/nukopy/server.log
StandardError=append:/var/log/nukopy/server.log
[Install]
WantedBy=multi-user.target
syslog - Facility と Severity
syslog におけるシステムログには「Facility」と「Severity」という考え方がある。
Facility：ログの種別
Facilityとは、正確に言えば「ログの種別」のことであり、分かりやすくいえばメッセージの「出力元」のことです。ファシリティには以下の種類があり、ファシリティを使用することでメッセージの出力元に応じてログの出力先を制御できます。Linuxでは「 * 」を使用することで全ファシリティを選択できます。
Severity：ログの重要度
Severityとは、メッセージの優先度を表します。Severityはemergが最も高く、debugが最も低いことを意味します。指定したSeverityよりもレベルが高いものが全て記憶されるので、例えばcritを 指定した場合、crit、alert、emergレベルのログが記録されます。特定のSeverityを指定したい場合、Severityの前に = をつけます。noneは例外指定したファシリティのログを除外する役割を持ちます。
例：シスコ製のネットワーク機器における Severity の定義
上述の標準仕様に従いシスコデバイスではSYSLOGのプライオリティを以下のように定義しています。
Facility＝ログを生成するサービス、Severity＝ログレベルと考えればアプリケーションのログと考え方は同じ。
nukopyQ. syslog の対象ってアプリケーションのログも含まれるの？最近のログ基盤だとアプリケーションのログはコンテナから直接 Fluentd で転送してもらうか、ローカルでログを app.log のようなテキストファイルとして吐き出して Fluentd で転送してもらうかだと思うんだけど。アプリケーションのログを使用する文脈で syslog を見たことない。OS のログを見る文脈ではよく出てくるけど。
はい、おっしゃる通りです。一般的に、syslog はオペレーティングシステムやシステムプロセスのログを扱うことが多く、アプリケーションのログを扱うことは比較的少ないです。
伝統的に、多くのアプリケーションは独自のログファイルを生成し、それらのファイルは syslog とは別に管理されていました。これは、アプリケーションのログが often syslog の単純なテキストベースの形式では扱いにくい、構造化されたデータを含んでいることが多いためです。
近年、コンテナ化やマイクロサービスアーキテクチャの普及に伴い、アプリケーションのログ管理には Fluentd, Logstash, Filebeat などのより柔軟で機能が豊富なログ収集ツールが使用されることが多くなっています。これらのツールは、様々な形式のログを収集、パース、変換、転送することができ、モダンなログ基盤に適しています。
例えば、コンテナ化されたアプリケーションの場合、各コンテナの標準出力/標準エラー出力をログとして扱い、それらを直接 Fluentd 等で収集することが一般的です。また、ログファイルを出力するアプリケーションの場合、Fluentd 等でそれらのファイルを監視し、新しいログエントリを収集することができます。
一方、syslog は今でもオペレーティングシステムレベルのログ、特にインフラストラクチャコンポーネント（sshd, cron, sudo など）のログを収集するために使用されています。多くの場合、これらのコンポーネントは syslog を直接サポートしており、設定によって syslog にログを送信するように指示できます。
したがって、現代のログ基盤では、アプリケーションのログは主に Fluentd 等の柔軟なログ収集ツールで扱い、システムレベルのログは syslog で扱うというハイブリッドなアプローチが一般的だと言えます。ただし、syslog で収集されたシステムログも、最終的には Fluentd 等を経由して集中ログ管理システムに転送されることが多いです。
なるほど、ずっともやもやしていた疑問が解決。システムログとアプリケーションのログの立ち位置の違いが理解できてきた。でも結局 CloudWatch Logs とかにログを送信するなら Fluentd / Fluent Bit 使えば良さそうね。
nukopyちょっと話が逸れるけど netplan について気になったので質問。
Q. systemd-networkd について、netplan とはどう違うのですか？
systemd-networkd と netplan はどちらもシステムのネットワーク設定を管理するためのツールですが、いくつかの重要な違いがあります。
- 設定ファイルのフォーマット
- systemd-networkd は、.network, .netdev, .link などの拡張子を持つ独自の設定ファイルを使用します。これらのファイルは、systemd の一般的な構文（キー=値のペア）に従います。
- netplan は、YAML 形式の設定ファイルを使用します。これにより、より人間にとって読みやすく、理解しやすい設定が可能になります。
- 設定の適用方法
- systemd-networkd は、設定ファイルが変更されると自動的に変更を検出し適用します。
- netplan は、設定を生成するだけで、実際のネットワーク設定の適用は backend（systemd-networkd または NetworkManager）に任せます。設定を適用するには、netplan apply コマンドを実行する必要があります。
- ネットワーク管理ツールとの関係
- systemd-networkd は systemd の一部であり、systemd ベースのシステムで直接使用することができます。
- netplan は、バックエンドとして systemd-networkd または NetworkManager を使用できます。つまり、netplan は systemd-networkd の上に抽象化のレイヤーを追加していると言えます。
- 対応している Linux ディストリビューション
- systemd-networkd は、systemd を採用しているほとんどの Linux ディストリビューションで利用可能です。
- netplan は当初 Ubuntu で開発され、現在でも主に Ubuntu とその派生ディストリビューションで使用されています。
- 機能の範囲
- systemd-networkd は、基本的なネットワーク設定（インターフェイス、アドレス、ルートなど）を管理することができます。
- netplan は、systemd-networkd や NetworkManager を通じて、より高度なネットワーク設定（ボンディング、ブリッジ、VLAN など）も管理することができます。
つまり、systemd-networkd はより低レベルで、systemd に深く統合されたネットワーク管理ツールであるのに対し、netplan はより高レベルで、ユーザーフレンドリーな設定を提供し、複数のバックエンドを抽象化するツールだと言えます。
Ubuntu では、netplan が推奨されるネットワーク設定ツールですが、他の多くの Linux ディストリビューションでは systemd-networkd が直接使用されることが多いです。
「systemd → systemd-networkd ← ユーザ」という使い方もあれば「systemd → systemd-networkd → netplan ← ユーザ」という使い方もあるってことか。
nukopysyslog とログ基盤の統合の例
色々事例があるみたい。気になった記事をいくつか。
Twitter: "aws syslog lang:ja"
- (2022/06, クラスメソッド) CloudWatch Logs に取り込んだ syslog を Kinesis Data Firehose + Lambda で動的パーティショニングしつつ S3 に出力してみた
- (2022/10, heartbeats)AWS Network Load Balancer + syslog転送における注意点
- (2015/09, クラスメソッド) [Elastic Beanstalk] CloudwatchLogsでsyslog、eb関連ログを集約管理してみた
- めっちゃ古いけど syslog ってこんな感じを知るためにも一応
Twitter: "fluent bit syslog lang:ja", "fluentd syslog lang:ja"
- (2017/04, Qiita) Dockerのlogging driver: それぞれの特徴と使いどころ(json-file, syslog, journald, fluentd)
- Grafana: Syslog - Telegraf / InfluxDB / Grafana as syslog receiver
- (2020/12, Qiita) Grafana + Loki + FluentdでSyslog Viewerを作る
- (2023/04, 個人ブログ) [Kubernetes] Fluent Bitを使ってリモートのSyslogサーバーへPodのログを集約する
- (2016/01, 個人ブログ) fluent-plugin-kafka: fluentd と Kafka の連携
nukopy(2017/04, Qiita) Dockerのlogging driver: それぞれの特徴と使いどころ(json-file, syslog, journald, fluentd)
syslog
信頼性が高いってのは確かに。ロギングドライバーなんて落ちたら終わりだもんね。
アプリケーションのログってやっぱり syslog 適してなさそう（自分がそう思いたい証拠を探してるだけの可能性はあるけども、、）
あと、syslogはOSそのものの挙動などをログ管理するものであって、あんまりミドルウェアプロセスのログを吐かせたくないという気持ちがあるのですが、個人的な気持ちなのでしょうか…。
journald
さっきでてきた systemd-journald だね。OS に搭載されている実績あるソフトウェアは信頼できそうよね。
systemd管理上でのログ管理システムに任せる方法です。Dockerホスト上の全てのコンテナが(logging driverをjournaldに指定すれば)統合管理できます。最近のOSはsystemdが採用されているため、安心感があります。
と思ったら不安定かもしれなかった。いまはさすがに解決してそうだけど。
macOS の Apple Unified Log もそうだけど、journald のログも膨大なんかね。
journald側の設定をちゃんとしないと、流量が多すぎると勝手に切り捨てられたりします。
journald.conf(5) - Linux manual page - man7.org
fluentd
本命。近年では Fluentd / Fluent Bit はログ収集ドライバー（ログ収集エージェント）としてはほぼデファクトと言っていいよね。いろんな監視基盤のアーキテクチャで採用されてるのを見る。
fluentdが死んだら終わり
ただ、Docker側のlog-optオプションによって、バッファやリトライなどの設定ができるため、言うほど「終わり」ではありません。fluentd側が再起動後、ちゃんと再送されてくるので、ほとんどは救うことができます。
fluentd が死んだらどうなる？
良い実験。たしかに fluentd / fluent bit が落ちたらどうなるかは気になる。あとどのくらいの頻度で落ちるのかも気になる。
結局 logging driver は何を使うべきか？
おそらく、大抵の場合は、(もちろん障害解析のときに、取りこぼさないことが理想ではありますが)「ログを1行たりとも欠損してはならない」という要件はないのではないでしょうか？そうなるとfluentdでログを飛ばして、集約管理するということで済むと思います。
docker logsコマンドでログを気軽に見られないというデメリットはあるにはありますが、そもそもdocker logsに頼って、これを必須の要件として見まくるような状況はそれはそれでヤバイ気がします。ただ、何かあったときにDockerホストにログが残っているという安心感は変え難く、その場合はjournaldが良さそうな気がします。
ぼくのかんがえたさいきょうのログかんり
fluentdとjournaldを組み合わせた使い方です。これによって、journald単体でのデメリットを消して、fluentdで全体的に集約を行うこともできるようになります。
journaldは信頼度が高い(はず)なので、ここにまずは記録していくことで、取りこぼしやログの消失を防ぎます。fluentdは、ここから読み込むことで、コンテナとの直接的な関与をなくします。また、fluentd自体がファイルのposition情報を持つことができるので、異常終了したとしても、次回起動時に途中から読み直すことができます。
fluentdは、以下のプラグインを利用しています。
systemd input plugin for Fluentdこれで問題なさそう…なのですが、このアーキテクチャを実現しようとしていたところに、先述のDocker & journald周りのバグにぶつかって死にかけたので、じゃあどういうログ管理がベストなんだろう？と悩んでいます。今ならもうバグを気にする必要はないのかもしれませんが。
nukopyQ. 複数のアプリケーションを動かしているオンプレミスサーバで fluent bit をロギングドライバーとして使用しています。このとき、fluent bit てどのくらい落ちるものなのでしょうか？また、落ちた場合どうなるでしょうか？fluent bit のプロセス自体が動作しているかどうか、エラーログを吐いていないかどうかはどうやって監視システムに統合すればよいのでしょうか？
Fluent Bit は、軽量で高性能なログ収集・転送ツールとして設計されており、安定性と信頼性が高いことが知られています。ただし、どんなソフトウェアでも完全に落ちないということはありません。
Fluent Bit が落ちる頻度は、設定の正確性、システムリソースの利用可能性、扱うログデータの量と種類などの要因に依存します。適切に設定され、十分なリソースが与えられている場合、Fluent Bit が頻繁に落ちることはまれです。
これはたしかに。Fluent Bit の役割上、安定性・信頼性が高くないと採用されないもんな。逆に言うと、採用されていることを信頼して採用して、あとは運用して経過見るしかない。
Fluent Bit が落ちた場合、いくつかの影響が考えられます：
- ログの欠落：Fluent Bit が停止している間、新しいログデータは収集・転送されません。これにより、ログの欠落が発生する可能性があります。
- メモリ消費：Fluent Bit が再起動するまで、送信されなかったログデータはメモリ内に蓄積される可能性があります。これにより、システムのメモリ消費量が増加する可能性があります。
- CPU 使用率：Fluent Bit の再起動時に、蓄積されたログデータを処理するために一時的に CPU 使用率が上昇する可能性があります。
ログの欠落自体は Fluent Bit を採用したログ基盤の構成上防ぎようがないね。運用テストしてどれくらい落ちないのかを見てこっちが信頼するしかない。ミドルウェアなどのように自分たちが実装するアプリケーションよりはよっぽど落ちにくいだろうし、そこはあまり心配してない。でも落ちたらどうなるかは必ず考えておく必要がある。
対策としては、ローカルにログを残しておくのが良いね。そもそも tail プラグインを使う予定だし最悪サーバにログが残っていることの安心感で寝れる。
Fluent Bit のプロセスを監視するためには、以下のような方法があります：
- プロセス監視：監視システム（Nagios, Zabbix, Datadog など）を使って、Fluent Bit のプロセスが実行中であることを確認します。これは通常、プロセス名やプロセスIDを確認することで実現できます。
- ログ監視：Fluent Bit 自体のログを監視します。デフォルトでは、Fluent Bit はログを標準出力に書き込みますが、設定ファイルでログファイルを指定することもできます。監視システムにこれらのログを統合し、エラーメッセージやその他の異常を検出するようにします。
- ヘルスチェックエンドポイント：Fluent Bit の HTTP サーバー機能を有効にし、ヘルスチェックエンドポイントを設定することができます。監視システムから定期的にこのエンドポイントにアクセスし、応答を確認します。
- メトリクス監視：Fluent Bit は、処理されたレコード数、エラー数、バッファ使用量などの内部メトリクスを Prometheus や Datadog などの監視システムに公開することができます。これらのメトリクスを監視することで、Fluent Bit の健全性を評価することができます。
これらの方法を組み合わせることで、Fluent Bit の可用性と正常性を効果的に監視し、問題が発生した場合に速やかに対応することができます。さらに、Fluent Bit を複数のノードで実行し、ログデータを複製することで、単一障害点を排除し、全体的な信頼性を向上させることができます。
3, 4 あたりが始め易そう！