All Products
Search
Document Center

Function Compute:Basics

Last Updated:Feb 02, 2024

This topic describes some basic information about coding in Function Compute, including handlers, instance lifecycle hooks, logging, and error handling.

Handlers

When you create a function, you must specify a handler for the function. Function Compute runtimes load and call handlers to process requests.

Handlers in standard runtimes follow only one format. You can use handlers to process event requests from various event sources, such as Object Storage Service (OSS) triggers, Simple Log Service triggers, ApsaraMQ for RocketMQ triggers, and EventBridge triggers. You can also create an HTTP trigger and use the URI provided by the HTTP trigger to trigger a function.

Request handlers in custom runtimes are different from request handlers in standard runtimes. For more information, see Web functions.

You can configure the handler for a function by using the Request Handler parameter in the Function Compute console. For more information, see Create a function.

Lifecycle hooks for function instances

On-demand instances can be automatically created based on requests. On-demand instances are frozen when they are not processing requests and destroyed after being frozen for a period of time. You can configure lifecycle hooks for instances to perform callback operations on the instances when the instance status changes. All types of runtimes of Function Compute support both Initializer and PreStop hooks. For more information, see Function instance lifecycle.

Initializer hooks

An Initializer hook is called after a function instance is started and before the handler runs. Function Compute ensures that an Initializer hook is successfully invoked only once within the lifecycle of a function instance. For example, if the Initializer hook fails to be invoked for the first time, the system retries the Initializer hook until the Initializer hook is successfully invoked, and then runs your handler.

In database-related scenarios, you can add time-consuming service logic to the Initializer hook, such as the service logic for creating connection pools and loading function dependency libraries. This prevents repeated executions of the service logic each time the function is invoked and reduces the latency of the function.

PreStop hooks

A PreStop hook is executed before a function instance is destroyed. You can use the PreStop hook to perform specified operations before an instance is destroyed. For example, you can configure a PreStop hook to make sure that database connections are closed and states are reported and updated before an instance is destroyed.

Log records

Note
  • You need to configure a service-level Logstore to store function logs of Function Compute. For more information, see Configure the logging feature.

  • By default, Function Compute automatically configures a Logstore for your service if you enable the logging feature when you create the service.

Function Compute integrates with Simple Log Service to store records of function invocations and logs printed in the function code to the Logstore. You can use the log statements provided by Function Compute to record function logs to facilitate debugging and troubleshooting. The following table describes the log printing statements for different programming languages.

Programming language

Built-in log printing statement of the programming language

Logging statement provided by Function Compute

References

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()

Print logs

Logs that are printed by using the built-in log printing statements of programming languages are collected and stored in Logstores. Logs that are printed by using the logging statements provided by Function Compute are tagged with request IDs, which facilitates log filtering.

# Print logs by using the built-in log printing statements of a programming language.
# print('hello world')
message:  hello world

# Print logs by using the logging statements provided by Function Compute.
# logger.info('hello world')
message:  2020-03-13T04:06:49.099Z f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650 [INFO] hello world
            

Log elements

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

The following example shows the data structure of a function execution log:

__source__:  
__tag__:__receive_time__:  1584072413
__topic__:  myService
functionName:  myFunction
message:  2020-03-13T04:06:49.099Z f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650 [INFO] hello world
qualifier:  LATEST
serviceName:  myService
versionId:         
  • When a function starts to run, the system prints FC Invoke Start RequestId: f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650, which marks the start of a function execution.

  • When a function execution is complete, the system prints FC Invoke End RequestId: f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650, which marks the end of a function execution.

Operating system

Standard runtimes of Function Compute provide two operating systems: Debian 9 LTS and Debian 10 LTS. Both operating systems support only the x86_64 architecture.