Activity tracking events for IBM Cloud VPC

Locations where activity tracking events are generated

Viewing activity tracking events for IBM Cloud VPC

You can use IBM Cloud Logs to visualize and alert on events that are generated in your account and routed by IBM Cloud Activity Tracker Event Routing to an IBM Cloud Logs instance.

Network resources

The following tables list the actions that are related to network resources and the generation of events.

Compute resources

The following tables list the actions that are related to compute resources and the generation of events.

Storage resources

Viewing events

Events that are generated by VPC resources are automatically forwarded to the IBM Cloud Activity Tracker service instance that is available in the same location.

IBM Cloud Activity Tracker can have only one instance per location. To view events, you must access the web UI of the IBM Cloud Activity Tracker service in the same location where your service instance is available. For more information, see Launching the UI through the IBM Cloud UI.

Analyzing events

Refer to the following information when you are analyzing events:

• Activity Tracker actions are set to read for both the GET and LIST calls, for example, is.instance.instance.read. However, for the LIST calls, the target.name field is set to *, whereas for the GET calls, it is set to the name of the resource.

• To determine if a virtual network interface is created with the protocol state filtering feature, look for the protocol_state_filtering_mode field in the AT events is.virtual-network-interface.virtual-network-interface.create or is.virtual-network-interface.virtual-network-interface.update. Values are as follows:

  • 0 sets the mode to Auto, which enables or disables filtering based on your VNI's target resource type. If the target type is a bare metal server or Elba virtual server instance, filtering is disabled; for other virtual server instances or a file share mount, filtering is enabled.
  • 1 enables protocol state filtering.
  • 2 disables protocol state filtering.

  For more information, see Protocol state filtering mode.

• When a user triggers an instance action change, an Activity Tracker log is generated. The action is specified to one of the following valid action types: start, stop, and reboot.

• The target field contains information about the top-level resources, for example, VPC, subnets, and instances (virtual machine). For subresources, such as volume-attachments and security-group rules, their unique identifier can be found from the responseData.responseURI field. The mapping to the parent resources is reflected by the URI.

• For events that are related to volume-attachments, the ID of the volume that was attached can be found indirectly by getting the ID of the volume-attachment from the target.responseURI field (which also contains the instance ID), and by using that ID to query the corresponding GET /instance/{instance_id}/volume-attachment/{volume-attachment-id} API. The volume ID can be found from the response of the GET API call.

• For events that are related to Load Balancer requests, consider the following information:

  You can get more data in the requestData.requestPath field. You can find details about a subresource such as a listener ID or rule ID.

  When you create resources, you can get IDs from the responseData.responseContent field.

  For update actions, the original value is not included. You can do a read action to get the value before you run an update on the resource.

• The following fields for Bare Metal Servers for VPC AT events are changing between the Beta and LA releases:

  1. The severity field in Beta events is not consistent with general practice within VPC and is corrected in the LA release.

  2. The target resourceGroupID field in Beta events does not include the CRN prefix. This is corrected in the LA release.

  3. Some Beta events include array data. If the array is too large, the event isn't recorded. For LA, these events display an array element count rather than the actual data.

• Each time you open a console for a virtual server instance or bare metal server, two API calls are issued: the first one generates a console access token, the second one uses the generated token to open the console websocket.

  This API call generates two Activity Tracker events: is.instance.console-access-token.create and is.instance.console.read, or is.bare-metal-server.console-access-token.create and is.bare-metal-server.console.read.

  You cannot use request id to correlate console Activity Tracker events as each call generates a unique request id. Instead, you can use initiator id to correlate console events that are generated from API calls issued by the same user.

• You can find the detailed information and fields included in the requestData and responseData for the Bare Metal Servers for VPC AT events in the API documentation.