Access Gatewayのロギングについて
Access Gatewayは様々なイベントのログを記録します。それらのログはログサーバーに転送したりオンデマンドでダウンロードできます。インラインプロキシとして、Access Gatewayは大量のログイベントを生成してWebトラフィックの重要な可視性を提供します。ただし、大量の永続的なログイベントはディスク容量を消費し、利用可能な情報の代わりにディスクスペースが犠牲となります。
アプリケーションやシステムレベルのコンポーネントを含む多くのAccess Gatewayコンポーネントでは、どのレベルのログイベントを発行するか指定できます。どのログイベントを発行するか指定することは、どのようにログイベントをフィルタリングするかとは別物です。どのログイベントを発行するか指定するために、Access Gatewayはアプリケーションレベルとシステムレベルの構成を提供しています。
項目:
ログイベントの構成
Access Gateway Managementコンソールを使用して、システムコンポーネントから発行されるログイベントのレベルを指定できます。システムコンポーネントにはNGINXエンジン、Kerberos、Access Gateway UI、管理コンソール、基になるShellスクリプト、その他同様のコンポーネントなどが含まれます 。
ロギングの相関図にシステムコンポーネント、アプリケーション、およびログ詳細度のフィルタリングの相互作用を示します。

Access Gatewayシステムコンポーネントとアプリケーションがログイベントを生成します。システムコンポーネントはCommand Line Management Consoleのリファレンスの[Monitor(監視)] > [Enable/Disable debug(デバッグを有効/無効にする)]によってコントロールできます。アプリケーションのデバッグ設定では、アプリケーションがデバッグモードまたは情報モードでログイベントを生成するか否かをコントロールし、ログ詳細度がイベントフィルターとして機能し、ディスクに保存するイベントの数を削減できます。

Access Gateway コンポーネントレベルのロギングでの、新規インストールとアップグレード操作の比較:
アップグレードすると、Access Gatewayは現在のシステム設定値を移行します。コンポーネントのロギングについて、以下に記載の通り、バージョン2020.12.3より前のデフォルトはDebug(デバッグ)です。新規インストールのデフォルトはInfo(情報)です。
コンポーネント | 変更箇所 | デフォルト |
---|---|---|
システムコンポーネント:
| Command Line Management Consoleのリファレンスの[Monitor(監視)] > [Enable/Disable debug(デバッグを有効/無効にする)]をご覧ください。 |
|
アプリケーション | Access Gateway Admin UIコンソールを使用して所定のアプリケーションのデバッグを有効にできます。詳しくは「アプリケーションのトラブルシューティングの「Configure(構成)」セクションをご覧ください。 | Info(情報) |

*Access Gateway Admin UIコンソールサービスはAccess Gateway Managementコンソールの有効/無効設定に基づいてログイベントを発行しますが、ログ詳細度によってフィルタリングされません。
ログの詳細度
Access Gatewayログイベントはローカルに保存されると同時に、graylog、splunkなどのログサーバーに転送されます。ログ詳細度はディスクに保存するイベントの粒度を指定するフィルターで、ディスクリソースの使用量に大きな影響を与えます。ログの粒度は段階的に表され、Debug(デバッグ)が最も粒度が低く、Fatal(致命的)が最も高くなります。例えば、Fatalに設定すると致命的なログイベントのみがディスクに残ります。Error(エラー)に設定すると、 致命的なイベントとエラーイベントがそれ以下のレベルの設定とともに残り、他のすべての高レベルのイベントも含まれます。Debug(デバッグ)ではすべてのイベントが保存されます。Debugはディスク使用率に最も大きな影響を与え、Fatalは最も影響が低くなります。

ログ詳細度の設定は、実際にディスクに保存されるログの粒度を示します。ログがディスクに保存されない場合、これらのログは管理者が「ログのダウンロード」を使用してダウンロードしたログには存在しません。同様に、Oktaサポートもこれらのログを取得できません。
Access Gatewayからダウンロードできるのはディスクに残されているメッセージのみです。高いログレベルを指定すると、そのレベル以下のイベントが破棄(フィルターで除外)されます。例えば、Warn(警告)を選択した場合、Warn以下のメッセージ(InfoやDebugなど)が破棄されます。
メモ:ログの詳細度はログの転送に影響を与えません。ログフォワーダーが設定されている場合、発行されたすべてのイベントはログ詳細度の設定に関わらず転送されます。
ログ詳細度を指定する方法はログ詳細度の管理 をご覧ください。
ログ詳細度とアプリケーションレベルのデバッグ
アプリケーションの一つひとつをデバッグに設定することができます。アプリケーションのデバッグ設定はシステムレベルのログ詳細度を無視してデバッグのレベルを指定しますが、アプリケーションに特化したログイベントに限られます。アプリケーションがデバッグに設定されている場合、すべてのアプリケーション固有のデバッグログイベントはログ詳細度の設定に関わらずディスクに保存されダウンロード可能になります。
注意:アプリケーションをデバッグに設定すると、特定のアプリケーションに対するシステムデバッグレベルの詳細度を優先することが許可されてしまうため、ディスクリソースを急速に消費する可能性があります。
アプリケーションのトラブルシューティング後は必ずデバッグモードを無効にしてください。デバッグモードを有効にしたままにするとログ詳細度は無視されるため、トラフィックが多い場合はディスクの空き容量がすぐになくなります。
問題のトラブルシューティングが完了したら、できるだけ早くアプリケーションのデバッグモードをオフにしてください。デバッグモードのままにするとログ詳細度が無視され、トラフィックが多い場合はディスクの空き容量がすぐになくなります。
アプリケーションのデバッグモードの有効化/無効化や、一般的なアプリケーションのデバッグ手法について詳しくは、アプリケーションのトラブルシューティングをご覧ください。ログの転送


高可用性クラスターでは、ログフォワーダーの定義がメイン管理者ノードに追加され、すべてのワーカーノードに伝達されます。ワーカーノードはログイベントを直接 syslogサーバーに送信します。
一般的に、ログの転送ではAccess GatewayはログをGraylogなどの外部syslogハンドラーに転送するかエクスポートできます。
ログフォワーダーの構成に関する詳細はログフォワーダーの構成をご覧ください。
ログのローテーションおよびアーカイブ
Access Gateway:
- ログを毎日ローテーションします。
- ログファイルを1か月保存し、古いログファイルを削除してディスク容量を節約します。
- Oktaサポートによって構成可能であり、他のログのローテーションとアーカイブスケジュールをサポートします。