vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Active connections are the number of connections that are established on a load balancer at a specific time.

The active connection metric contains the following metadata:



Table 1: IBM Cloud Load Balancer active connections metrics metadata

 Metadata Description 

 Metric name ibm_cloud_load_balancer_active_connections 
 Metric type gauge 
 Value type none 
 Segment by IBM Cloud Load Balancer appliance metrics and IBM Cloud Load Balancer listener metrics 







 Connection rate 

Connection rate is number of new incoming active connections per second to your load balancer.



Table 2: IBM Cloud Load Balancer connection rate metric metadata

 Metadata Description 

 Metric name ibm_cloud_load_balancer_connection_rate 
 Metric type gauge 
 Value type none 
 Segment by IBM Cloud Load Balancer appliance metrics and IBM Cloud Load Balancer listener metrics 







 Throughput 

Throughput is the amount of data that passes in and out of a load balancer over a period of time.



Table 3: IBM Cloud Load Balancer throughput metric metadata

 Metadata Description 

 Metric name ibm_cloud_load_balancer_throughput 
 Metric type gauge 
 Value type byte 
 Segment by IBM Cloud Load Balancer appliance metrics or IBM Cloud Load Balancer listener metrics 









 Metric segmentation 

You can split the data that IBM Cloud Monitoring presents into various visualizations in the IBM Cloud Monitoring dashboard, allowing views of different metrics based on your preferences. For example, if you have multiple load balancers or accounts with different load balancers in each account, you might want to focus on a particular listener (front-end protocol) port.

As an example, you can segment the active connections by IBM Cloud Load Balancer listener port to show how many active users are connected to the load balancer through each listener type. To illustrate this, let's assume that your load balancer has two different listener protocols one HTTP on port 80 and another for TCP on port 8080. The dashboard would contain different lines showing 10 users who are connected through HTTP on Port 80 in one color, and 6 users connected through TCP on port 8080 in another color.



 Global attributes 

The following attributes are available for segmenting all three of the IBM Cloud Monitoring metrics.



Table 4: IBM Cloud Monitoring global attributes
Debugging Block Storage for VPC metrics 

 What’s happening 

When you try to view Block Storage for VPC metrics in the monitoring dashboard, the metrics do not populate.

Metrics might fail to populate in the dashboard for one of the following reasons:

 Why it’s happening 



* The PVC you want to monitor may not be mounted. Metrics are only populated for PVCs that are mounted to a pod.
* There may be a console-related issue, which can be verified by manually viewing the storage metrics in the CLI.



 How to fix it 

Check that the PVC is mounted. If the issue persists, manually view your metrics in the CLI to determine if the cause is related to issues with the console.



1. [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
2. Describe the PVC. If the Used By row of the output is populated with the name of a pod, then the PVC is mounted.

kubectl describe pvc <pvc_name>

Example output.

Name: my-pvc
Namespace: default
StorageClass: ibmc-vpc-block-5iops-tier
Status: Bound
Volume: pvc-a11a11a1-111a-111a-a1a1-aaa111aa1a1a
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: vpc.block.csi.ibm.io
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 10Gi
Access Modes: RWO
VolumeMode: Filesystem
Used By: my-pod-11a1a1a1a1-1a11a
Events: <none>
3.
* CLI
* API







 Managing routes 

You can manage routes in your account by using the IBM Cloud Metrics Routing CLI, the IBM Cloud Metrics Routing REST API, and the IBM Cloud Metrics Routing Terraform provider. A route defines the rules that indicate what metrics are routed in a region and where to route them.

For more information on IBM Cloud Metrics Routing routes, see [routes](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-route).



 About routes 

You can configure IBM Cloud Metrics Routing to route metrics that are generated in different regions where the service is supported to a target destination.



* You can only route metrics that are generated in regions where IBM Cloud Metrics Routing is available. For more information, see [Regions](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions).
* If you have regulatory and compliance requirements, check the route rules comply with them.







 IAM Access 

You must have the correct IAM permissions to manage routes. For information, see [Managing IAM access.](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam)





 CLI prerequisites 

Before you use the CLI to manage routes, complete the following steps:



1. [Install the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).
2. [Install the IBM Cloud Metrics Routing CLI](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-metrics-router-cli-config).
3. Log in to IBM Cloud. Run the following command: [ibmcloud login](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login)







 Creating a route by using the CLI
Debugging Block Storage for VPC metrics 

 What’s happening 

When you try to view Block Storage for VPC metrics in the monitoring dashboard, the metrics do not populate.

Metrics might fail to populate in the dashboard for one of the following reasons:

 Why it’s happening 



* The PVC you want to monitor may not be mounted. Metrics are only populated for PVCs that are mounted to a pod.
* There may be a console-related issue, which can be verified by manually viewing the storage metrics in the CLI.



 How to fix it 

Check that the PVC is mounted. If the issue persists, manually view your metrics in the CLI to determine if the cause is related to issues with the console.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Describe the PVC. If the Used By row of the output is populated with the name of a pod, then the PVC is mounted.

oc describe pvc <pvc_name>

Example output.

Name: my-pvc
Namespace: default
StorageClass: ibmc-vpc-block-5iops-tier
Status: Bound
Volume: pvc-a11a11a1-111a-111a-a1a1-aaa111aa1a1a
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: vpc.block.csi.ibm.io
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 10Gi
Access Modes: RWO
VolumeMode: Filesystem
Used By: my-pod-11a1a1a1a1-1a11a
Events: <none>
3.
Non TLS-enabled channels typically have around 10% higher throughput but are not recommended for security reasons
* Messages of 2KB size are used for the benchmark scenario. To a reasonable approximation IBM MQ throughput has an inverse linear correlation to the size of the message, so a 4KB message size exhibits roughly half the throughput described above





 TCP benchmarks 



* The TCP benchmark applications are written using the IBM MQ C client which uses one client connection per application thread. Please note the comment in footnote 6 above regarding the use of client connections by JMS applications







 REST benchmarks 



* The REST benchmark applications are written using a Python client with each application thread using basic authentication to generate a fresh TLS connection per request against the same message queue.
* REST message throughput will generally be 10-15% higher if the client application uses cookie authentication. See [Authenticating your client to invoke REST API requests](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_qm_rest_api).
Monitoring for Satellite 

IBM Cloud Satellite® comes with basic tools to help you manage the health of your Satellite resources, such as reviewing location and host health. Additionally, you can integrate Satellite and other IBM Cloud resources with IBM Cloud® Monitoring to get a comprehensive view and tools to manage all your resources.

Monitoring for your Satellite location and for the IBM Cloud services that run in your location must be set up separately. For example, to collect metrics for your Satellite location setup, you enable a Monitoring instance to collect platform metrics in the same region that your location is managed from. Then, to collect metrics for a Red Hat OpenShift on IBM Cloud cluster that runs in your Satellite location, you create a monitoring agent in your cluster to automatically collect and forward pod metrics to a Monitoring instance. Note that you can use the same Monitoring instance to collect metrics for both your Satellite location and services that run in your Satellite location.



 Understanding what is logged and monitored by default 

By default, Satellite generates certain activity events and monitors the state of your location and host resources.



 Auditing events for Satellite actions 

See [Auditing events for Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-at_events).





 IBM monitoring to resolve and report location alerts 

When you create a Satellite location and set up the location control plane, IBM automatically monitors and resolves certain alerts for issues with your location setup and host infrastructure. The following table describes different scenarios and the actions that IBM takes to address the scenarios.

Additionally, if you [set up your Satellite location to forward logs to IBM Log Analysis](https://cloud.ibm.com/docs/satellite?topic=satellite-healthsetup-la), the messages and more detailed information from the IBM Monitoring component are captured and stored in your IBM Log Analysis instance.



IBM monitoring actions to address certain scenarios.

 Scenario Action 

 Location control plane does not have a host in three separate zones. Check for attached, unassigned hosts in the location. If a host is available, assign the host to the location control plane for the missing zone, giving preference to hosts with a label that matches the zone. 
 Cluster capacity exceeds 80% in a zone. Prevent or allow Red Hat OpenShift clusters to be created.
In future, you will be able to customize an agent to increase the number of job Pods, to increase the number of jobs that can run concurrently.
* What is the minimum cluster configuration required in Agent release?

The agent needs IBM Cloud Kubernetes Service Service with minimum three worker nodes, with a flavor of b4x16 or higher.
* How many workspaces can be assigned to an agent?

Currently, you can assign any number of workspaces to an agent. The workspace jobs are queued to run on the agent, based on the agent assignment policy. The agent periodically polls Schematics for jobs to run, with a polling interval of one minute. By default, the agent runs only three jobs in parallel. The remaining jobs are queued.
* How many jobs can run in parallel on an agent?



* Schematics Agent can perform three Git download jobs in parallel.
* Schematics Agent can run three Workspace jobs (Terraform commands), in parallel.
* Schematics Agent can run three Action jobs (Ansible playbook), in parallel.



* What is the default polling interval for Agents?

Schematics maintains a queue of jobs that will be executed on an agent. The agent will poll for Schematics Jobs, every one minute by default.
* What is the difference between agent-location and location input variable flag in Agent service?

The --agent-location parameter is a variable that specifies the region of the cluster where an agent service is deployed. For example, us-south. This must match the cluster region.

The --location parameter is a variable that specifies the region supported by Schematics service such as us-south, us-east, eu-de, eu-gb. The agent polls Schematics service instance from this location, for workspace or action jobs for processing.
* Can an agent run Workspace jobs belonging to different resource groups?

Yes, an agent can run Schematics Jobs related to workspace or actions, from all or any resource group, in an account. Agent (assignment) policies are used to assign the execution of jobs, based on resource group, region and user tags to a specific agent.
* You create a destination, but you have not set up the security. In this case, you might disable the destination until its security is set up.
* You do not want the service to be available to users because you are making some updates to the service. In this case, you might temporarily disable the necessary gateways and wait for the service to be updated.
* You have set up all your gateways and destinations on the front end, but your backend is still building. In this case, you would disable your gateways or destinations until the backend build is complete.



For more information on disabling a gateway or a destination, see [how to manage your Secure Gateway service instance](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-manage-sg-service).
* What is the recommended approach to creation automation across multiple spaces?

For example, your environment has one org and three spaces. One space is for development, another for staging, and the final one for production. Should you create a single Secure Gateway instance or multiple (that is, one for each space)? If you can create multiple gateways, are there any considerations for reusing a Node.js application to create a gateway and destination in each space?

The approach is as follows:



* You can create a single Secure Gateway instance for all three spaces. However, you must remember the gateway and destination [limitations for your specific plan](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-secure-gateway-service-plans).
* There are no additional considerations for reusing a Node.js application as no service bindings are required by Secure Gateway.



* What is the recommended approach to creation automation across multiple orgs?

Consider an environment that has three orgs: one for development, one for staging, and one for production. Is a Secure Gateway service instance required for each org and is the configuration available to all spaces within that org?

For automation across orgs, the approach is as follows:



* You are not required to have a Secure Gateway service instance in each org.
Table 1. Monitoring regions

 Hyper Protect DBaaS for MongoDB region Monitoring region 

 Dallas (us-south) Dallas (us-south) 
 Washington DC (us-east) Washington DC (us-east) 
 Frankfurt (eu-de) Frankfurt (eu-de) 
 Sydney (au-syd) Sydney (au-syd) 



You can only specify one Monitoring instance to receive platform metrics from platform services in one region. This instance will be used to monitor all Hyper Protect DBaaS for MongoDB service instances provisioned in this region.



 Prerequisite 

To enable monitoring, all three nodes of the database cluster need to be running. If one or more nodes aren't running, see [Getting help and support](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-mongodb?topic=hyper-protect-dbaas-for-mongodb-getting-help-and-support). You can retry enabling monitoring for the nodes when they're running again.





 Enabling monitoring 

On the Hyper Protect DBaaS for MongoDB dashboard, select Observability in the side navigation pane. Complete the following steps to add monitoring.



1. In the Monitoring Pane, select the checkbox to agree to sending metrics to Monitoring and click Enable for monitoring.
2. When you see the message that the service instance is enabled to send platform metrics, click Add monitoring.

a. If you don't have a Monitoring service instance, you'll be directed to the service creation page to create one. Select the same region as your service instance. For platform metrics, leave the Enable option selected.

b. If you already have a Monitoring service instance in the same region but it isn't enabled to receive platform metrics, you need to select the Monitoring service instance to receive platform metrics in the dialog box.







 Viewing metrics 

After you enable monitoring, click Launch monitoring on the Observability page of the Hyper Protect DBaaS for MongoDB dashboard to be directed to the Monitoring dashboard to view the metrics.
Correlation between NSX objects and vSphere objects enables easier troubleshooting.

VMware Aria Operations uses the management pack to poll VMware NSX for configuration, performance, and support data. On behalf of VMware Aria Operations, the Management Pack converts the polling requests into REST API calls to retrieve the required data from NSX Manager.

The NSX components need to be configured to send syslog to VMware Aria Operations for Logs.



* NSX Manager - [Specify a Syslog Server](https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.2/com.vmware.nsx-cross-vcenter-install.doc/GUID-EA70974C-07F8-469D-8A9D-0ED54F0C8F34.html).
* NSX Controllers - [Configuring syslog server for VMware NSX for vSphere 6.x controllers](https://kb.vmware.com/s/article/2092228).
* NSX Edge - [Configure Remote Syslog Servers](https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.2/com.vmware.nsx.admin.doc/GUID-9C25E097-E2CC-461A-9DA6-E8118D16EE62.html).
* Firewall - You must configure the remote syslog server for each cluster that where the firewall is enabled. The remote syslog server is specified in the Syslog.global.logHost attribute.



NSX Flow Monitoring can be used in NSX Manager to determine which flows are approved and which flows are blocked. If required, then port mirroring can be configured for a vSphere Distributed Switch.





 Monitoring of NSX-T 

To monitor NSX-T™, the following tools are implemented:



* VMware Aria Operations Manager
* VMware Aria Operations for Logs
To view metrics of your Hyper Protect DBaaS for PostgreSQL instance, you need to have a Monitoring service instance in the same region, as the following table shows.



Table 1. Monitoring regions

 Hyper Protect DBaaS for PostgreSQL region Monitoring region 

 Dallas (us-south) Dallas (us-south) 
 Washington DC (us-east) Washington DC (us-east) 
 Frankfurt (eu-de) Frankfurt (eu-de) 
 Sydney (au-syd) Sydney (au-syd) 



You can only specify one Monitoring instance to receive platform metrics from platform services in one region. This instance will be used to monitor all Hyper Protect DBaaS for PostgreSQL service instances provisioned in this region.



 Prerequisite 

To enable monitoring, all three nodes of the database cluster need to be running. If one or more nodes aren't running, see [Getting help and support](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-postgresql?topic=hyper-protect-dbaas-for-postgresql-getting-help-and-support). You can retry enabling monitoring for the nodes when they're running again.





 Enabling monitoring 

On the Hyper Protect DBaaS for PostgreSQL dashboard, select Observability in the side navigation pane. Complete the following steps to add monitoring.



1. In the Monitoring Pane, select the checkbox to agree to sending metrics to Monitoring and click Enable for monitoring.
2. When you see the message that the service instance is enabled to send platform metrics, click Add monitoring.

a. If you don't have a Monitoring service instance, you'll be directed to the service creation page to create one. Select the same region as your service instance. For platform metrics, leave the Enable option selected.

b. If you already have a Monitoring service instance in the same region but it isn't enabled to receive platform metrics, you need to select the Monitoring service instance to receive platform metrics in the dialog box.







 Viewing metrics
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
: Defines the CRN of the IBM Cloud Monitoring instance where you plan to route the metrics. IBM Cloud Monitoring targets are the only ones supported.

--region
: [Optional] Defines the region where the target definition is created. You can only specify a [supported region](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions&interface=cli). Set this option if you want to create a target in a region and you are connected to a different one.
2. Define a service to service authorization between the IBM Cloud Metrics Routing service and the IBM Cloud Monitoring instance that you configured as your destination in the target. For more information, see [Managing authorizations to grant access between services](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam-service-auth).







 Step 3. Configure 1 route 

A route defines the rules that indicate what metrics are routed in a region and where to store them. Routes are global under an account and are evaluated in all regions where IBM Cloud Metrics Routing is deployed. For more information, see [Understanding how routes work in your account](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-routes&interface=cliroute_behaviour).

In this step, you will configure a route to redirect metrics to the target destination that you configured in the previous step.

Run the following command to create the route:
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: vpc.block.csi.ibm.io
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 10Gi
Access Modes: RWO
VolumeMode: Filesystem
Used By: my-pod-11a1a1a1a1-1a11a
Events: <none>
3. If the PVC is not mounted to a pod, review the steps for [setting up Block Storage for VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-block-add) and mount the PVC to a pod. Then try to view the metrics again.
4. If the PVC is mounted, follow the steps for [manually verifying the Block Storage for VPC metrics](https://cloud.ibm.com/docs/containers?topic=containers-debug_monitoringmanual-monitor-metrics) then [open a support issue](https://cloud.ibm.com/docs/containers?topic=containers-get-helphelp-support). The steps for manual verification in the CLI allow you to view your metrics, but are not a solution for metrics that do not populate in the console. However, if you are able to manually verify your metrics, this indicates that there is a console issue for which you must open an issue.





 Manually viewing storage metrics in the CLI 

If your storage metrics are not visible in the monitoring dashboard, you can manually view them in the CLI. Note that manual verification of your storage metrics is a temporary workaround and not a permanent monitoring solution for viewing metrics. After completing the following steps, if you are able to manually view the metrics in the CLI and not the dashboard, this indicates that there is a console issue for which you must [open a support issue](https://cloud.ibm.com/docs/containers?topic=containers-get-helphelp-support).