log パラメーター
log を使用して、モニター、デバッグ、診断、トラブルシューティング、セキュリティー、監査パフォーマンスの最適化、可視性、および履歴分析のためのロギング・データを有効にします。 IBM® Sterling Intelligent
Promising はデフォルトで、アプリケーション・レベルのログをコンソールに書き込む。 ただし、 Log4j2 Kafka アペンダーを使用して、これらのログを Kafka にリダイレクトすることもできます。
デフォルトのコンソール・ロギング
コンソール・ロギングはデフォルトで有効になっています。 ログにアクセスするには、 kubectl または oc コマンドを使用します。 コンテナーが再始動、削除、または再作成されると、古いログはクリアされます。
Log4j2 Kafka アペンダー・ロギング
Log4j2 Kafka アペンダーを使用して、ログ・メッセージを Kafka トピックに送信します。 Log4j2 Kafka アペンダーを使用するには、 Kafka クラスターがセットアップされ、実行されている必要があります。 すべての IBM Sterling Intelligent Promising サービスには、 Lo4j2 Kafka アペンダーの組み込みサポートがあります。
logに適用可能なオプション・プロパティーについて説明します。| プロパティー | デフォルト値 | 値タイプ | 必須 | 説明 |
|---|---|---|---|---|
logChannels |
CONSOLE |
ストリング | いいえ | ログ出力チャンネルを定義する。 デフォルトでは、コンソール・ロギングは有効になっています。 Log4j2 Kafka アペンダーをロギングに使用したい場合は、 logChannels の値を KAFKA に設定してください。 KAFKA に設定されている場合は、Kakfa固有のプロパティを指定してください。 GELFレイアウトのみが暗黙的にサポートされている。これが |
logLevel |
INFO |
ストリング | いいえ | 個々のサーバー・レベルでログ・レベルを上書きするには、このプロパティを指定します。 許される値は OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL。 詳しくは、 logLevel の種類と優先順位を参照のこと。 |
logTopic |
|
ストリング | いいえ | ロギングに Kafka を選択した場合は、データをログに記録するトピックを指定します。 logTopic は、デフォルトのコンソール・ロギングには適用されません。 |
console.layout |
PATTERN |
ストリング | いいえ |
許される値は |
logExtraFields |
アレイ | いいえ | 各ログ・エントリに含める追加のキーと値のペアのリストを指定する。 これらの値は、環境変数から供給することもできる。 |
ログ・メタデータ内のカスタム属性
- DATACENTER
- Sterling Intelligent Promising デプロイメントをホストおよび管理するコンピュート・クラスターの名前。 例えば、Dublin_data_center などです。
- APP_NAME
- 使用しているアプリケーション・サービスの名前。 許可される値は、
rules、cas、search、およびその他のサービスです。
- component_name
- コンポーネントが API サーバーであるかバックエンド・サーバーであるかを示します。
- NODE_NAME
- クラスター内のワーカー・ノードのホスト名。
- pod_name
- ポッドの名前。
- ポッド IP
- ポッドのプライベート IP。
ログ設定のレベル
以下の3つのレベルでログを設定できる。
- グローバル・ログ・チャンネルの設定
SIPEnvironmentの
logChannelsプロパティを KAFKA または CONSOLEでグローバルに定義する。 このログ設定は、 Sterling Intelligent Promising のすべてのサービスに適用される。
- ログ・レベルの構成
以下のスコープで
logLevelプロパティを定義する。- グローバル・レベル
- このレベルでの設定は、すべての Sterling Intelligent Promising サービスとサーバーに適用される。
- サービス・レベル
- このレベルの構成は、ログレベルが定義されている特定の Sterling Intelligent Promising サービスに適用されます。
- サーバー・レベル
- このレベルでの設定は、特定の Sterling Intelligent Promising サービス内の個々のサーバーに適用される。
- カスタム構成
ログに含める環境名などのカスタムフィールドを定義する。 カスタム設定は、サービスグループと SIPEnvironment レベルで定義できる。 サーバーの場合、最終的なフィールドのセットは、両レベルの組み合わせであ り、サービスレベルのフィールドが優先される。
構成階層
| 範囲 | 目的 | 優先順位 |
|---|---|---|
| グローバル: SIPEnvironment | すべてのサービスとサーバーのデフォルト。 | 最低 |
| サービス・レベル | サービスのグローバル設定を上書きする。 | 中間 |
| サーバー・レベル | 各サーバーのカスタマイズ | 最高 |
ログの設定例
logExtraFields では key:env1 は QA である。 ペアについては key:env2 ペアでは、値は servers.properties で定義されている環境変数から取得されます。 対応する配置にこの環境変数が含まれていることを確認してください。 詳しくは、 serverProperties パラメータを参照。spec:
log:
console:
layout: GELF
logLevel: DEBUG
logChannels: CONSOLE
logExtraFields:
- key: env1
value: QA
- key: env2
envVar: var1
logLevel の種類と優先順位
logLevel プロパティは、個々のサーバー、サービスグループ、またはグローバル (SIPEnvironment) の3つのレベルで設定できる。
デフォルトのログレベルは INFO です。 利用可能なオプションは OFF, FATAL, ERROR, WARN, INFO, DEBUG,
TRACE, ALL。
- 個々のサーバーレベルでのログ記録
- ログはサーバーインスタンスごとにカスタマイズできる。 設定されている場合、個々のサーバーのログレベルが他の設定よりも優先される。
- サービスグループレベルでのロギング
- 個々のサーバーにログレベルが設定されていない場合は、サービスグループレベルで定義された設定が適用されます。
- SIPEnvironmentのグローバルレベルでのロギング
- 個々のサーバーとサービスグループの両方のログレベルが定義されていな い場合、 SIPEnvironmentのグローバル設定が考慮される。 ログレベルがどのレベルでも明示的に設定されていない場合、デフォルトのINFOレベルが適用される。 この階層的アプローチにより、各サーバーインスタンスに合わせたロギング制御が可能になる。
例
完全な設定については、 SIPEnvironmentカスタムリソースマニフェストを参照してください。spec: license: accept: true secret: "" # log: # logChannels: CONSOLE # logTopic: "" # logLevel: INFO
2つの Kafka クラスタのログ構成
2 つの Kafka クラスター (1 つはアプリケーション用、もう 1 つはロギング用) を使用する場合は、 Kafkaの externalServices カスタム・リソースで loggingContactPoints を指定します。 また、シークレットに、接頭部 log_が付いた Kafka プロパティーを追加します。 詳しくは、 秘密の作成を参照してください。
アプリケーションに定義したものと同じ contactPoints を使用する場合は、 loggingContactPointsを定義しないでください。 デフォルトでは、 Kafka トピックにログをプッシュするために contactPoints が使用されます。 Kafkaについて詳しくは、 kafka パラメーターの loggingContactPoints を参照してください。
Logstashのロギング
Kafka 10.0.2601.1 リリース以降、Logstash デプロイメント向けのロギングはサポートされていません。 が に logChannel 設定されている KAFKA場合、ログはコンソールに表示されます。
リリース 10.0.2601.1 前は、すべてのLogstashデプロイメントが以下の形式でログを表示していました。 10.0.2601.1 リリースおよび Operator IBM Sterling Intelligent Promising v1.6.0 以降、 Kafka のロギングは Logstash デプロイメントでサポートされなくなり、GELF レイアウト用の Logstash デプロイメントで使用されるログ形式は新しい形式に変更されました。
{
"version": "1.1",
"host": "sip-search-logstash-0",
"short_message": "Log4j configuration path used is: /opt/app/config/log4j2/log4j2.xml",
"timestamp": "2026-02-16T19:10:46.725+0000",
"level": 6,
"_logger": "logstash.runner",
"_thread": "main",
"log_level": "INFO",
"message": "Log4j configuration path used is: /opt/app/config/log4j2/log4j2.xml",
"app_name": "sip-search-logstash",
"component_name": "demand-inventorytag-reservation-supply",
"datacenter": "local",
"node_name": "worker0.py2.cp.fyre.ibm.com",
"pod_name": "sip-search-logstash-0",
"pod_ip": "10.254.17.12"
}{
"logEvent": {
"level": "WARN",
"loggerName": "org.logstash.deprecation.settings.DeprecatedAlias",
"timeMillis": 1771404940923,
"thread": "main",
"logEvent": {
"message": "The setting `http.host` is a deprecated alias for `api.http.host` and will be removed in version 9. Please use `api.http.host` instead"
}
},
"short_message": "${message}",
"timestamp": "2026-02-18T08:55:40.923+0000",
"component_name": "demand-inventorytag-reservation-supply",
"pod_ip": "10.254.18.102",
"app_name": "sip-search-logstash",
"pod_name": "sip-search-logstash-0",
"datacenter": "local",
"node_name": "worker0.py2.cp.fyre.ibm.com",
"version": "1.1",
"host": "sip-search-logstash-0"
}