This topic describes the common request headers, HTTP status codes, response headers, and log formats of a custom runtime.
Common request headers in Function Compute
The following table describes the common request headers that Function Compute forwards to a custom runtime. If you want to access other Alibaba Cloud services, you may need to use the request headers that specify a temporary AccessKey pair. If you migrate existing applications to Function Compute, ignore the following information.
- Both event functions and HTTP functions contain common request headers.
- Function Compute generates common request headers that contain basic information about permissions and functions.
Header | Description |
---|---|
x-fc-request-id | The ID of the request. |
x-fc-access-key-id | The temporary AccessKey ID. |
x-fc-access-key-secret | The temporary AccessKey secret. |
x-fc-security-token | The temporary security token. |
x-fc-function-handler | The handler of the function. If the runtime is a function, such as a custom runtime or a custom container, the value is meaningless and can be set to a random string. |
x-fc-function-memory | The maximum memory that a function can use. |
x-fc-function-initializer | The handler of an Initializer hook. If the runtime is a function, such as a custom runtime or a custom container, the value is meaningless and can be set to a random string. |
x-fc-initialization-timeout | The timeout period of the Initializer hook. |
x-fc-instance-lifecycle-pre-stop-handler | The handler of the PreStop hook. If the runtime is a function, such as a custom runtime or a custom container, the value is meaningless and can be set to a random string. |
x-fc-instance-lifecycle-pre-freeze-handler | The handler of the PreFreeze hook. If the runtime is a function, such as a custom runtime or a custom container, the value is meaningless and can be set to a random string. |
x-fc-region | The region where the function resides. |
x-fc-account-id | The user ID (UID) of the function owner. |
x-fc-qualifier | The service version or alias that you specify when you invoke the function. For more information, see Canary release. |
x-fc-version-id | The service version that you specify when you invoke a function. |
x-fc-function-name | The name of the function. |
x-fc-service-name | The name of the service to which the function belongs. |
x-fc-service-logproject | The Log Service project that is configured for the service to which the function belongs. |
x-fc-service-logstore | The Log Service Logstore that is configured for the service to which the function belongs. |
x-fc-control-path | The request type of the function.
For a custom runtime or a custom container, you can check whether you sent a request
to invoke an HTTP function or an event function based on the value of this parameter.
Valid values:
|
HTTP status codes and response headers in Function Compute
- HTTP status code (
StatusCode
)200
: succeeded404
: failed
- Response header (
x-fc-status
)200
: succeeded404
: failed
x-fc-status
field in response headers to report to Function Compute whether the local function is successfully invoked.
- If you do not specify a value for the
x-fc-status
field, Function Compute considers the invocation successful. If an error occurs during function execution, the system does not report the error to Function Compute. In this case, the business logic may not be affected, but the observability of Function Compute is affected. The following figure provides an example. - If you specify a value for the
x-fc-status
field, the system reports function invocation failures to Function Compute by using thex-fc-status
field. If an error occurs during function invocation, the system records the error stack information in logs. The following figure provides an example.
StatusCode
and x-fc-status
fields in the HTTP response.
Function log formats
We recommend that you enable logging when you create a service in Function Compute. This way, all stdout logs that the system generates are stored in the specified Log Service project. For more information, see Configure the logging feature.
If Function Compute invokes a function in a runtime that is not a custom runtime or a custom container
and the request contains the x-fc-log-type" = "Tail"
header, the response that contains the x-fc-log-result
header is the log that the system generates when the system invokes the function.
The maximum size of a log is 4 KB. You can view the log in the results of the function
invocation in the Function Compute console. If you want to view the logs of a custom runtime in the results of the function
invocation in the console, you must record the start and end logs of the requests
in the code.
Log | Required | Code format |
---|---|---|
Start of the runtime | No
Note The cold start flag of the function is recorded.
|
FunctionCompute ${runtime} runtime inited. Note You can specify a custom value for the
${runtime} parameter. We recommend that you do not specify an official language name in Function Compute, such as Node.js, Python, or PHP.
|
Start log of function invocation | Yes | FC Invoke Start RequestId: ${RequestId} |
End log of function invocation | Yes | FC Invoke End RequestId: ${RequestId} |
Start log of function initialization | No
Note If you use an initializer function, record this log.
|
FC Initialize Start RequestId: ${RequestId} |
End log of function initialization | No
Note If you use an initializer function, record this log.
|
FC Initialize End RequestId: ${RequestId} |
We recommend that you also include the request ID in your logs for diagnostics in
the future and the request ID in your logs is in the $utcdatetime(yyyy-MM-ddTHH:mm:ss.fff) $requestId [$Level] $message
format.