Monitoring for Code Engine

Get insight into the performance of your workloads that are deployed with IBM Cloud® Code Engine. Metrics can help you find bottlenecks or predict possible production problems.

You can use the IBM Cloud® Monitoring service to monitor your Code Engine workloads. Code Engine forwards selected information about your workloads to Monitoring so that you can monitor specific metrics such as requests, revisions, and duration.

Set up your IBM Cloud Monitoring service instance

To set up your Code Engine customer metrics dashboards in Monitoring, you must create a Monitoring instance and then enable Platform Metrics in the same region as the Code Engine projects that you want to monitor. If you have deployments in more than one region, you must provision Monitoring and enable platform metrics for each region. For more information, see Monitoring Getting started tutorial.

To set up Monitoring,

From the IBM Cloud navigation menu, select Observability.
Select Monitoring.
Either use an existing Monitoring service instance or create a new one.
After the instance is ready, enable platform metrics by clicking Configure platform metrics.
Select a region and then a Monitoring instance from that region. If you have deployments in more than one region, you must provision Monitoring and enable platform metrics for each region.

You can also start monitoring from your Code Engine dashboard by selecting Launch Monitoring.

You can adapt the dashboards by creating a copy of a dashboard template and by editing it.

Accessing your IBM Cloud Monitoring metrics

To see your Code Engine customer metrics dashboards in Monitoring:

From the IBM Cloud navigation menu, select Observability.
Select Monitoring.
Click Open dashboard to open the dashboard for your monitoring instance.
From the navigation menu, select Dashboards->IBM->IBM Code Engine Project Overview or Dashboards->IBM->IBM Code Engine Functions Overview. If you don't see the Code Engine dashboard in the menu, you can start monitoring from your Code Engine application or job by selecting Launch Monitoring.
Select the 10M timeline or greater. Because Platform Metrics data has a 1 minute granularity, the first timeline that shows metrics is the 10M timeline.

You can also start the Monitoring dashboard at any time by selecting Monitoring from the Code Engine Action menu.

When you use the IBM Cloud Monitoring service to monitor Code Engine workloads, delays can occur before the data is processed and available in Monitoring. For example, right after you create your monitoring instance, it takes a few minutes before meaningful monitoring data is displayed. Be aware that it might take around 5 minutes for your monitoring data to show in Monitoring.

Metrics available for Code Engine

Table 1: Metrics available for Code Engine
Metric Name
`ibm_codeengine_application_actual_instances`
`ibm_codeengine_application_requested_instances`
`ibm_codeengine_application_not_ready_instances`
`ibm_codeengine_application_pending_instances`
`ibm_codeengine_application_desired_instances`
`ibm_codeengine_application_terminating_instances`
`ibm_codeengine_application_requests_total`
`ibm_codeengine_application_revision_count`
`ibm_codeengine_application_service_count`
`ibm_codeengine_application_route_count`
`ibm_codeengine_application_target_concurrency_per_pod`
`ibm_codeengine_application_panic_request_concurrency`
`ibm_codeengine_application_stable_request_concurrency`
`ibm_codeengine_application_panic_mode`
`ibm_codeengine_functions_activations`
`ibm_codeengine_functions_exceeded_limit`
`ibm_codeengine_functions_execution_time_count`
`ibm_codeengine_functions_execution_time_sum`
`ibm_codeengine_functions_init_time_count`
`ibm_codeengine_functions_init_time_sum`
`ibm_codeengine_functions_status_success`
`ibm_codeengine_functions_status_error_application`
`ibm_codeengine_functions_status_error_developer`
`ibm_codeengine_jobruns`

`ibm_codeengine_application_actual_instances`

Number of pods that are currently allocated.

Use this metric to observe the behavior of automatic application scaling and to observe how many application instances are running. Monitor this value to determine if you need to adjust the configurable values for your application.

The number of running instances of an app are automatically scaled up or down based on configuration settings and your workloads. Application scaling is configurable. See Configuring application scaling and be aware of Application defaults and limits.

Table 2: Number of pods that are currently allocated
Metadata	Description
`Metric Name`	`ibm_codeengine_application_actual_instances`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_requested_instances`

Number of pods that the autoscaler requested from Kubernetes.

Use this metric to observe the behavior of automatic application scaling. Monitor this value to determine if you need to adjust the configurable values for your application.

Table 3: Number of pods that the autoscaler requested
Metadata	Description
`Metric Name`	`ibm_codeengine_application_requested_instances`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_not_ready_instances`

Number of pods that are not ready currently.

Use this metric to observe if there are issues with your running application.

Application instances that are in not ready state cannot serve requests. This not ready state indicates that something is preventing the app from becoming ready.

Table 4: Number of pods that are not ready currently
Metadata	Description
`Metric Name`	`ibm_codeengine_application_not_ready_instances`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_pending_instances`

Number of pods that are pending currently.

Use this metric to observe if there are issues with your running application.

You might observe pending applications when you observe automatic application scaling. Application instances that are pending are waiting to be scheduled. If your application remains in a pending state, perhaps the application cannot start because of insufficient resources, such as memory or CPU. See Supported memory and CPU combinations.

Table 5: Number of pods that are pending currently
Metadata	Description
`Metric Name`	`ibm_codeengine_application_pending_instances`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_desired_instances`

Number of pods that the autoscaler wants to allocate.

Use this metric to observe the behavior of automatic application scaling. Monitor this value to determine if you need to adjust the configurable values for your application.

Table 6: Number of pods that the autoscaler wants to allocate
Metadata	Description
`Metric Name`	`ibm_codeengine_application_desired_instances`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_terminating_instances`

Number of pods that are terminating currently.

Use this metric to observe the behavior of automatic application scaling. Monitor this value to observe if an application terminates when applications are scaled down.

Table 7: Number of pods that are terminating currently
Metadata	Description
`Metric Name`	`ibm_codeengine_application_terminating_instances`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_requests_total`

Total number of HTTPS requests to the application.

Use this metric to monitor the number of HTTPS requests that are received by your application.

Table 8: Total number of HTTPS requests to the application
Metadata	Description
`Metric Name`	`ibm_codeengine_application_requests_total`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name, http status code`

`ibm_codeengine_application_revision_count`

Number of revisions per application.

Use this metric to observe the number of revisions per application.

An application contains one or more revisions. Each update of an application configuration property creates a new revision of the application. Code Engine has a quota for the number of apps and app revisions in a project. For more information about limits for projects, see Project quotas.

Table 9: Number of revisions per application
Metadata	Description
`Metric Name`	`ibm_codeengine_application_revision_count`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name`

`ibm_codeengine_application_service_count`

Number of applications per project.

Use this metric to observe how many applications are in your project.

Code Engine has a quota for the number of apps and app revisions in a project. For more information about limits for projects, see Project quotas.

Table 10: Number of applications per project
Metadata	Description
`Metric Name`	`ibm_codeengine_application_service_count`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name`

`ibm_codeengine_application_route_count`

Number of routes per application.

Code Engine supports only 1 route per application.

Table 11: Number of routes per application
Metadata	Description
`Metric Name`	`ibm_codeengine_application_route_count`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name`

`ibm_codeengine_application_target_concurrency_per_pod`

The number of concurrent requests that you want for each pod.

Use this metric to observe the target concurrency value that is set for your application.

Target concurrency for application scaling is configurable. See Configuring application scaling.

Table 12: The number of concurrent requests that you want for each pod
Metadata	Description
`Metric Name`	`ibm_codeengine_application_target_concurrency_per_pod`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_panic_request_concurrency`

Average of requests count over the panic window.

Use this metric to observe the behavior of automatic application scaling. Monitor this value to observe if the application traffic arrives in bursts or if the traffic is steady.

While stable mode is used for general operations, panic mode has a much shorter window, and is used to quickly scale up an application revision if a burst of traffic occurs.

Table 13: Average of requests count over the panic window
Metadata	Description
`Metric Name`	`ibm_codeengine_application_panic_request_concurrency`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_stable_request_concurrency`

Average of requests count over the stable window.

Use this metric to observe the behavior of automatic application scaling. Monitor this value to observe if the application traffic arrives in bursts or if the traffic is steady.

While stable mode is used for general operations, panic mode has a much shorter window, and is used to quickly scale up an application revision if a burst of traffic occurs.

Table 14: Average of requests count over the stable window
Metadata	Description
`Metric Name`	`ibm_codeengine_application_stable_request_concurrency`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_application_panic_mode`

Specifies whether panic mode is enabled.

Use this metric to observe the behavior of automatic application scaling. Monitor this value to observe whether panic mode is used.

While stable mode is used for general operations, panic mode has a much shorter window, and is used to quickly scale up an application revision if a burst of traffic occurs.

Table 15: Specifies if panic mode is enabled
Metadata	Description
`Metric Name`	`ibm_codeengine_application_panic_mode`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, application name, application revision name`

`ibm_codeengine_functions_activations`

Number of invoked functions.

Table 16: Number of invoked functions
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_activations`
`Metric Type`	`counter`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name, function type`

`ibm_codeengine_functions_exceeded_limit`

Number of functions that are invoked after the limit for your project is exceeded. For more information about limits for projects, see Project quotas.

Table 17: Number of invoked functions after exceeding project limit
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_exceeded_limit`
`Metric Type`	`counter`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name, function type`

`ibm_codeengine_functions_execution_time_count`

Number of invoked functions that run to completion.

The ibm_codeengine_functions_execution_time_count and ibm_codeengine_functions_execution_time_sum metrics are used to determine the average execution time per invoked function.

Table 18: Number of invoked functions that complete execution
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_execution_time_count`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name`

`ibm_codeengine_functions_execution_time_sum`

Sum of all execution time for invoked functions that run to completion.

The ibm_codeengine_functions_execution_time_count and ibm_codeengine_functions_execution_time_sum metrics are used to determine the average execution time per invoked function.

Table 19: Sum of all execution time for invoked functions
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_execution_time_sum`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name`

`ibm_codeengine_functions_init_time_count`

Number of functions that complete initialization such that the code is loaded in Code Engine and ready for execution.

The ibm_codeengine_functions_init_time_count and ibm_codeengine_functions_init_time_sum metrics are used to determine the average initialization time for invoked functions.

Table 20: Number of functions that complete initialization
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_init_time_count`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name`

`ibm_codeengine_functions_init_time_sum`

Sum of all initialization time for invoked functions.

The ibm_codeengine_functions_init_time_count and ibm_codeengine_functions_init_time_sum metrics are used to determine the average initialization time for invoked functions.

Table 21: Sum of all initialization time for invoked functions
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_init_time_sum`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name`

`ibm_codeengine_functions_status_success`

Number of functions that are successfully invoked. A function is invoked successfully in Code Engine after the function completes initialization, runs to completion, and your function code responds with a successful HTTP response status code.

Table 22: Number of functions successfully invoked
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_status_success`
`Metric Type`	`counter`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name, function type`

`ibm_codeengine_functions_status_error_application`

Number of invoked functions that fail during Code Engine processing.

Table 23: Number of invoked functions that fail within Code Engine
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_status_error_application`
`Metric Type`	`counter`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name, function type`

`ibm_codeengine_functions_status_error_developer`

Number of invoked functions that fail with an error in your code.

Table 24: Number of invoked functions that fail with an error in your code
Metadata	Description
`Metric Name`	`ibm_codeengine_functions_status_error_developer`
`Metric Type`	`counter`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, function name, function pod name, function type`

`ibm_codeengine_jobruns`

Total number of job runs.

Use this metric to monitor how many job runs are in your project. Code Engine has a quota for the number of jobs and job runs in a project. For more information about limits for projects, see Project quotas.

Table 25: Total number of job runs
Metadata	Description
`Metric Name`	`ibm_codeengine_jobruns`
`Metric Type`	`gauge`
`Value Type`	`none`
`Segment By`	`Service instance, name of the namespace, project name, job Name, jobrun condition`

Attributes for segmentation

Global Attributes

The following attributes are available for segmenting all the metrics previously listed.

Table 26: Global attributes
Attribute	Attribute Name	Attribute Description
`Cloud Type`	`ibm_ctype`	The cloud type is a value of `public`, `dedicated`, or `local`.
`Location`	`ibm_location`	The location of the monitored resource, which can be a region, data center, or global.
`Resource`	`ibm_resource`	The resource that is measured by the service, which is typically an identifying name or GUID.
`Resource Type`	`ibm_resource_type`	The type of the resource that is measured by the service.
`Resource group`	`ibm_resource_group_name`	The resource group where the service instance was created.
`Scope`	`ibm_scope`	The scope is the account, organization, or space GUID associated with this metric.
`Service name`	`ibm_service_name`	Name of the service that is generating this metric.

More attributes

The following attributes are available for segmenting one or more attributes as described in the previous tables. See the individual metrics for segmentation options.

Table 27: Segmentation options
Attribute	Attribute Name	Attribute Description
`Name of the namespace`	`ibm_codeengine_namespace`	Name of the namespace. This unique identifier is contained in the URL of your application. The default URL for applications is of the format `https://<appname>.<uuid>.<region>.codeengine.appdomain.cloud` where `appname` is the name of your application, `uuid` is the automatically generated unique identifier, and `region` is the region in which your Code Engine project resides. The UUID portion of the URL is the name of the namespace.
`Service instance`	`ibm_service_instance`	The service instance segment identifies the instance that the metric is associated with.
`HTTP status code`	`ibm_codeengine_status`	HTTP status code.
`Application name`	`ibm_codeengine_application_name`	Name of the application.
`Application revision name`	`ibm_codeengine_revision_name`	Name of the application revision.
`Gateway instance`	`ibm_codeengine_gateway_instance`	The gateway instance.
`Job Name`	`ibm_codeengine_job_name`	Name of the job that is used to create the job run.
`Jobrun condition`	`ibm_codeengine_jobrun_condition`	The condition of the job run.
`Project name`	`ibm_codeengine_project_name`	Name of the project.
`Function name`	`ibm_codeengine_function_name`	Name of the invoked function.
`Function pod name`	`ibm_codeengine_function_podname`	The name of the system pod that invoked the function.
`Function type`	`ibm_codeengine_function_type`	The type for how the function was invoked (`sync` or `async`).