目的は、syslog()「local0」-「local7」を使用してシステムログをスキップすることです。

あなたはそれを達成できません。ライブラリsyslog()機能はsystemdログに記録されます。ライブラリとの通信のためによく知られているソケットを受信する/dev/logサーバーはrsyslogd。これはsystemd-journald。 rsyslogdはい反対側に付いている、ライブラリ機能はこれについて話しませんsystemd-journald。構成をいくら変更しても、rsyslogこの内容は変更されません。

経由せずに何かを送る唯一の方法は、systemd-journaldいくつかを使用することです。その他目的地までのルート、いいえsyslog()よく知られたソケットと通信するためのライブラリ関数

皮肉なことに、アプリケーションログの正確で簡単な場所はおそらく標準エラーです。標準エラーをネットワーク経由でリモートログコレクタに送信するプログラムと通信するパイプに接続します。

このようなタスクに対して私が好む設定は、daemontools Service Managerスイートから「デフォルト」サービスとしてアプリケーションを実行することです。

• アプリケーションは標準エラーに記録されます。
• 一般的なdaemontoolsスタイルのサービス管理には、標準入力がアプリケーションの標準エラーにパイプされるロギングサービスがあります。サービス管理者は、「基本」サービスと「ログ」サービスの間にこれらのパイプを設定することを担当します。
• これらのログサービスはcyclog、、、、またはこれらのサービスの一部を実行し、ログをmultilogローカル（厳密に制限されたサイズ、自動回転、アプリケーションから分離）ログディレクトリにダンプします。s6-logsvlogd
• 追加サービスは、これらのログディレクトリを監視し、ネットワークを介してlogstashまたは同様の機能を実行する集中型ログサーバーに新しい情報を提供します。私のexport-to-rsyslogツールはそのために設計されています。

これには次の利点があります。

• ローカル、即時アクセス可能、アプリケーション別、別々の最近のログ（他の項目と混在または圧倒されない）があります。
• ログサーバーへの不安定なネットワーク接続はアプリケーションに逆圧をかけません（アプリケーション標準エラーがネットワーク経由で配信されるか、ネットワークを介して即座に中継されるサーバーに直接配信される、より直接的なモデルと同様）。プロセス）;
• ネットワーク転送はローカルロギングに比べて完全に非侵害的で、後で設定することができ（中央集中型Logstashなどの必要なポイントまでデータボリュームが増加する場合）、影響を与えずにネットワークを再構成（転送アプリケーションログを追加/削除）することができます。それと;
• 極端な場合は、最近のログデータを不安定にしたり、誤って消去したログサーバーで再生したりすることもできます。

追加読書

• https://unix.stackexchange.com/a/294206/5132
• ジョナサンデボインポラード（2015）。 」記録」。デーモンツールシリーズ。一般的な答え。
• ジョナサンデボインポラード（2019）。 」記録」。スナックガイド。ソフトウェア。
• ジョナサンデボインポラード（2019）。export-to-rsyslog。 「注文する」。 スナックガイド。ソフトウェア。
• ジョナサンデボインポラード（2019）。follow-log-directories。 「注文する」。 スナックガイド。ソフトウェア。
• ジョナサンデボインポラード（2019）。udp-socket-connect。 「注文する」。 スナックガイド。ソフトウェア。