vania-janet/multiturn-rag-retrieval-data huggingface dataset:
After you configure IBM Cloud Metrics Routing in your account, metrics are routed to the target of your choice. You are responsible for managing the metrics in the target resources.

All data and the configuration that is required for the IBM Cloud Metrics Routing service deployment is retained within the region in which it is hosted.

The IBM Cloud Metrics Routing's metadata in your account is hosted in the primary metadata location and the backup metadata location. You choose the primary and backup regions. You can choose any location as long as the location is one where the IBM Cloud Metrics Routing is available.

The metrics that you route to 1 or more destinations stay in the same region where they are generated if you configuration sends them to destinations in the same region. However, you might have destinations collecting metrics from other regions or even in destinations in a different IBM Cloud account. Metrics will cross regions or even accounts in these scenarios. Your IBM Cloud Metrics Routing service configuration define where metrics data is routed.

The flow of all customer data between IBM Cloud Metrics Routing and its dependencies uses private network connections. For more information about private connections, see [Using service endpoints to privately connect to IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-service-endpoints).





 Connections 

You can use private and public endpoints to configure IBM Cloud Metrics Routing resources in your account.



 Private connections 

You cannot disable private endpoints.





 Public connections 

You can choose to disable public endpoints for IBM Cloud Metrics Routing.

For more information, see [Enforcing private endpoints to configure IBM Cloud Metrics Routing resources](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpoints-enforce-private).







 Dependencies to other IBM Cloud services 

Review the IBM Cloud services that IBM Cloud Metrics Routing connects to over public or private connections.



Table 1. IBM Cloud Metrics Routing dependencies to other IBM Cloud services.
The first column is the service. The second column is a description of the service.

 Service name Description
Select VPC Infrastructure service for What type of access do you want to assign?
7. Leave the default Account for in
8. Leave All resource types for Resource type and click Viewer for Platform Access.
9. Click Add > Assign. The VPC Infrastructure Service policy is assigned to your Service ID.







 Creating an API Key for the Service ID. 

Use the following steps to create an API Key for the new Service ID.



1. Select Service IDs and your newly created Service ID
2. Click the tab Access Policy and verify that the VPC Infrastructure Service is listed as an Access Policy. If not repeat steps 4-9.
3. Click the next tab API keys > Create.
4. Enter a Name and Description for the key and click Create.
5. Click Copy or Download your API key to save it.



This is the only opportunity to access the API Key's data. You cannot view this API key again, so you cannot retrieve it later.







 Installing the IBM Metrics Collector for SAP on Linux 

The IMCS is a daemon or service that automatically starts as soon as it is installed and requires an API key. It collects metrics from the metadata of the virtual server, IBM Cloud infrastructure services, runtime data about resources, such as CPU, memory, network, and disk. The metrics are aggregated and displayed through the web server for SAP customers. SAPOSCOL uses the XML output of this web server.

The IMCS uses port 18181 to display the metrics. Make sure that port 18181 is not used by any other application. For more information about checking port availability, see [Troubleshooting](https://cloud.ibm.com/docs/sap?topic=sap-ibm-metrics-collector-for-sap-linuxtroubleshooting-linux).

The commands that are listed in this section were run on a Red Hat virtual server instance. If you have a SUSE virtual server, you can follow the same steps but you will see a slightly different user interface.

Use the following steps to download the IMCS.



1.
* You need to enable the [metrics policy](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-monitoring-metrics) for your Hyper Protect Crypto Services instance in order to retrieve operational metrics.
* Other IBM Cloud users with administrator or editor permissions can manage the Monitoring service in the IBM Cloud. These users must also have platform permissions to create resources within the resource group where they plan to provision the instance.







 Connecting Monitoring with Hyper Protect Crypto Services 

Your dashboard show metrics for all Hyper Protect Crypto Services instances that are in the same region as the Monitoring instance with an enabled metrics policy.



 Configure a Monitoring instance for metrics 

To enable platform metrics in a region, complete the following steps:



1. [Provision an instance of Monitoring](https://cloud.ibm.com/docs/Monitoring-with-Sysdig?topic=Monitoring-with-Sysdig-provision) in the region of the Hyper Protect Crypto Services instance that contains an [enabled metrics policy](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-monitoring-metrics).
2. Go to the [monitoring dashboard](https://cloud.ibm.com/observe/monitoring).
3. Click Configure platform metrics.
4. Select the region where the Hyper Protect Crypto Services instance is created.
5. Select the Hyper Protect Crypto Services instance in which you would like to receive metrics.
6. Click Configure.
7. Your Hyper Protect Crypto Services instance is now set for platform metrics.









 Hyper Protect Crypto Services Metrics Details 

You can use the metrics in your Monitoring dashboard to measure the types of requests that are made to your service instance as well as the latency of the requests.



 API Hits 

The type and number of API requests that are made to your Hyper Protect Crypto Services instance.
When you configure IBM Cloud Metrics Routing in your account, you can configure account settings such as metadata locations, type of endpoints that are allowed to manage the configuration, locations where targets can be defined, and default targets for collecting metrics in regions that you have not explicitly configured how to route metrics. For more information, see [Configuring IBM Cloud Metrics Routing account settings](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-settings).

Before you can configure targets and routes in the account, you must configure the primary metadata location that defines the region where all your IBM Cloud Metrics Routing resource definitions are stored.

Run the following command to configure the primary metadata location:

ibmcloud metrics-router setting update --primary-metadata-region <REGION>

Where <REGION> is set to a supported region where IBM Cloud Metrics Routing is available. For more information, see [Locations](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions).

Before setting the metadata location, check any compliance or industry regulations that apply to the data location.





 Step 2. Configure 1 target 

A target defines where metrics are collected. For more information about targets, see [Understanding how targets work in your account](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-target&interface=clitarget_behavior).

When you configure a target, you are defining the destination where you plan to send platform metrics that are collected in a region in your account.

Complete the following steps to configure a target:



1. Define a target where to route metrics.

ibmcloud metrics-router target create --name TARGET_NAME --destination-crn DESTINATION_TARGET_CRN [--region REGION]

Where

--name
: Defines the name to be given to the target.

--destination-crn
VMWare virtual machines assigned non-IBM Cloud addresses (such as VMWare NSX networks) cannot be added directly as back-end servers to the load balancer. However, depending on your configuration, it might be possible to configure an intermediary, such as an NSX gateway, that has a IBM Cloud private address as the back-end server to the load balancer (with the actual servers being VMs attached to networks managed by VMware NSX).





 If I choose to use a public VLAN under my account to deploy my load balancer and I have a firewall deployed on my public VLAN, what configurations are required on my firewall to work with my load balancer service? 

TCP port 56501 is used for management. Ensure that incoming traffic to this port is not blocked by your firewall, otherwise, load balancer provisioning fails. Some outbound traffic is also required to be open to make sure the load balancer functions properly.

In summary, this is the required firewall configuration:



Required firewall configuration

 Inbound/Outbound Protocol Source IP Source Port Destination IP Destination Port 

 Inbound TCP AnyIP AnyPort AnyIP 56501 
 Inbound TCP AnyIP 443 AnyIP AnyPort 
 Inbound TCP AnyIP 10514 AnyIP AnyPort 
 Inbound TCP AnyIP 8834 AnyIP AnyPort 
 Outbound TCP AnyIP 56501 AnyIP AnyPort 
 Outbound TCP AnyIP AnyPort AnyIP 443 
 Outbound TCP AnyIP AnyPort AnyIP 10514 
 Outbound TCP AnyIP AnyPort AnyIP 8834 



Also, ensure your application's ports are open to accept traffic.





 What if I cannot see the monitoring metrics of an existing load balancer after linking my Softlayer account to IBM Cloud? 

Monitoring metrics are not available for existing load balancers after linking the accounts. You must re-create the load balancers or contact IBM Support. Monitoring metrics for newly created load balancers is available.





 Are the load balancer IP addresses fixed? 

IBM cannot guarantee load balancer IP addresses to remain constant due to the elasticity that is built into the service.
For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api
* You can pass multiple headers by using -H.

Authorization and IBMInstanceID are headers that are required for authentication.

SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

To get an AUTH_TOKEN and the GUID see, [Headers for IAM Tokens](https://cloud.ibm.com/docs/monitoring?topic=monitoring-mon-curlmon-curl-headers-iam).



All dashboards support the full PromQL API. For more information about what’s possible with PromQL, see the [Prometheus documentation](https://www.prometheus.io/docs/prometheus/latest/querying/api/).





 Sample: cURL sample to extract CPU data for a team 

This example shows how to extract CPU data that is available within the context of a team.

curl -X POST https://us-south.monitoring.cloud.ibm.com/api/data -H "Authorization: Bearer $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: 30785" -H "content-type: application/json" -d @metrics.json





 Sample: Extract metric data from Monitoring to Event Streams 

You can use the following code example to extract metrics from your Monitoring instance to Event Streams.



* Replace <region> with the region of your Monitoring instance, such as us-east.
* Replace <apikey> with an IBM Cloud [IAM API key token](https://cloud.ibm.com/docs/monitoring?topic=monitoring-api_token).
* Replace <instance_id> with the ID of your Monitoring instance.
* Replace the metrics field with the JSON array of metrics that you want to extract. The example metric is cpu.cores.used.



from sdcclient import IbmAuthHelper, SdMonitorClient
With a dedicated processor partition, you need to size the wanted number of cores to meet the peak demand of the partition. For example, if during a typical workday the CPU consumption is around four cores, but it peaks around eight cores, you need to configure the partition with eight cores. Otherwise, you might encounter queuing delays in dispatching applications because there are not enough cores to handle the peak demand. 





Table 2. Shared processors

 Shared processors 

 For shared processors, there are two sharing modes: capped or uncapped. For a capped partition, the amount of CPU time is capped to the value specified for the entitlement. For example, the partition might consume at most 30 seconds of CPU time every minute for a capped partition with processing units set to 0.5. For an uncapped partition, the number of virtual processors defines the upper limit of CPU consumption and not the value that is specified for processing units. For example, if virtual processors are set to 3, the partition might consume 180 seconds of CPU time every minute (three virtual processors each running at 100% utilization would be three physical cores worth of CPU time). There must be unused capacity available on the server for a partition to consume more than its configured processing units. 



* How does my current environment compare to what's available through the Power Systems Virtual Server?

If you'd like to compare your current environment's performance to what's available through the Power Systems Virtual Server offering, see the [IBM Power Systems Performance Report](https://www.ibm.com/downloads/cas/K90RQOW8). For a more condensed comparison, see [IBM Power Systems CPW performance data comparison](https://www.itechsol.com/wp-content/uploads/2018/07/IBM-Power-Systems-CPW-Performance-Data-Comparison-P7-vs-P8-vs-P9-rev3-July-2018.pdf).
* How do I migrate my VM from one data center to another (WDC04 to DAL13)?

To migrate your VM from one data center to another, you must capture and export your VM to Cloud Object Storage (COS).
[IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router) Use IBM Cloud Metrics Routing to configure the routing of platform metrics generated in your IBM Cloud account. [Platform metrics](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-platform-metrics) 







 Satellite 

The following table lists services that are enabled for IBM Cloud Monitoring:



Table 8. Satellite

 Service Description Metrics 

 [IBM Cloud Satellite®](https://cloud.ibm.com/docs/satellite?topic=satellite-getting-started) With IBM Cloud Satellite, you can bring your own compute infrastructure to run IBM Cloud services and consistently deploy, manage, and control your app workloads. [Platform metrics](https://cloud.ibm.com/docs/satellite?topic=satellite-monitor) 







 Security services 

The following table lists Cloud services that are enabled for IBM Cloud Monitoring:



Table 9. List of security services

 Service Description More info 

 [IBM® Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorialgetting-started-tutorial) You can use the Key Protect service to provision encrypted keys for apps across the IBM Cloud. [Platform metrics](https://cloud.ibm.com/docs/key-protect?topic=key-protect-operational-metrics) 
 [IBM Cloud Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) You can use the Hyper Protect Crypto Services to control your cloud data encryption keys in cloud hardware security modules for apps across the IBM Cloud. [Platform metrics](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-operational-metrics) 







 Serverless 

The following table lists container services that are enabled for IBM Cloud Monitoring:



Table 10. List of serverless services

 Service Description Metrics
For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Hyper Protect Crypto Services instance. For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-instance-ID). 



A successful request returns an HTTP 204 No Content response, which indicates that the metrics policy is disabled for your service instance.
3. Optional: Verify that the metrics policy is disabled by browsing the policies that are available for your Hyper Protect Crypto Services instance.

$ curl -X GET "https://api.<region>.hs-crypto.cloud.ibm.com/api/v2/instance/policies?policy=metrics"   -H "accept: application/vnd.ibm.kms.policy+json"   -H "authorization: Bearer <IAM_token>"   -H "bluemix-instance: <instance_ID>"









 What's next 

To find out more about configuring your Hyper Protect Crypto Services instance with Monitoring, check out [Monitoring Operational Metrics](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-operational-metrics).
Or, use trusted profiles to set up fine-grained authorization for applications that are running in compute resources. This way, you aren't required to create service IDs or API keys for the compute resources. You can also establish trust with IBM Cloud services or service IDs in another account to grant cross-account access. For more information, see [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).





 Assigning access to IBM Cloud Metrics Routing in the console 

There are two common ways to assign access to IBM Cloud Metrics Routing in the console:



* Access groups. You can manage access groups and their access from the Manage > Access (IAM) > Access groups page in the console. For more information, see [Assigning access to a group in the console](https://cloud.ibm.com/docs/account?topic=account-groups&interface=uiaccess_ag).
* Access policies per user. You can manage access policies per user from the Manage > Access (IAM) > Users page in the console. For information about the steps to assign IAM access, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=uiaccess-resources-console).







 Assigning access to IBM Cloud Metrics Routing in the CLI 

For step-by-step instructions for assigning, removing, and reviewing access, see [Assigning access ro resources by using the CLI](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=cliaccess-resources-cli). The following example shows a command for assigning the Viewer role for IBM Cloud Metrics Routing:

Use metrics-router for the service name. Also, use quotations around role names that are more than one word.

ibmcloud iam user-policy-create USER@EXAMPLE.COM --service-name metrics-router --roles "Viewer"





 Assigning access to IBM Cloud Metrics Routing by using the API
For more information, see [Enforcing private endpoints to configure IBM Cloud Metrics Routing resources](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpoints-enforce-private).







 Dependencies to other IBM Cloud services 

Review the IBM Cloud services that IBM Cloud Metrics Routing connects to over public or private connections.



Table 1. IBM Cloud Metrics Routing dependencies to other IBM Cloud services.
The first column is the service. The second column is a description of the service.

 Service name Description 

 IBM Cloud Internet Services IBM Cloud Internet Services is used as a provider for DNS and load-balancing capabilities. 
 IBM Cloud Kubernetes Service IBM Cloud Metrics Routing uses IBM Cloud Kubernetes Service to run its service. 
 IBM Cloud Monitoring IBM Cloud Metrics Routing integrates with Monitoring, by using a private connection, to send platform metrics. For more information, see [Monitoring metrics for IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-monitoring_metrics). 
 IBM Cloud Platform To authenticate requests to the service and authorize user actions, IBM Cloud Metrics Routing implements platform and service access roles in Cloud Identity and Access Management (IAM). For more information about required IAM permissions to work with the service, see [Managing access for IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam). Connections from IBM Cloud Metrics Routing to IAM do not use private connections. 
 IBM Cloud Databases for PostgreSQL IBM Cloud Metrics Routing uses IBM Cloud Databases for PostgreSQL for storing metadata. 
 Key Protect IBM® Key Protect for IBM Cloud® is used to store encrypted keys that are required to operate the service. This does not include Bring Your Own Key (BYOK). 







 Workload isolation 

Each regional deployment serves multiple tenants that are identified by the IBM Cloud account ID.



* There is 1 deployment per region that is responsible for running user workloads in the region.
The region of your buckets us-east 



ibmcloud resource service-instance-update <INSTANCE_NAME> -p '{"default_receiver": true}'





 Connect Object Storage to Monitoring 

Most of the work you will do with Monitoring will be in specific dashboards to be discussed later. But first, there are a couple of ways in which you can get started.

Complete the following steps to get an IAM token:



1. From a terminal, log in to the IBM Cloud.
2. Run the following command to get a token:

ibmcloud iam oauth-tokens



Keep the token handy for later if you are using the Dev Tools CLI.



 Configure a bucket for metrics 

Metrics are only sent to Monitoring every 24 hours. Any alert thresholds exceeded on metrics will not trigger until the next time the metrics are sent to Monitoring.

When creating a bucket, you can configure your Monitoring instance at the same time.

![Bucket creation](https://cloud.ibm.com/docs-content/v1/content/63322f2f3a72050206eb05ba7f590fdcb741105c/cloud-object-storage/images/SysDig-COS-UI-bucket-creation.png)

You can also configure an existing bucket to use the Monitoring instance by selecting configuration in the console.

![Bucket modification](https://cloud.ibm.com/docs-content/v1/content/63322f2f3a72050206eb05ba7f590fdcb741105c/cloud-object-storage/images/SysDig-COS-UI-bucket-modification.png)

Note that in each case the region for your new instance of Monitoring is automatically tied to the region of the bucket.

Note that if the Monitoring instance is created by COS, Platform metrics must be set on the Monitoring instance.

To set Platform metrics on the instance:



1.
IBM Cloud Monitoring 

IBM Cloud Monitoring collects basic Classic infrastructure and VPC virtual server instance metrics such as CPU usage, disk usage, network traffic, and memory. These metrics are stored in IBM Cloud Monitoring. You can access metrics through the prebuilt dashboard.

IBM Cloud Monitoring metrics are available only if you use the monitoring full agent. If you provisioned a 'no driver mode' instance, see [IBM Cloud Monitoring 'no driver mode' metrics](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-enabling-monitoring-light-no-drivermonitoring-light-metrics).



 Platform metrics overview 

You can view platform metrics when you enable monitoring services on your IBM Cloud platform. A monitoring instance must be configured in a region to monitor these metrics. For more information about enabling Platform metrics, see [Enabling platform metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enabling).

Before you enable IBM Cloud Monitoring on your platform, keep the following information in mind:



* You can configure only one instance of the IBM Cloud Monitoring service per region to collect platform metrics.
* Platform metrics are regional. Metrics are monitored only from IBM Cloud Monitoring services that are in the same region of the instance that you want to monitor.
* Metrics are collected automatically and are available for monitoring through the IBM Cloud Monitoring-enabled instance.





 Metrics available by virtual server generation 



* To view Classic virtual server monitoring metrics, see [Classic virtual server instance metrics definitions](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-monitoring-classic-metrics).
* To view VPC virtual server monitoring metrics, see [VPC virtual server instances metrics definitions](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-monitoring-metrics)









 Basic monitoring 

You use basic monitoring to initiate service and slow pings to make sure that the device is online and responsive.



Table 1. Basic monitoring service types

 Basic monitoring service types Description