vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Proactive tasks 

The goal of these proactive checks is to enable system administrators to maintain the VMware vCenter Server® environment in a health state. When carried out daily, it prevents many common issues that are related to usage, capacity and performance issues, from impacting your workloads. These proactive checks can be classified into the following structure.



* Health - Checks that indicate issues that are currently affecting the health of your environment and require immediate attention to minimize impact that is, hardware failures.
* Risk - Checks that indicate issues that are not immediate threats but must be addressed soon. For example, capacity issues.
* Efficiency - Checks that indicate areas to improve performance or reclaim resources. For example, right-sizing virtual machines (VMs) and clusters.



Many of these proactive tasks can be made much simpler with the Operations Management on IBM Cloud® and reduce the management time.

It is important to understand your "baseline". This baseline reflects normal operations in your environment. All clients have a different baseline that is determined by their standard practices, the workloads that run on the vCenter Server instance, and more. These proactive checks are then comparing the recent capacity/performance/utilization against this baseline. These proactive usage checks are answering the following four questions.



1. Am I over-utilized now?
2. Will I run out of capacity soon?
3. Is my cluster under-sized for expected peak usage periods?
4. Can I reclaim unused resources from my virtual infrastructure?





 Guidelines 

The following guidelines assist you in being proactive and maintaining a stable environment:



* Plan your VM deployments by allocating enough resources for all the VMs you plan to run. Don't forget to allow resources for vSphere ESXi™ itself.
* Size your VMs correctly and allocate to each VM only as much virtual resources as that VM needs. Provisioning a VM with more resources than it needs might reduce the performance of that VM and of others on the same host.
* In general, 80% host CPU usage is a reasonable ceiling and 90% is a warning that the CPUs are approaching an overloaded condition.
The legacy Prometheus WMI Exporter is still supported, see [Monitoring a Windows environment using the legacy WMI Exporter](https://cloud.ibm.com/docs/monitoring?topic=monitoring-windows_wmi) for information on the WMI Exporter.





 IPMI exporter 

In addition to the set of metrics that are automatically collected by the monitoring agent, you might want to collect other metrics such as sensor metrics.

Configure the [Prometheus IPMI exporter](https://github.com/soundcloud/ipmi_exporter) to collect Intelligent Platform Management Interface (IPMI) device sensor metrics.



* The Prometheus IPMI Exporter exporter supports local IPMI devices and remote devices that can be accessed by using Remote Management Control Protocol (RMCP).
* When you use RMCP to access remote devices, you can use an IPMI exporter to monitor multiple IPMI devices. You identify each device by passing the target hostname as a parameter.
* The IPMI exporter relies on tools from the FreeIPMI suite.



You can collect the following metrics when you configure the IPMI exporter:



* IPMI admin metrics

The metric ipmi_up {collector="<NAME>"} reports 1 when data from a remote host is collected successfully. It reports 0 for collection of data in a local host.

The metric ipmi_scrape_duration_seconds reports the amount of time that it takes the collector to retrieve the data.
* IPMI System event log (SEL) metrics

The metric ipmi_sel_entries_count reports the number of entries in the system event log.

The metric ipmi_sel_free_space_bytes reports the number of free bytes for new ystem event log entries.
* IPMI sensor data

The IPMI exporter collects 2 metrics per sensor type: state and value. A value of 0 reports a normal state. A value of 1 reports a warning state. A value of 2 reports a critical state. A value of NaN reports information not available. For example, see the metrics for different sensors:
[Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enabling).

To see the list of enabled-monitoring services, see [Cloud services](https://cloud.ibm.com/docs/monitoring?topic=monitoring-cloud_services).

For example, to configure platform metrics in a region, complete the following steps:



1. From theIBM 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 the enabled services on that location.
5. Click Save.



The main Observability page opens.

The instance that you configured to receive metrics shows the flag Platform metrics.





 Configure a monitoring agent 

After you provision an instance, you can configure a monitoring agent for each host, where agents are supported, that you want to monitor. For example, a host can be a cloud resource that you want to monitor and control its performance and health such as a Kubernetes cluster. You might also monitor hosts outside the IBM Cloud.

The monitoring agent automatically collects and reports on pre-defined metrics. You use the access key to configure the monitoring agent that is responsible for collecting and forwarding metric data to your instance. For more information, see [Working with access keys](https://cloud.ibm.com/docs/monitoring?topic=monitoring-access_keyaccess_key).

You can configure a monitoring agent for different environments. For example, to configure your Kubernetes cluster to send metrics to your IBM Cloud Monitoring instance, you must install a monitoring-agent pod on each node of your cluster.
* [Viewing LUN information in VMWare®](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-identifyLUNidentifyLUNVMware)







 Can I get storage performance metrics (IOPS or latency) from the Support teams? 

IBM Cloud® does not provide storage performance IOPS and latency metrics. Customers are expected to monitor their own Block Storage for Classic devices by using their choice of third-party monitoring tools.

The following examples are utilities that you might consider to use to check performance statistics.



* [sysstat](https://github.com/sysstat/sysstat/blob/master/README.md) - System performance tools for the Linux® operating system.
* [typeperf](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/typeperf) - Windows® command that writes performance data to the command window or to a log file.
* [esxtop](https://communities.vmware.com/t5/Storage-Performance/Interpreting-esxtop-Statistics/ta-p/2776936) - A command-line tool that gives administrators real-time information about resource usage in a VMware® vSphere environment. It can monitor and collect data for all system resources: CPU, memory, disk, and network.







 What is the difference between a replica volume, a dependent and an independent duplicate volume? 

You can create a replica or a duplicate volume by using a snapshot of your volume. Replication and cloning use one of your snapshots to copy data to a destination volume. However, that is where the similarities end.

Replication keeps your data in sync in two different locations. Only one of the volume pair (primary volume and replica volume) can be active at a time. The replication process automatically copies information from the active volume to the inactive volume based on the replication schedule. For more information about replica volumes, see [Replicating data](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-replication).
* [Viewing LUN information in VMWare®](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-identifyLUNidentifyLUNVMware)



* Can I get storage performance metrics (IOPS or latency) from the Support teams?

IBM Cloud® does not provide storage performance IOPS and latency metrics. Customers are expected to monitor their own Block Storage for Classic devices by using their choice of third-party monitoring tools.

The following examples are utilities that you might consider to use to check performance statistics.



* [sysstat](https://github.com/sysstat/sysstat/blob/master/README.md) - System performance tools for the Linux® operating system.
* [typeperf](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/typeperf) - Windows® command that writes performance data to the command window or to a log file.
* [esxtop](https://communities.vmware.com/t5/Storage-Performance/Interpreting-esxtop-Statistics/ta-p/2776936) - A command-line tool that gives administrators real-time information about resource usage in a VMware® vSphere environment. It can monitor and collect data for all system resources: CPU, memory, disk, and network.



* What is the difference between a replica volume, a dependent and an independent duplicate volume?

You can create a replica or a duplicate volume by using a snapshot of your volume. Replication and cloning use one of your snapshots to copy data to a destination volume. However, that is where the similarities end.

Replication keeps your data in sync in two different locations. Only one of the volume pair (primary volume and replica volume) can be active at a time. The replication process automatically copies information from the active volume to the inactive volume based on the replication schedule. For more information about replica volumes, see [Replicating data](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-replication).
FAQs for RackWare 



 What is RMM server? 

RackWare Management Module (RMM) server is a software appliance that is offered by RackWare that replatforms your server from an IBM Cloud® classic physical bare metal server to an IBM Cloud VPC virtual server instance.





 Where can I find more information about RMM server? 

For RMM server overview information, see [RackWare's Cloud Migration documentation](https://www.rackwareinc.com/cloud-migration). For RMM server usage guide information, see [RackWare RMM User's Guide for IBM Cloud](https://www.rackwareinc.com/rackware-rmm-users-guide-for-ibm-cloud).





 How do I install the RMM server? 

This software is available in the IBM Cloud® catalog in the Migration Tools category. After you complete the appropriate information, a virtual server instance is installed in a new VPC with the RMM already installed.





 Is this service free? 

You need to Bring Your Own License (BYOL), which you must purchase directly from RackWare. For more information or inquiries, contact [sales@rackwareinc.com](mailto:sales@rackwareinc.com). However, IBM is offering promotional licensing at no cost for three months for three reusable concurrent migration licenses.





 What is the promotional license? 

The promotional license is valid only for per-account and first-time users of the RMM server. After the three-month period, you need to purchase the license directly from RackWare.





 How does the reusable concurrent license work? 

IBM and RackWare have put together a special license model. Typically, a license is a one-time use for each server migration. Whereas for IBM purposes, after a completed migration, the license can be reused for a different server migration. The original host that the license was assigned to just needs to be deleted from the RMM server database.

The number of concurrent migrations that can occur is limited up to the number of licenses procured.





 How do I obtain and activate my promotional license? 

You can retrieve the promotional license through the discovery script that is part of the RMM software appliance.
Describe your admission control webhooks and save the output to a file called webhooks.txt.

kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
3. Review the webhooks.txt file for error messages. Webhook related error messages from an application, including oc, can help to identify the webhook.
4. Review the apiserver metrics for rejection type, count, and the rejection code. You can get a snapshot of the metrics by using the following command.

kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count

apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16

A rejection_code value of 0 indicates an error occurred when calling the webhook. A non-zero rejection_code value indicates the webhook rejected the request.

There are 3 apiserver instances. The oc command gets metrics from one of them and reflects the activity there. Each apiserver returns different data. Instances that have not processed the failing requests might not return this metric.
5. Review the command output from the previous steps and look for webhook descriptions to identify the specific MutatingWebhookConfiguration or ValidatingWebhookConfiguration value. If the errors, logs, or metrics do not help, review the webhook descriptions that you retrieved earlier. Each webhook configuration has a set of rules that specify the kinds of resources and actions the webhook is called for. This information can be used to identify the webhook(s) that might be involved.



* If there is an error calling the webhook, review the documentation for that service for product-specific debuggging steps.
Describe your admission control webhooks and save the output to a file called webhooks.txt.

kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
3. Review the webhooks.txt file for error messages. Webhook related error messages from an application, including kubectl, can help to identify the webhook.
4. Review the apiserver metrics for rejection type, count, and the rejection code. You can get a snapshot of the metrics by using the following command.

kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count

apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16

A rejection_code value of 0 indicates an error occurred when calling the webhook. A non-zero rejection_code value indicates the webhook rejected the request.

There are 3 apiserver instances. The kubectl command gets metrics from one of them and reflects the activity there. Each apiserver returns different data. Instances that have not processed the failing requests might not return this metric.
5. Review the command output from the previous steps and look for webhook descriptions to identify the specific MutatingWebhookConfiguration or ValidatingWebhookConfiguration value. If the errors, logs, or metrics do not help, review the webhook descriptions that you retrieved earlier. Each webhook configuration has a set of rules that specify the kinds of resources and actions the webhook is called for. This information can be used to identify the webhook(s) that might be involved.



* If there is an error calling the webhook, review the documentation for that service for product-specific debuggging steps.
* [Install the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).
* [Install the IBM Cloud Metrics Routing CLI](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-metrics-router-cli-config).
* You must have a userid with permissions to manage IBM Cloud Metrics Routing. For more information about IAM roles and how to assign them, see [Managing access with IAM](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam) and [Assigning access to IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam-assign-access).
* 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.

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)







 Step 1. Configure the account settings 

Set these account settings to define where and how metrics are collected, routed, and managed in your account by using IBM Cloud Metrics Routing.

When you configure IBM Cloud Metrics Routing in your account, you can configure account settings such as metadata locations, type of endpoints that are allowed to manage the configuration, locations where targets can be defined, and default targets for collecting metrics in regions that you have not explicitly configured how to route metrics. For more information, see [Configuring IBM Cloud Metrics Routing account settings](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-settings).
Change the image name to the repository name that you got from the previous step:

image: "<region>.icr.io/mynamespace/<container_name>" Edit me

Now, under secretKeyRef, change the name of <db-secret-name> to match the name of the secret that was created when you bound your database deployment to your Kubernetes cluster.

secretKeyRef:
name: <db-secret-name> Edit me

As for the service configuration at the end of the file, [nodePort](https://cloud.ibm.com/docs/containers?topic=containers-nodeport) indicates the port that the application can be accessed from. You have ports in the range 30000 - 32767 that you can use, but we chose 30081. The TCP port is set to 8080, which is the port the Node.js application runs on in the container.







 Deploying your Kubernetes App 



1. Deploy the application to Kubernetes Service. When you deploy the application, it is automatically bound to your Kubernetes cluster.

kubectl apply -f clouddb-deployment.yaml
2. Get the IP for the application.

ibmcloud ks workers -c <cluster_name>

The result is something like:

ID Public IP PrivateIP Machine Type State Status Zone Version
kube-hou02-pa1a59e9fd92f44af9b4147a27a31db5c4-w1 199.199.99.999 10.76202.188 free normal Ready hou02 1.10.11_1536

Now you can access the application from the Public IP from port 30082.

The clouddatabases-helloworld app displays the contents of an examples database. To demonstrate that the app is connected to your service, add some words to the database. The words are displayed as you add them, with the most recently added words displayed first.







 Code Structure 



Table 1. Code structure

 File Description
Give this new panel a title, Disk space used %.
3. Select fs.used.percent from the Metrics drop-down list.
4. In the Segment by drop down list, select kubernetes.deployment.label.name and click Save.
5. Hover your mouse over the data in the generated graph and a pop-up window is displayed that shows the average disk space percentage used by each peer container.



At this point you have configured panels to display the percentage of CPU used by each peer container, the percentage of memory used by each peer container, and the percentage of disk space used by each peer container. You can drag the panels up and down on the dashboard, and delete any panels that are not interesting to you.

Zoom

![peer dashboard in monitoring](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/peerdashboard.png)

Figure 1. Peer dashboard in IBM Cloud Monitoring





 Create dashboards for the CA and ordering nodes 

When you are satisfied with your peer dashboard, you can simply replicate it, using the Copy Dashboard menu item on the Options menu. Give the dashboard a new name, for example Blockchain Operations - CAs or Blockchain Operations - Ordering nodes. Then, edit the scope of the new dashboard to be either container.name contains ca or container.name contains orderer respectively.







 Step four: Configure alerts to monitor resource usage 

Now that you have configured monitoring of your peer, CA, and ordering nodes, the final important step is to configure alerts in IBM Cloud Monitoring so that a notification is triggered when a specified condition is met. You can trigger an alert notification via email, slack, PagerDuty, Webhooks, OpsGenie, and VictorOps channels. First configure the notification channel and then define the alert triggers.



1. Configure your preferred notification channel by clicking on your user icon followed by Settings.

Zoom

!
This tutorial has provided some basic steps for getting started using IBM Cloud Monitoring to monitor your blockchain node resource allocation. You now have three dashboards that you can use to monitor the resource allocation of your peer, CA, and ordering nodes in your Kubernetes cluster. With a graduated tier purchase of the IBM Cloud Monitoring service, you can edit your charts and add more segmentations to further scope the data. You've also configured alerts for when nodes approach exceeding their allocated resources. Combined, these actions allow you to monitor your blockchain nodes, alerting you when resources are constrained, so that you can take the appropriate action to scale your network.
For more information, see the [IBM Cloud for Financial Services profile change log](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-fs-change-log).





 21 January 2022 

New service available in Configuration Governance
: IBM Cloud App ID is now available as part of the Configuration Governance component. You can create guardrails for App ID such as enforcing whether monitoring of runtime activity that is made by application users is tracked.





 11 January 2022 

New service available in Configuration Governance
: IBM Cloud Code Engine is now available as part of the Configuration Governance component. You can create guardrails for Code Engine such as ensuring that projects can be created only within specific regions.





 13 December 2021 

Event Notifications integration
: You can now integrate with [IBM Cloud Event Notifications](https://cloud.ibm.com/catalog/services/event-notifications) so that you can view and manage all your Security and Compliance Center alerts in a single location. With a fast alert time, you're able to immediately start an investigation into any reported issue and fix the vulnerability before it becomes a larger problem in your application.

To connect the Security and Compliance Center with the Event Notifications service, see [Enabling event notifications](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-event-notifications). For more information, check out the [announcement blog](https://www.ibm.com/cloud/blog/announcements/ibm-cloud-security-and-compliance-center-is-now-integrated-with-event-notifications).

Deprecation of the alerts capability
: As of 13 December 2021, alerts are deprecated in favor of [Event Notifications](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-event-notifications). The ability to create alerts within the Security and Compliance Center is no longer supported. You can continue to view, enable, disable, or delete your existing alerts until 15 March 2021. After this date, any existing alerts will be deleted, and the feature will be removed from the UI.