Function Compute handlers, lifecycle hooks, and logging - Function Compute

Handlers

Every function requires a handler. The Function Compute runtime loads and invokes your handler to process requests.

Built-in runtimes

Handlers in built-in runtimes follow a standard format and process events from triggers such as Object Storage Service (OSS), Simple Log Service, ApsaraMQ for RocketMQ, and EventBridge. HTTP triggers provide a URI endpoint for direct invocation.

Custom and Custom Container runtimes

Custom and Custom Container runtime handlers work differently. Web functions.

Configure the handler

Set the Handler parameter in the Function Compute console. Create a function.

Instance lifecycle hooks

Function Compute creates on-demand instances to handle requests. Idle instances are frozen, then destroyed after a timeout.

Lifecycle hooks run custom logic when an instance's status changes. All runtimes support the Initializer and PreStop hooks. Configure instance lifecycles.

Initializer hook

The Initializer hook runs after an instance starts but before the handler. It runs exactly once per instance and must succeed. Failure behavior depends on the invocation type:

Synchronous invocations -- the system returns the error.
Asynchronous invocations -- the system retries based on the configured retry policy.

Use the Initializer hook for expensive setup that should run once, not on every invocation:

Creating connection pools
Loading function dependencies
Database-related setup tasks

PreStop hook

The PreStop hook runs before a function instance is destroyed. Use it for cleanup tasks such as:

Closing database connections
Reporting and updating the instance's status

Logging

Function Compute stores function invocation logs and code-printed logs in Simple Log Service.

Note

A service-level Logstore stores function logs. Configure the logging feature.
When logging is enabled during function creation, the console automatically creates a default Logstore.

Logging statements

Each language offers a built-in log statement and a Function Compute log statement. Function Compute statements tag entries with a request ID for easier filtering.

Language	Built-in statement	Function Compute statement	Reference
Node.js	`console.log()`	`context.logger.info()`	Print logs
Python	`print()`	`logging.getLogger().info()`	Print logs
Java	`System.out.println()`	`context.getLogger().info()`	Print logs
PHP	`echo "" . PHP_EOL`	`$GLOBALS['fcLogger']->info()`	Print logs
C#	`Console.WriteLine("")`	`context.Logger.LogInformation()`	Print logs
Golang	`log.Println()`	`fctx, _ := fccontext.FromContext(ctx)` `fctx.GetLogger().Info()`	Display logs

Both statement types send logs to the Logstore. Function Compute statements add a request ID to each entry:

# Built-in statement: print('hello world')
message:  hello world

# Function Compute statement: logger.info('hello world')
message:  2020-03-13T04:06:49.099Z f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650 [INFO] hello world

Log structure

A function execution log contains the service name, function name, current version, alias, and code logs:

__source__:
__tag__:__receive_time__:  1584072413
__topic__:  FCLogs:myFunction
functionName:  myFunction
message:  2020-03-13T04:06:49.099Z f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650 [INFO] hello world
qualifier:  LATEST
serviceName:  myService
versionId:

The runtime prints start and end markers for each invocation:

Start: FC Invoke Start RequestId: f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650
End: FC Invoke End RequestId: f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650

Operating systems

Built-in runtimes run on Debian 9 LTS, Debian 10 LTS, Debian 11 LTS, or Debian 12 LTS. Only the x86_64 architecture is supported.

Customize the operating system through layers or environment variables. For example, Function Compute defaults to UTC. Set TZ to Asia/Shanghai for UTC+8. Configure layers and Configure environment variables.