vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When the Event Streams service is run in a non-highly available configuration, such as [single zone locations](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-slasla_szr), the availability is 99.9%. For more information about the SLA for non-highly availabile services in IBM Cloud, see [Service Level Agreements for IBM Cloud (Public Cloud)](https://www.ibm.com/support/customer/csol/terms?id=i126-9268&lc=endetail-document).





 Satellite plan 

The Event Streams Satellite plan provides a highly available architecture by multi-zone region deployment. In a multi-zone location, with the correct IaaS configurations, the Event Streams service can be distributed across three availability zones, which means that the cluster is resilient to the failure of a single zone or any component within that zone.





 How do we measure it? 

Service instances are continuously monitored for performance, error rates, and their response to synthetic operations. Outages are recorded. For more information, see [Service status for Event Streams](https://cloud.ibm.com/status?component=messagehub&selected=status).

Availability refers to the ability of applications to produce and consume messages from Kafka topics.





 What do you need to consider to achieve this availability? 

To achieve high levels of availability from the application perspective, you should consider [connectivity](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-slaconnectivity), [throughput](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-slathroughput), and [consistency and durability of messages](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-slamessage_consistency). Users are responsible for designing their applications to optimize these three elements for their business.



 Connectivity 

Because of the dynamic nature of the cloud, applications must expect connection breakages. A connection breakage is not considered a failure of service.



 Retries
You can install IMCS without an API key. However, some metrics are missing and the virtual server is not supported by SAP.

For a list of missing metrics, see [Additional Information](https://cloud.ibm.com/docs/sap?topic=sap-ibm-metrics-collector-for-sap-linuxaddl-info).

You need to create only one Service ID and one API Key per Account. You can use the same Service ID and API Key for all the Metric Collectors that are installed in the virtual server that is associated to the Account.



 Creating a Service ID 

You need to first create a Service ID and then the related API key. Use the following steps to create a Service ID.



1. Sign in to the [IBM Cloud console](https://cloud.ibm.com) and click Manage > Access (IAM).

Figure 2. Open the Access (IAM page)

Zoom

![Figure 2. Open the Access (IAM) page](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap//images/imcs-ibmcloud-access-iam.png)

Figure 2. Open the Access (IAM) page
2. Click Services IDs > Create.
3. Enter a Name and Description for the Service ID and click Create. You can assign the Access Policy after your Service ID is created.
4. Click Access Policies > Assign Access.
5. Click IAM Services for Assign Service ID additional access.
6. 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.
For more information, see [Ensuring High Availability- XenApp and XenDesktop Deployments on Citrix Cloud](https://www.citrix.com/content/dam/citrix/en_us/documents/white-paper/ensuring-high-availability-xenapp-and-xendesktop-deployments-on-citrix-cloud.pdf) and the Citrix product documentation on [Workload Separation](https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/citrix-vdi-best-practices/design/design-userlayer5.htmldecision-workload-separation).





 VMware ESXi 

The minimum recommendation for high availability is three ESXi hosts with NFS storage. These servers are provisioned in the cluster and are highly available within the data center.







 Cloud Connectors 

Three Cloud Connectors are provisioned in your resource location for your Citrix DaaS service. All the three Cloud Connectors are stateless, and the load is evenly distributed. No additional configuration is needed for Cloud Connectors to make them highly available. For more information, see [Citrix Cloud Connector](https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-resource-locations/citrix-cloud-connector.html).





 DHCP server 

All virtual server instances in IBM Cloud classic infrastructure are configured with auto-evacuation. This means that instances are evacuated automatically to other servers if the underlying hypervisor fails.

The purpose of a DHCP server is to lease IP addresses on the newly created instances. In the case of failure, existing virtual servers might continue to operate. However, the system might not be able to lease IP addresses to newly created instances until DHCP VM comes up. If you have mission-critical applications and you need high availability beyond the auto-evacuation feature, you want to configure DHCP in hot standby mode. Complete the following steps.



1.
* CLI
* API







 Managing Monitoring targets 

You can manage Monitoring targets 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 target is a resource where you can collect metrics.

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



 About Monitoring targets 

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



* 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 Monitoring target is available in a valid location.
* To configure IBM Cloud Metrics Routing to route metrics to a Monitoring instance, you must configure a service to service authorization. You do not have to provide credentials to IBM Cloud Metrics Routing. You can define a service to service authorization between the IBM Cloud Metrics Routing service and an instance of the Monitoring service in the same account, or between the IBM Cloud Metrics Routing service and an instance of the Monitoring service in a different account.

For information on configuring Service to Service authentiation, see [Managing authorizations to grant access between services](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam-service-auth).







 IAM Access 

You must have the correct IAM permissions to manage targets. 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 targets, complete the following steps:



1.
[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 

 [IBM Cloud Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) Code Engine is a fully managed, serverless platform that runs your containerized workloads. [Platform metrics](https://cloud.ibm.com/docs/codeengine?topic=codeengine-monitor) 
 [IBM Cloud® Functions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-getting-started) A Functions-as-a-Service (FaaS) programming platform based on Apache OpenWhisk. [Platform metrics](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-monitor-functions) 







 Storage services 

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



Table 11. List of storage services

 Service Description Metrics 

 [IBM Cloud® Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage) You can use IBM Cloud Object Storage to store unstructured data in the IBM Cloud. [Platform metrics](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-mm-cos-integration&programming_language=Console) 







 VMware as a Service 

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



Table 12.
For example, a user with the namespace-scoped admin cluster role can't use the kubectl top pods command to view pod metrics for all the pods in the namespace. You might aggregate a cluster role so that users in the admin cluster role are authorized to run the top pods command. For more information, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).



 What are some common operations that I might want to extend permissions for a default cluster role? 

Review [the operations that each default RBAC cluster role permits](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-rolesrbac_ref) to get a good idea of what your users can do, and then compare the permitted operations to what you want them to be able to do.

If your users in the same cluster role encounter errors similar to the following for the same type of operation, you might want to extend the cluster role to include this operation.

Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAMmyname@example.com" can't list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"

Before you begin: [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)



1. Create a cluster role YAML file. In the labels section, specify the existing cluster role that you want to aggregate permissions to. The following example extends the predefined admin cluster role to allow users to run kubectl top pods. For more examples, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).
For more information, see [High availability for multizone clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersha_clusters).

In a multizone cluster deployment, are my app pods distributed evenly across the nodes?
: The pods are evenly distributed across zones, but not always across nodes. For example, if you have a cluster with one node in each of three zones and deploy a replica set of six pods, then each node gets two pods. However, if you have a cluster with two nodes in each of three zones and deploy a replica set of six pods, each zone schedules two pods, and might schedule one pod per node or might not. For more control over scheduling, you can [set pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

If a zone goes down, how are pods rescheduled onto the remaining nodes in the other zones?
: It depends on your scheduling policy that you used in the deployment. If you included [node-specific pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), your pods are not rescheduled. If you did not, pods are created on available worker nodes in other zones, but they might not be balanced. For example, the two pods might be spread across the two available nodes, or they might both be scheduled onto one node with available capacity. Similarly, when the unavailable zone returns, pods are not automatically deleted and rebalanced across nodes. If you want the pods to be rebalanced across zones after the zone is back up, configure the [Kubernetes descheduler](https://github.com/kubernetes-sigs/descheduler). In multizone clusters, try to keep your worker node capacity at 50% per zone so that enough capacity remains to protect your cluster against a zonal failure.

What if I want to spread my app across regions?
Configuring the log level of a monitoring agent 

The log level determines the type and amount of logging of an agent. You can configure the log level by adding parameters and log level arguments.

The monitoring agent writes log entries into the draios.log file.



* The log file rotates when it reaches 10MB in size.
* The 10 most recent log files are kept. The date-stamp that is appended to the filename is used to determine which files to keep.
* The log files are located in the directory /opt/draios/logs/.



By default, when you deploy a monitoring agent, the log level is set to info.

Valid log levels are: none, error, warning, info, debug, trace.

You can configure the level of detail that is written by a monitoring agent to its log file:



Table 1. Log levels

 Log level Detail 

 none No errors are reported. 
 info Reports an entry for each aggregated metrics transmission to the backend servers, once per second. <br>Reports entries for any warnings and errors. 
 error Reports error logs only. 
 trace Reports all logs that are available. 





* To get the least number of log entries, set the log level to error.
* To get the full set of available logs, set the log level to trace.



You should set the log level to info, debug, or trace to troubleshoot agent-related issues.

For example, consider the following use cases and the log section that you can configure to indicate the data that you want to log for an agent:



Table 2. Log section entries

 Use cases Log section entry 

 Troubleshoot agent behavior file_priority: debug 
 Reduce container console output console_priority: warning 
 Filtering events by severity event_priority: warning 
 Verify what metrics are included or excluded metrics_excess_log: true 





 Checking the log level of an agent 



 Linux monitoring agent 

To get the log level of a Linux monitoring agent, run the following command from a terminal:

more /opt/draios/etc/statsite.ini | grep log_level
If the service instance has three operational crypto units, you are prompted to enter the number of failover crypto units based on your need. Either 2 or 3 failover crypto units are supported.

For a service instance with only two operational crypto units, two failover crypto units are assigned automatically. You don't need to take any actions in this case.
4. Click Yes to confirm the action. The failover crypto units are assigned in the target failover region.

Failover crypto units are now available in us-south and us-east. The two regions are the target failover regions of each other. For example, if your instance is located in us-south, the failover region for your instance is us-east.



4. Initialize failover crypto units by using the same master key for the operational crypto units initialization and the same initialization approach:



* [Initializing service instances with smart cards and the Management Utilities](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm-management-utilities)
* [Initializing service instances by using key part files](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm)



You need to initialize failover crypto units before you use them for a regional disaster recovery. It is suggested you initialize the failover crypto units right after you enable them for your service instance.







 What's next 

If a regional disaster occurs, you can use failover crypto units for automatic data restoration. For more information, see [Cross-region disaster recovery](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-ha-drcross-region-disaster-recovery) and [Restoring your data from another region](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-data).
Monitoring a queue manager with Sysdig 

IBM MQ on Cloud, paid plans, generate metrics from queue managers that are displayed in your IBM Cloud Monitoring instances. IBM Cloud Monitoring is operated by Sysdig in partnership with IBM.



 Platform metrics overview 

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



* To configure the Sysdig instance, you must turn on the platform metrics configuration setting.
* If a Sysdig instance in a region is already enabled to collect platform metrics, metrics from Sysdig-enabled services are collected automatically and available for monitoring through this instance. For more information about Sysdig-enabled services, see [Cloud services](https://cloud.ibm.com/docs/monitoring?topic=monitoring-cloud_services).



Important: To monitor platform metrics, check that the IBM Cloud Monitoring instance is provisioned in the same region where the IBM MQ on Cloud instance is provisioned.





 Enabling platform metrics from the IBM MQ on Cloud dashboard 

Complete the following steps to configure platform metrics:



1. Log in to IBM Cloud.
2. Click View resources.
3. In the Services section, click the IBM MQ on Cloud instance that you plan to monitor.
4. Click the overflow menu. Then, select Add monitoring to configure platform metrics in the region of your IBM MQ on Cloud instance. Note: If the menu choices include the option Monitoring, then your instance is already configured for platform metrics.
5. Provision an instance of the IBM Cloud Monitoring service.



Note: After you provision the Sysdig instance, the Observabvility page opens. To continue working with IBM MQ on Cloud, go back to the IBM MQ on Cloud UI.

For more information about how to configure Sysdig instances to receive queue manager metrics, see [Provisioning an instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision).





 Viewing metrics
Services generating metrics 

List of IBM Cloud® services that send metrics to IBM Cloud Monitoring.

There are 2 ways that services send metrics:



* As platform metrics

You monitor these metrics through the monitoring instance that is configured to receive platform metrics. [Learn more about enabling platform metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enabling).
* By configuring a Monitoring agent

You configure the agent to send metrics to the Monitoring instance that you choose. You monitor these metrics through that instance.





 Classic 

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



Table 1. List of classic infrastructure services (generation 1)

 Service Description Metrics 

 [IBM Cloud® Virtual Servers](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-getting-started-tutorial) Scalable virtual servers that are purchased with cores and memory allocations. [Platform metrics](https://cloud.ibm.com/docs/virtual-servers?topic=cloud-infrastructure-monitoring-iaas) 







 Container services 

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



Table 2. List of IBM Cloud container services

 Service Description Metrics 

 [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started) IBM Cloud® Container Registry provides a multi-tenant, highly available, scalable, and encrypted private image registry that is hosted and managed by IBM®. [Platform metrics](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_monitor) 
 [IBM Cloud® Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) You can use the IBM Cloud Kubernetes Service service to deploy highly available apps in Docker containers that run in Kubernetes clusters.
* ibm_cos_bucket_first_byte_latency_misc_min
* ibm_cos_bucket_first_byte_latency_misc_max
* ibm_cos_bucket_first_byte_latency_misc_avg
* ibm_cos_bucket_request_latency_read_min
* ibm_cos_bucket_request_latency_read_max
* ibm_cos_bucket_request_latency_read_avg
* ibm_cos_bucket_request_latency_write_min
* ibm_cos_bucket_request_latency_write_max
* ibm_cos_bucket_request_latency_write_avg
* ibm_cos_bucket_request_latency_misc_min
* ibm_cos_bucket_request_latency_misc_max
* ibm_cos_bucket_request_latency_misc_avg



All metrics are reported as float64 numeric values:







 Attributes for Segmentation 

You can filter your results by attributes. In this guide, we'll look at some general examples as well as those specific to IBM Cloud Object Storage.



 Global Attributes 

The following attributes are available for segmenting all of the metrics listed above



Table 4: IBM global attributes

 Attribute Attribute Name Attribute Description 

 Cloud Type ibm_ctype public, dedicated or local 
 Location ibm_location The location of the monitored resource. This may be a Cross Region, Regional, or Single Site bucket. 
 Resource ibm_resource COS bucket name 
 Resource Type ibm_resource_type COS bucket 
 Scope ibm_scope The scope is the account associated with this metric. 
 Service name ibm_service_name cloud-object-storage 







 Additional Attributes 

The following attributes are available for segmenting one or more attributes as described in the reference above. Please see the individual metrics for segmentation options.



Table 5: COS specific attributes

 Attribute Attribute Name Attribute Description 

 IBM COS Bucket storage class ibm_cos_bucket_storage_class Storage class of the bucket
Monitoring a Linux bare metal server 

You can monitor a Bare Metal server with IBM Cloud Monitoring by configuring a monitoring agent in your server. The monitoring agent uses an access key (token) to authenticate with the IBM Cloud Monitoring instance. The monitoring agent acts as a data collector. It automatically collects metrics. You view metrics via the web-based user interface. You can monitor Bare metals in IBM Cloud, on-prem, and in other clouds.

By default, this agent collects core infrastructure and network time series that you can use to monitor the host. For a list of collected metrics, see [Metrics Available for non-orchestrated environments](https://docs.sysdig.com/en/docs/installation/sysdig-agent/agent-configuration/configure-agent-modes/metrics-available-in-monitor-light/).

The Monitoring agent automatically collects the following types of system metrics per host:



* System hosts metrics provide information about CPU, memory, and storage usage metrics, that you can use to analyze the performance and resource utilization of all your processes.
* File and File System metrics provide information about files and file system that you can use to analyze file interactions that occur in your system. For example, you can find information about your open files, bytes going in and out, or the percentage of usage of a given file system.
* Process metrics provide information about the processes that run in your servers. For example, you can use these metrics to explore the number of processes, or get client or server information.
* Network metrics provide information about the network. They offer insight to the connections that are established between your applications, containers, and servers. For example, you can find information about the bytes that are being sent or received, or the number of HTTP requests, connections, and latency. In addition, for SQL or MongoDB, the agent collects additional information when it is configured in troubleshooting mode.



Through the Monitoring UI, you can analyze data in the Advisor tab, the Explore tab, and in the Dashboard tab. You monitor the data through metric views and dashboards.

Consider the following information when monitoring your data: