syslogとjournaldSystem Logsをクエリ可能なテーブルに変換。
どちらのRFC形式のsyslogにも、エクスポート済みのsystemdジャーナルにも対応します。各行は、ホスト、プログラム、プロセスIDを含む1レコードになります。4回のSSH接続とgrepが必要だった調査も、1つのステートメントで行えます。
結果は、Excel、Google Sheets、AIツール、Database REST API経由のアプリで利用できます。
すべてのコネクタータイプをFreeで利用できます。データソース2つとエージェント1つから始められます。
Query Streamsは、syslogファイルをライブSQLテーブルに変換し、Microsoft Excel、Google Sheets、MCP経由のAIアシスタント、REST API、Power BIから読み取れるようにします。どちらのsyslog RFCにも対応し、テキストにエクスポート済みであればsystemdジャーナルも扱えます。各行には、元のホスト、書き込み元のプログラム、プロセスIDが含まれます。複数のマシンからログを収集するフォルダーをコネクターに指定すれば、すべてを1つのクエリで取得できます。中央ログサーバーの運用も、GB単位の取り込み料金も不要で、クエリ結果以外のデータがアップロードされることもありません。
- どちらのsyslog RFCにも対応
- ホスト、プログラム、PIDを列として表示
- 中央ログサーバーは不要
適切な設定でSystem Logsを接続。
接続はNetwork Agent上で行います。以下はSystem Logs固有の詳細です。
- フォルダ
- マシンのログディレクトリ、またはログの収集先フォルダー。ローカルディスク、もしくは\\server\share形式で指定するネットワーク共有（マップ済みドライブ文字は不可。LinuxまたはMacでは事前にマウントしてください）。サブフォルダーも含まれます。
- 形式
- どちらのRFC形式のsyslogにも、テキストにエクスポート済みのsystemdジャーナルにも対応
- 年の処理
- 行から取得するか、ファイルの更新日時またはファイル名から推定します。行ごとに推測するのではなく、一度選択します。
- ローテーション
- 名前付きのローテーションパターン10種類と、ローテーションなしの通常ファイルに対応。圧縮アーカイブもそのまま読み取ります
- 形式に一致しない行
- events_raw_linesに原文のまま保持され、破棄されることはありません
- 資格証明書
- ありません。サーバーは不要で、エージェントがファイルをその場で読み取ります
- SQL方言
- DuckDB — 標準SQLを使用するため、syslog固有の知識は不要です
稼働中のWindowsイベントログを読むことは、行が並ぶフォルダーではなく構造化されたチャネルを扱うため、別の問題であり、専用のコネクターが必要です。ただし、イベントをすでに定期的にテキストまたはCSVへエクスポートしているなら、そのフォルダーは今すぐ読み取れます。Custom Logsコネクターで一度レイアウトを記述すれば、エクスポートがここにあるほかのデータと同じようにテーブルになります。
System Logsの仕組みに合わせて設計。
取得できるデータ
- 1行につき1レコード。タイムスタンプ、ホスト、プログラム、プロセスID、メッセージが実際の列として格納されるため、後から1つの文字列を解析する必要はありません。
- 古いBSD形式と新しい構造化形式の両方のsyslog RFCに対応しているため、形式が混在する環境でも1つのテーブルで扱えます。
- systemdジャーナルはテキストにエクスポートすれば利用できます。ジャーナル独自のバイナリ形式はログファイルではなくデータベースであるため、先にエクスポートが必要です。
- _source_fileには各行の取得元ファイルが記録されます。これにより、50台のマシンからログを収集するフォルダーも1つのテーブルとして扱えます。
-- ホスト別に警告以上のログが最も多いプログラム
SELECT host, program, COUNT(*) AS lines
FROM fileset.events
WHERE severity <= 4
GROUP BY host, program
ORDER BY lines DESCsyslogの日付と欠落している年
古いsyslog形式では月日だけが記録され、年は記録されません。そのため、1月のログが11か月先に起きたように見えてしまうことがあります。ログドライバーは決めつけず、明示的に年を解決します。形式に年が含まれている場合は行から取得でき、そうでなければファイルの更新日時またはファイル名から推定できます。どの方法を使うかは一度選択します。
形式と動作の詳細
System Logsに必要なリファレンスを開いてください。
システムログのフォルダが1つのテーブルに変換されます。
システムログのフォルダが1つのテーブルに変換されます。
Query Streamsは、rsyslog、syslog-ng、またはsystemdがすでに書き込んだファイルを読み取り、形式を固定して、各行の横にホスト名を含む型付き列を提供します。コレクターの実行も、インデックスの保守も、データの二重コピーも不要です。パーサーで読み取れない行も、黙って破棄するのではなく、理由を付けたレコードとして保持されます。
syslogRFC 3164auth.log.2.gz回転
ジャーナル.export日記ローテーション、圧縮アーカイブ、再読み込み済みファイルにも対応
セレクト ホスト、プログラム、
カウント(*) AS 線
フロム ファイルセット.イベント
どこ メッセージ のように '％エラー％'
GROUP BY 司会者、番組
ORDER BY 線 DESC1つの結果に4つのサーバーが含まれているのは、 ホスト 列です
数値は例示用です。回答の傾向を示すもので、ベンチマークではありません。
2つのRFCとジャーナル
2つのRFCとジャーナル
各カードには、Query Streamsが読み取る正確なファイルと、その保存場所が記載されています。この機能を使うためにrsyslogを再設定する必要はありません。サーバーがすでに出力している形式を選ぶだけです。
サポートされているシステムログ
3つのフォーマット
SyslogRFC 3164、BSDファイルフォーマット
- ほとんどのLinuxサーバーでのデフォルト形式 —
月 DD HH:MM:SS ホストプログラム[pid]: メッセージ - ホスト、プログラム、プロセスIDはそれぞれ独立した列になります。
/var/log/syslog,auth.log,kern.log—メッセージRHEL上で- 周期
- マーク -フィラーは宣言によって削除され、記述したフィルターによって削除されるわけではありません。 - 付録; 日付と番号付き回転と
.gzフォロー
SyslogRFC 5424、構造化されたもの
- 最新の形式 — 実際のISO 8601タイムスタンプなので、年を推測する必要はありません
- 優先度、アプリ、プロセスID、メッセージIDそれぞれに列が割り当てられます。
- 構造化データブロックは、平坦化されることなくそのまま保持される。
- RFCのnil値は、テキストとしてではなくnullとして読み取られます
- - RFCに基づいて構築されたが、実際の捕獲に対する有効性はまだ証明されていない。
systemdジャーナルjournalctl -o export
- 作成したファイル
journalctl -o export - マイクロ秒単位のタイムスタンプなので、忙しい秒でも順序は維持されます
- ユニットと輸送手段はテキストではなく列として表示されます
- 他のジャーナルフィールドはすべて
データ捨てられるのではなく - レコードごとに1つのエントリ（行数に関係なく）
エージェントのリリースごとに、新しいシステムログ形式が追加されます。エージェントは常に最新の状態に保たれるため、後から追加された形式は、サーバーに何も操作を加えることなくコネクタに表示されます。
実行中のすべてのマシンを、1つのクエリで
質問が1つあります。 あなたが実行するすべてのマシン
System Logsは、まさにこの用途のために作られました。各行には、そのログを書き込んだホストが記録されるため、4台のサーバーから集めたフォルダーだけで、4台すべてを対象とした質問に答えられます。また、追加する各サイトでは、Network Agentが稼働し、ログファイルのある場所でそれを読み取り、Query Streamsへ接続します。ファイアウォールから見れば通常のアウトバウンド接続なので、ポートを開けたりVPNを構築したりする必要はありません。
/var/log/syslog
発信
3つのアウトバウンド接続を、1か所でクエリ — インバウンドポートもVPNもファイアウォールの変更も不要
各拠点につきエージェント1名
Agentは1台のサーバーではなくサイト全体をカバーします。多数のホストから集めたフォルダーツリーも1つのコネクターとして扱われ、各行にはすでにその情報が記録されています。 ホストFreeプランではAgentを1つ実行し、有料プランではさらに多く実行できます。
1サイト＝1エージェント＝多数のホスト
開けるものはありません
Agentは暗号化されたアウトバウンド接続を1つ確立し、送信するリクエストも、戻ってくる行データも、どちらもその接続を通ります。インバウンドポートもVPNも、ファイアウォールの変更依頼も不要です。すでに稼働中のサーバーにコレクターデーモンを追加する必要もありません。
接続は1つ、双方向
地域をまたがる単一のクエリ
すべての情報源 フェデレーションクエリ 各サイトには独自のAgentが割り当てられるため、1つのステートメントで、ある地域の認証ログを別の地域のログと並べたり、どのログインが重要だったかを示すアプリケーションデータベースと照合したりできます。BusinessおよびEnterpriseプランに含まれます。
2つのリージョン → 1つの結果セット
彼らは常に最新の情報を把握している。
エージェントは自動的にアップデートされるため、後のリリースで追加されたログ形式は、誰かがSSH接続を繰り返すことなくすべてのサーバーに届きます。そのため、上記のリストは固定されたものではなく、あくまで出発点となるのです。
エージェントと共に新しいフォーマットが登場
年、タイムゾーン、バイト数
年、タイムゾーン、バイト数
Syslogは、現在でも日常的に使用されている最も古いフォーマットの1つであり、その古さは明らかです。Syslogをデータとして扱おうとすると、通常4つの問題が発生しますが、ここでは推測ではなく宣言によってそれぞれに対処しています。
この行には年号がありません
RFC 3164切手は 9月10日 04:11:07 — 月、日、時刻のみです。これをそのまま読むと、アーカイブされたすべての行が現在の年として扱われます。Query Streamsは代わりにファイル自体の更新日時から年を推定するため、12月のローテーション分は12月として処理されます。
Sep 10 04:11:07 → 年はファイルから取得
タイムゾーンも指定なし
旧形式にはタイムゾーンオフセットがないため、タイムスタンプは書き込んだマシンとの関係でしか意味を持ちません。Agentのローカル時刻として読み取り、元のテキストも併せて保持します。RFC 5424とjournalには正確なUTC時刻が含まれており、そのとおりに扱われます。
RFC 3164はローカル時刻 · RFC 5424とjournaldはUTC
テキストファイル内のバイナリ値
journalのエクスポート形式では、改行を含む値は、名前、バイト長、続いて生のバイト列として書き出されます。Query Streamsは終端を探すのではなく、指定された長さに基づいて読み取るため、改行を含むメッセージも複数に分割されず、1つのエントリーとして扱われます。
長さで読む、内容で読むのではない
何も二度カウントされない
各ファイルは最初の4KBで識別されるため、回転されたファイルは先頭から再度読み込まれるのではなく、同じファイルとして認識されます。ローリング複製ウィンドウは、書き込み処理が末尾を再生する際に重複部分を捕捉します。
4 KBのプレフィックスハッシュ · 20,000レコードのウィンドウ
実際に取得できる列
実際に取得できる列
タイムスタンプが付いた単なるテキストの塊ではありません。各形式は、直接フィルタリング、グループ化、集計できる型付き列に解析されます。形式が新しいほど、列の数も増えます。
各行には イベント時間、読み取った元のタイムスタンプ、およびそのファイル名です。3つの形式すべてで共通の識別列として使われるのが ホスト — これにより、1つのクエリでフォルダー内のすべてのサーバーを対象にできます。2種類のsyslog形式ではログ行から取得し、journalではjournal独自の ホスト名 フィールド。すべてが1つのテーブルに収まります。 ファイルセット.イベント.
これは意図的に行わないことです
これは意図的に行わないことです
まず一番大きなものから言ってみましょう。 システムログには個人データが含まれています. auth.log ユーザー名と接続元IPアドレスを記録します。メールアドレスを記録するプログラムでは、そのアドレスがメッセージ本文に入ります。ファイルに含まれる内容がそのまま列に格納されます。Webサーバーログのように、ヘッダーマッピングでフィールドを除外することはできません。生成されたテーブルはファイルと同じように慎重に扱い、クエリを共有する相手についてもよく検討してください。
これはリアルタイム監視ではありません。クエリ ストリームは、クエリ実行時にディスク上のファイルをそのまま読み込むため、障害が発生したサービスは、監視対象のストリームではなく、行として表示されます。行が出力される瞬間に1秒未満のアラートが必要な場合は、ログ パイプラインが適切なツールです。
バイナリジャーナルは読みません。systemd プロファイルは、 journalctl -o export、 ない /var/log/journal 直接 — そのため、エクスポートは自動で行われるものではなく、スケジュールして実行する作業です。
仕様書に基づいて記述されているものの、実際のファイルで検証されていない点が3つあります。それらは、RFC 5424プロファイル全体、rsyslogとsyslog-ngが従来のスタンプの代わりに書き込めるISO-8601スタンプのバリアント、そして複数行にわたるジャーナル値の処理です。これら3つはすべてテストで網羅されていますが、いずれも実際のキャプチャで検証されたことはありません。
最後に、このファミリーはシステムログと呼ばれていますが、今日ではLinuxとUnixを指します。Windowsイベントログプロファイルはなく、macOSもありません。 ログショー プロファイルであり、名前から推測されるよりも、そう表現する方が良いでしょう。残りの部分は通常の設計に従います。エージェントはアウトバウンド接続を行い、ファイルを読み取ります。サーバーには何もインストールされず、何も書き戻されず、アクセスは読み取り専用です。保持フィールドは、このプリセットでは60日から始まりますが、変更可能です。
接続から有用な結果まで。
- ログを参照できる場所にNetwork Agentをインストールします。1台のマシンの/var/log、または既存のログ収集先フォルダーにインストールしてください。
- コネクターの参照先をそのフォルダーに設定し、プロファイルを選択します。2種類のsyslog RFCに加え、systemd journalのエクスポート済みテキスト形式も用意されています。
- プロファイルによってレイアウトが固定されるため、初回同期からhost、program、process id、messageが名前付き列として取り込まれます。
- 圧縮アーカイブを含め、ローテーションに対応しています。各同期では新しいバイトだけが読み取られます。
- クエリを実行しましょう。ホストが1台でも50台でも、program別にグループ化し、severityで絞り込みます。sshやgrepではなく、通常のSQLで操作できます。
System Logsの結果を活用しましょう。
1つの接続で、スプレッドシート、アプリ、AIツールを利用できます。保存済みクエリを実行する権限を共有すれば、受信者には許可された結果だけが表示され、SQLとソースのログイン情報は隠されます。
チーム、ベンダー、パートナーの皆様へ
System Logsの最新結果をワークシートに直接取り込み、必要に応じて更新できます。デスクトップ版Excel、Excel Online、Microsoft 365に対応しています。
Excelを見るサイドバーから保存済みのSystem Logsクエリを実行し、行をシートに追加します。共有相手も自分で更新できます。
Google Sheetsを見る平易な英語で質問してください。NovaはSystem Logsのテーブルをすでに把握しており、SQLの作成と実行、回答の説明、グラフの作成まで行います。クエリを書く必要も、認証情報を渡す必要もありません。
Novaの仕組み同僚、ベンダー、パートナーなど、誰とでもSystem Logsの最新結果を共有できます。ブックマーク可能なグリッドで、開くたびに最新データを再取得します。スマートフォン、タブレット、デスクトップに対応しています。相手に表示されるのは結果だけで、SQLやファイルは見えません。
データビューアの仕組みアプリとシステム向け
System Logsクエリを認証付きJSONエンドポイントとして公開すれば、任意のアプリケーションから呼び出せます。OpenAPI 3.1仕様と、すぐに使えるPostman、Insomnia、Hoppscotchのコレクションも用意されています。データベースのポートを開く必要はありません。
REST APIを見る生成されたPower Query MをPower BIの詳細エディターに貼り付けると、レポートがHTTPS経由でSystem Logsの最新結果を読み込みます。ODBCドライバーは不要で、データベースのポートを開く必要もありません。
Power BIを見るスケジュールに従ってSystem Logsの行をAirtableのベースに同期するか、Airtableのオートメーションスクリプト内から取得できます。
Airtableを見るRESTエンドポイント経由でSystem LogsのデータをBaserowのテーブルに取り込みます。セルフホスト版とBaserow Cloudの両方に対応しています。
Baserowを見るファイルをエクスポートしたりデータベースを公開したりせずに、SeaTableのベースをSystem Logsのデータで最新の状態に保てます。
SeaTableを見るSystem Logsの結果をSmartsheetのグリッドに送信し、計画やレポートが先週のエクスポートではなく、ソースシステムのデータを参照できるようにします。
Smartsheetを見るデータベース認証情報をアプリに埋め込む代わりに、RESTエンドポイント経由でSystem LogsをAnvilのPythonアプリに接続します。
Anvilを見るAIツール向け
AIアシスタントに、正しいSQLを書くために必要なスキーマ情報とともに、System Logsへの読み取り専用アクセスを提供します。チャットに認証情報を入力する必要はありません。
MCPを探索する人々に届けられる
System Logs クエリをスケジュールに登録して、行を Slack、Discord、メール、または署名付き Webhook に配信できます。または、行数、しきい値、変化率が設定した基準を超えるまでメッセージを保留できます。
アラートとレポートの仕組みSystem Logs をほかのデータと結合できます。
データベース、ビジネスAPI、ファイル、ログを1つの読み取り専用クエリにまとめられます。すべてのコネクターがFederated Queriesに対応しています。
接続とテーブルを指定してください。Query Streamsがソースへのクエリを処理し、結果を統合します。
Federated Queriesを見る-- コピーなし、マージなし、スケジュールなし
セレクト c.region、COUNT(*) AS orders、SUM(i.amount_due) AS invoiced
フロム syslogfiles.fileset.orders1 f
ジョイン pg_crm.一般顧客2 c ON c.id = f.customer_id
ジョイン 請求する.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.領域
ORDER BY 請求書記載のDESC;ご自身の接続名、スキーマ名、テーブル名、カラム名を使用してください。
コネクターシリーズ共通の機能。
すべてのログコネクターでは、次のテーブルも利用できます。
- events — 解析された各行を1レコードとして格納します。タイムスタンプ、文法で定義されたフィールド、および元のファイル名を示す_source_fileが含まれます。
- events_raw_lines — 文法に一致しなかった行を削除せず、元のまま保持します。想定外の形式も、引き続きクエリで調べられます。
- files_currentとfiles_events — 現在のファイル一覧と監査履歴です。何が追加され、何がローテーションされ、何が消え、何が保留されたかを、ファイル名と理由とともに確認できます。
- ローテーションを回避するのではなく、正しく認識します。名前付きのローテーションパターン10種類に加え、ローテーションされていない通常のファイルにも対応するため、昨日のログもその圧縮アーカイブも、今日のログと同じテーブルとして扱えます。
知っておくと良い
- 読み取り専用を徹底。一度に実行できるのは1つのステートメントのみで、SELECTなどの読み取り操作に限られます。こちらがログを書き込んだり、移動したり、ローテーションしたり、切り詰めたりすることは一切ありません。
- アップロードは一切ありません。行はエージェントの隣にあるお客様自身のマシン上で解析され、暗号化されてキャッシュされます。ネットワーク外に送信されるのはクエリの結果だけです。
- 読み取るのは新しいバイトだけです。エージェントはファイルを最初から読み直すのではなく、前回の続きから再開するため、ログが頻繁に更新されても日ごとに負荷が増えることはありません。
- SQL方言はDuckDBです — 他のコネクタに対して書くのと同じSQLを使用します。
関連するコネクターを見る。
ファイルシステム
CSVフォルダ
寄木細工のフォルダー
Excelフォルダ
SQLiteフォルダ
JSONLフォルダ
複数レコードのCSV
マシンログSystem Logs に関する質問
System Logs のクエリ結果はどこで使えますか？
System Logs の結果は、Excel、Google Sheets、Data Viewer、Database REST API 経由のアプリ、MCP または Nova 経由のAIツールで利用できます。保存した結果は、対応する Automation の出力先、レポート、アラートにも連携できます。利用可能な出力先と利用枠は、ご利用のプランによって異なります。
System Logs を使うには、受信ポートを開放する必要がありますか？
いいえ。System Logs にアクセスできるマシンに Network Agent をインストールしてください。エージェントは外向きに Query Streams へ接続するため、受信ポートやVPNは必要ありません。ただし、接続元であるマシンからの接続が、接続先のアクセスルールで許可されている必要があります。
System Logs のファイルはアップロードされますか？
Network Agentはファイルが保存されている場所で読み取り、キャッシュはエージェントのマシン上に保持します。ソースファイルがアップロード、移動、書き換えられることはありません。要求されたクエリ結果のみが、暗号化された外向き接続を通じてネットワークの外に送られます。
System Logs に接続するには何が必要ですか？
フォルダー：マシンのログディレクトリ、またはログの収集先フォルダー。ローカルディスク、または \\server\share の形式で指定するネットワーク共有（マッピングされたドライブ文字は不可。Linux または Mac では事前にマウントが必要）。サブフォルダーも含まれます。形式：RFC 3164 と RFC 5424 の両方の Syslog、およびテキストにエクスポートされた systemd journal。年の扱い：行から取得するか、ファイルの更新日時またはファイル名から推定します。選択は一度だけ行われ、行ごとに推測することはありません。ローテーション：名前付きローテーションパターン 10 種類に加えて、ローテーションされていない通常のファイルに対応。圧縮アーカイブもその場で読み取ります
System Logs を他の接続済みデータソースと結合できますか？
はい。Federated Queriesは、データベース、ビジネスAPI、ファイル、ログなど、あらゆるコネクタータイプに対応しています。1つの読み取り専用クエリで接続とテーブルを指定してください。Query Streamsが必要に応じてソースごとのクエリを変換し、結果を統合します。 Federated Queriesの仕組みをご覧ください。
私のファイル形式はどれですか？
行の先頭を見てください /var/log/syslog または /var/log/messages。3 文字の月名で始まる場合は — 9月10日 04:11:07 — RFC 3164 です。現在も多くの Linux サーバーがデフォルトで書き込む形式です。山かっこ内の数字に続いて ISO 8601 形式の完全なタイムスタンプがある場合は、RFC 5424 です。
開始前に確信を持つ必要はありません。接続テストでは、認識されたプロファイルとファイルのどの部分が一致したかが報告されるため、答えは推測ではなく実際のファイルから得られます。
rsyslogまたはsyslog-ngを再設定する必要がありますか？
いいえ。どちらの形式もサポートされているため、サーバーがすでに書き込んでいる形式を選べばよく、従来のデフォルト形式は最も多くのテスト実績があります。
検討する価値のある変更が 1 つありますが、形式とは関係ありません。複数のマシンから 1 つのコレクターにログをすでに転送している場合は、Agent の参照先をそのコレクターのフォルダーに設定すると、すべてのホストを 1 つのコネクターで取得できます。各行に送信元のホストが含まれているためです。
古いsyslog行で年が欠落している場合、どのように対処すればよいですか？
年はファイルの更新日時から取得されます。最後に書き込まれたのが 12 月のローテーション済みアーカイブは 12 月として読み取られ、素朴なパーサーのようにすべての行が現在の年に割り当てられることはありません。
制限について知っておく必要があります。ファイルのタイムスタンプが失われている場合（タイムスタンプを保持しないバックアップから復元した場合や、タイムスタンプがリセットされる方法でコピーした場合など）、推定はファイルシステムが示す情報に基づいて行われます。解析後の値の横には常に元のテキストが保持されるため、実際の行の内容を確認できます。
systemdジャーナルを直接読むことはできますか？
いいえ、そしてこれが多くの人が見落としがちな設定手順です。ディスク上のジャーナルはバイナリデータベースであり、Query Streams はそれを開きません。Query Streams が読み込むのはエクスポート形式です。 journalctl -o export > journal.exportエージェントが読み取れる任意のフォルダ内。
実際には、サーバー上で小規模な定期ジョブを実行することになります。Agent がすでに参照している場所にエクスポートを書き込むタイマーや cron エントリを設定します。その後はすべて自動で処理され、gzip 圧縮されたエクスポートも読み取れます。
WindowsイベントログやmacOSの場合はどうでしょうか？
どちらにもプロファイルはありません。このページにある 3 つの形式は Linux と Unix 向けです。「システムログ」という言葉から対応範囲を誤解させるより、この未対応部分を明示する方がよいと考えています。
ただし、Windows のケースにも対応する方法はあります。ライブ Event Log の読み取りはテキストファイルの読み取りとは別の問題です。行が並ぶフォルダーではなく、構造化されたチャネルであり、このコネクターではなく別のコネクターの対象です。ただし、イベントをすでに定期的にテキストまたは CSV にエクスポートしている場合、そのフォルダーは今すぐ読み取れます。レイアウトを一度、 カスタムログ コネクタとエクスポートされたデータは、このページ上の他のものと同様にテーブル形式になります。
ログファイルにユーザー名とIPアドレスが含まれています。これは問題でしょうか？
はい、そして質問を共有する前に考えておく方が、共有した後で考えるよりも良いでしょう。 auth.log これは、誰がどこから接続したかの記録であり、ほとんどの法域では個人データに該当します。一方、syslogメッセージは、プログラムが出力することを選択したあらゆる内容を含むことができる自由形式のテキストです。
Query Streams はファイルの内容を変更しないため、テーブルにはファイルと同じ機密性が引き継がれると考えるのが適切です。役立つ点が 2 つあります。保存済みクエリで共有されるのは結果であり、接続ではないため、受信者がログ全体を取得することはありません。また、フィルターを使って、共有する前に必要なプログラムだけにクエリを絞り込めます。
複数のサーバーからログを収集して1つのフォルダにまとめています。これで問題ないでしょうか？
これこそ、この機能が最も得意とするケースです。3 つの形式すべてでホストが列として含まれます。2 種類の Syslog 形式では行から読み取り、journal のエクスポートでは独自の hostname フィールドから取得します。そのため、40 台のマシンから収集したフォルダーも 1 つのコネクターで扱え、ホストごとのグループ化は通常の GROUP BY.
異なる建物や地域にあるサーバーも問題なく動作します。各拠点にはそれぞれ独自のエージェントが稼働しており、ビジネスプランおよびエンタープライズプランでは、単一のステートメントで複数の拠点を横断したフェデレーションクエリを実行できます。
パーサーが読み取れない行の場合はどうでしょうか？
削除されるのではなく、保持されます。固定されたフォーマットと一致しない行は、理由が付加された生の行として保持されるため、不正な入力や予期しないフォーマット変更は、数値の空白としてではなく、確認および照会可能な形で表示されます。
フォーマットによってバイナリとしてマークされたジャーナル値にも同じことが当てはまります。推測されるのではなく、理由とともにエントリの横に配置され、エントリ自体はそのまま保持されます。
System Logs を、実際に作業する場所で活用しましょう。
Freeから始めましょう。すべてのコネクタータイプ、データソース2つ、Network Agent 1つを利用できます。ニーズの拡大に応じて、プランの利用枠を追加できます。
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish