DockerとPortainerContainer Logsをクエリ可能なテーブルに変換します。
デーモンが実行するすべてのコンテナがログを書き込みます。すべてを一度にクエリし、64文字のIDが並ぶディレクトリではなく、コンテナの実際の名前、イメージ、Composeサービス名を取得できます。
結果は、Excel、Google Sheets、AIツール、Database REST API経由のアプリで利用できます。
すべてのコネクタータイプをFreeで利用できます。データソース2つとエージェント1つから始められます。
Query Streamsは、Dockerのjson-fileログ、手動で保存したdocker logsのエクスポート、Portainer独自のサーバーログを、Microsoft Excel、Google Sheets、MCP経由のAIアシスタント、REST API、Power BIから読み取れるライブSQLテーブルに変換します。解決する難題は識別情報です。ディスク上ではこれらのファイルはコンテナIDを名前にしているため、行が取り込まれる前にAgentが各ファイルをコンテナの実際の名前、イメージ、Composeサービスに対応付けます。データはアップロードされません。Agentはホスト上のファイルを読み取り、クエリ結果のみがネットワークの外に出ます。
- IDではなく、実際のコンテナ名
- 各行にイメージとComposeサービスを表示
- stdoutとstderrを個別に保持
適切な設定でContainer Logsを接続します。
接続先はNetwork Agentのままにします。以下はContainer Logs固有の詳細です。
- フォルダ
- コンテナホスト上のデーモンのログディレクトリ、またはエクスポートしたログを格納したフォルダー
- 情報源
- Docker json-fileログ、保存済みのdocker logsエクスポート、Portainerのサーバーログ
- 識別情報
- デーモンから解決したコンテナ名、イメージ、Composeサービス。行は64文字のIDをキーにしません
- ローテーション
- デーモンによるローテーションに追従し、エクスポートファイル用の名前付きローテーションパターン10種類にも対応
- 形式に一致しない行
- events_raw_linesに原文のまま保持され、破棄されることはありません
- 資格証明書
- なし。Agentはホスト上のファイルをその場で読み取ります
- SQL方言
- DuckDB。標準SQLに対応し、コンテナ固有の構文を覚える必要はありません
Agentはデーモンがすでに書き込んだログファイルを読み取ります。コンテナにアタッチせず、ストリーミングのためにデーモンソケットを開いたままにすることもありません。また、ファイルへの書き込みやローテーションを行うこともありません。そのため、コネクターを実行したままにしても、ホストの動作は変わりません。
Container Logsの仕組みに合わせて構築されています。
難しいのは解析ではなく、識別情報です
Dockerのjson-fileドライバーは、各コンテナのログを、その64文字のIDを名前にしたディレクトリに書き込みます。JSONの解析は簡単ですが、それがどのコンテナのものかを把握するのは簡単ではありません。そして、その識別こそがテーブルを実用的にする要素です。
- 各行には、パスから推測するのではなく、デーモンから解決したコンテナの実際の名前、イメージ、Composeサービスが含まれます。
- つまり、「今朝のapiサービスのエラー」は、手作業で管理する対応表を調べるのではなく、WHERE句で指定できます。
- ストリーム情報も保持されるため、stdoutとstderrを1つのテキスト列にまとめず、区別できます。
- 削除されたコンテナについても、すでに生成された行は保持されます。コンテナとともに履歴が消えることはありません。
-- 現在、最もログが多いサービスはどれか
SELECT service, stream, COUNT(*) AS lines
FROM fileset.events
WHERE stream = 'stderr'
GROUP BY service, stream
ORDER BY lines DESC1つではなく、3つの形式
デーモンのjson-fileログが中心ですが、クエリする価値のあるコンテナログはそれだけではありません。手動で保存したdocker logsのエクスポートは形式が異なり、Portainerも独自のサーバーログを書き込みます。3つすべてにプロファイルがあるため、1つのパーサーですべてを処理できると期待するのではなく、読み取る形式を選べます。
形式と動作の詳細
Container Logsで必要なリファレンスを開きます。
コンテナログのフォルダ1つが、1つのテーブルに変換されます。
コンテナログのフォルダ1つが、1つのテーブルに変換されます。
Query Streamsは、デーモンがすでに書き込んだファイルを読み取り、形式を固定して、各行の横にコンテナ名が表示される型付き列を提供します。サイドカーも、ログ転送パイプラインも、保守が必要なインデックスも不要です。パーサーが読み取れない行も、黙って破棄せず、理由とともに1行として保持します。
a3f9c1…-json.logドッカーshopfront-stack_api.log輸出
portainer.logポーターローテーション、圧縮アーカイブ、再読み込み済みファイルにも対応
セレクト アプリ、compose_service、
カウント(*) AS 線
フロム ファイルセット.イベント
どこ ストリーム = 'stderr'
GROUP BY アプリ、compose_service
ORDER BY 線 DESC同じクエリでアプリケーションデータベースに結合します
デーモンが既に書き込んでいるファイルを、レポート可能なテーブルとして表示します。
2つのツール、3つのフォーマット、サイドカーなし
2つのツール、3つのフォーマット、サイドカーなし
各カードには、Query Streamsが読み取る正確なファイルと、その保存場所が記載されています。これを使うためにログドライバーを変更する必要はありません。— jsonファイル は Docker のデフォルトであり、デフォルトはサポートされているものです。
サポートされているコンテナログ
3つの形式 · 2つのツール
ドッカーjsonファイルログドライバー
- 1つ
{"log","stream","time"}デーモンによって書かれた、1行あたりの封筒 - コンテナ名はDocker独自の情報から取得されます
config.v2.json丸太の横 - Image and Composeプロジェクト/サービスはコラムとして掲載されます
- いつもの
/var/lib/docker/containers - 追加; 番号付き回転と
.gzフォロー
ドッカーdocker logs export
- 保存したファイル
docker logs --timestamps - RFC 3339形式のナノ秒タイムスタンプに続いて、コンテナ独自の行が記録されます
- コンテナバナーの行は、偶然ではなく、宣言によってスキップされます。
- エクスポートしたファイルを保存するフォルダ
- サービスごとに1つのファイル。ファイル名はファイルステムから取得されます。
ポーターサーバーログ、ゼロログコンソール
portainer.logまたはコンテナ独自の出力- 解析前にANSIカラーコードが削除されるため、レベルはレベルとして扱われます。
- の
キー=値末尾は列になり、残りはデータ - 埋め込みトンネルサーバーの、異なる形式の行も読み取ります
- 分単位のタイムスタンプ（UTCと読み替える）
エージェントのリリースごとに、新しいコンテナログ形式が追加されます。エージェントは常に最新の状態に保たれるため、後から追加された形式は、サーバーにアクセスすることなくコネクタに表示されます。
docker ログ Swarmホストからのエクスポートと、Portainer CE 2.39.1のサーバーログです。まず知っておいていただきたいことがあります。WindowsおよびMac版Docker Desktopでは、json-fileログは仮想マシン内に保存されるため、サービスとして実行されるAgentからはアクセスできません。次の方法でエクスポートしてください docker logs --timestamps そして、2番目のプロファイルを使用します。
あらゆるリージョンのコンテナ、その場所で読み取るログ
各リージョンのコンテナ、ログ読み取り 彼らが座る場所
コンテナがすべて同じ場所で稼働することはほとんどありません。オフィスのホスト、あるクラウドリージョンのSwarmクラスター、別の国の単独サーバー。それぞれの場所でNetwork Agentが稼働し、既存の場所にあるログファイルを読み取ってQuery Streamsへ接続します。ファイアウォールから見れば通常のアウトバウンド接続にすぎません。開放するポートも、構築するVPNもありません。
docker ログ サービスごとのエクスポート
発信
3つのアウトバウンド接続を、1か所でクエリ — インバウンドポートもVPNもファイアウォールの変更も不要
各拠点につきエージェント1名
Agentは単一のフォルダーではなく、サイト全体をカバーします。その場所で使用するログ形式ごとに、同じAgent上に独自のFile Setコネクターを作成します。通常は場所ごとにAgentを1つ配置します。FreeプランではAgentを1つ、 有料プランではそれ以上実行できます。
1サイト＝1エージェント＝多数のコネクタ
開けるものはありません
Agentは暗号化されたアウトバウンド接続を1つ確立し、送信リクエストも返される行データもその接続を通ります。インバウンドポートもVPNも、ファイアウォールの変更申請も不要です。認証情報はネットワーク内に留まります。
接続は1つ、双方向
サイトをまたがる単一のクエリ
すべての情報源 フェデレーションクエリ それぞれのAgentに独自の名前を付けるため、1つのステートメントで、ある国のログと別の国のログを読み取って1つの結果を返したり、どちらかのログをデータベースと結合したりできます。BusinessおよびEnterpriseに含まれます。
2か国 → 1つの結果セット
彼らは常に最新の情報を把握している。
エージェントは自動的にアップデートされるため、後のリリースで追加されたコンテナログ形式は、サーバーにログインしてインストールする必要なく、すべてのサイトに配信されます。そのため、上記のリストは固定リストではなく、あくまで出発点となるのです。
エージェントと共に新しいフォーマットが登場
名前、時計、カラーコード
名前、時計、カラーコード
コンテナログは、日付が書かれたテキストファイルではありません。コンテナログをデータとして扱おうとすると、通常3つの問題が発生しますが、ここでは推測ではなく宣言によってそれぞれに対処します。
名前であって、16進数IDではない
Dockerは各ログフォルダにコンテナIDを名前として付けるため、グループ化されたクエリでは読み取りが困難になります。Query Streamsは、Dockerがログの横に書き込むレコードを読み取り、実際の名前を取得し、IDを独自の列として保持します。
a3f9c1…-json.log → app = shopfront-api
デーモンの時計
コンテナが独自のタイムスタンプをエポック秒で出力すると、それを信じれば時刻は1970年になります。イベント時刻にはデーモンがログを取得した時刻を使用し、コンテナ独自のタイムスタンプは信頼せず、列として保持します。
エンベロープ時刻 → event_time
ファイル内のカラーコード
コンソールロガーは、ターミナルのエスケープシーケンスをそのままログに書き込みます。解析前にこれらを取り除くため、レベルはエスケープ文字で囲まれた値ではなく、レベルとして読み取れます。元のバイト列は変更されません。
エスケープコードを削除 → level = INF
何も二度カウントされない
各ファイルは最初の4KBで識別されるため、回転されたファイルは先頭から再度読み込まれるのではなく、同じファイルとして認識されます。ローリング複製ウィンドウは、書き込み処理が末尾を再生する際に重複部分を捕捉します。
4 KBのプレフィックスハッシュ · 20,000レコードのウィンドウ
実際に取得できる列
実際に取得できる列
タイムスタンプが添えられた単なるテキストの塊ではありません。各形式は、直接フィルター、グループ化、集計に使える型付きの列に解析されます。コンテナが構造化JSONをログに記録している場合は、そのフィールドも列に展開されます。
各行には イベント時間、読み取った元のタイムスタンプと、読み取り元のファイルです。各形式では識別用の列が追加されます — アプリ jsonファイルとPortainerの場合、 容器 エクスポート用 — また、json-fileの行にはさらに 画像, compose_project, compose_service そして コンテナIDシングル メッセージ エクスポートの列は意図的なものです。コンテナ独自の行は推測で解釈せず、そのまま丸ごと保持されます。
これは意図的に行わないことです
これは意図的に行わないことです
これはリアルタイムのログではありません。クエリ ストリームは、クエリ実行時にディスク上のファイルをそのまま読み込むため、再起動ループは監視対象のストリームではなく、行として表示されます。行が出力される瞬間に1秒未満のアラートが必要な場合は、ログ パイプラインが適切なツールです。
コンテナの出力は自由形式であり、はっきりお伝えしておくべき点があります。アプリケーションが出力したものはすべて、テーブルに格納されます。トークンや顧客のメールアドレスをログに記録すれば、その文字列はすでにログファイルに含まれており、列にも入ります。Webサーバーログのように除外項目を指定するヘッダーマップはありません。生成されるテーブルは、ログファイルと同じ注意を払って取り扱ってください。
2つの小さな制限は、隠されているのではなく、名前が付けられています。 docker ログ エクスポートでは、コンテナ独自の行全体が1つの メッセージ 列に保持されます。内側の行を独自の形式で再解析する機能は、まだ実装されていません。また、logging tagを使ってDockerが追加できる任意の属性は、形状だけで認識されます。取得対象のコーパスではそれらを使用するコンテナがなかったため、この処理は仕様として定義されていますが、実証はされていません。
残りの部分は通常の設計に従います。エージェントはアウトバウンド接続を行い、ファイルを読み取ります。コンテナ内には何もインストールされず、何も書き戻されず、DockerソケットとAPIは一切変更されず、アクセスは読み取り専用です。保持フィールドは、このプリセットでは30日から始まりますが、変更可能です。
接続から有用な結果まで。
- Network Agentをコンテナホストにインストールします。デーモン'のログディレクトリにアクセスできる場所です。
- コネクターの接続先を指定します。すべてのコンテナのjson-fileログが対象になり、パターンを使って対象を絞り込むこともできます。
- Agentは各64文字のディレクトリから、対応するコンテナ（実際の名前、イメージ、Composeサービス）を特定するため、SQLを書く前から行を読みやすい状態で確認できます。
- 各行は1つの行データになり、ストリーム（stdoutまたはstderr）とデーモン'のタイムスタンプが付きます。デーモンによるログローテーションにも追従します。
- クエリを実行します。すべてのコンテナのエラーをまとめて調べることも、1つのサービスだけを確認することも、デプロイ前後を比較することもできます。
Container Logsの結果を活用しましょう。
1つの接続で、スプレッドシート、アプリ、AIツールを利用できます。保存済みクエリを実行する権限を共有すれば、受信者には許可された結果だけが表示され、SQLとソースのログイン情報は隠されます。
チーム、ベンダー、パートナーの皆様へ
Container Logsの最新結果をワークシートに直接取り込み、必要に応じて更新できます。デスクトップ版Excel、Excel Online、Microsoft 365に対応しています。
Excelを見るサイドバーから保存済みのContainer Logsクエリを実行し、行データをシートに追加します。共有相手も自分で更新できます。
Google Sheetsを見る自然な英語で質問してください。NovaはContainer Logsのテーブルを把握しているため、SQLを作成して実行し、回答を説明してグラフにします。クエリを書く必要も、認証情報を渡す必要もありません。
Novaの仕組み同僚、ベンダー、パートナーなど誰とでも、最新のContainer Logsの結果を共有できます。ブックマーク可能なグリッドは、スマートフォン、タブレット、デスクトップで開くたびに新しい結果を再取得します。共有相手に表示されるのは結果だけで、SQLやファイルは見えません。
データビューアの仕組みアプリとシステム向け
Container Logsのクエリを、あらゆるアプリケーションから呼び出せる認証付きJSONエンドポイントとして公開できます。OpenAPI 3.1仕様と、すぐに使えるPostman、Insomnia、Hoppscotchのコレクションも用意されています。データベースのポートを開放する必要はありません。
REST APIを見る生成されたPower Query MをPower BIの詳細エディターに貼り付けると、レポートはHTTPS経由でContainer Logsの最新結果を読み込みます。ODBCドライバーも、データベースのポート開放も不要です。
Power BIを見るスケジュールに従ってContainer Logsの行をAirtableベースに同期するか、Airtableのオートメーションスクリプト内で取得できます。
Airtableを見るRESTエンドポイント経由でContainer LogsのデータをBaserowテーブルに取り込みます。セルフホスト版とBaserowクラウドの両方に対応しています。
Baserowを見るファイルをエクスポートしたりデータベースを公開したりせずに、Container LogsのデータでSeaTableベースを最新の状態に保てます。
SeaTableを見るContainer Logsの結果をSmartsheetグリッドに送信し、計画やレポートが先週の'エクスポートではなく、ソースシステムのデータを参照するようにします。
Smartsheetを見るデータベースの認証情報をアプリに埋め込む代わりに、RESTエンドポイント経由でContainer LogsをAnvilのPythonアプリに接続します。
Anvilを見るAIツール向け
AIアシスタントに、正確なSQLを書くために必要なスキーマとともに、Container Logsへの読み取り専用アクセスを提供します。チャットに認証情報を入力する必要はありません。
MCPを探索する人々に届けられる
Container Logs クエリをスケジュールに登録して、結果の行を Slack、Discord、メール、または署名付き Webhook に配信できます。または、行数、しきい値、設定した割合の変化が条件を超えるまでメッセージを保留できます。
アラートとレポートの仕組みContainer Logs を他のデータと結合する。
データベース、ビジネスAPI、ファイル、ログを1つの読み取り専用クエリにまとめられます。すべてのコネクターがFederated Queriesに対応しています。
接続とテーブルを指定してください。Query Streamsがソースへのクエリを処理し、結果を統合します。
Federated Queriesを見る-- コピーなし、マージなし、スケジュールなし
セレクト c.region、COUNT(*) AS orders、SUM(i.amount_due) AS invoiced
フロム containerlogs.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
マシンログContainer Logs に関するよくある質問
Container Logsのクエリ結果はどこで使えますか？
Container Logsの結果は、Excel、Google Sheets、Data Viewer、Database REST API経由のアプリ、MCPまたはNova経由のAIツールで利用できます。保存した結果は、対応するAutomationの送信先、レポート、アラートにも利用できます。送信先の提供状況や利用枠はプランによって異なります。
Container Logsを利用するには、受信ポートを開く必要がありますか？
いいえ。Container Logsに接続できるマシンにNetwork Agentをインストールしてください。Agentは外向きにQuery Streamsへ接続するため、受信ポートもVPNも必要ありません。ただし、接続元のアクセスルールでAgentマシンからの接続が許可されている必要があります。
Container Logsのファイルはアップロードされますか？
Network Agentはファイルが保存されている場所で読み取り、キャッシュはエージェントのマシン上に保持します。ソースファイルがアップロード、移動、書き換えられることはありません。要求されたクエリ結果のみが、暗号化された外向き接続を通じてネットワークの外に送られます。
Container Logsの接続には何が必要ですか？
フォルダー：コンテナーホスト上のデーモンのログディレクトリ、またはエクスポートしたログを格納するフォルダー。ソース：Docker の json-file ログ、保存済みの docker logs エクスポート、Portainer のサーバーログ。識別情報：デーモンから解決されるコンテナー名、イメージ、Compose サービス。行のキーに64文字の ID は使いません。ローテーション：デーモンのローテーションに追従し、エクスポートファイル用の名前付きローテーションパターン10種類にも対応します。
Container Logsを他の接続済みソースと結合できますか？
はい。Federated Queriesは、データベース、ビジネスAPI、ファイル、ログなど、あらゆるコネクタータイプに対応しています。1つの読み取り専用クエリで接続とテーブルを指定してください。Query Streamsが必要に応じてソースごとのクエリを変換し、結果を統合します。 Federated Queriesの仕組みをご覧ください。
Dockerのログドライバを変更する必要はありますか？
いいえ。 jsonファイル は Docker のデフォルトドライバーであり、サポート対象です。ログ設定を変更したことがなければ、ファイルはすでに存在し、形式もそのまま利用できます。
別のドライバーに移行した場合は、 docker logs --timestamps export は入力経路です。CLI はデーモンを介して読み込むため、どのドライバでも機能します。
コンテナのIDだけでなく、名前もどのように特定するのですか？
Docker は、ログと同じフォルダにコンテナの記録を書き込みます。Query Streams はそのファイルから名前を読み取り、それを ID 列として使用します。イメージ、Compose プロジェクト、サービスは、その横の列として保持されます。64 文字のフォルダ ID は、 コンテナIDだから、何も失われることはない。
そのレコードが存在しない、読み取れない、または名前が含まれていない場合は、代わりにフォルダー名が使われます。また、スキャンではその発生回数がカウントされます。つまり、フォールバックは黙って置き換えられるのではなく、確認できる数値として表示されます。
私はWindows版またはMac版のDocker Desktopを使用しています。これは動作しますか？
jsonファイルログを直接攻撃することはできません。Docker Desktopはそれらを独自の仮想マシン内に保持するため、ホスト上でサービスとして実行されているエージェントはそれを閲覧できません。
その解決策はエクスポートプロファイルを使用することです。 docker logs --timestamps <コンテナ> Agentが読み取れる任意のフォルダーにリダイレクトされたファイルです。これは回避策ではなく、それ自体がサポート対象の形式です。コンテナがなくなった後もログのコピーを保持するために、すでに多くの人が使っている方法と同じです。
これはリアルタイムですか？
ストリーミングではなく、オンデマンドで読み取ります。クエリ実行時点のファイルを読み取るため、コンテナーが書き込んだ新しい行は、ファイルが検出された時点で表示されます。固定の夜間スケジュールではありませんが、ライブテールでもありません。
過去数週間のあらゆるコンテナについて質問し、その回答をスプレッドシートにまとめるには、この形状が便利で、丸太を積み重ねるよりもはるかに少ない機械で済む。
KubernetesやPodmanはどうでしょうか？
どちらも現時点では独自のプロファイルを持っておらず、カバー範囲を暗示するよりも、その旨を明記する方が良いでしょう。適用されるのはエクスポート形式です。プロファイルは正確な形状にキー付けされています。 docker logs --timestamps が書き込みます。RFC 3339 のナノ秒精度タイムスタンプ、スペース、続けてコンテナー独自の行という形式で、サービスごとに1ファイルです。同じ形式を書き込むツールなら、そのまま読み取れます。
自分のファイルについて確実に確認する方法は、接続テストを実行することです。これは、何かを確定する前に認識された内容を報告します。
私のコンテナはJSON形式でログを出力します。そのフィールドを列として取得できますか？
はい、json-file ログに対応しています。デーモンのエンベロープを取り除き、その中にあるコンテナー独自の JSON を列に展開します。存在する場合は、level、logger、message、host、service などが列になります。名前付きの列に対応しない項目は、a データ 破棄されるのではなく列として保持されるため、通常とは異なるフィールドもクエリ可能です。
コンテナーの JSON から取得しない項目は、タイムスタンプだけです。これはデーモンから取得します。アプリケーション独自のタイムスタンプは形式が一定ではなく、誤って解釈すると行の時刻が気づかないうちにずれてしまうためです。
パーサーが読み取れない行の場合はどうでしょうか？
削除されるのではなく、保持されます。固定されたフォーマットと一致しない行は、理由が付加された生の行として保持されるため、不正な入力や予期しないフォーマット変更は、数値の空白としてではなく、確認および照会可能な形で表示されます。
作業の現場で Container Logs を活用しましょう。
Freeから始めましょう。すべてのコネクタータイプ、データソース2つ、Network Agent 1つを利用できます。ニーズの拡大に応じて、プランの利用枠を追加できます。
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish