vania-janet/multiturn-rag-retrieval-data huggingface dataset:
(https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/tut-sdu-apply-biblio.png)

Figure 21. A bibliography label is being applied
15. After you annotate and submit all the pages, click Apply changes and reprocess.

A notification is displayed to indicate that the collection was updated. You remain on the SDU tool page, but the Apply changes and reprocess button is disabled.



An SDU model is generated based on the structures that you labeled in this document.

For more information about the Smart Document Understanding feature, see [Using Smart Document Understanding](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-configuring-fields).





 Step 6: Streamline the searchable data 

Now that you have an SDU model that can recognize the different types of sections in the document, you can instruct it to include some sections in searches and to exclude others. To control what data gets searched, you include or exclude fields from the search index.



1. Click Manage fields.

Zoom

![Shows the Manage fields tab to click after SDU processing.](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/tut-sdu-manage-fields-tab.png)

Figure 22. The Manage fields tab
2. From the list of fields to index, set the switcher to No for all fields except these ones:



* footnote
* html
* subtitle
* table
* text



Zoom

!
Controlling user access with IBM Cloud IAM and Kubernetes RBAC 

Set IBM Cloud IAM platform access and service access policies in the IBM Cloud console or CLI so that users can work with clusters in Red Hat OpenShift on IBM Cloud. IAM service access roles correspond with Kubernetes role-based access control (RBAC) within the cluster.

Before you begin, check out [Understanding access policies and roles](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewaccess_policies) to review what policies are, whom you can assign policies to, and what resources can be granted policies.

IBM Cloud IAM roles can't be assigned to a service account. Instead, you can directly [assign RBAC roles to service accounts](https://cloud.ibm.com/docs/openshift?topic=openshift-usersrbac).



 Example cluster use cases and IAM roles 

Wondering which access roles to assign to your cluster users? Use the examples in following table to determine which roles and scope to assign. You can find more information about what roles authorize which types of actions on the user access reference page in the table's links.



Types of roles you might assign to meet different use cases.

 Use case Example roles and scope 

 App auditor [Viewer platform access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles), [Reader service access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles).
Limits 

Learn about known limits for IBM Cloud Metrics Routing.



  Targets 



*  You can define a target in any of the supported locations where IBM Cloud Metrics Routing is available. For more information, see [Locations](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions).
*  You can configure up to 16 targets in each account.
*  You can configure up to two default targets for each IBM Cloud account.
*  The target name must be 1000 characters or less and cannot include any special characters other than space, dash -, dot ., underscore _, and colon :.

The name must not include any personal identifying information (PII).
*  You can update the name of a target or the CRN of the target resource. The change can take up to 10 minutes to complete.







  Routes 



*  You can define a route in any of the supported locations where IBM Cloud Metrics Routing is available. For more information, see [Locations](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions).
*  You can define up to 4 routes for an account.
*  By default, the account has 0 routes configured.
*  You can configure up to 4 rules for each route.
*  You can configure up to 3 targets for each rule.
*  The route name must be 1000 characters or less and cannot include any special characters other than space, dash -, dot ., underscore _, and colon :.

The name must not include any personal identifying information (PII).





  Inclusion filters 



*  You can configure up to 7 inclusion filters for each rule.
*  You can configure up to 20 values for inclusion_filter.values.
*  Each value configured for inclusion_filter.values can be a maximum of 100 characters.
Every pod defaults to zero, except the cluster-critical pods that IBM deploys with the [default priority classes](https://cloud.ibm.com/docs/openshift?topic=openshift-pod_prioritydefault_priority_class). Because pod priority is relative, this basic setup ensures that the cluster-critical pods are prioritized for resources, and schedules any other pods by following the existing scheduling policies that you have in place.



 Understanding default priority classes 

Your Red Hat® OpenShift® on IBM Cloud® clusters come with some priority classes by default.

Do not modify the default classes, which are used to properly manage your cluster. You can use these classes in your app deployments, or [create your own priority classes](https://cloud.ibm.com/docs/openshift?topic=openshift-pod_prioritycreate_priority_class).

The following table describes the priority classes that are in your cluster by default and why they are used.



Default priority classes that you must not modify

 Name Set by Priority Value Purpose 

 system-node-critical Kubernetes 2000001000 Select pods that are deployed into the kube-system namespace when you create the cluster use this priority class to protect critical functionality for worker nodes, such as for networking, storage, logging, monitoring, and metrics pods. 
 system-cluster-critical Kubernetes 2000000000 Select pods that are deployed into the kube-system namespace when you create the cluster use this priority class to protect critical functionality for clusters, such as for networking, storage, logging, monitoring, and metrics pods. 
 ibm-app-cluster-critical IBM 900000000 Select pods that are deployed into the ibm-system namespace when you create the cluster use this priority class to protect critical functionality for apps, such as the load balancer pods. 



You can check which pods use the priority classes by running the following command.

oc get pods --all-namespaces -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName





 Creating a priority class 

To set pod priority, you need to use a priority class.

Before you begin:
--------------------



 Collecting metrics by using Prometheus remote write 

You can use the built in Prometheus remote write feature to send metrics from environments where the Monitoring agent coexists with Prometheus servers. Additionally, you can send metrics from environments where the Monitoring agent cannot currently be installed.

Use the Monitoring agent in environments where an agent is available. However, use the Prometheus remote write feature to send metrics from ephemeral or batch jobs that may not exist long enough to be scraped by the agent.

Use the Prometheus remote write feature to send metrics from environments where the Monitoring agent cannot currently be installed:



* Windows hosts and other operating systems
* Non x86 based architectures, typically seen on IoT environments or Edge computing



To collect metrics by using the Prometheus remote write feature, your Monitoring instance requires the Prom-Beacon service enabled. For existing IBM Cloud Monitoring instances, the Prom-Beacon service is enabled by default. Notice that for new instances, the feature is coming soon.

With the Prometheus remote write feature, you can either monitor metrics through the UI or you can use PromQL to query the data by using the standard Prometheus query language.

All communication between your Prometheus servers and Monitoring instances must use the authorization header with the Monitor API token as Bearer Token.



 Configuring Prometheus remote write 

You can configure your Prometheus server to remote write to a Monitoring instance.

For Prometheus v2.25 and previous versions, you must configure the remote_write section in your prometheus.yml configuration file as follows:

global:
external_labels:
[ <labelname>: <labelvalue> ... ]
remote_write:
- url: "https://<INGESTION_URL>/prometheus/remote/write"
bearer_token: "<MONITOR_API_TOKEN>"

Where



* <MONITOR_API_TOKEN> contains the authorization token.
* <INGESTION_URL> indicates the ingestion endpoint.
Windows environments [Monitoring a Windows environment](https://cloud.ibm.com/docs/monitoring?topic=monitoring-windows) 
 Linux environments [Working with the Linux agent](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent_linux) <br>[Deploying the agent on a Linux host with no public access](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent_linux_1) 





 Provisioning the Monitoring service 

To start using the IBM Cloud Monitoring service in the IBM Cloud, you must provision an instance of the Monitoring service in each region where you operate within IBM Cloud.

You provision an instance within the context of a resource group. You use a resource group to organize your services in the IBM Cloud for access control and billing purposes. You can provision the Monitoring instance in the default resource group or in a custom resource group. For more information, see [Provisioning an instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision).

When you [provision an instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provisionprovision), you automatically get an [access key](https://cloud.ibm.com/docs/monitoring?topic=monitoring-access_keyaccess_key). The access key is used to authenticate the sender of metrics from a resource to a Monitoring instance.





 Configuring sources 

After you provision an instance, you must configure metric sources, enable platform metrics, or both.



* A metric source is any resource that you want to monitor and control its performance and health.

When you configure a source by using an agent, data for default metrics is automatically collected.

You can also configure custom metrics and add labels to those metrics to describe their characteristics. Data for these custom metrics is also automatically collected.

For more information on how to configure sources to collect default metrics and custom metrics, see [Collecting metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-about-collect-metrics).
Understanding Satellite Config 

With Satellite Config, you create a configuration to specify what Kubernetes resources you want to deploy to a group of Red Hat OpenShift on IBM Cloud clusters that run in your Satellite location or in IBM Cloud.

You can create either GitOps-based configurations or Direct Upload configurations.



 Understanding GitOps-based configurations 

Store your Kubernetes resource definitions in a Git repository. Clusters automatically pull changes directly from your repository and Git references. Your resources stay in your source repository and automatically deploy when the referenced source changes. To use this method, select the GitOps template when you create your configuration. If you are using GitOps-based configuration for the first time and want to see how this flow works, you can select the GitOps - Sample application template, which guides you to set up and deploy a sample application from the IBM Git repository to your clusters.

Zoom

![How Satellite configurations work](https://cloud.ibm.com/docs-content/v1/content/c8335d66af691d19e837116fd633481c477061eb/satellite//images/satcon-gitops.svg)

Figure 1. How GitOps configurations work

A GitOps-based configuration involves the follow high-level steps.



1. Create a Satellite configuration and specify the repository, Git reference type, Git reference name, and path.
2. Create a subscription to associate the source repository of resource files with one or more cluster groups.
3. The resource files in the source repository is automatically deployed to the clusters that belong to the selected cluster group.







 Understanding Direct Upload configurations 

Store your Kubernetes resource definitions in Satellite Config by either manually uploading your YAML files or pushing YAML files from your CI/CD process. Manage changes directly through Satellite Config GUI, CLI, or from your CI/CD process. To use this method, select the Direct upload template when you create your configuration.

Zoom

!
Monitoring for watsonx.data 

Provide insight about your IBM® watsonx.data instance. View metrics on the health of key watsonx.data components such as the metastore and engine. Also, understand the usage of your instances by actively running tasks and queries.

You can use the IBM Cloud Monitoring service to monitor your watsonx.data instance. watsonx.data forwards selected information about your instance to Monitoring so that you can monitor specific metrics such as cpu and memory utilization.



 Set up your watsonx.data service instance 

To set up Monitoring for watsonx.data, you must create a service instance and then enable Platform Metrics in the same region as the watsonx.data instance that you want to monitor. If you have deployments in more than one region, you must provision Monitoring and enable platform metrics for each region.

To set up Monitoring,



1. From the IBM Cloud navigation menu, select Observability.
2. Select Monitoring. The Monitoring pane opens.
3. Either use an existing Monitoring service instance or create a new one.
4. After the instance is ready, enable platform metrics by clicking Configure platform metrics.
5. Select a region and then a Monitoring instance from that region. If you have deployments in more than one region, you must provision Monitoring and enable platform metrics for each region.







 Accessing your IBM Cloud Monitoring metrics 

To see your IBM® watsonx.data customer metrics dashboards in Monitoring:



1. From the IBM Cloud navigation menu, select Observability.
2. Select Monitoring. Click Open Dashboard.
3. Click Dashboards in the sidepane, open the IBM® watsonx.data dashboard to view your watsonx.data metrics.
4. For more information, see [Monitoring Getting started tutorial](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started).







 Metrics available by Service Plan
Attachments are evaluated once per day or can be initiated as needed.

Report
: The information that is returned by an evaluation is known as a report. For a breakdown of the information in the report, see [Understanding results](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-results).





 Understanding the user flow 

Now that you have an understanding of the various entities that exist within Security and Compliance Center, how do they work together? The following diagram details the user flows that you might take when you are working with Security and Compliance Center.

Zoom

![A diagram that shows the relationship between the entities that you work with in the service.](https://cloud.ibm.com/docs-content/v1/content/a6478671e8f845a84102d9cf49bf28ee7f4f3227/security-compliance/images/terminology-flow.svg)

Figure 1. Understanding the user flow for Security and Compliance Center



1. As a security or compliance focal, choose a predefined profile that is most suitable for your organization. Optionally you can customize the profile by creating custom rules, adding or removing rules, or building your own profile based on the catalog of controls.
2. To start scanning your resources, create an attachment of the profile to the scope of resources you want to scan. You can optionally customize parameters of the controls when you create the attachment.
3. After the attachment is created, your resources are evaluated one time per day by Security and Compliance Center.
4. As results are returned, they are forwarded to a Cloud Object Storage bucket that you own.
5. Results are shown in the Security and Compliance Center dashboard.
See [Understanding Satellite storage templates](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov). 







 Choose your infrastructure for Satellite 

To get started with Satellite, decide what type of infrastructure you want to use. Then, create a location by attaching hosts and creating a location control plane. For some cloud providers, you can use a Terraform template to create and attach your hosts. Otherwise, you can manually attach your hosts. For more help deciding what to choose, see [Planning your environment for Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-infrastructure-plan).

I want to try out Satellite.
: You can try out Satellite with our [Satellite guided tour](https://framer.com/share/External-Satellite-Demo--4QmxdNMF6smthRhzQgzt/ddN6j0Nrt?fullscreen=1&highlights=0ddN6j0Nrt). You can also create a Satellite location by using [IBM Cloud for tests](https://cloud.ibm.com/docs/satellite?topic=satellite-ibm). Note that this set up is not intended for use with production systems.

I'm planning to use my on-prem or edge infrastructure.
: For on-prem infrastructure, you can [manually set up a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locationslocation-create-manual).

I want to use a different cloud provider for my infrastructure.
: Choose from [Amazon Web Services (AWS)](https://cloud.ibm.com/docs/satellite?topic=satellite-aws), [Google Cloud Platform (GCP)](https://cloud.ibm.com/docs/satellite?topic=satellite-gcp), [Microsoft Azure](https://cloud.ibm.com/docs/satellite?topic=satellite-azure), or [Alibaba Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-alibaba).
Creating custom dashboards to monitor Code Engine 

Use IBM Cloud Monitoring to gain visibility into the health and performance of Code Engine workloads. You can customize a Monitoring dashboard for Code Engine workloads to a tailored set of metrics to help you identify bottlenecks or predict possible production problems.



 Create custom dashboards to monitor Code Engine 

You can create a custom Monitoring dashboard for Code Engine workloads to a tailored set of metrics.

Before you can create a custom dashboard in Monitoring, you must first set up monitoring for Code Engine workloads. Set up your Monitoring service instance and enable Platform Metrics in the same region as the Code Engine projects that you want to monitor. If you have deployments in more than one region, you must provision Monitoring and enable platform metrics for each region. For more information about setting up your IBM Cloud Monitoring service instance and accessing your IBM Cloud Monitoring metrics dashboard for monitoring Code Engine workloads, see [Monitoring for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-monitor).

Code Engine provides the IBM Code Engine Project Overview dashboard, which is composed of pre-defined panels that monitor various aspects of Code Engine workloads. You might want to create a custom Monitoring dashboard for Code Engine workloads to a tailored set of metrics.



1. Set up an [IBM Cloud Monitoring service instance](https://cloud.ibm.com/docs/codeengine?topic=codeengine-monitorsetup-monitor). To check for active IBM Cloud Monitoring instances, see the [Observability dashboard](https://cloud.ibm.com/observe/monitoring).
2. Ensure that there is monitoring data available. Because designing a custom dashboard is easier when you have data to monitor, it is important to have a running [application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloads) or [job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan). Some Code Engine metrics exist only if they are available in the environment.
3.
Enabling IBM Cloud Monitoring 'no driver mode' 

When you provision a monitoring instance, you can enable the 'no driver mode' (Light). You can access metrics through the pre-built dashboards that are available in the IBM Cloud dashboards section.



 Configuring IBM Cloud Monitoring 'no driver mode' 

To enable 'no driver mode' and monitor and manage metrics, you need to configure a monitoring agent in each environment that you want to use 'no driver mode'.

Use these steps to enable 'no driver mode'.



1. Provision a Graduated tier monitoring instance by following the steps in [Provisioning a monitoring instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision). For more information about the Graduate tier, see [Monitoring service plans](https://cloud.ibm.com/docs/monitoring?topic=monitoring-pricing_plans).
2. Enable monitoring 'no driver mode' by following the steps that correspond to your provisioned environment by following the steps in [Configuring a monitoring agent](https://cloud.ibm.com/docs/monitoring?topic=monitoring-config_agent).
3. Add the following configuration to the dragent.yaml file:

feature:
mode: monitor_light
Available options for the feature mode are: monitor_light | monitor | none.

OR

Alternatively, you can use the following curl command:

curl -sL https://ibm.biz/install-sysdig-agent | sudo bash -s -- -a SYSDIG_ACCESS_KEY -c COLLECTOR_ENDPOINT --collector_port 6443 --secure true -ac "feature:n mode: monitor_light"

Where

SYSDIG_ACCESS_KEY is the ingestion key for the instance.

COLLECTOR_ENDPOINT is the ingestion URL for the region where the monitoring instance is available.
4. Restart the agent.

After you complete the previous steps, limited functionality is implemented and you see the reduced pricing on your invoice.





 What's next
Visualizing your virtual data center environment with IBM Cloud Monitoring 

VMware Shared provides an integration with IBM Cloud® Monitoring, which allows you to use a dashboard, provided by VMware Shared to view metrics for your virtual data centers. Alternatively, you can create your own dashboard to visualize performance, volume of usage, and to define alerts to monitor your environment.

Use Monitoring dashboards to complete the following tasks.



* Explore and easily visualize your environment.
* Accelerate a diagnosis and a resolution for performance incidents.
* Control cost of monitoring infrastructure.
* Mitigate impact of abnormal situations with proactive notifications.



For more information about the benefits of using Monitoring, see the Features section in [Monitoring getting started tutorial](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-startedgetting-started-features).



 Provisioning an IBM Cloud Monitoring instance 

Before you can view platform metrics for your virtual data center, you must order a Monitoring instance.

Review the following requirements for your instance order.



* Order the instance with the Graduated Tier plan, not the Lite plan.
* The instance must be within the same region as your virtual data center instance.
* You must enable the automatic collection of platform metrics.



Order the Monitoring instance.



1. From the IBM Cloud for VMware Solutions console, click Resources > VMware Shared from the left navigation pane.
2. In the VMware Shared table, select the instance for which you want to collect platform metrics.
3. From the instance details page, click the Actions menu and click Add monitoring.
4. On the Monitoring provisioning page, complete the steps in [Provisioning an instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision) to order a Monitoring instance and enable the automatic platform metrics collection.







 Viewing platform metrics for your virtual data center 

After you order your Monitoring instance, you can view the platform metrics in the Monitoring console.



1. In the VMware Shared table, select the virtual data center for which you want to view platform metrics.
2.