構成ログ

最終公開日 : Nov 13, 2026
構成ログは、サイト構成の変更と管理アクティビティをデータベースにキャプチャする機能です。この機能はデフォルトで有効になっています。ログに記録されたコンテンツは、次の目的で使用できます。
  • 構成変更後、問題の診断とトラブルシューティングを行います。ログは追跡記録を提供します。
  • 変更管理の支援と構成の追跡。
  • 管理アクティビティを報告します。
Citrix Studioから、構成ログ設定の指定、構成ログの表示、HTMLおよびCSVレポートの生成を行うことができます。構成ログの表示は、日付範囲や全文検索結果でフィルタリングできます。強制ログが有効になっている場合、ログに記録できない構成変更は行えません。適切な権限があれば、構成ログからエントリを削除できます。構成ログ機能を使用してログコンテンツを編集することはできません。
構成ログは、PowerShell SDKと構成ログサービスを使用します。構成ログサービスは、サイト内のすべてのControllerで実行されます。いずれかのControllerが失敗した場合、別のControllerのサービスが自動的にログ要求を処理します。
デフォルトでは、構成ログ機能は有効になっており、サイト作成時に作成されるデータベース(サイト構成データベース)を使用します。データベースの別の場所を指定できます。構成ログデータベースは、サイト構成データベースと同じ高可用性機能をサポートしています。
構成ログへのアクセスは、委任管理を通じて、「ログ設定の編集」および「構成ログの表示」の権限で制御されます。
構成ログは作成時にローカライズされます。たとえば、英語で作成されたログは、リーダーのロケールに関係なく、英語で読み取られます。

ログに記録される内容

Studio、Director、およびPowerShellスクリプトから開始された構成変更と管理アクティビティがログに記録されます。ログに記録される構成変更の例には、以下に関する作業(作成、編集、削除、割り当て)が含まれます。
  • マシンカタログ
  • デリバリーグループ(電源管理設定の変更を含む)
  • 管理者ロールとスコープ
  • ホストリソースと接続
  • Studioを介したCitrixポリシー
ログに記録される管理変更の例には、以下が含まれます。
  • 仮想マシンまたはユーザーデスクトップの電源管理
  • StudioまたはDirectorがユーザーにメッセージを送信する
次の操作はログに記録されません。
  • プール管理による仮想マシンの電源投入などの自律的な操作。
  • グループポリシー管理コンソール (GPMC) を介して実装されたポリシーアクション。これらのアクションのログを表示するには、Microsoftツールを使用してください。
  • レジストリ、データベースへの直接アクセス、またはStudio、Director、PowerShell以外のソースを通じて行われた変更。
  • 展開が初期化されると、最初の構成ログサービスインスタンスが構成サービスに登録されたときに、構成ログが利用可能になります。したがって、構成の初期段階(たとえば、データベーススキーマが取得および適用されるとき、ハイパーバイザーが初期化されるとき)はログに記録されません。

構成ログの管理

デフォルトでは、構成ログはサイトの作成時に作成されるデータベース(サイト構成データベースとも呼ばれます)を使用します。Citrixは、次の理由により、構成ログデータベース(および監視データベース)に別の場所を使用することを推奨します。
  • 構成ログデータベースのバックアップ戦略は、サイト構成データベースのバックアップ戦略とは異なる可能性があります。
  • 構成ログ(および監視サービス)のために収集されるデータ量によって、サイト構成データベースで利用可能な領域に悪影響が及ぶ可能性があります。
  • これにより、3つのデータベースの単一障害点が分割されます。
構成ログをサポートしない製品エディションには、Studioにログノードがありません。

構成ログと強制ログの有効化と無効化

デフォルトでは、構成ログは有効になっており、強制ログは無効になっています。
  1. Web Studio にサインインし、左側のペインで Logging を選択します。
  2. アクションバーで Preferences を選択します。構成ログのダイアログボックスには、データベース情報が含まれており、構成ログと強制ログが有効か無効かを示します。
  3. 希望するアクションを選択します。
    構成ログを有効にするには、Enable を選択します。これはデフォルト設定です。データベースに書き込みができない場合、ログ情報は破棄されますが、操作は続行されます。
    構成ログを無効にするには、Disable を選択します。以前にログが有効になっていた場合、既存のログはPowerShell SDKで読み取り可能です。
    強制ログを有効にするには、Prevent changes to the site configuration when the database is not available を選択します。通常ログに記録される構成変更や管理アクティビティは、構成ログデータベースに書き込みが可能な場合にのみ許可されます。強制ログは、構成ログが有効になっている場合(Enable が選択されている場合)にのみ有効にできます。構成ログサービスが失敗し、高可用性が使用されていない場合、強制ログが有効であると見なされます。そのような場合、通常ログに記録される操作は実行されません。
    強制ログを無効にするには、Allow changes when to the site configuration when the database is not available を選択します。構成ログデータベースにアクセスできない場合でも、構成変更と管理アクティビティが許可されます。これはデフォルト設定です。

構成ログデータベースの場所を変更する

強制ログが有効になっている場合、データベースの場所を変更することはできません。場所の変更には、ログに記録できない短い切断期間が含まれるためです。
  1. サポートされているSQL Serverバージョンを使用して、データベースサーバーを作成します。
  2. Web Studio にサインインし、左側のペインで Logging を選択します。
  3. アクションバーで Preferences を選択します。
  4. ログ設定ダイアログボックスで、Change logging database を選択します。
  5. ログデータベースの変更ダイアログボックスで、新しいデータベースサーバーを含むサーバーの場所を指定します。有効な形式については、データベースアドレス形式を参照してください。
  6. Studio がデータベースを作成できるようにするには、OK をクリックします。プロンプトが表示されたら OK をクリックすると、データベースが自動的に作成されます。Studio は、現在のStudioユーザーの資格情報を使用してデータベースにアクセスしようとします。それが失敗した場合、データベースユーザーの資格情報の入力を求められます。その後、Studio はデータベーススキーマをデータベースにアップロードします。(資格情報はデータベース作成中のみ保持されます。)
  7. データベースを手動で作成するには、データベーススクリプトの生成をクリックします。生成されたスクリプトには、データベースを手動で作成するための手順が含まれています。スキーマをアップロードする前に、データベースが空であり、少なくとも1人のユーザーがデータベースにアクセスして変更する権限を持っていることを確認してください。
以前のデータベースの構成ログデータは、新しいデータベースにはインポートされません。ログを取得する際に、両方のデータベースからログを集約することはできません。新しい構成ログデータベースの最初のログエントリは、データベースの変更が発生したことを示しますが、以前のデータベースを特定するものではありません。

構成ログコンテンツの表示

構成ログコンテンツを表示するには、左ペインでログを選択し、次にイベントタブを選択します。
デフォルトでは、イベントログは管理者名で一覧表示されます。必要に応じて、次のタスクを実行できます。
  • ログの詳細を表示します。 高レベルの操作は、1つ以上のサービスおよびSDK呼び出し(低レベルの操作)をもたらします。上部ペインで高レベルの操作を選択すると、下部ペインに低レベルの操作が表示されます。
  • 表示を並べ替えます。 列ヘッダーをクリックして表示を並べ替えます。
  • ログをフィルターします。 日間隔やカスタム期間などのフィルター条件を設定するか、検索ボックスにメインタスクの完全または部分的な名前を入力して、表示を絞り込みます。検索を使用した後に標準表示に戻るには、検索ボックスのテキストをクリアします。
  • ログをエクスポートします。 選択したログまたはすべてのログをCSVファイルにエクスポートして、アーカイブまたは詳細な分析を行います。
  • 列をカスタマイズします。 クライアントIPやラベルなどのデフォルト以外の列を追加して、表示をニーズに合わせて調整します。
  • ラベルを管理します。 イベントログのラベルを追加、編集、削除して、ログの整理と追跡を強化します。
表示特性:
  • 操作が完了する前に失敗した場合、ログ操作がデータベースで完了しない可能性があります。たとえば、開始レコードに対応する停止レコードがない場合などです。このような場合、ログには情報が不足していることが示されます。時間範囲に基づいてログを表示すると、データが基準に一致する場合、不完全なログが表示されます。
    たとえば、過去5日間のログを要求し、過去5日間に開始時刻があるログに終了時刻がない場合、それも含まれます。
  • PowerShellコマンドレットを呼び出すスクリプトを使用する場合、親の高レベル操作を指定せずに低レベル操作を作成すると、構成ログは代理の高レベル操作を作成します。

レポートを生成する

構成ログデータを含むCSVおよびHTMLレポートを生成できます。
  • CSVレポートには、指定された時間間隔のすべてのログデータが含まれます。データベース内の階層データは、単一のCSVテーブルにフラット化されます。データのどの側面もファイル内で優先されません。書式設定は使用されず、人間が読み取れることは想定されていません。ファイル(MyReportという名前)には、普遍的に利用可能な形式でデータが含まれています。CSVファイルは、データのアーカイブや、Microsoft Excelなどのレポート作成ツールまたはデータ操作ツールのデータソースとしてよく使用されます。
  • HTMLレポートは、指定された時間間隔のログデータを人間が読み取れる形式で提供します。変更を確認するための構造化されたナビゲート可能なビューを提供します。HTMLレポートは、SummaryとDetailsという名前の2つのファイルで構成されます。Summaryには、各操作がいつ、誰によって、どのような結果になったかなど、高レベルの操作が一覧表示されます。各操作の横にあるDetailsリンクをクリックすると、Detailsファイル内の低レベルの操作に移動し、追加情報が表示されます。
構成ログレポートを生成するには、StudioナビゲーションペインでLoggingを選択し、アクションバーでCreate custom reportを選択します。
  • レポートの日付範囲を選択します。
  • レポート形式(CSV、HTML、またはその両方)を選択します。
  • レポートを保存する場所を参照します。

構成ログコンテンツを削除する

構成ログを削除するには、特定の委任管理権限とSQL Serverデータベース権限が必要です。
  • 委任管理: 展開構成の読み取りを許可する委任管理ロールが必要です。完全管理者ロールにはこの権限があります。カスタムロールには、カテゴリでまたはが選択されている必要があります。
    構成ログデータを削除する前にバックアップを作成するには、カスタムロールのカテゴリでまたはが選択されている必要もあります。
  • SQL Serverデータベース: データベースからレコードを削除する権限を持つSQL Serverログインが必要です。これには2つの方法があります。
    • データベースサーバー上のあらゆるアクティビティを実行できるsysadminサーバーロールを持つSQL Serverデータベースログインを使用します。または、serveradminまたはsetupadminサーバーロールを使用すると、削除操作を実行できます。
    • 展開でより高いセキュリティが必要な場合は、データベースからレコードを削除する権限を持つデータベースユーザーにマッピングされた非sysadminデータベースログインを使用します。
      1. SQL Server Management Studioで、「sysadmin」以外のサーバーロールを持つSQL Serverログインを作成します。
      2. ログインをデータベース内のユーザーにマッピングします。SQL Serverは、ログインと同じ名前のユーザーをデータベース内に自動的に作成します。
      3. データベースロールメンバーシップで、データベースユーザーのロールメンバーのうち少なくとも1つを指定します: ConfigurationLoggingSchema_ROLE または dbowner。
      詳細については、SQL Server Management Studioのドキュメントを参照してください。
構成ログを削除するには:
  1. Web Studioにサインインし、左ペインでログを選択します。
  2. アクションバーでログの削除を選択します。
  3. ログを削除する前にバックアップを作成するかどうかを尋ねられます。バックアップを作成することを選択した場合、バックアップアーカイブが保存される場所を参照します。バックアップはCSVファイルとして作成されます。
構成ログがクリアされた後、ログの削除は空のログに投稿される最初のアクティビティです。そのエントリには、誰がいつログを削除したかに関する詳細が記載されています。

APIおよびPowerShellログの表示

現在のセッション中に作成されたAPIリクエストを監視するには、APIタブをクリックします。APIログは、Web Studioからサインアウトするとクリアされます。
その日に行ったUIアクションに対応するPowerShellコマンドを表示するには、PowerShellタブをクリックします。

構成ログにメタデータを関連付ける

ログレコードにMetadataMapと呼ばれるname-valueペアを関連付けることで、構成ログにメタデータを添付できます。
注:
  • メタデータは、高レベルの操作オブジェクトにのみ添付できます。
  • メタデータは、実行時に既存のレコードに関連付けられます。

メタデータを設定する

ログレコードをMetadataMapに関連付けるには、PowerShellコマンドSet-LogHighLevelOperationMetadataを実行します。 Set-LogHighLevelOperationMetadataは次のパラメーターを受け取ります。
  • Id: 上位レベルの操作のID。
  • InputObject: メタデータを追加する上位レベルの操作。これは、上位レベルの操作オブジェクトまたはオブジェクトのリストがPowerShellコマンドに渡されるIdパラメーターの代替です。
  • Name: 追加するメタデータのプロパティ名。このプロパティは、指定された上位レベルの操作に対して一意である必要があります。このプロパティには、次の文字を含めることはできません: ()\/;:#.*?=<>|"'。
  • Value: プロパティの値。
  • Map: プロパティの(名前、値)ペアの辞書。これは、-Nameおよび-Valueパラメーターを使用してメタデータを設定する代替手段です。
たとえば、Id 40を持つすべての高レベルログレコードにメタデータを添付するには、次のPowerShellコマンドを実行します。
Get-LogHighLevelOperation – Id 40 | Set-LogHighLevelOperationMetadata -Name A -Value B
ユーザーabc@example.comを持つ上位レベルのレコードにメタデータを添付するには、次のPowerShellコマンドを実行します。
Get-LogHighLevelOperation – User `abc@example.com` | Set-LogHighLevelOperationMetadata -Name C -Value D

メタデータを使用して取得する

関連付けられたメタデータを使用してログレコードを取得するには、次のPowerShellコマンドを実行します。
  • キーと値で検索:
    Get-LogHighLevelOperation -Metadata "Key:Value"
  • 値で任意のキーを検索:
    Get-LogHighLevelOperation -Metadata "*:Value"
  • キーと任意の値で検索:
    Get-LogHighLevelOperation -Metadata "Key:*"

メタデータを削除する

関連付けられたメタデータを削除するには、PowerShell コマンド Remove-LogHighLevelOperationMetadata を実行します。 Remove-LogHighLevelOperationMetadata は次のパラメーターを受け入れます。
  • Id: 高レベル操作のID。
  • InputObject: メタデータを追加する高レベル操作。これは、高レベル操作オブジェクトまたはオブジェクトのリストがPowerShellコマンドに渡される `Id`` パラメーターの代替です。
  • Name: 削除するメタデータのプロパティ名。指定されたオブジェクトのすべてのメタデータを削除するには、$null に設定します。
  • Map: プロパティの (名前、値) ペアの辞書。これはハッシュテーブル (@{"name1" = "val1"; "name2" = "val2"} で作成) または文字列辞書 (new-object "System.Collections.Generic.Dictionary" で作成) のいずれかです。マップ内のキーと名前が一致するプロパティは削除されます。

ベストプラクティス

  1. まず直接パラメーターを使用します。アクションについてわかっていることを、対応するパラメーター (-User、-OperationType、-TargetType、-Source、または -IsSuccessful) と一致させます。
  2. 常に時間範囲を含めます。-StartTime と -EndTime は、あらゆるクエリで最も効果的な最初のフィルターです。
  3. 高レベルから低レベルへドリルダウンします。特定のアクションを調査するときは、まず高レベル操作を取得し、そのIDを -HighLevelOperationId とともに使用します。
  4. エクスポートを対象期間に限定します。-StartDateRange と -EndDateRange を使用して、関連する時間枠をターゲットにします。
  5. 表示名が不要な場合は、エクスポートで -RawReport を使用します。これにより、処理時間と出力サイズが削減されます。