Expand Monitoring Capability with Custom Resources
You can extend the scope of Stack Monitoring's capabilities with custom resources. Custom resources enable you monitor other applications or infrastructure components by creating instances of new resource types. Once created, you can associate these new resource instances with other resources in Stack Monitoring to complete your application topology and support richer performance correlation across the application stack.
Custom resources can be defined using any of the following methods:
Importing Resources - Stack Monitoring will create a home page for the imported resource that includes performance charts and the ability to create a navigational topology between the imported resource and existing Stack Monitoring resources. Importing a Resource requires the Enterprise Extensibility license to be enabled within the compartment.
- OCI Services - Import resources from other OCI services such as autonomous database, load balancer, block storage etc. When importing a resource, the Stack Monitoring service will identify the list of resources available to import. Importing an OCI Resource requires the Enterprise Extensibility license to be enabled within the compartment.
- Monitoring Prometheus-based resource – Import resources into Stack Monitoring for metrics collected in Prometheus format.
- Imported Resources Administration
Process-based Custom Resources - You can monitor any resource, such as an application or application infrastructure running on a host by identifying the processes that make up the resource and the hosts on which the resource is running. Once defined, Stack Monitoring starts monitoring the resource for status, CPU and Memory Utilization. You can monitor the resource using the built-in homepage and also create alarms to trigger when the resource is detected to be down or is high in CPU or Memory.
OCI Services
OCI Resource Extensibility requires the Enterprise Extensibility to be enabled within a compartment. To enable Enterprise Extensibility navigate to the Licensing page within the Stack Monitoring UI.
Importing an OCI resource into Stack Monitoring will create a home page for the resource within the Stack Monitoring service that includes performance charts and the ability to create a navigational topology between the imported resource and existing Stack Monitoring resources. For example, an imported OCI Load Balancer can be related to its E-Business Suite application. Then use Stack Monitoring topology to easily navigate the entire application stack.
Suported Namespaces
Stack Monitoring supports the following OCI metric namespaces:
Service Name | Metric Name Space |
---|---|
OCI API Gateway | oci_apigateway |
OCI Autonomous Database | oci_autonomous_database |
OCI Analytics | oci_analytics |
OCI Bastion | oci_bastion |
OCI Blockstore | oci_blockstore |
OCI Filestorage | oci_filestorage |
OCI Internet Gateway | oci_internet_gateway |
OCI LBaaS | oci_lbaas |
OCI Management Agent | oci_managementagent |
OCI MySql Database | oci_mysql_database |
OCI Nat Gateway | oci_nat_gateway |
OCI Network Firewall | oci_network_firewall |
OCI Notification | oci_notification |
OCI NoSql | oci_nosql |
OCI Object Storage | oci_objectstorage |
OCI Kubernetes | oci_oke |
OCI Service | oci_service_gateway |
OCI Streaming Service | oci_streaming |
Importing an OCI Resource using the UI
Follow the steps below to import an OCI resource:
-
Within Stack Monitoring navigate to the Import Resources page and click Import resources.
- Select OCI Native Services as the Source.
OCI Service Import Input
Input field | Description |
---|---|
OCI monitoring namespace |
This is the namespace from which the metrics are retrieved and dimensions are parsed to identify and import the resources. |
Request name |
The name of the work request that will be submitted for the import operation. |
Import UI Work Requests
- Click the Workrequest name link to display a popup showing the list of imported resources.
- Click the Status link to display a popup with work-request logs.
Importing an OCI Resource using the Command Line
Use the import-telemetry-resources
or create
OCI CLI command syntax to import OCI native resources into stack-monitoring:
- Using import command:
oci stack-monitoring resource-task import-telemetry-resources --compartment-id "<Compartment_OCID>" --name <Request_name> --namespace <OCI_monitoring_namespace> --source <source-of-resource>
- Using create command:
oci stack-monitoring resource-task create --compartment-id "<Compartment_OCID>" --name <Request_name> --task-details file://<JSON_INPUT_FILE>
Example JSON for importing an OCI Resource using the Command Line
{
"type": "IMPORT_OCI_TELEMETRY_RESOURCES",
"source": "<source-of-the-resource>"
"namespace": "<OCI-Monitoring-namespace>"
}
JSON Input Parameters:
Input Field | Required | Description | Notes |
---|---|---|---|
<Compartment_OCID> | yes | The [OCID] of the compartment. | Within the Stack Monitoring home page of the resource, Configuration / General OCI Properties / compartmentID |
<OCI-Monitoring-namespace> | Yes | OCI monitoring namespace used by the import task. | Supported name spaces are <provide link to supported list of namespaces> |
<source-of-the-resource> | Yes | Identifier for the type of resources being imported. Currently supported source is OCI_TELEMETRY_NATIVE. | Currently its only OCI_TELEMETRY_NATIVE is supported. |
<Request_name> | No | Work request name. Default value is in the format "<namespace><timestamp>. | Any valid string for the task name |
<defined-tags> | No | OCI defined tags that need to be applied for all the imported resources and the work-request itself. | |
<freeform-tags> | No | OCI freeform tags that need to be applied for all the imported resources and the work-request itself. |
Monitoring Prometheus Resources
Stack Monitoring now supports monitoring for resources and metrics that have a Prometheus
format. This is a two step process: configure agent to scrape and upload to telemetry and then import the resource into Stack Monitoring.
All Prometheus-based resources imported into Stack Monitoring will be assigned an Enterprise License. For more information, see Configuring Licensing.
Prerequisites
Create policyThe following policy is required to allow importing a Prometheus-based resource within a compartment:
Policy | Description |
---|---|
ALLOW DYNAMIC-GROUP StackMonitoringManagementAgentsEasyOnboarding TO USE METRICS IN COMPARTMENT <compartment_name> where target.metrics.namespace = 'oracle_appmgmt_prometheus' |
Allow the agent to upload metrics to Telemetry into 'oracle_appmgmt_prometheus' namespace. Here, Management_Agent_Dynamic_Group is a dynamic group of management agents in a compartment.
|
The availability status of a Prometheus-based resource is determined as follows:
- A resource is considered up if at least one of the selected metrics under Availability Proxy Metric input has a datapoint in telemetry (including 0) during the specified interval.
- If the Availability Proxy Metric Interval is less than what is configured in the Management Agent (
scheduleMins
), the UI will show the resource as Not Reporting. It is recommended to enter the same value (converted to seconds) that was specified forscheduleMins
in the agent configuration file.- For example, when configuring the Management Agent, if the value of
scheduleMins
is set to 5 (minutes), the availability proxy metric interval must be >= 300 (seconds, or 5 minutes). If the availability proxy metric is set to less than 300 seconds, the resource will show a status of Not Reporting.
- For example, when configuring the Management Agent, if the value of
If multiple metrics are selected to calculate availability of the resource, at least one of the metrics must have a value during the specified availability interval for the resource to be considered up. If none of the metrics have values the resource will be considered Not Reporting
Importing Prometheus-based Resource using the UI
Configuring the Management Agent
Prometheus metrics can be uploaded to Telemetry Service through the Management Agent. The Management Agent must be configured to identify where the metrics should be scraped. Navigate to the Management Agent's page located within Observability and Management, Management Agent, then Agents. From the list of available Management Agents click the name of the agent to enable Prometheus collection. From the Management Agent page, click Manage DataSources, then Add DataSource. For more information, see Management Agent documentation.
Agent UI Configuration Input
All fields below are mandatory, including those listed within the "Optional properties" section.
Input field | Description |
---|---|
DataSourece type | Select Prometheus |
Name | The name of the Prometheus-based resource to monitor |
Metric compartment | The compartment where you wish to monitor the resource in Stack Monitoring |
Metric namespace | oracle_appmgmt_prometheus |
URL | The url through which the Prometheus Exporter publishes its metrics. (http only) |
Custom metric dimensions | |
dimensionName | This MUST be entered as: "resourceName" |
dimensionValue | This MUST match the value entered into the "Name" field. |
Optional properties | |
allowMetrics | "*" indicates all metrics defined will be collected |
resourceGroup | Resource group allows for grouping of similar resource types (host, weblogic_j2eeserver, apache_tomcat, etc) |
scheduleMins | The frequency in which the metrics will be collected in minutes. |
Importing Prometheus-based Resource
Under Import Resources menu, click on Import Resources button, at the top left corner of the table. Once the inputs are filled, click on Import Resources. The panel will close and the newly created job will appear on the list. When the job is completed, the user can click on the job name, this will open a new panel that shows the imported resources. Clicking on any imported resource will automatically open the resource's home page.
Input field | Description |
---|---|
OCI monitoring namespace |
This is the namespace from which the metrics are retrieved and dimensions are parsed to identify and import the resources. The user must select oracle_appmgmt_prometheus to be able to import Prometheus resources |
Resource Group | List of resource groups under oracle_appmgmt_prometheus namespace |
Availability Proxy Metric | List of metrics that are available in the selected Resource Group. This is a multi-selection input. These metrics are used to calculate resource availability. For more information, see Availability Status Calculation for Imported Resource |
Availability Proxy Metric Interval | Interval, in seconds, in which the metric(s) are collected by the agent (minimum value is 60). For more information, see Availability Status Calculation for Imported Resource |
Request name | The name of the work request that will be submitted for the import operation. This is only used for tracking purposes. |
Once the input fields are completed, click Import resources to submit the import work request. When the work request has completed, the user can click the job name to review the list of imported resources. Clicking any imported resource's name will navigate to the newly imported resource's home page.
Importing Prometheus-based Resource using the CLI
Configuring the Management Agent
Prometheus metrics can be uploaded to Telemetry Service through the Management Agent. The Management Agent must be configured to identify where the metrics should be scraped. Navigate to the Management Agent's page located within Observability and Management, Management Agent, then Agents. From the list of available Management Agents click the name of the agent to enable Prometheus collection. From the Management Agent page, click Manage DataSources, then Add DataSource. For more information, see Management Agent documentation.Input Field | Description |
---|---|
allowMetrics | "*" indicates all metrics defined will be collected |
compartmentId | The OCID of the compartment where you wish to monitor the resource in Stack Monitoring |
dimensionValue | This MUST match the value entered into the "Name" field. |
metricDimension | This MUST be resourceName |
namespace | This MUST be oracle_appmgmt_prometheus |
resourceGroup | Resource group allows for grouping of similar resource types (host, weblogic_j2eeserver, apache_tomcat, etc) |
resourceName | Unique identifier for the resource that will be monitored. The resource name must be unique with the monitored compartment. |
scheduleMins | The frequency in which the metrics will be collected in minutes. The minimum value is 1 minute. If it is not specified, the default value is 5 minutes. |
url | The url through which the Prometheus Exporter publishes metrics. Management Agent will scrape metrics from this URL. |
Configuration nginx file example:
url=http://localhost:1234/metrics
namespace=oracle_appmgmt_prometheus
allowMetrics=*
compartmentId=ocid1.compartment.oc1..aaaaaaaanub6bf1234123412341234123412341234
resourceName=resourceName1
resourceGroup=resourceGroup1
metricDimensions=resourceName
scheduleMins=5
Stack Monitoring only supports oracle_appmgmt_prometheus
namespace
Importing Prometheus-based Resource
Users can import Prometheus resources by using the CLI.
The import resource CLI command needs the following mandatory parameters:
Input Field | Description |
---|---|
compartment-id | OCID of the compartment where the resource will be imported |
namespace |
This is the namespace from which the metrics are retrieved and dimensions are parsed to identify and import the resources. The user must select |
source | This value must be OCI_TELEMETRY_PROMETHEUS |
resource-group | Resource group that was assigned to the emitted metrics and will be used as the resource type for the imported resources. |
availability-proxy-metrics | Comma separated list of metric(s) that will be used to determine the resource availability. For more information, see Availability Status Calculation for Imported Resource. |
availability-proxy-metrics-collection-interval | For more information, see Availability Status Calculation for Imported Resource. |
Example command to import prometheus resources using the CLI
oci stack-monitoring resource-task import-telemetry-resources
--compartment-id "ocid1.compartment.oc1..aaaaaaaanub6bf1234123412341234123412341234"
--namespace oracle_appmgmt_prometheus
--source OCI_TELEMETRY_PROMETHEUS
--resource-group postgres
--availability-proxy-metrics "['pg_up']"
--availability-proxy-metric-collection-interval 300
Imported Resources Administration
Associating an imported resources with existing resources
To associate an imported resource, to another resource within Stack Monitoring, follow the steps below:
- From the Resource home page, click on Topology.
- Click on the Add association button.
- In the Add related resources popup, fill-in the fields:
- Relation - Select on of the two associations possible : Uses and Used by. The selected Related resource will be source or destination accordingly. If the association is Uses then the related resource becomes the destination in the association pair. If the association is Used by then the related resource becomes the source in the association pair
- Resource type - Select the resource type you want to associate.
- Resource - Select the resource to be associated. Based on the resource type selected, the Resource list will be populated with available option.
- Click Add resources
Once the association is added, the associated resource will show in the Topology table. If an incorrect association was created, click the delete icon to remove the relationship.
To create associations using CLI, see Application Topology.
Availability Status Calculation for Imported Resource
The availability status of an imported resource is determined as follows:
- A resource is considered up (available) if there is metric data for the OCI Service. It is considered down if there is no metric data.
- If an OCI Service that is down continues to emit metric data to OCI Monitoring, then its Lifecycle state attribute will be used to determine its availability status.
In other cases, such as MySql DB system, the availability status is calculated based on the presence of a predetermined metric. If the metric is present in the OCI monitoring namespace during the given time period, the imported resource is considered Up. If the metric data is absent during this period, the resource is considered down.
Viewing the OCI Resource in Stack Monitoring Enterprise Summary
Stack Monitoring allows you to monitor the availability status and performance metrics of the imported OCI resources in Enterprise Summary.
If the user does not have access to an autonomous database, the resource availability status will be shown as Not Reporting.
For more information on monitoring the status of your resources in Enterprise Summary, see Monitor the Status and Performance of Your Enterprise.
Process-based Custom Resources
- UI operations
- CLI operations
- Checking the Status of the Discovery Job
Process-based custom resources require Enterprise Extensibility to be enabled within a compartment. To enable Enterprise Extensibility license, navigate to the Licensing page within the Stack Monitoring UI.
You can monitor any custom resource, such as an application or application infrastructure, running on a host by identifying the processes that make up the resource and the hosts on which the resource is running. Once defined, Stack Monitoring creates a new resource instance for your custom resource which you can monitor using a built-in homepage. If this custom resource is used by an application monitored in Stack Monitoring, you can easily create an association between this custom resource and the application, therefore enriching your application topology.
The following metrics are collected for each Process Set that corresponds to your custom resource. These metrics are available as an aggregate over the entire process set, but also separately for each identified process name and owner, or label, if provided.
- Monitoring status
- Memory used (physical/virtual)
- Memory utilization
- CPU usage
- CPU utilization
- Total number of processes
To identify the specific set of processes that make up the custom resource, define a Process Set. When defining a Process Set, specify filters that consist of either a process name, process owner, or process line regular expression, which are then used to match the resource's running processes. Each filter needs to have at least one of the fields present. It is possible to add an optional label that serves as a symbolic reference to the processes matched by the filter. For example, to monitor the nginx application server as custom resource, create a Process Set called nginx processes that has a filter specifying the process name nginx
, with the process line regular expression nginx: main
, and a label nginx main process.
Processes used as input
The following command-line command is used on Linux to retrieve the processes that are used:
ps -ww -e -o comm:32,user:32,args
Piping the output from this command to a search tool such as grep allows you to isolate the processes you're interested in, and determine how to construct the Process Set. The following command shows process lines that contain the keyword nginx in them.
ps -ww -e -o comm:32,user:32,args | grep nginx
Executing this command outputs the following table, with three columns called: COMMAND, USER, and again COMMAND. The mapping from the table columns to the fields of a Process Set filter are as follows. The processCommand field of the filter is applied to the first COMMAND column, the processUser field is applied to the USER column, and the regular expression is applied to the last COMMAND column. If one of the fields is not provided, the column is ignored for that specific filter.
COMMAND | USER | COMMAND |
---|---|---|
bash | myuser | -bash |
init | root | /init |
nginx | root | nginx: main process nginx -c /etc/nginx/nginx.conf |
nginx | www-data | nginx: worker process |
Suppose you wish to monitor the master and worker processes separately, the Process Set payload could look as follows. The filter with label nginx-main-process matches the first process in the table, the filter with label nginx-worker-processes the others.
{
"compartmentId": "<Compartment_OCID>",
"displayName": "nginx processes",
"specification": {
"items": [
{
"label": "nginx-main-process",
"processCommand": "nginx",
"processLineRegexPattern": "nginx: master.*"
},
{
"label": "nginx-worker-processes",
"processCommand": "nginx",
"processLineRegexPattern": "nginx: worker.*"
}
]
}
}
The same can be achieved via the Monitor processes page, by creating a Process Set with 2 filters.
Create a Process Set Using the UI
A Process Set represents a specification for identifying processes running on a host that make up a custom resource, and consists of one or more filters that specify a set of processes running on a host.
A host process gets matched to a Process Set if it meets the criteria defined in one of the filters of the Process Set.
- From the Stack Monitoring menu, select Monitor processes
-
Click Create Process Set. The Create Process Set UI panel displays.
- Complete the required fields, for a detailed description of each field see UI Discovery Input.
- Create and map or Create the Process Set:
- Create and map allows you to create the Process Set and subsequently starts monitoring the selected hosts, in a single step.
- Create creates the Process Set without mapping it to any hosts.
Input field | Description |
---|---|
Display Name |
Name of the process set. NOTE: The name of the process set must be unique per compartment |
Label | A descriptive label for the processes matching the filter |
Process command | Specifies the command name. Only processes whose command name exactly matches this value are included. If this value is not specified, no filtering on command name is done. |
User | The name of the user running the process. Only processes whose user name exactly matches this value are included. If this value is not specified, no filtering on invoking user is done. |
Process line regex pattern | A regex pattern which is matched against the processes command line. The command line typically includes both the command name and any arguments passed when starting the process. |
Target hosts | The host(s) in which the process set runs and is to be monitored. |
Updating a process set
- From the Stack Monitoring menu, select Monitor processes
-
Choose the Process Set from the list of Process Sets.
- Make the necessary adjustments to the Process Set properties or specification.
- Select additional hosts to monitor under Target hosts.
- Save changes will:
- Update the Process Set on existing process-based custom resources.
- Map the updated Process Set to the selected hosts.
Creating a Process Set Using OCI-CLI
A Process Set represents a specification for identifying processes running on a host that make up a custom resource, and consists of one or more filters that specify a set of processes running on a host.
A host process gets matched to a Process Set if it meets the criteria defined in one of the filters of the Process Set.
A Process Set is created using an OCI-CLI command with a JSON payload. The JSON file contains a list of filter definitions, which is constructed using strings and regular expressions (regex) to filter out the processes that you're interested in. A Process Set is then defined using the OCI-CLI command: oci stack-monitoring process-set.Once you've created the Process Set, you can then run OCI-CLI commands that perform p
Once you've created the Process Set, you can then run OCI-CLI commands that perform process-based custom resource setup and configuration operations.
The payload of a Process Set has the following mandatory fields:
- compartmentId - the OCID of the compartment
- displayName - a symbolic name for the Process Set
- specification - a list of filters.
Each filter item has the following optional fields. However, at least one of processCommand
, processUser
, and processLineRegexPattern
must be specified. Filters are used to select which processes are part of the process set. A process must match all specified fields of one filter to be selected.
- label is a descriptive label for processes matching this filter.
- processCommand specifies the command name. Only processes whose command name exactly matches this value are included. If this value is not specified, no filtering on command name is done.
- processUser specifies the name of the user running the process. Only processes whose user name exactly matches this value are included. If this value is not specified, no filtering on invoking user is done.
-
processLineRegexPattern specifies a regex pattern which is matched against the processes command line. The command line typically includes both the command name and any arguments passed when starting the process. If the regex matches any substring of the command line (using javascript regex rules), the process is included. If this regex is not specified, no filtering on command line is done (but filtering on command name is still done, if specified).
Note
When a process matches multiple filters (for example, because the regular expressions are overlapping), it will only be matched against on the first matching filter.Note
To report the status of the resource as up, at least one process should be matched on each filter item.
Create a process set using the one of the below nginx payloads using the following OCI-CLI create
command.
Example of a CLI create
command:
oci stack-monitoring process-set create --compartment-id "<Compartment_OCID>" --from-json file://<JSON_INPUT_FILE>Examples of nginx payload files:
{ "compartmentId": "<Compartment_OCID>", "displayName": "nginx processes", "specification": { "items": [ { "processCommand": "nginx", } ] } }
This will monitor if at least one process is up, but it won't be checking if all required processes from
nginx
are up, nor have metrics for those specifically (only total summed on thenginx
process Command dimension).{ "compartmentId": "<Compartment_OCID>", "displayName": "nginx processes", "specification": { "items": [ { "processCommand": "nginx", "processLineRegexPattern": "nginx: master." }, { "processCommand": "nginx", "processLineRegexPattern": "nginx: worker." } ] } }
This will make sure all the processes required for nginx are monitored, and the
MonitoringStatus
is only up when there's the master process and at least one worker. The amount of granularity in metrics is the same as in the first example, as the dimensionsProcessCommand
is the same and the regex is not reported as a dimension in metrics.{ "compartmentId": "<Compartment_OCID>", "displayName": "nginx processes", "specification": { "items": [ { "label": "nginx-main-process", "processCommand": "nginx", "processLineRegexPattern": "nginx: master." }, { "label": "nginx-worker-processes", "processCommand": "nginx", "processLineRegexPattern": "nginx: worker." } ] } }
Adding a label will allow the user to differentiate the master and worker processes in the metrics.
Since in the nginx case the program is always nginx, we add a label to differentiate workers and master (as regex nor complete process line are being reported as dimensions).
Note that in the examples above the process user field processUser is omited to match on all processes regardless of which user owns the process.
The response contains the Process Set, and the property id
will contain the process_set_id
.
Identify the Hosts on Which the Custom Resource Should be Monitored
Now that a Process Set has successfully been created a custom resource can be created, to monitor this process set on a specific host. This is done by starting a Stack Monitoring Discovery Job, and creating a resource of type CUSTOM_RESOURCE
, via the Stack Monitoring DiscoveryJobs API. See the following payload for an example.
In this example, specify the agent and host on which the custom resource will be monitored.
The host on which the custom resource is running must be monitored by Stack Monitoring.
In the JSON payload, the license must be ENTERPRISE_EDITION
.
{
"discoveryType": "ADD",
"discoveryClient": "APPMGMT",
"compartmentId": "<Compartment_OCID>",
"discoveryDetails": {
"agentId": "<Agent_OCID>",
"resourceType": "CUSTOM_RESOURCE",
"resourceName": "nginx processes",
"properties": {
"propertiesMap": {
"host_ocid": "<Host_OCID>",
"process_set_id": "<ProcessSet_OCID>"
}
},
"license": "ENTERPRISE_EDITION"
},
"freeformTags": {},
"definedTags": {}
}
Once you've defined the JSON file, run the following command to create the custom resource discovery job:
oci stack-monitoring discovery-job create --compartment-id "<Compartment_OCID>" --from-json file://<JSON_INPUT_FILE>
Once the Discovery Job has completed, a Stack Monitoring resource of type CUSTOM_RESOURCE
named nginx processes and its corresponding homepage will be available.
Updating a process set
Updating a Process Set is similar to creating one. Determine the OCID of the Process Set you wish to update and perform an update using a payload structured similarly to the create payload. Once the update has been completed you will notice that the revision of the Process Set has been incremented. This is used to track which version of the Process Set specification is currently present on a monitored Host. Note that updating a Process Set via the OCI-CLI or via a REST call does not update the specification used to monitor the processes on a host.
Update a Process Ser using the following CLI command:
oci stack-monitoring process-set update --process-set-id <ProcessSet_OCID> --from-json file://<JSON_INPUT_FILE>
Using a raw request or a PUT request to /processSets/<ProcessSet_OCID>
:
{
"compartmentId": "<Compartment_OCID>",
"displayName": "nginx processes",
"specification": {
"items": [
{
"processCommand": "nginx",
"label": "all nginx processes filter"
}
]
}
}
Refresh a Custom Resource
When a process set is changed, update the process set on a custom resource using a REFRESH
Discovery Job command:
oci stack-monitoring discovery-job create --compartment-id "<Compartment_OCID>" --from-json file://<JSON_INPUT_FILE>
REFRESH
JSON payload example:
{
"discoveryType": "REFRESH",
"discoveryClient": "APPMGMT",
"compartmentId": "<Compartment_OCID>",
"discoveryDetails": {
"agentId": "<Agent_OCID>",
"resourceType": "CUSTOM_RESOURCE",
"resourceName": "nginx processes",
"properties": {
"propertiesMap": {
"resource_id": "<Resource_OCID>",
"host_ocid": "<Host_OCID>",
"process_set_id": "<ProcessSet_OCID>"
}
},
"license": "ENTERPRISE_EDITION"
}
}
The custom resource homepage reflects the currently in use process set and its revision.
Checking the Status of the Discovery Job
Once the command has been executed, the job's status and logs can be viewed within Stack Monitoring under the Resource Discovery page. From the Resource Discovery page, search for the submitted job with a Resource Name matching the name of the Custom Resource, a Resource Type of Custom Resource, and with a job type of Add
. Once the Job Status has Succeeded, click the name of the Custom Resource under Resource Name to navigate to the resource’s homepage.
For the list of metrics collected for custom resources, see Process-based Custom Resource Metrics.
For the list of recommended alarm rules for custom resource, see Process-based Custom Resource Sample Alarm Rules.