vania-janet/multiturn-rag-retrieval-data huggingface dataset:
With an approval, resources can be deployed and monitored by using IBM Cloud® Schematics. Then, if an update to the deployable architecture becomes available, your team is notified within your project and can update the version on your schedule.



 Benefits of projects 

Projects help manage IaC at scale. They help ensure that the IaC and its configuration are always valid, secure, and compliant. Because a single project can deploy to different accounts, projects allow users to group related resources across accounts for better collaboration, organization, and user management. Users can get started more efficiently on IBM Cloud by using projects to create resources by using deployable architectures that help build complex cloud infrastructures that are designed to meet high-availability, scalability, resiliency, and business continuity and disaster recovery (BC/DR) requirements. A project is a useful tool for many reasons.



* You can associate a set of deployable architectures, their configurations, and the resulting resources in a single interface. This helps you to manage your resources in a more secure and repeatable way, while simultaneously managing cost, status, and team activity.
* Projects offer a secure solution supply chain by ensuring that only approved deployable architectures are used to deploy resources and by leveraging trusted profiles to provide secure authorization that doesn't require key rotation and can't be misplaced.
* Projects provide governance over the configuration of IaC by ensuring that configuration changes are tracked, approved, and subject to automated validation and compliance checks.
* Projects help ensure that security and compliance issues are addressed by notifying project users of new versions and helping them get deployed in a timely manner.
* Projects allow infrastructure to be managed as code across accounts, allowing all infrastructure that is related to a project to be managed from a single place. This makes it easy to monitor that development and test infrastructure is aligned with production infrastructure by avoiding surprises as applications move through to production.
* Projects help with accounting and configuration management by ensuring that all resources that are associated with the project can be tracked back to the project by tagging and resource reports. Projects can also be tagged to provide a higher level of organization.







 Exploring popular use cases 

Projects help organize and secure the configurations that you create from an IaC deployable architecture as well as the resulting resources.
Getting information about Kubernetes monitoring agent images 

Kubernetes monitoring agent images are public images that are available in IBM Cloud through the [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started) service.

You can access the images that are provided by IBM® by using the command line.

Complete the following steps to get information about the monitoring agent images:



  Before you begin 

Before you begin, complete the following tasks:



1.  Ensure that the IBM Cloud Container Registry CLI is installed, see [Installing the container-registry CLI plug-in](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespacecli_namespace_registry_cli_install).
2.  Log in to [IBM Cloud](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login):

ibmcloud login







  Step 1. Target the global registry 

Run the following command:

ibmcloud cr region-set global





  Step 2. List the monitoring agent images that are hosted in the global registry 

Run the following command:

ibmcloud cr images --restrict ext/sysdig

The output of this command is the list of monitoring agent images. It includes information about the repository, icr.io/ext/sysdig, the image tag, the image digest, the image namespace, when the image was created, the image size, and the images security status.
The biggest difference between the admin user and any other users you add to your deployment is the [pg_monitor](https://www.postgresql.org/docs/current/default-roles.html) and [pg_signal_backend](https://www.postgresql.org/docs/current/default-roles.html) roles. The pg_monitor role provides a set of permissions that makes the admin user appropriate for monitoring the database server. The pg_signal_backend role provides the admin user the ability to send signals to cancel queries and connections that are initiated by other users. It is not able to send signals to processes owned by superusers.

pg_monitor is only available in PostgreSQL 10 and above. pg_signal_backend is only available in PostgreSQL 9.6 and above.

You can also use the admin user to grant these two roles to other users on your deployment.

If you want to expose the ability to cancel queries to other database users, you can grant the pg_signal_backend role from the admin user. For example,

GRANT pg_signal_backend TO joe;

to allow the user joe to cancel backends. You can also grant pg_signal_backend to all the users with the ibm-cloud-base-user role with

GRANT pg_signal_backend TO "ibm-cloud-base-user";



Be aware this privilege allows the user or users to terminate any connections to the database, so assign it with care.

Similarly, if you want to set up a specific monitoring user, mary, you can use

GRANT pg_monitor TO mary;

You can also grant pg_signal_backend to all the users with the ibm-cloud-base-user role with

GRANT pg_monitor TO "ibm-cloud-base-user";





 Service Credential Users
Proper operational logging and monitoring can help you determine if you need to failover to an alternate storage or processing site. In addition, operational logging and monitoring can help you determine if operations have returned to normal after a system disruption.

Operational logging is a complement to [audit logs](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-audit-logs). Audit logs contain auditable events, while operational logs contain everything else that might be logged. For example, an operational log might contain entries that reflect what's happening as a program executes, such as functions getting called, stack traces getting thrown, etc. While this kind of log data is key to keeping a system running smoothly, it's typically not sent to a SIEM.

Operational logs can be split into two categories:



* Application - Log data generated by software components that you deploy and manage within your deployment. This may be from your own code, or other software components like databases, message queues, etc.
* Platform - Log data from IBM Cloud service instances that is not contained in the [audit data sent to Activity Tracker Event Routing](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-logging-audit).



Operational monitoring for gauging system health is a very important complement to [monitoring for security and compliance](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-security-compliance-monitoring). Operational metrics include measurements for CPU usage, memory usage, API response times, etc.

Most Relevant Controls:



Table 9. Related controls in IBM Cloud Framework for Financial Services

 Family Control
[Monitor Cloud Foundry resources in IBM Cloud Public](https://cloud.ibm.com/docs-content/v1/content/1e0945ee44f87283927af9404a8f2d077786db0c/cloud-foundry-public//images/components-cf-public.svg)

Figure 1. Monitoring Cloud Foundry resources in IBM Cloud Public

If your Cloud Foundry resources run on IBM Cloud dedicated or outside the IBM Cloud, you can configure a custom user provided (CUPS) service for your app, so system and application logs are collected and streamed to a custom logging instance.

Zoom

![Monitor Cloud Foundry resources outside the IBM Cloud Public](https://cloud.ibm.com/docs-content/v1/content/1e0945ee44f87283927af9404a8f2d077786db0c/cloud-foundry-public//images/components-cf-dedicated-or-public.svg)

Figure 2. Monitoring Cloud Foundry resources outside IBM Cloud Public

The following table summarizes the type of logs that you can collect and monitor when you use the IBM Log Analysis service in IBM Cloud:

Monitor Cloud Foundry resources in IBM Cloud Public

Monitor Cloud Foundry resources in IBM Cloud Dedicated

Monitor Cloud Foundry resources outside IBM Cloud



Table 1. IBM Cloud public

 Cloud Foundry resource By using platform logs By using Syslog drains 

 CF infrastructure logs ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/1e0945ee44f87283927af9404a8f2d077786db0c/cloud-foundry-public//images/checkmark-icon.svg) NO 
 CF app logs ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/1e0945ee44f87283927af9404a8f2d077786db0c/cloud-foundry-public//images/checkmark-icon.svg) !
* Make sure that the domain does not have malformed IP addresses or load balancer hostnames registered.



4. Check if the domain has health monitoring.



* Get the list of the subdomain that have health monitoring enabled using the ibmcloud ks nlb-dns monitor ls[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_nlb-dns-monitor-ls).
* If the domain is included in the list, get the health monitor details using the ibmcloud ks nlb-dns monitor get[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_nlb-dns-monitor-get) command.
* Verify that the health monitor configuration is correct, and that your backend applications are healthy.
* Ensure that you allow incoming network traffic from [Akamai's source IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/akamai/gtm-liveness-test).
* Fix any backend, NLB-DNS health monitor configuration of firewall issues.



5. Wait 10-15 minutes, then check if the warning is resolved.
6. If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
* Make sure that the domain does not have malformed IP addresses or load balancer hostnames registered.



4. Check if the domain has health monitoring.



* Get the list of the subdomain that have health monitoring enabled using the ibmcloud oc nlb-dns monitor ls[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_nlb-dns-monitor-ls).
* If the domain is included in the list, get the health monitor details using the ibmcloud oc nlb-dns monitor get[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_nlb-dns-monitor-get) command.
* Verify that the health monitor configuration is correct, and that your backend applications are healthy.
* Ensure that you allow incoming network traffic from [Akamai's source IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/akamai/gtm-liveness-test).
* Fix any backend, NLB-DNS health monitor configuration of firewall issues.



5. Wait 10-15 minutes, then check if the warning is resolved.
6. If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
Monitor Event Notifications service metrics with IBM Cloud Monitoring 

Use IBM Cloud Monitoring to gain operational visibility into the performance and health of your applications, services, and platforms. It offers administrators, DevOps teams, and developers full stack telemetry with advanced features to monitor and troubleshoot, define alerts, and design custom dashboards.



 Set up your IBM Cloud Monitoring service instance 

To get started, you need to [provision IBM Cloud Monitoring](https://cloud.ibm.com/catalog/services/ibm-cloud-monitoring?callback=/observe/monitoring/create) instance on your IBM® account. See [Provisioning an instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision) for more details.

Currently, IBM Cloud Monitoring integration is available for Event Notifications service deployments in the following regions:



Table 1. Deployment regions

 Deployment region Monitoring region 

 Dallas Dallas 
 London London 
 Sydney Sydney 
 Frankfurt Frankfurt 



Before you can start with Event Notifications monitoring metrics, you must first opt in and [enable platform metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enabling)

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



* To configure the IBM Cloud Monitoring instance, you must turn on the platform metrics configuration setting.
* If a monitoring instance in a region is already enabled to collect platform metrics, metrics from enabled-monitoring services are collected automatically and available for monitoring through this instance. For more information about enabled-monitoring services, see IBM Cloud® services.



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.
In this design, power management is not enabled since there's no operational or financial benefit to powering on and off hosts in the cluster.







 vSphere High Availability 

vSphere provides high availability for VMs by pooling them and the hosts that they are on into a cluster. Hosts in the cluster are monitored and if a failure occurs, the VMs on a failed host are restarted on alternative hosts.

In this design, vSphere High Availability is enabled with host monitoring and VM monitoring on the cluster.



 Host monitoring 

Host monitoring allows hosts in the cluster to exchange network heartbeats and enables vSphere HA when it detects failures. This feature is enabled in this design.





 Virtual machine monitoring 

The VM monitoring feature uses the heartbeat information that VMware Tools captures as a proxy for guest operating system availability. VM monitoring allows vSphere HA automatically to reset or restart individual VMs that no longer have their ability to heartbeat. This design enables both VM and application monitoring.



 Failure conditions and VM response 

The failure conditions define how the VMs fail and the response that is given to each failure. In this design, the VM restart priority is set to medium. Review this value and adjust settings so that the restart priority matches the importance of the workload. Additionally, the response for host isolation is set to “Power off and restart VMs” so that VMs are not affected by an isolated host in the cluster. The rest of the values for this setting are set to default.

The following table shows the settings for the vSphere HA cluster in the VMware vSphere Web Client.



Table 2. Failure Conditions and VM Response settings for the vSphere HA cluster

 Setting Value 

 VM restart priority Medium 
 Response for Host Isolation Power off and restart VMs 
 Response for Datastore with Permanent Device Loss (PDL) Disabled 
 Response for Datastore with All Paths Down (APD) Disabled 
 Response for APD recovery after APD timeout Disabled 
 VM monitoring sensitivity Custom 
 Failure interval 50 s 
 Minimum uptime 90 s 
 Maximum per-VM resets 10 
 Maximum resets time window Within 1 hr
Monitoring the status of a configuration and its resources 

In a project, a configuration has one status: either draft or deployed. However, configurations go through many changes that you can track throughout the configuration's lifecycle. You can find more information about the detailed status of a configuration by opening the configuration within your project.



  Understanding configuration status 

The following table shows an example lifecycle of a configuration from creation through deployment.



Table 1. Status of a configuration in a project compared to the detailed status within the configuration and next steps.

 Configuration action        Status in the project  Detailed configuration status  Next steps                                                                                                      

 Create a configuration      Draft                  N/A                            Edit, save, and validate the changes                                                                            
 Validate the configuration  Draft                  Validation failed              Edit, save, and validate the changes                                                                            
 Validate the configuration  Draft                  Validation successful          Approve                                                                                                         
 Approve                     Draft                  Approved                       Deploy                                                                                                          
 Deploy                      Draft                  Changes failed to deploy       Edit and deploy again                                                                                           
 Deploy                      Deployed               Changes deployed               No other actions are necessary, but you can still edit the configuration, validate it, and deploy any changes.  



When you deploy a draft configuration, the status of the configuration changes to deployed within your project. After a configuration is deployed, you can still edit the configuration and deploy changes. If you do so, the status of the configuration remains deployed within your project.





  Understanding resource status 

You can track resources that were created by a deployment from the Resources tab in your configuration. From there, you can destroy resources or view more information about the status of your resources. For more information, see [Destroying resources that are created by projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-best-practices-projectsproject-resources-destroy).

If your changes failed to deploy, some or all of the resources weren't created by IBM Cloud® Schematics. The Resources tab in your configuration does not include the resources that weren't created successfully.
Understanding your responsibilities when using IBM Cloud Monitoring 

Learn about the management responsibilities and terms and conditions that you have when you use IBM Cloud Monitoring. For a high-level view of the service types in IBM Cloud and the breakdown of responsibilities between the customer and IBM for each type, see [Shared responsibilities for IBM Cloud offerings](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities).

Review the following sections for the specific responsibilities for you and for IBM when you use IBM Cloud Monitoring. For the overall terms of use, see [IBM Cloud Terms and Notices](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms).



 Incident and operations management 

You and IBM share responsibilities for the set up and maintenance of your IBM Cloud Monitoring service instance for monitoring your application and infrastructure workloads. You are responsible for incident and operations management of your application data.



Table 1. Responsibilities for incident and operations

 Task IBM Responsibilities Your Responsibilities 

 Monitor incidents Provide notifications for planned maintenance, security bulletins, or unplanned outages. Set preferences to [receive emails about platform notifications](https://cloud.ibm.com/docs/overview?topic=overview-uiemail-prefsl). <br>Monitor the [IBM Cloud status page](https://cloud.ibm.com/status?selected=announcement) for general announcements. 
 Maintain IBM Cloud high availability SLA Operate the Continuous Delivery service in accordance with the IBM Cloud Public [Service Level Agreements (SLAs)](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-slas). 
 Provide high availability capabilities Provide capabilities, such as IBM-owned infrastructure in multizone regions (MZR), to meet local access and low latency requirements for each supported region. Use the list of [available regions](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpoints) to plan for and create new instances of the service.
resolving Satellite is trying to resolve issues for you, such as by assigning available hosts to the control plane to relieve capacity issues. For more information, see the status message. 







 Viewing host health 

When you attach hosts to a Satellite location, IBM Cloud monitors the host and reports back statuses that you can use to keep your hosts healthy. For more information, see [IBM monitoring to resolve and report location alerts](https://cloud.ibm.com/docs/satellite?topic=satellite-monitormonitoring-default). For troubleshooting help, see [Debugging host health](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-hosts-debug).

You can review the host health from the Hosts table in the [Satellite console](https://cloud.ibm.com/satellite/locations), or by running ibmcloud sat host ls --location <location_name_or_ID>.



Host health states.

 Health state Description 

 assigned The host is assigned to a Satellite resource, such as a location control plane or cluster. View the status for more information. If the status is -, the hosts did not complete the bootstrapping process to the Satellite resource. For hosts that you just assigned, wait an hour or so for the process to complete. If you still see the status, [log in to the host to continue debugging](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-hosts-login). 
 health-pending The host is assigned and bootstrapped into the cluster as worker nodes that are provisioned and deployed. However, the health components that IBM sets up in the host cannot communicate status back to IBM Cloud. Make sure that your hosts meet the [minimum host and network connectivity requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network) and that the hosts are not blocked by a firewall in your infrastructure provider. 
 provisioning The host is attached to the Satellite location and is in the process of bootstrapping to become part of a Satellite resource, such as the worker node of a Red Hat OpenShift on IBM Cloud cluster.