Sysdig

SCSK株式会社

×

サイト内検索

ブログ

HOME Developer Square ブログ Sysdig Monitor による PaperCut Web Print の監視について

SCSK技術者ブログSysdig Monitor

Sysdig Monitor による PaperCut Web Print の監視について

本検証では、PaperCut MF Web Print の処理状態を Sysdig Monitor で監視・可視化するため、windows_exporter の textfile コレクターを用いて、ホットフォルダ内の滞留ファイル数と保留ジョブ数を独自メトリクスとして収集しました。Sysdig Monitor のメトリクスと JMeter の負荷テストログを突き合わせた結果、PDF レンダリング時の CPU・Disk Write の変動、滞留ファイルの増加、および保留ジョブの一括リリース時におけるディスク I/O の集中を把握できることを確認しました。

1. はじめに

Sysdig が提供する監視プラットフォーム「Sysdig Monitor」の利活用範囲を広げるため、標準的な Windows ホスト監視に加え、カスタムアプリケーション監視を実装しました。監視には、Prometheus エコシステムの windows_exporter textfile コレクターを利用しました。

監視対象には、統合印刷管理システム「PaperCut MF」の Web Print（ドライバーレス Web 印刷）機能を採用しました。Web Print の処理ライフサイクルから「ホットフォルダ内の滞留ファイル数」と「保留ジョブ数」を独自メトリクスとして抽出し、JMeter による負荷テスト時のログおよびシステムリソースの変化と比較することで、Sysdig Monitor による監視の有効性を検証しました。

2. 監視アーキテクチャの構成

（1）Sysdig Monitor と Windows Exporter

Windows ホストの監視において、Sysdig Windows Prometheus Bundle を使用しました。本構成のデータフローは以下の通りです。

  1. Windows Exporter:

    Windows ホスト上でサービスとして常駐し、CPU、メモリ、論理ディスクなどの OS 標準メトリクスを収集してポート 9182 で公開します。

  2. Prometheus Agent:

    Agent モードで起動し、Windows Exporter からメトリクスをスクレイプして、HTTPS（ポート 443）経由で Sysdig Monitor の Remote Write エンドポイント（/prometheus/remote/write）へ転送します。

  3. Sysdig Monitor:

    転送された時系列データを受信し、PromQL によるクエリ実行およびダッシュボード表示を行います。

（2）textfile コレクターによるメトリクスの追加

Windows Exporter の標準コレクターでは取得できない PaperCut 固有の状態を収集するため、textfile コレクター（--collector.textfile.directory）を使用しました。

  • 動作仕様:

    指定ディレクトリ内に配置された .prom 拡張子のテキストファイルからメトリクスを読み込みます。ファイル末尾には改行コードが必要です。

  • 追加したメトリクス:
    • papercut_sharejob_file_count（表示名：SharedJobCount）：Web Print のホットフォルダおよびスプール共有領域に存在するファイルの合計数。
    • papercut_print_jobs_total（表示名: 保留ジョブ数）：PaperCut 上で保留（Hold）状態にある印刷ジョブの総数。

3. PaperCut Web Print の概要とライフサイクル

（1）Web Print サンドボックスモードの構成

PaperCut の Web Print サンドボックスモードは、印刷処理を専用の Windows マシン（サンドボックスサーバー）で実行する構成です。Application Server とサンドボックスサーバー間は、ホットフォルダ（SMB 共有、本環境では W:\ ドライブとしてマウント）を介して通信します。

（2）Web Print のライフサイクル

ドキュメントのアップロードから完了までの各ステップは以下の通り定義されています。

  1. Upload: ユーザーがブラウザから PaperCut Application Server へファイルをアップロードします。
  2. Storing to Hot Folder (Shared Folder): アップロードされたファイルが Application Server 上のホットフォルダ（web-print-hot-folder）に書き込まれます。
  3. Rendering: サンドボックスサーバーがホットフォルダ内のファイルを検知し、対応アプリケーション（内蔵の pdf.exe 等）を起動して印刷形式へ変換します。
  4. Queued for Printing: レンダリングされたジョブがプリンターの印刷キューに送信され、プリントリリースが有効な場合は保留状態で待機します。
  5. Printing: ユーザーの操作によりジョブが解放され、プリンターへ印刷データが送出されます。
  6. Tracking: Web 画面上でジョブのステータスが更新され、一定時間経過後に完了処理および中間ファイルの削除が行われます。

4. 動作確認結果とログ・メトリクスの突合

JMeter を用いてテスト用 PDF ファイル（1ファイル約 102 KB、3 ページ）を複数回投入し、サンドボックスサーバーの web-print.log と Sysdig Monitor のメトリクスを照合しました。

（1）ログから確認された動作

  1. 初期化とフォーマット認識:
    • 起動時、サンドボックスサーバーがホットフォルダ（W:\）を認識した後、Web Print 用プロセスが起動します。
    • ホットフォルダの認識後、Office アプリケーションがインストールされていないため、mso-word.exe などのハンドラーは「Invalid Handler」と判定されました。一方、PDF、XPS、画像は受付可能な形式として認識されました。
  2. JMeter によるジョブ処理:
    • 00:19:59 〜 00:21:36: 51 件の PDF ジョブを処理。
    • 01:01:39 〜 01:05:20: 90 件の PDF ジョブを処理（所要時間 221 秒）。
    • 02:04:29 〜 02:08:00: 90 件の PDF ジョブを処理（所要時間 211 秒）。
    • 各ジョブの処理開始時刻の差分を確認した結果、本検証環境では、ジョブが 1 件ずつ直列に処理されていました。処理間隔は 1 ジョブあたり約 2.3～2.5 秒で、スループットは約 24～26 ジョブ／分でした。処理エラーは記録されていません。

（2）各ライフサイクルにおけるメトリクス変化

ログに記録された処理時刻と、Sysdig Monitor 上の各グラフの数値を突合した結果は以下の通りです。

1. Upload 〜 Storing to Hot Folder
  • ジョブが投入されると、SharedJobCount（ファイル数）が階段状に増加しました。
    • バッチ 1 後：約 250 件
    • バッチ 2 後：約 650 件
    • バッチ 3 後：約 1,050 件
  • 本検証環境では、投入ジョブ数と SharedJobCount の増加量から、1 つの印刷ジョブにつき原本やメタデータなど約 4～5 個の中間ファイルが生成・保持されたと推定されます。
2. Rendering
  • web-print.log で Processing job ... が記録されている時間帯に一致して、CPU 使用率が上昇しました。
    • バッチ 1（51 件）：約 30%
    • バッチ 2（90 件）：約 60%
    • バッチ 3（90 件）：Core 0 で約 88%、Core 1 で約 80%
  • バッチ 2 とバッチ 3 はいずれも 90 件の投入でしたが、滞留ファイル数が多いバッチ 3 で CPU 使用率のピークが高くなりました。本結果は両者の関連を示すものですが、因果関係を特定するには、他の条件を統制した追加検証が必要です。
  • レンダリング処理中は Disk Write スループットが増加し、バッチ 1 で約 150 KiB/s、バッチ 2 で約 400 KiB/s、バッチ 3 で約 945 KiB/s を記録しました。
3. Queued for Printing（保留中）
  • レンダリング完了後、PaperCut 上の保留ジョブ数は、各バッチの投入に伴って約 50 件、約 150 件、約 260 件へと段階的に増加しました。各バッチの処理完了後は、ジョブをリリースするまでその件数を維持しました。
  • Windows の印刷キュー（test-prin1）でも、PaperCut 側の保留ジョブ数と対応する 260 件のドキュメントが待機していました。
  • 保留状態の間、メモリ使用率は約 70 〜 75% で推移しました。
4. Printing（一括リリース時）
  • PaperCut 管理画面から 260 件の保留ジョブに対して「すべてリリース」を実行したところ、以下の数値変化を確認しました。
    • SharedJobCount: 約 1,050 件から 93 件へ減少。
    • 保留ジョブ数: 260 件から順次減少（219 件等を経て消化）。
    • CPU 使用率: アイドル状態から約 65% へ上昇。
    • Disk Write IOPS / Throughput: 約 68 IOPS、約 7.2 MiB/s を記録。
    • Disk Read IOPS / Throughput: 約 240 IOPS、約 5.6 MiB/s を記録。
    • MemoryUsage: 75% 前後から一時的に約 55% まで低下した後、約 88% まで上昇。
5. Tracking
  • ジョブ解放後は、印刷キューの消化に伴って一時ファイルが削除されました。その後、CPU 使用率は約 10% のベースラインへ戻り、Disk I/O もほぼ 0 まで低下しました。

5. 検証結果のまとめ

今回の動作確認から得られた事項は以下の通りです。

  1. Web Print 処理特性の確認:
    • 本検証環境では、PaperCut Web Print の PDF レンダリングが直列に実行され、処理間隔は 1 ジョブあたり約 2.3～2.5 秒、スループットは約 24～26 ジョブ／分でした。
    • ジョブを保留したままにすると、ホットフォルダ内の一時ファイル（SharedJobCount）が累積しました。また、本検証では、同一投入量でも滞留ファイル数が多いバッチほど CPU 使用率と Disk Write スループットのピークが高くなる傾向が見られました。
  2. システム負荷の集中ポイント:
    • 最も高いディスク I/O（Write: 約 7.2 MiB/s、Read: 約 5.6 MiB/s）は、ジョブ投入時ではなく、保留ジョブの一括リリース（Printing）時に発生しました。
  3. Sysdig Monitor による可視化の有効範囲:
    • Windows Exporter の標準メトリクス（CPU、メモリ、Disk I/O）と、textfile コレクターで収集した PaperCut 固有メトリクス（保留ジョブ数、SharedJobCount）を同一画面で時系列に比較しました。これにより、ログに記録された処理とシステムリソースの変動との対応を確認できました。
    • ホットフォルダ内のファイル滞留やスプールキューの増加、およびそれに伴う CPU・ディスク負荷の変動を Sysdig Monitor 上で把握できることを確認しました。

■参考資料

1.Sysdig

2.PaperCut

担当者紹介

担当者名
冨田
コメント
Sysdigを中心にコンテナ、Kubernetes、RedHatプロダクト領域の業務に従事しています。
保有資格
PMP、IT コーディネータ、G 検定、EX280
PaperCut Hive Tech Foundation Certified, PaperCut Tech Certified Foundation

SCSK技術者ブログ

Sysdig Monitor による PaperCut Web Print の監視について

Sysdig Monitor による PaperCut Web Print の監視について
SysdigのAI機能を徹底解説！ SageからMCP Serverまで、4つのツールの使い分け

SysdigのAI機能を徹底解説！ SageからMCP Serverまで、4つのツールの使い分け
セキュリティ運用の効率化を実現するSysdigとSIEMの連携：Agent Local機能の実装ガイド

セキュリティ運用の効率化を実現するSysdigとSIEMの連携：Agent Local機能の実装ガイド
Sysdig Secure新機能レビュー：EOLまでのカウントダウン表示でライフサイクル管理も支援(Software Lifecycle and End-of-Life Visibility)

Sysdig Secure新機能レビュー：EOLまでのカウントダウン表示でライフサイクル管理も支援(Software Lifecycle and End-of-Life Visibility)
【動画公開】結局「CNAPP」って何なのさ？ CNAPPとSysdigをゼロトラストセキュリティから学びなおそう（最新版）

【動画公開】結局「CNAPP」って何なのさ？ CNAPPとSysdigをゼロトラストセキュリティから学びなおそう（最新版）
Sysdigで始める「守りのセキュリティ」：コンプライアンスチェック機能の重要性と活用術

Sysdigで始める「守りのセキュリティ」：コンプライアンスチェック機能の重要性と活用術
Sysdigで実現するKubernetesのSOAR！新機能「Automation」でセキュリティ運用を自動化してみた

Sysdigで実現するKubernetesのSOAR！新機能「Automation」でセキュリティ運用を自動化してみた
今のSysdig Secureはどう選ぶ？現在のライセンス体系を分かりやすく解説

今のSysdig Secureはどう選ぶ？現在のライセンス体系を分かりやすく解説
FIM Policyで可視化する コンテナ内ファイルの変更

FIM Policyで可視化する コンテナ内ファイルの変更
Sysdigのサプライチェーンポリシーを試してみる

Sysdigのサプライチェーンポリシーを試してみる
Sysdig MCP Server x Claude Desktopを試してみました【セットアップから実践まで】

Sysdig MCP Server x Claude Desktopを試してみました【セットアップから実践まで】
Sysdig運用の基本！トラブルシューティングのポイントを解説

Sysdig運用の基本！トラブルシューティングのポイントを解説
クラウドにおけるサーバーレスワークロードの保護：Sysdig Secureによるアプローチ

クラウドにおけるサーバーレスワークロードの保護：Sysdig Secureによるアプローチ
Platform Engineering Kaigi 2025 参加レポート

Platform Engineering Kaigi 2025 参加レポート
検知から対応をシームレスに！ Sysdigの新機能「Response Action」でインシデント対応を迅速化

検知から対応をシームレスに！ Sysdigの新機能「Response Action」でインシデント対応を迅速化
【SCSK技術者によるブログ】生成AIでSysdigエージェントのアップグレードを効率化 〜Helm values.yamlの移行作業を自動化〜

【SCSK技術者によるブログ】生成AIでSysdigエージェントのアップグレードを効率化 〜Helm values.yamlの移行作業を自動化〜
【SCSK技術者によるブログ】Sysdigの「Search」機能を体験！生成AIでクエリの学習コスト無しに脆弱性調査

【SCSK技術者によるブログ】Sysdigの「Search」機能を体験！生成AIでクエリの学習コスト無しに脆弱性調査
【SCSK技術者によるブログ】ゼロトラスト文脈でのクラウドセキュリティ、そしてSysdig

【SCSK技術者によるブログ】ゼロトラスト文脈でのクラウドセキュリティ、そしてSysdig
【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ネットワークポリシー編~

【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ネットワークポリシー編~
【SCSK技術者によるブログ】生成AIで過検知対策を効率化！Sysdig Sageの実力検証

【SCSK技術者によるブログ】生成AIで過検知対策を効率化！Sysdig Sageの実力検証
【SCSK技術者によるブログ】なぜ今、Sysdigが選ばれるのか？動画で解説！クラウドネイティブセキュリティの最前線 - SCSKの日本語伴走サポートで安心導入

【SCSK技術者によるブログ】なぜ今、Sysdigが選ばれるのか？動画で解説！クラウドネイティブセキュリティの最前線 - SCSKの日本語伴走サポートで安心導入
【SCSK技術者によるブログ】Serverless AgentがAzure Container Appsに対応しました

【SCSK技術者によるブログ】Serverless AgentがAzure Container Appsに対応しました
【SCSK技術者によるブログ】システムコール分析における生成AIの活用

【SCSK技術者によるブログ】システムコール分析における生成AIの活用
【SCSK技術者によるブログ】Sysdig情報アップデート～AWS連携にS3オプションが追加されました～

【SCSK技術者によるブログ】Sysdig情報アップデート～AWS連携にS3オプションが追加されました～
【SCSK技術者によるブログ】Falco初学者講座 - Exceptions編

【SCSK技術者によるブログ】Falco初学者講座 - Exceptions編
【SCSK技術者によるブログ】Falco初学者講座 - List/Macro編

【SCSK技術者によるブログ】Falco初学者講座 - List/Macro編
【SCSK技術者によるブログ】コンテナの電力消費をSysdig Monitorで監視してみよう

【SCSK技術者によるブログ】コンテナの電力消費をSysdig Monitorで監視してみよう
【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~Contianer Drift編~

【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~Contianer Drift編~
【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう②

【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう②
【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう①

【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう①
【 SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた(Monitor編)

【 SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた(Monitor編)
【SCSK技術者によるブログ】Falco初学者講座 - condition編

【SCSK技術者によるブログ】Falco初学者講座 - condition編
【SCSK技術者によるブログ】Sysdig Sageを使ってみた

【SCSK技術者によるブログ】Sysdig Sageを使ってみた
【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編②~

【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編②~
【SCSK技術者によるブログ】Sysdigをセキュアに使おう~IP Allowlist編~

【SCSK技術者によるブログ】Sysdigをセキュアに使おう~IP Allowlist編~
【SCSK技術者によるブログ】Node ExporterをSysdig Monitorに連携してみた

【SCSK技術者によるブログ】Node ExporterをSysdig Monitorに連携してみた
【SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた

【SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた
【SCSK技術者によるブログ】CNAPPの理解とSysdigのカバレッジ

【SCSK技術者によるブログ】CNAPPの理解とSysdigのカバレッジ
【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~マルウェア検知編~

【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~マルウェア検知編~
【SCSK技術者によるブログ】Sysdigのライセンス体系

【SCSK技術者によるブログ】Sysdigのライセンス体系
【SCSK技術者によるブログ】Sysdig とMicrosoft Entra ID間でSAML認証設定を試してみた

【SCSK技術者によるブログ】Sysdig とMicrosoft Entra ID間でSAML認証設定を試してみた
【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編~

【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編~
【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~AWSサインインなりすまし検知編~

【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~AWSサインインなりすまし検知編~
【SCSK技術者によるブログ】Sysdig SecureのRisks機能を試してみた

【SCSK技術者によるブログ】Sysdig SecureのRisks機能を試してみた
【SCSK技術者によるブログ】Sysdigの防御機能Kill Processを試してみた

【SCSK技術者によるブログ】Sysdigの防御機能Kill Processを試してみた
ページトップへ