vania-janet/multiturn-rag-retrieval-data huggingface dataset:
See [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations) for more information.





 Are the two free months of transition period resources in addition to my existing server time? 

Yes. You can [contact an appropriate support representative](https://www.ibm.com/cloud/data-centers?contactmodule=undefined) to help you through the process of acquiring your transition period servers.





 How do I determine my current hardware configuration? 

You can find your system configuration details by selecting your device from your [list of resources](https://cloud.ibm.com/resources) in the IBM Cloud console.





 How do I determine the utilization of my current hardware? 

In general, you need to understand which specific resources within the system are required regarding things like the processor, memory, disk, and network. Having this information can help you better size your new system. For example, a system where memory capacity is frequently overcommitted is likely to benefit from larger memory sizes in the target system that you migrate to.

Most operating systems provide tools that you can use to understand the utilization of your system, for example, vmstat and iostat on Linux or Windows System Performance Monitor. Performance monitoring and tuning is something that you might invest significant time and effort in.

For more information, contact the [Client Success team](https://www.ibm.com/cloud/data-centers/?focusArea=WCP%20-%20Pooled%20CSM&contactmodule).





 How do I compare old and new processors? 

To compare the specifications of old and new Intel processors, go to [Intel processors product specifications page](https://ark.intel.com/content/www/us/en/ark.html@Processors). Newer processors tend to have more processor cores and typically run at slower clock speeds than older variants.

If you have a workload that is processor-bound, meaning that the performance is limited by the speed of the processor, choose a processor that has fewer cores and a higher clock speed. If you run many workloads that aren't constrained by processor speed, choose a processor with more cores and a similar, or slower, clock speed.
In the metric field, type ibm_codeengine_ for a list of Code Engine metrics. Select the ibm_codeengine_jobruns metric and specify a Maximum time aggregation and a Maximum group rollup. Specify the ibm_codeengine_jobrun_condition segmentation for this metric.
5. Check that you only set the ibm_codeengine_application_actual_instances and ibm_codeengine_jobruns metrics for this panel.
6. From the Panel tab, change the name of this panel to Application and Job Run Instances.
7. Click Save to save the changes for this panel



6. Keep the panels that were updated in the previous steps for this scenario, but use the actions menu to delete other panels. After you remove panels that are not needed, you can adjust the size and layout of the individual panels to meet your needs.

Whenever you change the layout of your dashboard, be sure to click Save Layout to save your changes. You must save the layout changes or cancel before you continue to make changes to your dashboard.



After you complete scenario 1, your custom dashboard includes three panels: Total number of Application Instances, Total number of Job Runs, and Application and Job Run Instances.





 Scenario 2: Using PromQL queries with Code Engine workloads 

From the custom dashboard that you created in Scenario 1, suppose you want to use the Prometheus Query Language (PromQL) query feature of IBM Cloud Monitoring to aggregate the number of applications and job runs metrics into one panel. In this scenario, let's use PromQL to add the number of application instances and the number of job runs into a single number panel.



1. Open your custom dashboard that was customized with Scenario 1. The custom dashboard is available in the dashboard navigation menu, Dashboards->My Dashboards.
2. Modify the Total number of Applications number panel and change the query to sum the number of application instances and the number of job runs.



1. Click the pencil icon to edit the panel.
2. From the Query tab, click PromQL to use PromQL queries.
3.
Type ibm_codeengine_ for a list of Code Engine metrics. For this example, select the ibm_codeengine_jobruns metric and specify a Maximum time aggregation and a Maximum group rollup.
3. From the Panel tab, rename this panel to Total number of Job Runs.
4. Click Save to save the changes for this panel.



4. Delete the Total number of Application routes number panel by using the action menu.
5. Modify the Applications overview timechart panel and change the query to display monitoring information about your application and job run instances by using the [ibm_codeengine_application_actual_instances](https://cloud.ibm.com/docs/codeengine?topic=codeengine-monitoribm_codeengine_application_actual_instances) and [ibm_codeengine_jobruns](https://cloud.ibm.com/docs/codeengine?topic=codeengine-monitoribm_codeengine_jobruns) metrics.



1. Click the pencil icon to edit the panel.
2. From the Query tab, keep the ibm_codeengine_application_actual_instances metric and remove the other rows of metrics by using the action menu for those metrics.
3. From the Query tab, locate the ibm_codeengine_application_actual_instances metric and modify the segmentation to include application revision information. Click ibm_codeengine_application_name and add ibm_codeengine_revision_name. Make sure that you clear the selection for Apply to All Queries.
4. From the Query tab, click Add Query to add a query for job runs. In the metric field, type ibm_codeengine_ for a list of Code Engine metrics. Select the ibm_codeengine_jobruns metric and specify a Maximum time aggregation and a Maximum group rollup. Specify the ibm_codeengine_jobrun_condition segmentation for this metric.
5. Check that you only set the ibm_codeengine_application_actual_instances and ibm_codeengine_jobruns metrics for this panel.
6.
Navigate to the [metrics monitoring portal](https://cloud.ibm.com/observe/monitoring), then click Create a monitoring instance.
2. Select a region for your monitoring instance.

If you do not have an existing load balancer, see [Creating an IBM Cloud Application Load Balancer for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-load-balancer) to provision one.

The region should match the location of your existing load balancer.
3. Choose your pricing plan.

Pricing plan details are explained in the selection window. Select the plan that best meets your requirements.
4. Provide a service name for your instance. It can be any name that you want, and has no impact on functionality.

Do not create multiple monitoring instances with the same name.
5. Optionally, select a resource group. A resource group is a way to organize account resources in customizable groupings. Any account resource that is managed by using IBM Cloud Identity and Access Management (IAM) access control belongs to a resource group within your account.

If you do not have any pre-configured resource groups, or no reason to share this resource selectively, use the default selection.

If your account has multiple resource groups, you can choose which one has access to this monitoring instance. This allows you to have metrics available to some resource groups and not to others.
6. Select the Enable Platform Metrics checkbox. You must select this to receive metrics from your load balancer.
7. Click Create. You are taken back to the monitoring metrics home page.



Within a few minutes, your new monitoring instance is displayed with several configurations. You might have to refresh your browser to see it.





 Working with the IBM Cloud Monitoring dashboard 

To view and work with your metrics, follow these steps:



1. Navigate to the [metrics monitoring portal](https://cloud.ibm.com/observe/monitoring).
2. Click View IBM Cloud Monitoring next to the service name of the monitoring instance that you want to work with.
The first time that you access your IBM Cloud Monitoring instance, several windows display as part of the internal setup. Leave these selections with their default entries, and click through the pages until you reach the IBM Cloud Monitoring main page.
3. Select Dashboards on the left sidebar to open the IBM Load Balancer Monitoring Metrics dashboard. Then, click Default Dashboards > IBM > Load Balancer Monitoring Metrics. The default dashboard is not editable.
4. Three main metrics in the dashboard are shown: Throughput, Active Connections, and Connection Rate. To modify options and segment your metrics by load balancer ID or listener port, you must create a custom dashboard.

You can choose what time window that you'd like to see your metrics by using the time selection bar. You can also zoom in and out for more granularity and drag the mouse to create a selection of a specific time window.







 Creating a custom metrics dashboard 

You can create your own dashboard to customize your monitoring metrics, such as viewing information about particular load balancers, or seeing only traffic that comes through HTTPS listeners.

To customize your dashboard, follow these steps:



1. Navigate to the [metrics monitoring portal](https://cloud.ibm.com/observe/monitoring).
2. Click View IBM Cloud Monitoring next to the service name of the IBM Cloud Monitoring instance you want to work with. The dashboard opens.
3. On the left sidebar, select Dashboards. Then, click the green + sign in the pane.
4. Select Blank dashboard, then select the type of visual representation you want.

IBM Cloud Monitoring offers eight different visualizations for your dashboard. Read the description for each visualization, then choose the one that best meets your requirements.

Line ("View trends over time") is the easiest and most basic option. It is also the most frequently selected option. The following examples show a Line-based visualization.
5. Configure your custom dashboard.



* In the Metrics field, enter ibm_cloud to display the IBM IBM Cloud Monitoring load balancer metrics.
You can define more than one target metric policy, but only one policy for each type of metric. Need more help? You can always run ibmcloud is instance-group-manager-policy-create --help to display help for creating a scaling policy.







 Next steps 

You can use [IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/vpc?topic=vpc-at-events) to find specific details that are related to instance group events. For more information, see [Instance group events](https://cloud.ibm.com/docs/vpc?topic=vpc-at-eventsevents-compute-instance-group).
For more details, [View the examples](https://cloud.ibm.com/docs/CDN?topic=CDN-code-examples-using-the-cdn-apiexample-code-for-getting-real-time-metrics).



* Parameters:



* mappingUniqueId - Unique ID of the mapping for which metrics are queried.
* startTime - The start time timestamp (UTC+0) for query. The start time must be later than 48 hours ago. For example, if it's 9:00 AM March 08 2020 now, the start time should be later than 9:00 AM March 06 2020 in the same time zone(the timestamp should be more than 1583485200).
* endTime - The end time timestamp (UTC+0) for query must be later than the start time.
* timeInterval - An optional parameter to provide the time interval in seconds. The time interval must be a multiple of 60 and should be less than the time range from start time to end time.



* Return - A collection of objects of type SoftLayer_Container_Network_CdnMarketplace_Metrics.



--------------------







 API for Geographical Access Control 



 createGeoblocking 

Creates a new Geographical Access Control rule, and returns the newly created rule.



* Parameters: A collection of type SoftLayer_Container_Network_CdnMarketplace_Configuration_Input. You can view all of the attributes in the Input container here:

[Input container](https://cloud.ibm.com/docs/CDN?topic=CDN-input-container)

The following attributes are part of the Input container and are required when creating a new Geographical Access Control rule:



* uniqueId - Provide a unique ID of the mapping to assign the rule.
* accessType - Specifies whether the rule will ALLOW or DENY traffic to the given region.
* regionType - The type of region to apply the Geographical Access Control rule to, either CONTINENT or COUNTRY_OR_REGION.
* regions - An array listing the locations that the accessType applies to.
With the same data set and aggregation as is used in the term aggregation example, the results might look as follows.Notice that the topic_indicator values are different from the trend_indicator values that are returned by the trend aggregation. While both are calculated from the actual and expected frequencies, they differ because their expected frequencies are computed differently. In the trend aggregation, the expected frequency of the feedback submissions for vanilla-flavored ice cream in May is computed from the number of feedback submissions that were received for vanilla previously (from Jan to Apr) and the total number of feedback submissions received for all of the flavors in May. However, in the topic aggregation, the expected frequency of feedback submissions for vanilla-flavored ice cream in May is calculated from the number of feedback submissions that were received for vanilla and the total number of feedback submissions received for all of the flavors in May. In this example, the expected frequency result is 12.169, the actual frequency is 10, and the topic_indicator is -0.621777032. {
"aggregations":
{
"type": "topic",
"facet": "term(flavor)",
"time_segments": "timeslice(date, 1month)",
"show_estimated_matching_results": true,
"show_total_matching_documents": true,
"results":
{
"aggregations":
{
"type": "term",
"field": "flavor",
"results":
{
"key": "vanilla",
"matching_results": 36,
"aggregations":
{
"type": "timeslice",
"field": "date",
"results":
{
"key": 1577836800000,
"key_as_string": "2020-01-01T00:00:00.000Z",
"matching_results": 4,
"topic_indicator": -0.027972712,
"total_matching_documents": 7,
"estimated_matching_results": 4.056338028
Wait for the instances to scale as the aggregate period is set to 90 seconds and cooldown period set to 120 seconds.
5. Wait for the instances to scale to 1 before moving to the next step.







 Scheduled actions 

In this section, you will use scheduled scaling for VPC to schedule actions that automatically add or remove instance group capacity, based on daily, intermittent, or seasonal demand. You can create multiple scheduled actions that scale capacity monthly, weekly, daily, hourly, or even every set number of minutes.



1. To create a one-time scheduled action, set the step3_is_scheduled variable to true, Save the setting and Apply the plan.
2. Check the status of your scheduled action under the scheduled actions tab of the instance group. The Terraform template will schedule the actions for 5 minutes from the time you apply the plan. When the status of the action is changed to completed, the instance group size will be set to a minimum of 2 and a maximum of 5 instances. You should see 2 instances under the Memberships tab of the instance group.
3. Click on Generate load a couple of times to generate more traffic to see the instances scale to a maximum of 5.







 Monitoring Load Balancer for VPC metrics 

Load balancers calculate the metrics and send those metrics to your monitoring instance, which reflects different types of use and traffic. You can visualize and analyze metrics from the IBM Cloud Monitoring dashboard.



1. You can monitor your load balancers from the [Load balancers for VPC](https://cloud.ibm.com/vpc-ext/network/loadBalancers) page by



1. Clicking on the name of the load balancer.
2. Under Monitoring preview tile of the load balancer, click on Launch monitoring.



2. Alternatively, you can also monitor the load balancers by navigating to the [Observability](https://cloud.ibm.com/observe) page and click Monitoring on the left pane



1. Click on Open dashboard next to the instance marked as Platform metrics.
2. Click on Dashboards on the left sidebar to open the IBM Load Balancer for VPC Monitoring Metrics dashboard.
This panel uses the query sum(sysdig_ts_usage)by(metric_category) that you can also run in PromQL Explorer, in your dashboards or for alerts.

In case you need to investigate which applications or services are contributing more to the Prometheus time-series, you can use the metric scrape_series_added. This metric represents the number of time series scraped and ingested from the monitoring agent via Prometheus and includes several labels to facilitate the analysis such as kube_cluster_name, kube_namespace_name, kube_workload_name or container_name.

The following query represents the number of time series ingested from the monitoring agent via Prometheus grouped by cluster, namespace, workloads and container so you can identify those applications that are contributing more time series:

sum(scrape_series_added)by(kube_cluster_name, kube_namespace_name, kube_workload_name, container_name)







 Billing samples 



 Billing sample 1: Basic usage 

Consider the following example where you have the following configuration:



* 1 Kubernetes cluster with 3 worker nodes running agents for orchestrated environments



* Host-1 generates 1200 custom metrics time-series
* Host-2 generates 1000 custom metrics time-series
* Host-3 generates 1500 custom metrics time-series





The billing calculation for the month is calculated as follows:



* Base cost per host

The base price per host per month is 36 USD which includes up to 1K time-series (includes Prometheus, JMX, appchecks, and StatsD metrics).

For 3 hosts, the total monthly base cost is 108 USD.

3 * 36 USD = 108 USD
* Additional time-series cost

Each host has a 1000 time-series allotment that are included in the base cost per host of 36 USD. If you have 3 hosts, you have 3000 time-series included. The remaining time-series are priced based on the tiers. The following shows the calculation of the 700 additional time-series.

1200 + 1000 + 1500 - ( 31000 ) = 700

The result from adding the time series per host minus the allotment defines the tier that is applied for pricing.
[Launch the monitoring UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launch).
2. Navigate to the Settings section.

Zoom

![Settings section](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/platform/images/sysdig-platform-12.png)

Settings
3. Select Teams. Then, select a team where you want to restrict access to the platform metrics.
4. In the Visibility section, select Platform metrics.
5. Select the attribute ibm_service_instance to segment data by instance ID.
6. Select 1 or more instance IDs for which you want the data to be visible to users that are members of this team.
7. Add additional global attributes. Other attributes are available per IBM Cloud service. In the [Cloud services](https://cloud.ibm.com/docs/monitoring?topic=monitoring-cloud_services) topic, identify the service that you want to monitor and navigate the the More info section. Look for the section Attributes for segmentation to get the list of attributes that you can use to segment metrics for that service.
8. Click Save.
6. Customize the metric to see data per topic.

![Customize metric.](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/streaming-topic-metric-1.png)
7. Check that the resolution is set to 10M.



If you do not see data, do 1 of the following:



* Resend sample logs to verify that sample data is streaming.
* Check my setup to go back to the configuration panel. After you make your changes, retry the verification steps.



If you see data, click YES.

After you provision an instance of Event Streams, the Monitoring dashboard may take up to 15 mins to show.





 Step 5. Start streaming 

After you verify that sample data is reaching Event Streams, click Start stream.

Streaming may take up to 15 minutes to begin.
Enabling platform metrics 

You can configure 1 instance only of the IBM Cloud Monitoring service per region to collect platform metrics in that location.



* Platform metrics are metrics that are exposed by enabled-monitoring services and the platform in IBM Cloud.
* To monitor platform metrics for a service instance, provision the IBM Cloud Monitoring instance in the same region where the IBM Cloud service instance that you want to monitor is provisioned.



In a region, before you configure a monitoring instance to collect platform metrics, check with the account or service administrator if another monitoring instance has already been configured. You may not have permissions to see all monitoring instances in the region.



 Enabling a monitoring instance through the UI 

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



 Step 1. Provision a monitoring instance 

[Provision an instance of IBM Cloud Monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision) in the region where the service that you wish to monitor is running.

For example, if you are monitoring an Event Streams instance in the London region, then you must create a monitoring instance in London.





 Step 2. Set on the platform metrics flag 



1. From the IBM Cloud dashboard, go to the menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > Observability to access the Observability dashboard.
2. Select Monitoring > Options > Edit platform.
3. Select a [region](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_regions).
4. Choose the monitoring instance that will collect metrics from enabled services on that location.
5. Click Select.



The main Observability page opens.







 Enabling a monitoring instance from the command line 

To enable platform metrics in a region, the instance that you want to configure to receive platform metrics must have set on the default_receiver property.

Complete the following steps:



1.
You can configure 1 instance only of the IBM Cloud Monitoring service per region to collect platform metrics in that location. For more information about supported locations, see [Locations supported by the Monitoring service](https://cloud.ibm.com/docs/monitoring?topic=monitoring-regions).

In a region, before you configure a Monitoring instance to collect platform metrics, check with the account or service administrator if another Monitoring instance has already been configured. You may not have permissions to see all Monitoring instances in the region.
* Configure IBM Cloud Metrics Routing in the IBM Cloud account

You can use IBM Cloud Metrics Routing, a platform service, to collect and route metrics at the account-level by configuring targets and routes that define where and how metrics are routed in the account. Supported targets are Monitoring instances.

IBM Cloud Metrics Routing routes metrics based on filtering conditions that are defined by 1 or more of the following values from the incoming service data. Presently, we allow the following operands: location, service name, service instance ID, resource type, and resource.

You can define a target, the resource where metrics are routed to, in any IBM Cloud Metrics Routing supported region. However, the target resource can be located in any region where that type of target is supported, in the same account or in a different account. You can define rules to determine where metrics are to be routed by configuring 1 or more routes in the account. For more information about how to configure IBM Cloud Metrics Routing, see [Getting started with IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-getting-started).

IBM Cloud Metrics Routing can only route metrics that are generated in [supported regions](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions). Other regions, where IBM Cloud Metrics Routing is not available, continue to collect and manage metrics by using the Monitoring service.



You can collect metrics that are generated by IBM Cloud Metrics Routing by using any of the following methods:



Table 1.