vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In addition, the Monitoring agent automatically collects the following types of metrics per Kubernetes or Red Hat OpenShift cluster:



* State metrics: Kube state metrics report on the health and state of the various objects that run inside Kubernetes components, such as deployments, nodes and pods. To see the list of metrics that are collected by default, see Kubernetes State.
* Resource usage metrics: Resource usage metrics reports on the health and state of CPU and memory for workers (nodes) and pods that are running in the cluster. The data can be analyzed by namespace, by worker, by pod, by workload object such as deployments, daemonSets, and more.





 Agent for non-orchestrated environments 

By default, this agent collects core infrastructure and network time series that you can use to monitor the host.

For a list of collected metrics, see [Metrics Available for non-orchestrated environments](https://docs.sysdig.com/en/docs/installation/sysdig-agent/agent-configuration/configure-agent-modes/metrics-available-in-monitor-light/).





 Agent for orchestrated environments 

By default, this agent collects the same metrics as the agent for non-orchestrated environments and also Kubernetes state and resource usage metrics.

For a list of collected metrics, see [Metrics Available for orchestrated environments](https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/prometheus-format/).







 Collecting custom metrics by using the Monitoring agent 

The Monitoring agent includes components that collect metrics via Syscall, StatsD, JMX, and Promscrape.



* The agent extracts information directly from the kernel through server system calls. System calls provide information about the processes that are running, memory allocation, network connections, access to the filesystem, resource usage, and more.
* The agent includes a lightweight Prometheus server known as Promscrape. You can configure the agent to collect Prometheus metrics and send them to a Monitoring instance for storage and processing.
Using IBM Metrics Collector for SAP (IMCS) on Linux 

The IBM® Metrics Collector for SAP (IMCS) on Linux® is a requirement by SAP Support for IBM Cloud® Virtual Private Cloud Infrastructure only when SAP workloads are running on the virtual server instance (VSI).

The IMCS collects performance-related data from IBM Cloud® Virtual Servers for Virtual Private Cloud for SAP. The SAP Support team uses the collected metric data to monitor, troubleshoot, and improve performance of business transactions. Use the following information to help with installing, configuring, and troubleshooting the IBM Metrics Collector for SAP on Linux.



 Before you begin 

You need to successfully create an IBM Cloud® Virtual Private Cloud and Virtual Servers for VPC by using the appropriate catalog image for SAP. Check [SAP Note 2927211](https://launchpad.support.sap.com//notes/2927211) to make sure that the selected operating system is supported by SAP. The Metrics Collector runs specifically on Virtual Servers for VPC to gather required SAP metrics. Figure 1 outlines the data sources that are used by IBM Metrics Collector for SAP.

Zoom

![Figure 1. Data sources for IBM Metrics Collector for SAP](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap//images/imcs-data-sources.svg)

Figure 1. Data sources for IBM Metrics Collector for SAP





 Getting an IBM Cloud API key 

You need an IBM Cloud API key for IMCS to successfully collect all required metrics. The API key grants view access to IBM Cloud infrastructure services. You can install IMCS without an API key. However, some metrics are missing and the virtual server is not supported by SAP.

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

You need to create only one Service ID and one API Key per Account.
Securing your data 

To ensure that you can securely manage your data when you use IBM Cloud Metrics Routing, it is important to know exactly what data is stored and encrypted, and how you can delete any stored data.



 What data is stored in IBM Cloud Metrics Routing 

IBM Cloud Metrics Routing stores configuration data only.



* Stores target definitions in the region where the target is defined, and in the primary and backup metadata locations that you configure in the account. For more information, see [targets](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-target).
* Stores route definitions in the primary and backup metadata locations that you configure in the account. For more information, see [routes](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-routes).
* Stores account settings in the primary and backup metadata locations that you configure in the account. For more information, see [settings](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-settings-about).







 How your data is stored and encrypted 



 Configuration data 

You can configure IBM Cloud Metrics Routing resources by using public and private endpoints.

To ensure that you have enhanced control and security over your data, your account must be virtual routing and forwarding (VRF) enabled and you must use private routes to IBM Cloud® service endpoints. You must configure IBM Cloud Metrics Routing resources over a private network connection.

IBM Cloud Metrics Routing stores the configuration of settings, targets and routes for your account.



* Connections use TLS/SSL encryption for data in transit. The current supported version of this encryption is TLS 1.2.
* The storage where the configuration is stored is encrypted with LUKS using AES-256.







 Metrics data 

You can define 1 or more routing rules that define how metrics are routed in the account.



* Metrics data from an IBM Cloud service to your target service in IBM Cloud is secured via private connection.
blacklisted_ports:
- 6666
- 6379
4. Save the changes.



Changes are applied automatically.





 Changing the log configurations 

To configure the log configurations, you must customize the log section in the sysdig-agent-configmap.yaml file.

The monitoring agent generates log entries in /opt/draios/logs/draios.log.



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



The following table lists some common scenarios and the value that you must set in each one of them:



Table 2. Log section entries

 Use cases Log section entry Default Value 

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





 Changing the log level 



* The file_priority in the log section controls the type of log entries written to the file /opt/draios/logs/draios.log.
* The console_priority in the log section controls the type of log entries written to the container console output when running the containerized agent.
* The default log level is info, where a log entry is created for each aggregated metrics transmission to the backend servers, once per second, in addition to entries for any warnings and errors.
* Valid log levels are: none, error, warning, info, debug, trace







 Filtering Kubernetes events by severity 



* The event_priority in the log section controls the type of events that are sent from the agent
* The default log level is information. This means that only information and higher severity events are transmitted.
* Valid levels are: emergency, alert, critical, error, warning, notice, information, debug and none. Note: The values are listed from high priority to low priority.
* Setting the level to none will block all event collection.







 Logging into a file what metrics are included or excluded
kubectl -n schematics-runtime create configmap bnpp-authentication —-from-file 2014-2029 BNPP_Users_Authentication.cer

kubectl -n schematics-runtime create configmap bnpp-infrastructure —-from-file 2014-2029 BNPP_Infrastructure.cer
2. Mount config map file as a volume in a directory /etc/ssl/certs/ as file agent-runtime-deployment-certs.yaml in a shared bnpp_agent_deployment_files directory.



Shared directory bnpp_agent_deployment_files has two yaml files named - agent-runtime-deployment-certs.yaml and - agent-runtime-deployment.yaml.

The agent-runtime-deployment-certs.yaml file updates the certificates and appends the agent-runtime-deployment.yaml file which provides you the desired deployment details to inject the certificates without any additional changes.
* What attributes of Workspaces or Actions are used to dynamically select a target agent for execution

The following attributes of the Schematics Workspace or Schematics Action are used to dynamically select the agent instance.



* Resource group
* Location (region)
* Tags



The [Agent assignment policy](https://cloud.ibm.com/docs/schematics?topic=schematics-policy-manage) for an agent instance describes how an Agent is selected to run a Workspace job or Action job.

Example:

If your organization has three different network isolation zones (such as Dev, HR-Stage, and HR-Prod) and you have installed three agents (one each, for the three network isolation zones). You have defined an agent-assignment-policy for the agent running in Dev, with the selector as tags=dev. All workspaces that have tags=dev automatically are bound to the Dev agent. In other words, the Dev agent is used to download Terraform templates (from the Git repository) and run Terraform jobs. Similarly, the agent-assignment-policy can include other attributes of the workspaces, to define the agent for job execution.
* Official exporters are available in [the official Prometheus GitHub organization](https://github.com/prometheus) and are lable official.
* Sysdig curates and maintains [PromCat](https://promcat.io/). PromCat is an enterprise resource catalog where you can find supported Monitoring integrations for Kubernetes platforms and cloud-native services.



You can collect metrics from different sources such as:



* Hosts for which a Monitoring agent is not available such as Windows systems or VMware ESXi-Host systems.
* Hosts for which a Monitoring agent is available, but you need to collect other types of metrics such as IPMI sensor metrics or hardware and kernel-relaed metrics.
* Services like MySQL database



Zoom

![Prometheus integration with Monitoring](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring//exporters/images/prometheus.svg)

Figure 1. Prometheus integration with Monitoring

For more information, see [Collecting metrics by using Prometheus exporters](https://cloud.ibm.com/docs/monitoring?topic=monitoring-prometheus-exporters).





 Collecting Platform metrics from IBM Cloud services 

Platform metrics are metrics that are exposed by enabled-monitoring services and the platform in IBM Cloud.

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

To monitor platform metrics for a service instance, provision the IBM Cloud Monitoring instance in the same region where the IBM Cloud service instance that you want to monitor is provisioned.

For more information, see [Working with platform metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_working).
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 

After you provision your monitoring agent and enable 'no driver mode', you need to configure a monitoring agent in each environment that you want to monitor. For more information about configuring a monitoring agent, see [Configuring a monitoring agent](https://cloud.ibm.com/docs/monitoring?topic=monitoring-config_agent).







 IBM Cloud Monitoring 'no driver mode' metrics 

IBM Cloud Monitoring collects basic virtual server instance metrics such as CPU usage, disk usage, network traffic, and memory. These metrics are stored in IBM Cloud Monitoring. You can access metrics through the prebuilt monitoring dashboard.

Use the following table to see which metrics are available in 'no driver mode'.



Table 1. Monitoring 'no driver mode' metrics

 Name Description 

 cpu.cores.used CPU core usage 
 cpu.cores.used.percent CPU core usage percent for each container 
 cpu.idle.percent Percentage of time that the CPUs were idle and the system had no outstanding disk I/O requests 
 cpu.iowait.percent Percentage of time that the CPUs were idle and the system did an outstanding disk I/O requests 
 cpu.nice.percent Percentage of user level CPU utilization with 'Nice' priority 
 cpu.stolen.percent Percentage of time that a virtual machine CPU is in a state of involuntary wait because the physical CPU is shared among virtual machines. 
 cpu.system.percent Percentage of system level CPU utilization 
 cpu.used.percent Percentage of system level CPU utilization
Updating idle time before worker nodes are removed 

The idle time behavior for Symphony host factory is controlled by three properties that are defined in the symAreq_policy_configuration.json file:



*  billing_interval has a default value of 60, defines what the interval is in minutes where cloud resources are metered. For IBM Cloud, VPC hourly virtual server instances are used.
*  return_interval has a default value of 10, defines the time before it hits the next counter of billing interval where the worker can be released from cluster. The Symphony symA requester constantly monitors the cluster capacity and workload requirements, and if it detects that unnecessary cores are present in the cluster it can release workers from the cluster and adjust the workloads to optimally use the existing compute resources.
*  return_idle_only has a default value of false, and determines that the machines should be returned from the cluster only if they are idle and not busy processing workload.



These three properties can be edited to guarantee the wanted behavior on idle time for worker nodes.

For more information on this file configuration, see [symAreq_policy_config.json reference](https://www.ibm.com/docs/en/spectrum-symphony/7.3.1?topic=reference-symareq-policy-configjson).

The file can be found in: /data/<CLUSTER>/sym731/hostfactory/conf/requestors/symAinst/symAinstreq_policy_config.json. Replace <CLUSTER> value with the name of your cluster. The default value is HPCCluster.

You can make changes to the configuration file and restart the Symphony Host Factory service by using the following commands:

egosh service stop HostFactory

egosh service start HostFactory
You can use public endpoints, private endpoints or both to manage the IBM Cloud Metrics Routing account configuration.

Decide whether public endpoints, private endpoints, or both are allowed to manage the IBM Cloud Metrics Routing account configuration. For more information, see [Enforcing private endpoints to configure IBM Cloud Metrics Routing resources](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpoints-enforce-private).

Configure private endpoints and disable public endpoints when you require to be Financial Services Validated.





 Target locations 

Define the locations where an account administrator can configure targets to collect metrics. You can choose 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).

To enforce target locations in the account, you can configure the account settings and specify the locations that are allowed.

Take into account any corporate or industry compliance requirements such as Financial Services Validated locations, or EU-managed regions.

The location of a target definition must be a supported location where IBM Cloud Metrics Routing is available. The target can configure a resource in the same account where the metrics are located or in a different account. In addition, the resource can be located in any region where that type of resource is supported in IBM Cloud.

For each target that you define in the same account where metrics are generated, you must define a service to service authorization between the IBM Cloud Metrics Routing service and the IBM Cloud Monitoring instance that you configured as your destination in the target. For more information, see [Managing authorizations to grant access between services](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam-service-auth).

For each target that you define in a different account from the one where metrics are generated, you must define a service to service authorization in the account where the target resource is available between the IBM Cloud Metrics Routing service and the IBM Cloud Monitoring instance that you configured as your destination in the target.
Platform metrics for Activity Tracker Event Routing 

You can use the IBM Cloud® Monitoring service to monitor platform metrics that are exposed by Activity Tracker Event Routing. For example, you can use it to monitor how Activity Tracker Event Routing is routing events in each region where you are collection auditing events.

IBM Cloud Monitoring is a cloud-native, and container-intelligence management system that you can include as part of your IBM Cloud architecture. You can use it 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.



 Enabling platform metrics 

Platform metrics are metrics that are exposed by enabled-monitoring services and the platform in IBM Cloud. You can use them to find and take action on configuration problems and possible outages.



* To monitor platform metrics, you must provision a Monitoring instance in the same region where the metrics are exposed.

For example, you can use the IBM Cloud Monitoring service to monitor that events are forwarded to the configured destination.
* You can configure 1 instance only of the IBM Cloud Monitoring service per region to collect platform metrics in that location.

In a region, before you configure a Monitoring instance to collect platform metrics, check with the account or service administrator if another Monitoring instance has already been configured. You may not have permissions to see all Monitoring instances in the region.
* If you have configured Activity Tracker Event Routing in more than one region, you must enable platform metrics for each region.



For more information on how to enable platform metrics, select 1 of the following options:

[![Option 1. UI](https://cloud.ibm.com/docs-content/v1/content/bcd8b79ca2ed73bfcaefb20051f12cb6400286ab/atracker/images/platform_metrics_option_1.svg)](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enablingplatform_metrics_enabling_ui)[![Option 2.
Through the public network, you must use an API endpoint with the following format: https://<region>.metrics_router.cloud.ibm.com





 What data can you configure through the IBM Cloud® Metrics Routing account settings? 

You can define any of the following information:



* The location in your IBM Cloud account where the IBM Cloud Metrics Routing account configuration metadata is stored.

By metadata, we refer to the target/route/settings data that is available across the account in any region.

You can choose 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&interface=cli).

You can choose a location where the data is stored. You can also configure a backup location where the metadata is stored for recovery purposes.

Take into account any corporate or industry compliance requirements such as Financial Services Validated locations, or EU-managed regions.

If you do not configure the primary metadata region, the location of the first target that you configure in the account determines the primary metadata location.
* The type of endpoints that are allowed to manage the IBM Cloud Metrics Routing account configuration in the account.

By default, public and private endpoints are enabled.

You can configure your account to restrict management through private endpoints only.
* The locations where an account administrator can define targets to collect metrics.

You can choose 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&interface=cli).

Take into account any corporate or industry compliance requirements such as Financial Services Validated locations, or EU-managed regions.
* Default target locations, that is, 1 or more targets in the account, that will collect metrics from supported IBM Cloud Metrics Routing locations where you have not configured how you want to collect metrics.
Monitoring an Ubuntu Linux VPC server instance 

Use this tutorial to learn how to configure an Ubuntu host to forward metrics to the IBM Cloud Monitoring service in the IBM Cloud.

These instructions are for Ubuntu systems but can be used for other Linux systems.

To configure an Ubuntu server to forward metrics, you must install a monitoring agent. The agent uses an access key (token) to authenticate with the IBM Cloud Monitoring instance. The monitoring agent acts as a data collector. It automatically collects metrics.

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

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



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



Through the Monitoring UI, you can analyze data in the Advisor tab, the Explore tab, and in the Dashboard tab.