標準出力とエラーへのログの書き込み

Code Engine では、ワークロードによって生成されたログレコードは、 stdout または stderr に書き込まれたときにのみ収集されます。これは、ログファイルを管理するのではなく、ログをイベントストリームとして扱うことを推奨する Twelve-Factor App ガイドラインに従ったものです。 クラウド・ネイティブ・アプリケーションの作成：12ファクターのアプリケーション - ファクター11 - ログ を参照。

プラットフォームのロギング・パイプラインは、この出力を自動的にキャプチャして処理し、分析やトラブルシューティングに利用できるようにする。 コンテナのエフェメラル・ファイル・システム内のファイルに書き込まれたログ行は、取り込まれず、永続化されず、ロギング・インターフェースを通じて公開されない。 その結果、エフェメラル・ファイル・システムに保存されたログは、インスタンスが再起動または終了すると失われ、運用のデバッグや根本原因の分析に利用できなくなる。

ログ行にタイムスタンプを加えるべきか？

ユーザーのワークロードによって生成されたログレコードは、 Code Engine インフラストラクチャが自動的にタイムスタンプを取得し、標準化するため、独自のタイムスタンプ情報を埋め込むことは避けるべきである。 アプリケーションレベルのタイムスタンプを含めると、特にシステムクロックがずれたり違ったりする可能性のある分散環境やコンテナ環境でワークロードが実行される場合、サービス間で不整合が生じる可能性がある。 プラットフォームのタイムスタンプに依存することで、統一された時間フォーマット、正確なシーケンス、および他のシステム生成ログとの信頼性の高い相関が保証され、展開全体にわたるトラブルシューティング、監査、および観測可能性が簡素化されます。

私のログレベルは、 IBM Cloud Logs の重要度にどのように対応しますか？

各ログレコードで提供されるログレベルは、「 ログの重大度を IBM Cloud Logs の重大度にマッピングする 」の説明に従って、 IBM Cloud Logs の重大度にマッピングされる。 以下のセクションでは、非構造化ログと構造化ログのログレベルがどのように解析され、どのログレベル値がサポートされるかについて詳しく説明します。

ログデータが複数行にわたる場合は？

IBM Cloud Logs の検索とフォーマット機能を利用するには、以下のようにログのフォーマットを変更してください。

• ログの行が複数行にまたがる場合は、ログの書式と出力方法を変更して、1行に収まるようにしてください。 IBM Cloud Logs を使用して、ログにJSONLフォーマット（「 ログのフォーマット 」を参照）を使用します。
• ログは IBM Cloud Logs の制限に 適合していなければならない。

例

以下は、構造化されていないログ行（自由形式のテキスト）を標準出力に書き出す簡単な例である。

サンプルは、 Code Engine パブリックサンプルリポジトリ https://github.com/IBM/CodeEngine/blob/main/logging/README.md に公開されています。

Node.js (JavaScript)

console.log('User signup succeeded for account abc123');

Python

print("User signup succeeded for account abc123")

Golang

package main

import (
    "fmt"
)

func main() {
    fmt.Println("User signup succeeded for account abc123")
}

Java

package com.ibm.cloud.codeengine.sample;

public class App {
    public static void main(String[] args) {
        System.out.println("User signup succeeded for account abc123");
    }
}

ログレベル検出

各ログ記録は、深刻度を決定するためにキーワードでスキャンされる。 深刻度の値は、大文字小文字を区別せずに評価され、 critical、 error、 warn、 info、 debug、 verbose となる。

ログ行が LEVEL MESSAGE の形式で重大度キーワードで始まる場合、 Code Engine は、表示されたログメッセージから検出されたレベルを削除します。これにより、ユーザは、 IBM Cloud Logs ビューで重大度によって正確にフィルタリングしながらも、コアコンテンツに集中することができます。 この場合、抽出された重大度値はログレコードのフィールド level に格納されます。 以下の大文字小文字を区別しない重大度レベルがサポートされている： fatal error, warn, info, debug, および trace。 例えば、 Node.js ：

// Unstructured log with level prefix
console.log('ERROR Payment service timeout while creating invoice');

IBM Cloud Logs では、この項目は深刻度 「Error 」で表示され、 「請求書作成中に決済サービスがタイムアウトしました」というメッセージが表示されます。 深刻度「Error 」でフィルタリングして結果を絞り込むことができます。 また、構文解析ルールと重大度ルールを使用して、レベルの抽出方法と照合方法を環境に合わせて調整することもできる。

ログ・レベルの検出は、ログ行が LEVEL: MESSAGE や [LEVEL] MESSAGE のように微妙に異なる書式に従っている場合にも機能する。 しかし、このような場合、重要度が適切に分類されていても、ログメッセージからlevelキーワードは削除されない。

さらに、検出ロジックは、サポートされるキーワードが冒頭だけでなく、 メッセージ内の任意の場所、重大度レベルを推測することができます。 例えば、ログライン：

The payment workflow encountered an unexpected error during validation

このログ行は、メッセージテキストにエラーという単語が表示されているため、 エラーに分類される。

ログレベル検出では、入力ストリーム（stdout または stderr ）は考慮されません。 そのため、標準エラー(stderr)に書き込まれたログ・メッセージは、純粋にメッセージ・テキストだけで評価される。 例えば、 console.error("Some message") は標準エラーに書き込まれるが、 Infoに分類される。

ファンクションワークロードの場合、ログレベルが、 LEVEL MESSAGE の形式でログ行の先頭に検出されても、表示されたログメッセージから削除されることはない。

タイムスタンプの解析と評価

アプリケーションのログ行にタイムスタンプを追加することは推奨されません。なぜなら、ログが取り込まれるときに、 Code Engine、自動的に正規化されたタイムスタンプが割り当てられるからです。 ログ行の先頭にタイムスタンプが含まれている場合、システムはそのタイムスタンプの解析を試みる。 それがサポートされている書式の1つにマッチする場合、タイムスタンプは、ログレベルがどのように処理されるかに似て、表示されたログメッセージから取り除かれる。 サポートされているタイムスタンプ形式は以下の通り：

• 2026-02-08T20:30:45.123
• 2026-02-08T20:30:45.123Z
• 2026-02-08T21:03:45.123456Z
• 2026-02-08T21:03:45.123456789Z
• 2026-02-08 21:03:45.123Z
• 2026-02-08 20:30:45.123

ログ行の先頭にタイムスタンプとログレベルの両方が含まれる場合（例えば、 TIMESTAMP LEVEL MESSAGE ）、パイプラインは両方のフィールドを評価する。 両方がサポートされているパターンにマッチする場合、それらはそれぞれ適切に分類され、レンダリングされたログメッセージから取り除かれ、読みやすくフィルタリングしやすいようにメッセージ本体だけが残される。 例えば、以下のフォーマットは正常にパースされる：

• 2026-02-08T21:03:45.123456789Z ERROR Payment service timeout
• 2026-02-08 20:30:45.123 INFO Starting billing workflow

タイムスタンプが表示されるが、サポートされているフォーマットと一致しない場合、そのタイムスタンプはログ行の一部として残り、通常のテキストとして扱われるが、メッセージの残りの部分は通常通り処理される。

関数ワークロードでは、タイムスタンプは解析、評価、ログメッセージからの削除は行われない。 関数のログに含まれるタイムスタンプは、表示されるメッセージの一部として残ります。

マルチライン・サポート

Code Engine は複数行のログエントリーをサポートする。 しかし、ログを出力する際には、改行文字 (\n) が 適切にエンコードされた (\\n) であることを確認しなければなりません。そうすれば、ロギングパイプラインは複数行のメッセージを正しく処理し、レンダリングすることができます。 例えば、 Node.js では、次のような複数行のログ・エントリーを作成できる：

console.log("Starting billing workflow...\\nStep 1: Validating input...\\nStep 2: Processing payment...");

エラーの記録

作業負荷が複数行のエラー・スタック・トレースを出力する場合、構造化されていないコンソール出力の代わりに、構造化されたJSONログ・フォーマットを使用する。 構造化 ログは 複数行のフィールドを確実に保持し、スタックトレースが1つのログレコードにグループ化されることを保証します。

例えば、以下のログメッセージは、キーワード "error" がログメッセージに現れるため、 エラーとして分類される。 しかし、 err オブジェクトによって提供されるスタック・トレースは、複数のログ行で表示される。

try {
  throw new Error("boom!");
} catch (err) {
  console.error("An error occurred", err);
}

例

以下は、 level フィールドにログレベルを、 message フィールドにログメッセージを持つ単一のJSONを生成する、各言語とランタイムの最小構造化ログの例である。

サンプルは、 Code Engine パブリックサンプルリポジトリ https://github.com/IBM/CodeEngine/blob/main/logging/README.md に公開されています。

Node.js ( ウィンストン )

import winston from "winston";
const { combine, json } = winston.format;

// Create a custom logger
const logger = winston.createLogger({
  level: 'info',
  transports: [new winston.transports.Console()],
  format: combine(json())
});

// Usage
logger.info("User signup succeeded")
logger.error("Payment service timeout")

Python ( ログル )

from loguru import logger
import sys
import json
import traceback

# Define a custom JSON sink
def json_sink(message):
    record = message.record

    # Base fields: level + message, no timestamp
    payload = {
        "level": record["level"].name,   # e.g., "INFO"
        "message": record["message"],    # rendered message
    }

    # Merge in any bound extra fields as top-level keys
    # (skip reserved keys to avoid accidental overwrite)
    for k, v in record["extra"].items():
        if k not in ("level", "message", "stack"):
            payload[k] = v

    # If an exception is attached, render full stack trace into "stack"
    exc = record["exception"]
    if exc:
        # exc.type, exc.value, exc.traceback are available from Loguru
        stack_text = "".join(traceback.format_exception(exc.type, exc.value, exc.traceback))
        payload["stack"] = stack_text

    # Emit a single JSON line
    sys.stdout.write(json.dumps(payload, ensure_ascii=False) + "\n")
    sys.stdout.flush()


# Remove default handler (which includes timestamp, etc.) and add our custom sink
logger.remove()
logger.add(json_sink, level="DEBUG")  # lowest level you want to capture

# Usage
logger.info("User signup succeeded")
logger.error("Payment service timeout")

Golang ( スロッグ )

package main

import (
    "log/slog"
    "os"
)

func main() {
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        // Remove time and rename msg->message
        ReplaceAttr: func(groups []string, attr slog.Attr) slog.Attr {
            // Drop the time attribute
            if attr.Key == slog.TimeKey {
                return slog.Attr{} // empty => removed
            }
            // Rename msg to message
            if attr.Key == slog.MessageKey {
                return slog.String("message", attr.Value.String())
            }
            return attr
        },
    })
    logger := slog.New(handler)

    // Usage
    logger.Info("User signup succeeded")
    logger.Error("Payment service timeout")
}

Java ( SLF4J と Logback with logstash-logback-encoder )

src/main/resources/logback.xml:

<configuration>
    <appender name="jsonConsoleAppender" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <timeZone>UTC</timeZone>
            <fieldNames>
                <timestamp>[ignore]</timestamp>
                <logger>[ignore]</logger>
                <version>[ignore]</version>
                <levelValue>[ignore]</levelValue>
                <threadName>[ignore]</threadName>
            </fieldNames>
        </encoder>
    </appender>

    <root level="DEBUG">
        <appender-ref ref="jsonConsoleAppender" />
    </root>
</configuration>

src/main/java/com/ibm/cloud/codeengine/sample/App.java:

package com.ibm.cloud.codeengine.sample;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class App {
  private static final Logger logger = LoggerFactory.getLogger(App.class);

  public static void main(String[] args) {
    logger.info("User signup succeeded");
    logger.error("Payment service timeout");
  }
}

ログレベル検出

各ログ記録は、深刻度を決定するためにキーワードでスキャンされる。 深刻度の値は、大文字小文字を区別せずに評価され、 critical、 error、 warn、 info、 debug、 verbose となる。

構造化ログを使用する場合、 Code Engine は、ログレベルが以下のフィールドのいずれかで提供されると、自動的にそれを検出します： level severity または logLevel。 これらのフィールドの値は、大文字小文字を区別しない。つまり、 error、 ERROR、 Error のようなエントリーは、すべて同じ重大度にマッピングされる。 以下の大文字小文字を区別しない重大度レベルがサポートされている： critical error, warn, info, debug, および verbose。 サポートされているフィールドが存在し、これらの値の1つが含まれている場合、ログレベルが抽出され、正規化され、ログUI内のフィルタリングおよび分類に使用されます。 例えば、以下の構造化されたログ行は、すべてレベル Errorで適切に解釈される：

{ "level": "error", "message": "Payment service timeout" }
{ "severity": "ERROR", "message": "Failed to connect to database" }
{ "logLevel": "eRrOr", "message": "Workflow aborted" }

大文字小文字や使用されている特定のフィールド値に関係なく、プラットフォームはログレベルを正しく識別し、構造化ログデータ全体のフィルタリング、グループ化、分析のためにそれを適用します。

タイムスタンプ評価

構造化ログの場合、 カスタムタイムスタンプは解析も評価もされない。 あなたが提供したタイムスタンプフィールドは、純粋にペイロードデータとして扱われ、プラットフォームは、順序付けとフィルタリングのために、常に独自のインジェストタイムスタンプを適用します。

以下の例では、"timestamp"の値は保存されるが、ログのタイミングでは無視される。

{ "level": "INFO", "message": "Processing started", "timestamp": "2026-02-08T20:30:45.123Z" }

コンテキスト情報の追加

構造化ログをカスタムフィールド（例えば、 requestId、 userId、またはドメイン固有のメタデータ）で充実させることができる。 以下は、先に使用した各スタックの最小限の例である。

カスタムフィールドを簡潔で安定したもの（例えば、ID、コード、または小さな列挙型）に保ち、ロギングインスタンスのフィルタリング可能性を最大化し、カーディナリティを最小化します。

Node.js ( ウィンストン )

logger.debug("A structured log entry that contains an extra key", {
  extra_key: "extra_value",
});

Python ( ログル )

logger.bind(extra_key="extra_value").debug("A structured log entry that contains an extra key")

Golang ( スロッグ )

logger.Debug("A structured log entry that contains an extra key",
  slog.String("extra_key", "extra_value"),
)

Java ( SLF4J と Logback with logstash-logback-encoder )

logger.atDebug().addKeyValue("extra_key", "extra_value")
                .log("A structured log entry that contains an extra key");

エラーの記録

エラーメッセージとそのスタックトレースの 両方を構造化ログに取り込むには、標準フィールド（level、 message ）と stack （または同様の）フィールドを含むJSONレコードを発行する。

Node.js ( ウィンストン )

// Error logging
try {
  throw new Error("boom!");
} catch (err) {
  // The error stack trace is rendered in a single log message (see field stack)
  logger.error("An error occurred", err);
}

Python ( ログル )

try:
  raise RuntimeError("boom!")
except Exception:
  # logger.exception() automatically attaches the current exception info
  logger.exception("An error occurred")

Golang ( スロッグ )

err := errors.New("boom!")
logger.Error("An error occurred",
    slog.Any("err", err),
    // The error stack trace is rendered in a single log message (see field stack)
    slog.String("stack", string(debug.Stack())),
)

Java ( SLF4J と Logback with logstash-logback-encoder )

try {
    throw new RuntimeException("boom!");
} catch (Exception e) {
    logger.atError()
            .setCause(e) // The error stack trace is rendered in a single log message (see field stack_trace)
            .log("An error occurred");
}

関数ワークロードは複数行のログを扱うが、各改行文字は別々のログエントリーになる。 構造化されたロギングフレームワークでスタックトレースをロギングする場合、改行文字を手動でエスケープして、1つのログエントリとして正しく表示されるようにする必要があるかもしれません。

IBM Cloud Logs データにフィルタを適用できますか？

IBM Cloud Logs ページから、特定のアプリケーションリビジョン、ジョブの実行、またはビルドの実行に対して、特定のレベル、またはより詳細なレベルでログデータを表示するために、必要に応じてフィルタを変更し、スコープを設定することができます。

• app:"codeengine" が設定されている場合、 Code Engine のログのみが表示される。

• codeengine.project:'<project_name>' が設定されている場合、特定のプロジェクトのログのみが表示されます。

• codeengine.component:'<your_component_name>' が設定されている場合、指定されたコンポーネント（アプリケーション、ジョブ、ビルド）からのログのみが表示されます。 Code Engine コンポーネントが同じ名前を共有している場合、フィルターにはこれらのコンポーネントからのログが含まれます。 以下に例を示します。

  • フィルター app:"codeengine" AND codeengine.component:"myapp" は、ログを myapp アプリケーションレベルにスコープする。
  • フィルター app:"codeengine" AND codeengine.subcomponent:"myapp\-00002" は、ログを myapp-0002 アプリケーションリビジョンレベルにスコープします。
  • フィルター app:"codeengine" AND codeengine.component:"myjob" は、ログを特定の myjob ジョブレベルにスコープする。
  • フィルター app:"codeengine" AND codeengine.subcomponent:"myjob\-jobrun\-t6m7l" は、ログを特定の myjob-jobrun-t6m7l ジョブ実行レベルにスコープする。
  • フィルター app:"codeengine" AND codeengine.component:"mybuild" は、ログを特定の mybuild ビルド・レベルにスコープする。
  • フィルター app:"codeengine" AND codeengine.subcomponent:"mybuild\-run\-121212" は、ログを特定の mybuild-run-121212 ビルド実行レベルにスコープする。

コンソールでのロギングの設定と開始の詳細については、 コンソールからアプリ、ジョブ、または関数のログを表示するを 参照してください。