All Products
Search

This Product

    Function Compute:Basics

    Document Center

    Function Compute:Basics

    Last Updated:Jan 29, 2025

    This topic describes the basic concepts related to code development in Function Compute, including handlers, lifecycle hooks for function instances, and logs.

    Handlers

    You must specify a handler when creating a function. The Function Compute runtime loads and calls this handler to process requests.

    Handlers in built-in runtimes adhere to a standard format. They process events from various sources, such as Object Storage Service (OSS), Simple Log Service, ApsaraMQ for RocketMQ, and EventBridge triggers, whenever these sources invoke your functions. You can also set up an HTTP trigger for your function. In this case, you are given a Uniform Resource Identifier (URI) endpoint that you can use to send HTTP requests to directly invoke the function.

    Handlers in a custom runtime or a Custom Container runtime differ from those in a built-in runtime. For more information, see Web functions.

    To specify a handler, configure the Handler parameter in the Function Compute console. For more information, see Create a function.

    Lifecycle hooks for function instances

    In on-demand mode, instances are automatically created to handle incoming requests. When they are not processing requests, on-demand instances are frozen. They will be destroyed if they remain in this frozen state for a certain period of time. You can configure lifecycle hooks for instances to perform callback operations on instances when the instance status changes. All types of runtimes of Function Compute support both Initializer and PreStop hooks. For more information, see Configure instance lifecycles.

    Initializer hooks

    An Initializer hook is invoked after an instance is initialized, but before the handler is executed. Function Compute ensures that the Initializer hook is executed only once throughout an instance's lifecycle. If the execution fails, the current instance is destroyed, and a new instance is created to retry the execution.

    You can incorporate time-consuming service logic into the Initializer hook. Doing so eliminates the need to run such service logic every time the function is called, thereby decreasing the function's latency. Examples of time-consuming service logic include creating connection pools, loading function dependencies, and performing other database-related tasks.

    PreStop hooks

    A PreStop hook is executed before a function instance is destroyed. You can utilize this hook to carry out specific tasks prior to an instance's destruction. For example, you can configure a PreStop hook to ensure that database connections are closed and the instance's status is reported and updated before it is destroyed.

    Logs

    Note

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

    • If you enable the logging feature when you create a function, the Function Compute console automatically sets up a default Logstore for you.

    Function Compute is integrated with Simple Log Service to store function invocation logs and logs that are printed in the function code to the Logstore. You can use the logging statements provided by Function Compute to record function logs, which facilitates debugging and troubleshooting. The following table describes the built-in log printing statements of different programming languages, along with the logging statements provided by Function Compute.

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

    Display logs

    Both the logs printed by using the built-in log printing statements of programming languages and the logging statements provided by Function Compute are collected and stored in the Logstore. The latter logs are tagged with request IDs for easier filtering. 

    # Log printed by using the built-in log printing statement of the programming language
# print('hello world')
message:  hello world

# Log printed by using the logging statement 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, current version, alias, and code logs.

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

    __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 system prints FC Invoke Start RequestId: f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650 when the function execution starts.

    • The system prints FC Invoke End RequestId: f84a9f4f-2dfb-41b0-9d6c-1682a2f3a650 when the function execution ends.

    OSs

    The built-in runtimes of Function Compute use Debian 9 LTS or Debian 10 LTS for execution, both running on the x86_64 architecture.