vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Where does IBM store the customer's logs and how long does IBM keep the audit logs for the blockchain platform service?

The logs are stored in the customer's Kubernetes cluster. IBM does not have access to the logs and it is up to the customer to manage all of their log data including retention management.
* Do we have access to logging services and what logs are available to me?

With IBM Blockchain Platform, you can now directly access logs from your Kubernetes dashboard. It is recommend that you take advantage of the IBM Log Analysis service that allows you to easily parse the logs in real time.
* Is there a best practice for monitoring my blockchain resources?

You are responsible for the health monitoring and resource allocation of the blockchain nodes in your Kubernetes cluster. While requests against the nodes are being actively processed, you should be monitoring for spikes in resource consumption to avoid problems. IBM recommends that you configure IBM Cloud Monitoring and set up alerts to track when blockchain nodes are reaching their limits. See the tutorial on [IBM Cloud Monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started) for more details.

You should be aware that JavaScript and TypeScript smart contracts require more resources than contracts written in Golang. Therefore, when you are allocating resources to your cluster, it is important to ensure adequate resources are available to your smart contract pods when they are deployed on a channel and during transaction processing. The pods containing the smart contracts will consume as much resources as they need to function.



Compute Bare Metal Servers for Classic



* Why don’t I see some of my disks as choices on the 'Create image template' page?

Disks that aren't contained within a volume (storage group) aren't eligible to capture and therefore you don't see them listed on the page. If you want a missing disk to show up as a choice, you must submit a [support ticket](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar) that asks to associate the disk with a volume.
* Why did my capture fail?

When a capture fails, an error occurred.
The Manage Log Analysis button links to the main list of all Log Analysis instances in your IBM Cloud account. Select the instance where you set your database platform logs to be forwarded. Click View Log Analysis to view the logs.

Each log line can be expanded to a detailed view by clicking the arrow to the left of the timestamp. The expanded view has some handy, color-coded fields to help you parse your logs.



* Line Identifiers



* Source - the region the logs are being sent from
* App - the ID of the application that sent the log. It is the last part of your deployment ID and CRN.



* Tags



* - all of the logs that come from a Cloud Databases deployment are tagged with ibm-cloud-databases



* Labels



* database - the database type that this log is from
* member - the member ID for which node in the cluster generated the log
* CRN - the full deployment ID of your deployment.





Log Analysis offers [searching](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logsview_logs_step6), [filtering](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logsview_logs_step5) to help you navigate your logs.

[Export](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-exportexport) and [archiving](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-archivingarchiving) are available so you can customize retention (and cost) for your use-case.

To set up logging alerts, see [Working with Alerts](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-alertsalerts)

For more information on features offered by IBM Cloud® Log Analysis, including integrating it with your other IBM Cloud services, see [its full documentation](https://cloud.ibm.com/docs/log-analysis).





 Internal Log Retention
Release notes for IBM Cloud® Databases for Redis 

Use these release notes to learn about the latest updates to IBM Cloud® Databases for Redis that are grouped by date or build number.



 23 May 2023 

Setting up disk alerts for disk utilization tutorial
: In this tutorial, you use the IBM Cloud API and the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) to set up an alert that emails you whenever the disk utilization of your database exceeds 90%. This specific example creates an alert on a Databases for Elasticsearch deployment, but it is applicable to all the databases in the IBM Cloud Databases catalog. For more information, see [Setting up disk alerts for disk utilization](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-disk-util-alert-tutorial).





 19 October 2022 

Deploying and Connecting a Cloud Databases Instance Tutorial
: This tutorial guides you through the process of deploying a Cloud Databases instance and connecting it to a web front end by creating a webpage that allows visitors to input a word and its definition. These values are then stored in a database running on Cloud Databases. You install the database infrastructure by using Terraform and your web application uses the popular Express framework. The application can then be run locally, or by using Docker. For more information, see [Deploying and Connecting a Cloud Databases Instance](https://cloud.ibm.com/docs/databases-for-redis?topic=cloud-databases-create-instance-tutorial).





 11 October 2022 

Protecting IBM Cloud® Databases for Redis resources with context-based restrictions
: Context-based restrictions (CBR) give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud® resources based on the context of access requests. Access to Cloud Databases resources can be controlled with CBR and identity and access management (IAM) policies.
Notice that the link expires automatically after 12 hours. The compressed file is hosted in IBM Cloud Object Storage (COS).
* When you export logs programmatically, you can choose to send an email, or to write data to the terminal.
* When you export logs, you have a limit of lines that you can export in a request. You can specify to export older lines or newer lines in case you reach the limit in the time range that you specify for the export.







 Deleting your data 



 Deleting logs when an instance is deleted 

When you delete a logging instance, the instance is automatically deactivated, and ingestion of logs is stopped. [Learn more](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-remove).

logging deletes all logs that are already ingested. Deletion is completed within 24 hours after receiving your request.

You are responsible for deleting archived logs.





 Deleting metadata when an instance is deleted 

When you delete a logging instance, user metadata such as views, alerts, dashboards, screens, and templates, is never deleted.

You must open a case through support to request the data to be deleted. For more information, see [Open a support ticket](https://cloud.ibm.com/docs/get-support).

You are responsible for deleting archived metadata.





 Deleting metadata from an instance 

You can delete metadata such as views, dashboards, screens, templates, and alerts at any time.





 Deleting subsets of logs from an instance 

Deletion of a subset of logs is not supported.

For example, you cannot delete logs from one logging agent. You cannot delete data for a specific service. You cannot delete data that match a particular query.
Consider the following information when you export log data:



* You export a set of event entries. To define the set of data that you want to export, you can apply filter and searches. You can also specify the time range.
* From the Web UI, when you export events, you get an email that is sent to your email address, with a link to a compressed file that includes the data. To get the data, you must click the link and download the compressed file. Notice that the link expires automatically after 12 hours. The compressed file is hosted in IBM Cloud Object Storage (COS).
* When you export data, you have a limit of lines that you can export in a request. You can specify to export older lines or newer lines in case you reach the limit in the time range that you specify for the export.



When you delete an instance, the instance is automatically deactivated, and ingestion of events is stopped. [Learn more](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-remove). Activity Tracker deletes all events that are already ingested. Deletion is completed within 24 hours after receiving your request. You are responsible for managing archived data.

When you delete an auditing instance, user metadata such as views, alerts, dashboards, screens, and templates, is never deleted. You must open a case through support to request the data to be deleted. For more information, see [Open a support ticket](https://cloud.ibm.com/docs/get-support). You are responsible for deleting archived metadata.

You can delete metadata such as views, dashboards, screens, templates, and alerts at any time.

Deletion of a subset of your data is not supported. For example, you cannot delete data for a specific service. You cannot delete data that match a particular query.
A graph will help you determine the number of log entries for the timezone and time range.



6. Specify the Service. If required, you will be prompted to connect to PagerDuty.

If no services are listed, click Add PagerDuty to connect and add a service. Create a PagerDuty service and associate it with an escalation policy. You will be directed to PagerDuty to authorize the integration. After authorization, your alerts will display in the PagerDuty incidents dashboard.
7. Optional: You can click Test to test that your alert configuration is correct.

![PagerDuty Test button](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/pagerduty-test.png)
8. Click Save Alert.

The alert definition must be saved for alerts to be sent to PagerDuty.







 Integrating with multiple PagerDuty services 

Each view can be linked to one or more PagerDuty services. To alert multiple PagerDuty accounts, configure multiple alerts for the same view with each alert notifying a different PagerDuty account.

You can also configure differnt views to notify a single PagerDuty account.





 Limitations 

Due to [PagerDuty API limitations](https://developer.pagerduty.com/docs/events-api-v2/overview/), all requests are trimmed to a maximum of 400 KB.
{"error":"Nothing to configure","code":"BadRequest","status":"error"}





 Deleting views 

When you delete a view, consider the following information:



* You must specify the ID of the view that you plan to delete.
* You delete the view and all the alerts that are configured for the view.









 API methods 

The following table outlines the actions that you can run to manage views and alerts programmatically:



Table 1. Configuration API endpoints

 Action Request URL 

 Create a view and attach an alert to a view. POST <ENDPOINT>/v1/config/view 
 Get all configured views and alerts GET <ENDPOINT>/v1/config/view 
 Modify an existing view and the alerts that are attached to the view. PUT <ENDPOINT>/v1/config/view/<VIEWID> 
 Delete a view and its associated alerts. DELETE <ENDPOINT>/v1/config/view/<VIEWID> 



Where <VIEWID> represents the ID of a view.





 Endpoint URL 

Depending on [your account settings](https://cloud.ibm.com/docs/account?topic=account-service-endpoints-overview), you can use public or private endpoints to manage views and alerts programmatically. For information about endpoints per region, see [API endpoints](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-endpointsendpoints_api).





 Authentication 

When you manage views and alerts programmatically, you must use a service key. Authorization to the Configuration API is enforced by using a service key.

A service key is a unique code that is passed in an API request to identify the calling application or user. The service key is specific to an auditing instance. For more information on how to generate a service key, see [Managing service keys](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-service_keys).
By using access groups, you can simply add or remove users in your account from the access groups to assign or revoke access as needed. By using trusted profiles, you can easily update the conditions by which federated users from your corporate user directory are allowed to apply trusted profiles without having to invite them to the account or assign individual access to each user.



 Multiple users working together on a single project by using access groups 

Some of the users in your account need to manage the account and assign other users access. Some users need to create service instances that incur expenses. Other users are application developers who need to use only the service instances from their application components.

You want to grant all users various roles in the account and the default resource group. You don't need to create more resource groups to separate resources or restrict some users from accessing some of the resources. You can grant the users the roles that are appropriate for their needs by creating an access group for each group of users:



* Create an access group and assign users to the group who need to manage the account and give others access. Then, assign a policy with an administrator role on the all IAM-enabled services and all account management services.
* Create an access group and assign users to the group who need to create service instances. Then, assign a policy with an editor role on the default resource group and a policy with the editor role for any service the users need to create.
* Create an access group and assign users to the group who need to use the service instances in a resource group. Then, assign a policy with a writer or reader role on the service instances that exist in the resource group.







 Multiple users working together on a single project by using trusted profiles 

In a larger organization, you want to manage access at scale. Some of the members in your organization need to manage the IBM Cloud account and assign other users access. Some members need to create service instances that incur expenses. Other members are application developers who need to use only the service instances from their application components.

You want to grant all users various roles in the account and the default resource group. You don't need to create more resource groups to separate resources or restrict some users from accessing some of the resources.
Some of the members in your organization need to manage the IBM Cloud account and assign other users access. Some members need to create service instances that incur expenses. Other members are application developers who need to use only the service instances from their application components.

You want to grant all users various roles in the account and the default resource group. You don't need to create more resource groups to separate resources or restrict some users from accessing some of the resources. You can grant the users the roles that are appropriate for their needs by creating trusted profiles for each type of user and map them to the correct profile based on external IdP attributes:



* Create a trusted profile for users who need to manage the account and give others access. Establish a trust relationship with your external IdP and define the attributes that allow the appropriate members of your organization to apply the profile. Then, assign a policy with an administrator role on the all IAM-enabled services and all account management services.
* Create a trusted profile for users who need to create service instances. Establish a trust relationship with your external IdP and define the attributes that allow the appropriate members of your organization to apply the profile. Then, assign a policy with an editor role on the default resource group and a policy with the editor role for any service the users need to create.
* Create a trusted profile for users who need to use the service instances in a resource group. Establish a trust relationship with your external IdP and define the attributes that allow the appropriate members of your organization to apply the profile. Then, assign a policy with a writer or reader role on the service instances that exist in the resource group.







 Two teams working on two related projects 

You have two functional projects in your account. Developers working on a project need access to all of its resources. As an account administrator, you can grant access by creating access groups for each project and incorporating access management tags into each group's access policies.

Flexibility is important, and with IAM, you can share resources between various groups. Let's say you notice that a resource might work well for both projects. You can share a resource between the two projects by tagging the resource and relying on the existing permissions to grant access to the developers.
Integration 

Review the following topic to understand the Operational Management layer of the design. However, some enterprises might want to integrate this layer with the Service Management layer. In this design, VMware Aria® Operations™ Manager is the central point where all alerts are surfaced.

Review the following categories of integration.



* Northbound – Integration from VMware Aria Operations to other tools.



* Notification of alerts to SMTP server or tools like Slack or PagerDuty.
* Ticket integration into a service desk tool like ServiceNow.
* Initiating VMware Aria Orchestrator workflows to remediate an issue discovered by VMware Aria® Automation™.



* Southbound – Integration from service management or cloud management tools.



* VMware Aria Automation configures monitoring when new workload is added.
* Update VMware Aria Operations objects with event enrichment from external sources.





VMware Aria Operations provides the following outbound alert plug-ins:



* Automated Action – enabled by default.
* Standard email – uses Simple Mail Transfer Protocol (SMTP) to email VMware Aria Operations Manager alert notifications to your interested individuals.
* SNMP Trap– logs alerts on your SNMP Trap server.
* REST Notification – sends VMware Aria Operations alerts to another REST-enabled application where you built a REST web service to accept these messages.
* Log file – enables VMware Aria Operations to log alerts to a file on each of your VMware Aria Operations Manager nodes. If you installed VMware Aria Operations Manager as a multiple node cluster, each node processes and logs the alerts for the objects that it monitors. Each node logs the alerts for the objects it processes.
* Smarts SAM Notification – sends alert notifications to EMC Smarts Server Assurance Manager.
* Network Share – sends reports to a shared location, supports SMB version 2.0.



Notifications are alert notifications that meet the filter criteria in the notification rules before they are sent northbound to external systems. Notification rules are configured for the required outbound alerts so that they can be filtered before they are sent to the selected external system. The notifications list is used to manage these rules.



 Integration use case
Ideally, pipeline requests spend only a second or two on the queue before being picked up by the private worker pool. If pipeline requests remain queued for several seconds or minutes, the private worker pool might lack the capacity to handle the incoming pipeline workload. Alerting when pipeline queue times exceed a reasonable threshold, such as 10 seconds, can help draw your attention to a private worker pool that needs to be scaled up.





 User action 

The Continuous Delivery dashboard in Monitoring can help to identify trends in pipeline queue time. If the queue times for pipelines serviced by a private worker pool last several seconds or are trending upwards, check the configuration of the private worker pool, including the number and processing capacity of the nodes in the pool. You might lower queue times by scaling up the private worker pool, or by reducing the frequency, variety, or complexity of pipeline jobs and tasks that are dispatched to the private worker pool.









 Continuous Delivery predefined dashboards 

The following table outlines the pre-defined dashboards that you can use to monitor Continuous Delivery metrics:



Table 2. Pre-defined dashboards

 Dashboard Name Description 

 Continuous Delivery Default dashboard when you launch the Monitoring web UI from your service instance UI. 



You cannot change the Default dashboard. To customize the dashboard, you can create a copy of it.





 Metrics available by service plan 



Table 3: Metrics available by plan names

 Metric Name Lite Professional 

 [Pipeline queue time](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd-monitor-sysdigcd_ibm_toolchain_pipeline_queue_time_seconds) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 







 Predefined alerts 

The following table outlines the pre-defined alerts that are available in Monitoring:



Table 4. Pre-defined alerts

 Alert Name Description
* Restoring all of the volumes that are part of a VM snapshot
* Running multiple VM restore operations
* Retrying a VM restore operation if it originally failed
* Rolling back a VM to its original volume state







 Restrictions and considerations 



* If the restore operation fails, reach out to your storage support administrator. A failed restore operation can leave behind incomplete states, which might require a cleanup initiative from an IBM operation's team.
* If you choose to restore a shared volume on one VM, you cannot perform the snapshot, restore, clone, or capture operations on the other VMs that are using the shared volume (while the restore operation is running).
* If you encounter a failure while submitting multiple volume clone requests on the same volume, you should either delete any previous requests or start and execute the previous volume clone request.









 Frequently asked questions 

Here are some of the following frequently asked questions on snapshots and clonning that are documented on the faq page:



* [What are the key differences between a snapshot and clone?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqssnap-vs-clone)
* [Is there any UI to perform snapshot or clone operations?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqssnap-clone-ui)
* [Are there any initial snapshot requirement in terms of storage?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqssnap-storage-req)
* [Does the snapshot and volume clone supports any safeguard policy?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqssnap-clone-safeguard)
* [Can you tell me more about the backup process using the PowerHA Toolkit for IBM i?]