Logs

Logs#

This section introduces openYuanrong’s logging system.

Logs on Host Deployment Environment#

The default log paths and files for master and worker nodes are as follows. Each deployment creates a new log directory using a timestamp, such as 20250520091445, where the log directory stores component and function logs. You can also refer to the Deployment Parameters Table to customize log paths and log levels.

Master node:

/tmp/yr_sessions
├── 20250520091445
├── 20250520091612
└── latest
    ├── deploy_std.log
    └── log

Worker node:

/tmp/yr_sessions
├── 20250520091445
├── 20250520091612
└── latest
    ├── deploy_std.log
    └── {node_id}
        └── log

Deployment Logs#

The deployment log file default path is /tmp/yr_sessions/latest/deploy_std.log. You can view deployment parameters and processes through this log to locate deployment issues.

Function Logs#

Function logs are in the log directory. Function standard output is merged into a single file {node_id}-user_func_std.log by default. When you configure the --enable_separated_redirect_runtime_std=true option during deployment, each function execution’s standard output will generate a separate runtime-{runtime_id}.out file.

Function processes also contain some platform logic such as code loading, outputting logs as job-{job_id}-runtime-{runtime_id}.log and runtime-{runtime_id}.log. When function instances fail to start normally, you can check these logs to locate configuration errors such as function package path issues.

Component Logs#

Component logs are in the log directory:

  • function master component: Contains {node_id}-function_master.log and {node_id}-function_master_std.log files, only exists on master node.

  • function scheduler component: Contains {node_id}-scheduler_libruntime.log, faasscheduler.so-run.{timestamp}.log, and {node_id}-scheduler_std.log files, only exists on master node.

  • frontend component: Contains {node_id}-faas_frontend_libruntime.log, faasfrontend.so-run.{timestamp}.log, and {node_id}-faas_frontend_std.log files, only exists on master node.

  • meta service component: Contains meta-service-run.{timestamp}.log and {node_id}-metaservice_std.log files, only exists on master node.

  • dashboard component: Contains dashboard-run.{timestamp}.log and {node_id}-dashboard_std.log files, only exists on master node.

  • function proxy component: Contains {node_id}-function_proxy.log and {node_id}-function_proxy_std.log files.

  • function agent and runtime manager component: Deployed in the same process by default, contains {node_id}-function_agent.log file.

  • data worker component: worker.{INFO|WARNING}.log and ds_worker_std.log files exist on both master and worker nodes. ds_master_std.log and master/worker.{INFO|WARNING}.log files only exist on master node.

  • collector component: Contains {node_id}-collector_std.log file.

  • etcd component: Contains etcd-run.log file, only exists on master node.

Logs on K8s Deployment Environment#

openYuanrong component and function logs are mounted to the host by default. The Function System mount path is /var/paas/sys/log/cff/default, and the Data System mount path is /home/sn/datasystem/logs.

Function system logs:

/var/paas/sys/log/cff/default
├── componentlogs
├── processrouters
│   └── stdlogs
└── servicelogs

Data system logs:

/home/sn/datasystem
└── logs

Mounted Function Logs#

The function log default path is /var/paas/sys/log/cff/default/processrouters/stdlogs. Function standard output is generated in the function-agent-{pools_id}-xxx/{node_id}-user-func_std.log file under the directory corresponding to the resource pool Pod name. Functions running in the same Pod have merged logs into a single file.

Function processes also contain some platform logic such as code loading, outputting logs with default path /var/paas/sys/log/cff/default/servicelogs. In the same resource pool Pod name directory, each function run generates files named job-{job_id}-runtime-{runtime_id}.log and runtime-{runtime_id}.log. When function instances fail to start normally, you can check these logs to locate configuration errors such as function package path issues.

Mounted Component Logs#

  • function scheduler component: Includes files in componentlogs and servicelogs under Pod name function-agent-xxx-faasscheduler-xxx subdirectory.

  • function manager component: Includes files in componentlogs and servicelogs under Pod name function-agent-xxx-faasmanager-xxx subdirectory.

  • frontend component: Includes files in componentlogs and servicelogs under Pod name function-agent-xxx-faasfrontend-xxx subdirectory.

  • function master component: Contains files in componentlogs under Pod name function-master-xxx subdirectory.

  • meta service component: Contains files in componentlogs under Pod name meta-service-xxx subdirectory.

  • IAM adaptor component: Contains files in componentlogs under Pod name iam-adaptor-xxx subdirectory.

  • function proxy component: Contains files in componentlogs under Pod name function-proxy-xxx subdirectory.

  • function agent and runtime manager component: Deployed in the same Pod. In each resource pool Pod name corresponding subdirectory function-agent-{pools_id}-xxx under componentlogs, contains {node_id}-function_agent.log and {node_id}-runtime_manager.log two files.

  • data worker component: Data system component, contains files in worker subdirectory under default path /home/sn/datasystem/logs.

Using openYuanrong’s Logger#

Function services support using openYuanrong’s logger. You can print logs through the function’s context method context.getLogger(), which will produce the same output format as openYuanrong component logs. Taking Java function services as an example, the code and log output are as follows.

package org.yuanrong.demo;

import org.yuanrong.services.runtime.Context;
import org.yuanrong.services.runtime.RuntimeLogger;
import com.google.gson.JsonObject;

public class Demo {
    // Function execution entry point, executed on each request, where input parameter and function return type can be customized
    public String handler(JsonObject event, Context context) {
        RuntimeLogger log = context.getLogger();
        log.info("received request,event content:" + event);

        return event.toString();
    }

    // Function initialization entry point, executed once when function instance starts
    public void initializer(Context context) {
        RuntimeLogger log = context.getLogger();
        log.info("function instance initialization completed");
    }
}

If the request body is set to {“name”:“yuanrong”}, during host deployment, the following log content can be seen in the default log file /tmp/yr_sessions/latest/log/runtime-{runtime_id}/user-log.log.

[16:41:35:820] | [INFO] | org.yuanrong.services.logger.UserFunctionLogger.info(UserFunctionLogger.java:68) | Thread-1 | userLog | function instance initialization completed
[16:41:35:820] | [INFO] | org.yuanrong.executor.FaaSHandler.faasInitHandler(FaaSHandler.java:288) | Thread-1 | userLog | faas init handler complete.
[16:41:35:827] | [INFO] | org.yuanrong.executor.FaaSHandler.execute(FaaSHandler.java:174) | Thread-2 | userLog | executing udf methods, current type: InvokeFunctionStateless
[16:41:35:828] | [INFO] | org.yuanrong.executor.FaaSHandler.faasCallHandler(FaaSHandler.java:300) | Thread-2 | userLog | faas call handler called.
[16:41:35:832] | [INFO] | org.yuanrong.services.logger.UserFunctionLogger.info(UserFunctionLogger.java:68) | Thread-2 | userLog | received request,event content:{"name":"yuanrong"}