Service Invocation Logs

Overview

When using CloudBase resources (HTTP access service, cloud functions, database, cloud storage), corresponding service invocation logs will be generated for developers to retrieve and analyze in the CloudBase console.

Log Information

When using CloudBase resources via SDK or HTTP access service, a service invocation log will be generated. Each service invocation log contains data such as log metadata, invoked service & event, resource information, caller information, time information, and other data.

Log Metadata

Log Metadata contains the traceId, spanId, and childOf fields.

During a complete service invocation, multiple CloudBase resources may be accessed, generating several cloud invocation logs. These logs share the same traceId, while each log has a different spanId, and the childOf field records the spanId of its parent hop.

Example

Take the following scenario as an example: cloud function A is called via the SDK, and cloud function A then calls cloud function B. SDK --> Fun A --> Fun B

In this service invocation, two CloudBase resources were actually accessed, thus generating two service invocation logs A and B. They share the same traceId but have different spanIds, and the childOf of B is the spanId of A.

Invoked Service & Event

In logs, service and event are used to mark the service type and event action of each service invocation.

service Service Type	event Event Action
function cloud function	callFunction
storage cloud storage	upload, delete, etc.
database cloud database	Database Operation Category: CRUD+aggregation
app cloud-hosting	http type, PUT/GET/POST, etc.

Resource Information

Different resource types represent accessed resource information through distinct fields.

Resource Type	Field Name	Description
cloud function	function	Function Name
cloud storage	file_path	File path (array; multiple paths returned for batch temporary file operations)
Cloud Database	collectionName	Collection name (array; multiple in aggregation operations)
http access service	httpPath	Path without query

Caller Information

Service invocation logs contain the following caller information.

Field Name	Field Information
invoker	Caller: admin/uid/empty
source	Request source channel, web-sdk/node-sdk/http/schedule, etc.
UA	Client User-Agent information
invokerIp	Source IP

Time Information

The time information fields in logs are startTime and timeCost, representing the start time and duration of service invocation.

Error Information

In logs, errorCode and errorMsg represent the error code and error description, respectively.

Introduction to Typical Use Cases

Finding Errors in User A's Access to Cloud Development Resources

For details on the log search method, please refer to Search Logs.

If User A encounters an error while accessing cloud development resources, how to locate the cause of the error?

1. Retrieve the latest service call logs with access errors for this user by using invoker:A and errorCode:*.
2. After retrieving the service invocation logs, locate the traceId in the logs based on the access time. Then, use traceId:\${traceId} to retrieve all service invocation logs for this service call, and analyze the cause of the error based on the invocation information, resource information, and error information in the logs.
3. Click the "Full Link Logs" button to go to the full link logs page and view the call chain relationships. On the call page, you can click to view the logs during function execution.

Cloud Hosting Service Invocation Scenario

When a user invokes interface 1 of Cloud Hosting service A, and then within interface 1 of Cloud Hosting service A, there is a subsequent call to interface 2 of the same service, if the intention is to associate both requests with the same traceid, then the business side needs to make corresponding modifications.

1. In the /json interface, when calling the /trace interface, propagate the x-cloudbase-trace header from the request headers.
2. In the /trace interface, parse the x-cloudbase-trace to obtain the traceId, output it in the logs, and use it for subsequent log searches.

Taking the Node.js koa framework code as an example, in Cloud Hosting A, the /json interface calls another /trace interface.

router.get("/json", async (ctx, next) => {
  const res = await axios.get(
    "https://test-2gbynbtb9996d4d0-1252395194.ap-shanghai.service.tcloudbase.com/node-capp/trace",
    {
      headers: {
        "x-cloudbase-trace": ctx.req.headers["x-cloudbase-trace"]
      }
    }
  );

  ctx.body = res.data;
});
router.get("/trace", async (ctx, next) => {
  // Convert from base64 to utf8 encoding, the data format is ${traceId},${spanId},${on | off}
  // Example: OGY0MzFiN2ViZmNjNDIzZTk5ZDhjZGE3MjQ3MWZmNDksYmJlNzU2ODdmZmZiNmNiOCxvbg is decoded to 8f431b7ebfcc423e99d8cda72471ff49,bbe75687fffb6cb8,on
  const traceStr = Buffer.from(ctx.req.headers["x-cloudbase-trace"], "base64").toString("utf-8");

  const [traceId] = traceStr.split(",");
  // After decoding, this field can be printed in the logs to facilitate log correlation.
  console.log(`${traceId}: traceId log start`);
  ctx.body = {
    traceStr,
    traceId
  };
  console.log(`${traceId}: traceId end`);
});

Note: When invoking cloud hosting from a cloud function, x-cloudbase-trace propagates the TCB_TRACELOG environment variable from the cloud function context.