vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Be as descriptive as possible so that it's easy for other members of your team to understand what is being evaluated. Then, click Next.
3. Select the Profile and Profile version that you want to use for your evaluation.
4. Customize the underlying evaluations in your scan by editing the default parameters to match your specific use case.
5. Define a Scope to identify the resources that you want to evaluate and those that you want to Exclude. Then, click Next.
6. Select the frequency at which you want to evaluate your attachment. Options include every day, every 7 days, and every 30 days. Additionally, you can pause your scans if you need to.



Profiles are created from libraries. There is a predefined profile, but you can create a custom profile to use only the controls that you want. In other words, create a custom profile if you don’t want to use all the controls in the predefined profile.

For more information, see [Running an evaluation](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-scan-resources).





 Viewing the results 

To view the results, go to the Security and Compliance Center dashboard.

Zoom

![A visual representation of the Security and Compliance Center dashboard. The concepts are fully explained in the surrounding text.](https://cloud.ibm.com/docs-content/v1/content/a6478671e8f845a84102d9cf49bf28ee7f4f3227/security-compliance/images/dashboard.svg)

Figure 2. Example dashboard

When you visit the Security and Compliance Center dashboard, three graphical representations of data are aggregated from your scans. The following data is displayed:

Success rate
: The rate at which your configurations pass the evaluation that is conducted.

The number of evaluations conducted does not always match the number of billable evaluations, as there is no charge for assessments evaluated as unable to perform. Be sure to look for the billable evaluations in each scan result if you need to estimate your cost.

Total controls
Leaving these two lines out of your request returns an aggregate sum over that time period instead.

If the time range specified by from and to is large (for example, 4 days), but you define a sampling and value of 10 seconds, this means that you receive 4 days worth of data that is split into 10-second chunks. This is not a useful sampling due to the large amount of data returned. Specifying a larger chunk is recommended (for example, 1 hour instead of 10 seconds).

curl -H 'Authorization: Bearer <API_TOKEN>’ -H 'Content-Type: application/json' https://us-south.monitoring.cloud.ibm.com/api/data/batch -d '{
"requests": [
{
"format": {
"type": "data"
},
"scope": "ibm_resource = "cfc851b1-f30b-4a06-b354-5b64526c0a69"",
"metrics": {
"k0": "timestamp",
“v1”: "ibm_is_load_balancer_throughput"
},
"time": {
"from": 1584396900000000,
"to": 1584402600000000,
“sampling”: 600000000
},
"group": {
"by":
{
"metric": "k0",
“value” : 600000000
}
],
"aggregations": {
“v1”: "sum"
},
"groupAggregations": {
“v1”: "sum"
}
}
}
]
}'
Show more
Resource monitoring 



 Dasboard 

On the Dashboard page, you can view graphs for the following items:



* Resource consumption
* Query throughput
* Query performance
* Query runtime distribution
* Sessions
* Current GRA distribution



By default, the information is saved for the following time intervals.



* 1 hour
* 6 hours
* 12 hours
* 24 hours
* 3 days



You can also set a custom time setting.



1. Click Custom.
2. Specify the start and end dates.
3. Click Done.



For any of the charts, you can zoom in and out by moving the slider to see a specific range. You can also expand your graph view by clicking the arrows icon.



 Resource consumption 

The resource monitor chart summarizes several key system resources for the monitored system.

The chart displays information about the overall CPU, disk, fabric network, and memory utilization of the monitored system.





 Query throughput 

The query throughput chart displays a current summary and view of the query throughput of the system. You can view the number of queries that are running over time on the system.

Queries can be grouped basing on the number of queries that run per minute or per hour.





 Query performance 

The query performance chart displays information on the query preparation time. Query preparation time is the time between when a query is submitted and when it starts to run. The chart also shows the total duration of a query.

The charts can help you to identify the busiest and the least busy hours for your system, and whether the query trend is growing or decreasing over time. You can also identify times when queries take the longest to run.

This features can help you to plan for activities such as scheduling maintenance windows during the least used times and identifying the busiest times when high activity might cause users to report query result delays or performance concerns.





 Query runtime distribution 

The query runtime distribution chart displays a relative duration of a query over time.





 Sessions 

The sessions chart displays the number of connections over time. You can also view the list of sessions, change priority, stop transactions, or stop sessions.





 Current GRA distribution
[Pencil icon](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/images/pencil.png). The select the desired scope. By default, Entire infrastructure is selected.



1. Select the scope.
2. Optionally, click Override the custom panel scopes to override the scope for all panels which currently have a custom scope defined.

This action cannot be undone.

To reset the dashboard scope to the entire infrastructure, or to update an existing dashboard's scope to the entire infrastructure, select Entire infrastructure.
3. Click Save.



4. Configure panels. Repeat this step for any of the panels in the dashboard that you want to modify.



1. Identify the panel that you want to modify.
2. Select Edit Panel. This is the Pencil icon ![Pencil icon](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/images/pencil.png).
3. Change the a chart type.
4. Change the metric, and rate. Rate defines the type of aggregation that is done to the data.
5. Change the scope of the panel. Click the Pencil icon ![Pencil icon](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/images/pencil.png). Then, change the scope. If you need to restore the dashboard scope to the panel, delete the custom scope. Click Apply.
6. In the Compare to field set the time range for the comparison.
7. For Number and Threshold chart types you can set the panel color based on metric thresholds.
You might get the error message: Your request is taking longer than expected, try refreshing your browser after a few minutes of delay to allow logs to flow into the service. Also, ensure that the the timeframe selected is likely to have events available for display. It may be required to change the time query, and retry.





 Create a dashboard 

You can create a dashboard to monitor your app graphically through interactive graphs. For example, you can use graphs to analyze patterns and trends over a period of time.

Index fields are created on a regular schedule. Currently it is done at 00:01 UTC (midnight). The following steps that require fields will not be possible until this process completes.

Complete the following steps to create a dashboard to monitor logs from the lab's sample app:



1. In the Log Analysis web UI, click the Boards icon.
2. Select NEW BOARD to create a new dashboard.
3. Click Add Graph.
4. Select the Field All lines under Graph a field.
5. Select the Filter app:patient-health-frontend.

Zoom

![New Board](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/board-img-4.png)

New Board
6. Click Add Graph.

Zoom

![Add Graph](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/board-img-5.png)

Add Graph
7. Note the view that displays the count of logs lines for the frontend app. Click the graph in a peak of data at the time that you want to see logs, and then click Show logs.
Monitoring metrics for Container Registry 

You can use IBM Cloud® Monitoring to monitor platform metrics of IBM Cloud® Container Registry usage for your account and to create alerts based on these metrics.

Platform metrics for Container Registry must be enabled in each Container Registry region that you want to monitor, see [Enabling metrics for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_monitorregistry_enable_platform_metrics).



 Enabling metrics for Container Registry 

You must enable Container Registry metrics in each region that you want to see metrics.

You can create a Monitoring instance in the region that you want to monitor and enable platform metrics for it. Alternatively, you can enable platform metrics on an existing Monitoring instance in that region.

Complete the following steps to create and configure platform metrics for Container Registry.



1. Create and configure an IBM Cloud Monitoring instance that is configured with platform metrics in the region that you want to monitor, see [Getting started with IBM Cloud Monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started).

For more information about the locations where Container Registry is enabled for monitoring, see [Locations of platform metrics](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_monitorregistry_monitor_locations).
2. Log in to IBM Cloud.

ibmcloud login
3. Target the [region](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions) where you want to enable metrics by running the [ibmcloud cr region-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_region_set) command. Replace <region> with the name of the [region](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions_local).

ibmcloud cr region-set <region>
4.
* Topology maps are no longer available in dashboards. Topology maps can be accessed through the Explore option.
* My Dashboards are no longer available under Explore.
* The dashboard wizard has been removed. Use the dashboard templates in place of thd dashboard wizard.
* History and summary metrics have been deprecated.
* Ability to configure scope variables on a dashboard to quickly filter metrics.
* Addition of intelligent auto-completion and syntax highlighting.
* The ability to define a default role when a new member is added to a team.
* Enhanced RBAC support.







 16 April 2020 

Dashboard support for Istio 1.5
: Addition of dashboard support for Istio 1.5, in addition to Istio 1.0.





 8 April 2020 

Global support
: Worldwide support for IBM Cloud Monitoring.





 21 November 2019 

Overview generally available
: Functional enhancements include:



* Metrics prioritized by event count and severity.
* Dashboards for insights.
* Added new default dashboards while retaining some existing dashboards and removing others.



Filtering events by scope
: Events can be filtered by scope to show the most relevant events. Filtering is available in the Explore and Dashboards views.

Beta support for Prometheus and new dashboards
: Functional enhacements in beta include:



* Support of native Prometheus time series ingestion.
* Addition of a PromQL dashboard.
* New dashboard functionality for greater configuration flexibility and query support.







 11 October 2019 

Dashboard updates
: The ability to mark a dashboard as a "favorite" has been added.

Additional metrics segmentation
: The ability to segment metrics by the following have been added:



* file.bytes.in
* file.bytes.out
* file.mount
* file.name







 14 August 2019 

New Kubernetes groupings
: Groupings for Kubernetes have been modified.

Enhanced event notification
: The ability to customize the subject and body of an alert notification with variables has been extended.

Units for metrics
: Introduction of a common metrics format to ease comparison.

Display instance name
For example, you can track how many API requests have been made by an authorized user be setting an [alert](https://cloud.ibm.com/docs/key-protect?topic=key-protect-operational-metricsset-monitor-alerts) that triggers when your monitoring instance notices a frequent amount of 401 status codes being returned from your Key Protect instance.



Table 1. Describes the API Hits metrics.

 Metadata Description 

 Metric Name ibm_kms_api_request_gauge 
 Metric Type Gauge 
 Value Type none 
 Segment By [Attributes for Segmentation](https://cloud.ibm.com/docs/key-protect?topic=key-protect-operational-metricsattributes-for-segmentation) 









 Latency 

The amount of time it takes Key Protect to receive an API request and respond to it.

The latency is calculated by getting the average of all requests of the same type that occur within 60 seconds.



Table 2. Describes the Latency metrics.

 Metadata Description 

 Metric Name ibm_kms_api_latency_gauge 
 Metric Type Gauge 
 Value Type Milliseconds 
 Segment By [Attributes for Segmentation](https://cloud.ibm.com/docs/key-protect?topic=key-protect-operational-metricsattributes-for-segmentation) 







 Attributes for Segmentation 

You can filter your metrics by using the following attributes.



Table 3. Describes the attributes use for segmenting metrics.

 Attribute Name Description 

 ibm_resource_type Supported resource type is instance. 
 ibm_kms_response_code Response code for the Key Protect service API request. 
 ibm_scope The account, organization, or space GUID associated with the metric. 
 ibm_ctype public, dedicated, or local. 
 ibm_location Location of the Key Protect service instance. 
 ibm_service_name kms. 
 ibm_resource Key Protect service instance ID. 
 ibm_kms_api Key Protect service API name. 
 ibm_resource_group_name Resource group name associated with the Key Protect service instance. 
 ibm_service_instance_name Key Protect service instance name.
Reviewing your plan and usage 

You can review information about your API Connect Reserved plan and API use. The information lets you track overall usage against your plan, and displays a graph showing your monthly usage rate.

Reviewing your subscription start and end dates helps you plan renewal cycles and subscription extensions.

Reviewing your API usage, help you determine whether your current plan provides for a sufficient number of API calls. If your usage looks like it will exceed your allowed number of calls, you can contact IBM Sales to upgrade the plan before you exceed the limit and sustain overage charges. You can also view your historical API usage data on a monthly basis, so that you can see trends and usage spikes when planning future subscription volumes.

On the administration console's home page, click Plan and usage in the navigation list.

The following information displays for the current Reserved service plan and its usage levels:



*  Current plan: The name of the purchase plan for your service, the start and end dates of the subscription, and the maximum allowed number of API calls for the plan period. If you have exceeded your plan maximum or are approaching that limit, a message displays with details.
*  Cumulative usage: The total number of API calls to date.
*  Projected annual usage: The expected yearly API usage, which is calculated on the basis of daily usage.
*  API call usage per month: A graph showing the number of API calls for each month in the subscription period. Hover over the bar for a particular month to see the time period and API usage. Hover over the dotted line to see the average monthly usage from the start of the subscription period through the current date.
Specify the cool down period, the number of seconds to pause further scaling actions after scaling has taken place.
6. Create one or more target policies that define a metric and target utilization that the instance group manager will use for auto scaling in your instance group. See Table 1 for more information.





Table 1. Target policies selections

 Field Value 

 Metric type Select the metric type that you want to associate with a target utilization value to use for adding or removing instances from your group. You can choose one of these metrics: CPU utilization (%), RAM utilization (%), Network in (Mbps), Network out (Mbps). You can define more than one target scaling policy, but only one policy for each metric type. 
 Average target utilization Specify a desired average utilization for the metric that you select. This target value defines when the instance group manager should scale up instances or scale down instances in your group. At the end of each aggregation window, the instance group manager adds the current utilization of each instance and divides it by this target utilization value to determine the membership count. 







 Creating target scaling policies 

For the dynamic scaling method, you define certain metrics (like CPU) and the desired target utilization for that metric. Together, the metric and the average target utilization, determine when your instance group should dynamically add or remove virtual server instances from your group.

To add scaling policies, complete the following steps. You can define more than one target scaling policy, but only one policy for each type of metric.



1. Make sure that the dynamic scaling method is enabled for the instance group. Auto scale will display under Scaling method. If the scaling method shows that the instance group is unmanaged, you can [change the scaling method](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-instance-groupchanging-scaling-method) to dynamic.
2. Under Target policies, click Add a policy and complete the information in Table 2.





Table 2. Target policies selections

 Field Value 

 Metric type Select the metric type that you want to associate with a target utilization value to use for adding or removing instances from your group.
To monitor platform metrics, check that the IBM Cloud Monitoring instance is provisioned in the same region where the IBM Cloud instance is provisioned.





 Access your IBM Cloud Monitoring metrics 



1. Start the [IBM Cloud Monitoring web UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launch) from the Observability page.
2. Click DASHBOARDS.
3. In the Default Dashboards section, expand IBM.
4. Choose the Event Notifications dashboard from the list.



Access your deployment's monitoring dashboard from IBM Cloud Monitoring, it's in the sidebar, under IBM. Next, change the scope or make a copy of the default dashboard to monitor an Event Notifications service instance.





 Metrics available by Service Plan 



Table 2. Metrics available by service plan

 Metric Name 

 [ibm_eventnotifications_total_ingested_notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-monitoringibm_eventnotifications_total_ingested_notifications) 
 [ibm_eventnotifications_total](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-monitoringibm_eventnotifications_total) 
 [ibm_eventnotifications_failed](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-monitoringibm_eventnotifications_failed) 
 [ibm_eventnotifications_devices](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-monitoringibm_eventnotifications_devices) 





 ibm_eventnotifications_total_ingested_notifications 

Total number of notifications that are ingested. Ingested notifications are events from a source that has at least one condition that is defined on them for filtering.



Table 3. Ingestion metadata

 Metadata Description 

 Metric Name ibm_eventnotifications_total_ingested_notifications 
 Metric Type gauge
* 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 context of the resource group where they plan to provision the instance.







 Connecting Monitoring with Key Protect 

Your dashboard will show metrics for all Key Protect instances 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?topic=monitoring-provision) in the region of the Key Protect instance that contains an [enabled metrics policy](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-monitor-metrics).
2. Go to the [monitoring dashboard](https://cloud.ibm.com/observe/monitoring).
3. Click on "Configure platform metrics."
4. Select the region where the Key Protect instance was created.
5. Select the Key Protect instance in which you would like to receive metrics.
6. Click "Configure."
7. Your Key Protect instance is now set for platform metrics.









 Key Protect Metrics Details 

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



 API Hits 

The type and amount of API requests being made to your Key Protect instance. For example, you can track how many API requests have been made by an authorized user be setting an [alert](https://cloud.ibm.com/docs/key-protect?topic=key-protect-operational-metricsset-monitor-alerts) that triggers when your monitoring instance notices a frequent amount of 401 status codes being returned from your Key Protect instance.



Table 1. Describes the API Hits metrics.

 Metadata Description 

 Metric Name ibm_kms_api_request_gauge 
 Metric Type Gauge 
 Value Type none
Debugging the metrics-server 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

The following symptoms might indicate a need to adjust the metrics-server resources:



* The metrics-server is restarting frequently.
* Deleting a namespace results in the namespace being stuck in a Terminating state and kubectl describe namespace includes a condition reporting a metrics API discovery error.
* kubectl top pods, kubectl top nodes, other kubectl commands, or applications that use the Kubernetes API to log Kubernetes errors such as:

The server is currently unable to handle the request (get pods.metrics.k8s.io)

Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
* HorizontalPodAutoscalers (HPAs) do not scale deployments.
* Running kubectl get apiservices v1beta1.metrics.k8s.io results in a status such as:

NAME SERVICE AVAILABLE AGE
v1beta1.metrics.k8s.io kube-system/metrics-server False (FailedDiscoveryCheck) 139d



 Why it’s happening 

Your cluster has a metrics service provided by the metrics-server deployment in the kube-system namespace. The metrics-server resource requests and limits are based on the number of nodes in the cluster and are optimized for clusters with 30 or less pods per worker node. If the memory requests are too low, it can fail with out-of-memory errors and can respond very slowly. If the CPU requests are too low, it can possibly fail liveness and readiness probes due to CPU throttling.

Problems with the metrics-server can also be cause problems in other areas. The metrics APIs is not available if the control plane is not able to communicate with the metrics-server by using Konnectivity. Admission control webhooks can prevent the control plane from creating pods, including the metrics-server pod.

 How to fix it