vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Note that within one region, only one Log Analysis instance can be enabled for platform logs collection.







 Viewing logs for your Satellite location 

Because the IBM Log Analysis instance is enabled for platform-level log collection, logs for all Log Analysis-integrated services are shown in the Log Analysis dashboard. You can apply filters to view only logs for your Satellite location.



1. In the [Logging dashboard](https://cloud.ibm.com/observe/logging), click Open Dashboard for your Log Analysis instance.
2. In the Filters toolbar, click Sources, select satellite, and click Apply. The logs for all your Satellite locations in the region are shown.
3. To filter for a specific Satellite location, click Apps in the Filters toolbar, select the CRN for your Satellite location, and click Apply. To identify the CRN for your location, get your location ID by running ibmcloud sat location ls, look for this location's ID at the end of the listed CRNs.



For more tips on identifying logs in the dashboard, review how you can [search and filter logs](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logs).





 Analyzing logs for your Satellite location 

Use logs that are automatically generated for your Satellite location to monitor and maintain its health.



 How often are logs posted? 

Logs are collected for your location and posted every 60 seconds.





 What kinds of logs are collected? 

By default, three types of logs are automatically generated for your Satellite location: [R00XX-level error messages](https://cloud.ibm.com/docs/satellite?topic=satellite-healthlogs-error), [the status of whether resource deployment to the location is enabled](https://cloud.ibm.com/docs/satellite?topic=satellite-healthlogs-deploy), and [the status of Satellite Link](https://cloud.ibm.com/docs/satellite?topic=satellite-healthlogs-link). Review the following sections for an example of each log type and descriptions of each log field.





 How can I set up alerts for location error logs?
[ <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. You must set this value to the ingestion endpoint for the region where the Monitoring instance is available.



For Prometheus version 2.26 and later 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"
authorization:
credentials: "<MONITOR_API_TOKEN>"

For example, you can configure the Prometheus server that runs in a Kubernetes cluster in different ways. Depending on how you installed it, you can choose any of the following options to configure the remote write feature in Prometheus to send metrics to an IBM Cloud Monitoring instance:



* Configure a Prometheus server that is managed by Prometheus Operator
* Configure a Prometheus server by using Helm
* Configure a Prometheus server through a Kubernetes ConfigMap For more information, see [Collecting metrics from a Kubernetes cluster by using Prometheus remote write](https://cloud.ibm.com/docs/monitoring?topic=monitoring-prometheus_remote_write).







 Managing metrics 

By default, when you configure your Prometheus server to remote write to a Monitoring instance, all metrics are sent. These metrics are sent and include a remote_write: true label to easily identify them.



 Controling the metrics that are sent
total_compute_cluster_instances Total number of compute cluster instances that you need to provision. A minimum of three nodes and a maximum of 64 nodes are supported. No 3 
 total_storage_cluster_instances Total number of storage cluster instances that you need to provision. A minimum of three nodes and a maximum of 18 nodes are supported if the storage type selected is scratch. A minimum of three nodes and a maximum of 10 nodes are supported if the storage type selected is persistent. No 4 
 vpc_availability_zones IBM Cloud availability zone names within the selected region where the Spectrum Scale cluster should be deployed. For the current release, the solution supports only a single availability zone. For more information, see [Region and data center locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations). Yes None 
 vpc_cidr_block IBM Cloud VPC address prefixes that are needed for VPC creation. Since the solution supports only a single availability zone, provide one CIDR address prefix for VPC creation. For more information, see [Bring your own subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes). No 10.241.0.0/18 
 vpc_compute_cluster_dns_domain IBM Cloud DNS Services domain name to be used for the compute cluster. No compscale.com 
 vpc_compute_cluster_private_subnets_cidr_blocks The CIDR block that's required for the creation of the compute cluster private subnet. Modify the CIDR block if it has already been reserved or used for other applications within the VPC or conflicts with any on-premises CIDR blocks when using a hybrid environment. Provide only one CIDR block for the creation of the compute subnet. No 10.241.0.0/24 
 vpc_region Name of the IBM Cloud region where the resources need to be provisioned (for example, us-east, us-south).
You can configure Prometheus remote write to collect metrics from environments where a Monitoring agent is not available and send them to a Monitoring instance.

You can collect metrics from:



* An existing Prometheus server.
* Ephemeral or batch jobs that may not exist long enough to be scraped by a Monitoring agent.
* Windows hosts and other operating systems where the Monitoring agent is not available
* Non-x86 based architectures, typically seen on IoT environments or Edge computing.
* Non-containerized workloads, such as NGNIX, custom applications, RabbitMQ, and others.



Zoom

![Prometheus remote write option](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring//images/prometheus_rw.svg)

Figure 1. Prometheus remote write

You can monitor the metrics that are collected by using Prometheus remote write through the Monitoring web UI. You can also use PromQL to query the data by using the standard Prometheus query language.

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





 Collecting custom metrics by using Prometheus exporters 

You can use Prometheus exporters to collect metrics from hosts, services, or apps which do not natively expose Prometheus-formatted metrics. You can monitor these metrics through a Monitoring instance.

There are different sources for Prometheus exporters:



* 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:
Working with the Docker agent 

After you provision an instance of the IBM Cloud Monitoring service in the IBM Cloud, you can deploy the Monitoring agent as a Docker container in supported hosts to collect data and metrics automatically. You can configure which metrics to monitor in each environment.

You can associate one or more tags to each monitoring agent. Tags are comma-separated values that are formatted as TAG_NAME:TAG_VALUE. When you monitor your environment, you can use these tags to identify metrics that are available from an agent. For example, you can include information about the service name and location with all of the metrics that are collected by this agent.



 Prereqs 

Check the topic [Tuning Sysdig Agent](https://docs.sysdig.com/en/docs/installation/sysdig-agent/troubleshooting-agent-installation/tuning-sysdig-agent/)





 Deploying a monitoring agent as a Docker container 

When you configure a monitoring agent directly on a Linux host as a standard Docker container, you may need to install external linux headers to launch the monitoring agent correctly.

For example, you might need to run the following command to install external linux headers:

apt-get -y install linux-headers-$(uname -r)

Notice that when you use a MacOS with a container that returns ...-linuxkit with the command uname -r, it is most likely not compatible.

Complete the following steps to configure a monitoring agent on a Docker container to collect and forward metrics to an instance of the IBM Cloud Monitoring service:



1. Obtain the access key. For more information, see [Getting the access key through the IBM Cloud UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-access_keyaccess_key_ibm_cloud_ui).
2. Obtain the public or private ingestion URL. For more information, see [collector endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_ingestion).
3. Deploy the monitoring agent.
OpenVPN client and server 2.4.4-r1-6 2.4.6-r3-IKS-8 Updated image for [CVE-2018-0732](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0732) and [CVE-2018-0737](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0737). 







 Change log for worker node fix pack 1.12.2_1528, released 19 November 2018 

The following table shows the changes that are in the worker node fix pack 1.12.2_1528.



Changes since version 1.12.2_1527

 Component Previous Current Description 

 Kernel 4.4.0-137 4.4.0-139 Updated worker node images with kernel update for [CVE-2018-7755](https://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.4.0-139.165/changelog). 







 Change log for 1.12.2_1527, released 7 November 2018 

The following table shows the changes that are in patch 1.12.2_1527.



Changes since version 1.11.3_1533

 Component Previous Current Description 

 Calico configuration N/A N/A Calico calico-* pods in the kube-system namespace now set CPU and memory resource requests for all containers. 
 Cluster DNS provider N/A N/A Kubernetes DNS (KubeDNS) remains the default cluster DNS provider.. 
 Cluster metrics provider N/A N/A Kubernetes Metrics Server replaces Kubernetes Heapster (deprecated since Kubernetes version 1.8) as the cluster metrics provider.
To get the apiserver port, run ibmcloud ks cluster get -c <cluster_name_or_ID> and look for the node port that is listed for the Master URL.<br> * Complete the steps in [Releasing individual IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-ts-app-container-startindividual-ips) to ensure that any pod IP addresses that are incorrectly detected as in use by the Calico IP address manager (IPAM) are released.<br><br><br> 
 Unsupported: CoreDNS federations plug-in CoreDNS version 1.7 and later no longer support the federations plug-in. If you customized your CoreDNS configuration to use this plug-in, you must remove the plug-in and any related configurations before updating. For more information about updating your CoreDNS configuration, see [Customizing the cluster DNS provider](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dnsdns_customize). 
 Unsupported: Select CoreDNS metrics CoreDNS version 1.7 and later [metrics changed](https://coredns.io/2020/06/15/coredns-1.7.0-release/metric-changes). If you rely on these changed metrics, update accordingly. For example, you might update a Prometheus query of CoreDNS metrics to handle both the old and new metrics. 
 Unsupported: Select Kubernetes API server metrics The following Kubernetes API service metric label names for kubernetes_build_info changed. These metrics, available via the /metrics endpoint, changed as follows. If you rely on these changed metrics, update accordingly.<br><br><br><br> * From gitVersion to git_version<br> * From gitCommit to git_commit<br> * From gitTreeState to git_tree_state<br> * From buildDate to build_date<br> * From goVersion to go_version.<br><br><br>
Monitoring Block Storage for VPC health states, volume status, and metrics 

By using the UI, CLI, or API, you can check on the status and health states of your Block Storage for VPC volumes. You can also view the cumulative number of read and write operations for a specific volume that is attached to a virtual server instance.



 Monitoring Block Storage for VPC performance 

You can monitor certain Block Storage for VPC volume performance from the VPC virtual server instance metrics. These metrics include:



* Cumulative number of [bytes read for a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-monitoring-metricsbytes-read-for-volume-gen2) since the virtual server instance was started.
* Cumulative number of [bytes written for a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-monitoring-metricsbytes-written-for-volume-gen2) since the virtual server instance was started.



To see these metrics in the UI, do the following.



1. In the [IBM Cloud console)](https://cloud.ibm.com/login), go to VPC Infrastructure > Compute > Virtual server instances.
2. Click the instance name to go to the instance details.
3. Click the Monitoring tab and scroll to the Volume metrics.
4. Select a volume. The read and write metrics are displayed. Figure 1 shows this view.



Zoom

![Figure showing volume metrics.](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/volume-read-write-metrics.png)

Figure 1. Read/write metrics for Block Storage for VPC volumes.





 Block storage volume status 

The following table shows statuses that you might see when you create, view, or manage your Block Storage for VPC volumes, and the associated health state.



Table 1.
Log in to your cluster using the CLI and run the Public Endpoint curl command to install the agents, if necessary.





 Step three: Configure the TLS secret 

Configuring Sysdig created the ibm-observe namespace in your Kubernetes cluster. You will repeat this configuration for Prometheus by editing the associated daemonset and configmap. First, store the downloaded TLS certs in a Kubernetes secret by logging into the cluster (via the CLI) and running the following commands.

Create a TLS secret in the ibm-observe namespace by running the following command, where <cert-path> and <key-path> are the paths to the certs you downloaded to your local file system. Be sure to keep a record of the <secret-name> that you use:

kubectl create secret tls <secret-name> --cert=<cert-path> --key=<key-path> -n ibm-observe

If you are setting up Prometheus metrics for components from multiple CAs, run the previous command for each set of generated certificates, making sure to give them each a unique <secret-name>.

Next, get the current daemonset by running:

kubectl get daemonset sysdig-agent -o yaml > dm-sysdig-agent.yaml -n ibm-observe

Edit the daemonset by locating spec.template.spec.containers.volumeMounts and adding the following section:

- mountPath: /<directory-path>
name: <volume-name>

For example:

- mountPath: /ibp
name: ibp-volume

If you set up multiple secrets, you should add as many volumeMounts as there are secrets, making sure to specify a unique directory-path and volume-name for each one.

Next, edit the daemonset by locating spec.template.spec.containers.volumes and adding the following section:

- name: <volume-name>
secret:
defaultMode: 420
secretName: <secret-name>

For example:

- name: ibp-volume
secret:
defaultMode: 420
Monitoring a Windows environment 

The standard monitoring agent cannot be installed on a Windows platform. In order to monitor a Windows system with IBM Cloud Monitoring, you can leverage the [Prometheus Windows Exporter](https://promcat.io/apps/windows) to perform the collection of the metrics on the system.

Once the metrics are collected you have two options for publishing the metrics, remotely scraping the metrics with a Linux monitoring agent,or pushing from a local instance of Prometheus using remote write. Step 3 will cover these two options, but step 1 and 2 are the same regardless of how the metrics are sent.

Complete the following steps to configure the following Windows images to send metrics to a monitoring instance:



* Windows Server 2019 Standard Edition (64 bit)
* Windows Server 2016 Standard Edition (64 bit)





 Step 1: Configure the Prometheus Windows exporter 

Configure the [Prometheus windows_exporter](https://github.com/prometheus-community/windows_exporter) to collect Windows system metrics.

The Prometheus Windows exporter runs as a Windows service. You configure the metrics that you want to monitor by enabling collectors.

The following collectors are supported:



Table 1. Collectors

 Collector name Information about metrics collected per collector 

 cpu [CPU metrics](https://github.com/prometheus-community/windows_exporter/blob/master/docs/collector.cpu.md) 
 cs [Computer system metrics](https://github.com/prometheus-community/windows_exporter/blob/master/docs/collector.cs.md) 
 logical_disk [Disk metrics](https://github.com/prometheus-community/windows_exporter/blob/master/docs/collector.logical_disk.md) 
 os [Operating System metrics](https://github.com/prometheus-community/windows_exporter/blob/master/docs/collector.os.md)
Understanding high availability for IBM Cloud Metrics Routing 

IBM Cloud® Metrics Routing is a highly available, multi-tenant, platform service. In this topic, you can learn more about IBM Cloud Metrics Routing's availability strategy.

High availability(HA) is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure. The main purpose of high availability is to eliminate potential points of failures in an IT infrastructure.



 Responsibilities 

For more information about your responsibilities when using IBM Cloud Metrics Routing, see [Shared responsibilities for IBM Cloud Metrics Routing](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-shared-responsibilities).





 Availability zones 

IBM Cloud Metrics Routing is available in multiple regions. For more information on the regions where IBM Cloud Metrics Routing is available, see [Regions](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-regions).



* Each region has three different data centers for redundancy configured in active/active mode.
* If all the data centers in a location fail, IBM Cloud Metrics Routing becomes unavailable in that location.
* In each supported region, traffic is load balanced across infrastructure in multiple availability zones, with no single point of failure.



For more information about service availability, see [Service Level Agreements (SLAs)](https://cloud.ibm.com/docs/overview?topic=overview-slas).

The following table lists the high-availability (HA) status for the regions (locations) where the IBM Cloud Activity Tracker service is available:



Table 1. List of locations where the service is available.

 Geography Region EU-Supported HA Status 

 North America Dallas (us-south) N/A MZR 
 North America Washington DC (us-east) N/A MZR 
 Europe Frankfurt (eu-de) !
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).

For example, you can configure a Monitoring agent to collect metrics from a Kubernetes cluster. You use the access key to configure the agent that is responsible for collecting and forwarding metric data to your instance. After the agent is deployed, collection and forwarding of metrics to the Monitoring instance is automatic. The Monitoring agent automatically collects and reports on pre-defined metrics. You can configure which metrics to monitor in an environment.
* You can enable platform metrics to monitor IBM Cloud services. You can only configure 1 Monitoring instance per region to collect automatically platform metrics. [Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enabling).







 Collecting metrics 

You can collect metrics from a number of platforms, orchestrators, and a wide range of applications such as Prometheus, JMX, StatsD, Kubernetes, and other application stacks, that are available in the IBM Cloud®, outside the IBM Cloud, or on-prem. You can also add more metrics by creating custom metrics and adding integrations. For more information, see [Collecting metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-about-collect-metrics).





 Sending metrics 

You can send metrics via the public or the private endpoints by using the appropriate ingestion URL. Details can be found in the [endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints) section.





 Viewing metrics
About endpoints 

You can configure your account to manage private and public endpoints by using the IBM Cloud Metrics Routing CLI, the IBM Cloud Metrics Routing REST API, and Terraform scripts.

You can view the type of endpoints that are available in the account to manage IBM Cloud Metrics Routing by using the [settings API](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-settings).



  Private endpoints 

By default, private endpoints are enabled.



*  You cannot disable private endpoints.
*  The private endpoint format is https://private.<region>.metrics-router.cloud.ibm.com/api/v3.
*  For more information about the list of ENDPOINTS that is available, see [Private endpoints](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpointsendpoints_api-private).



To manage IBM Cloud Metrics Routing in your account by using private endpoints only, see [Enforcing private endpoints to configure IBM Cloud Metrics Routing resources](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpoints-enforce-private&interface=cli).





  Public endpoints 

By default, public endpoints are enabled.

You can disable the use of public endpoints to manage IBM Cloud Metrics Routing in your account by using private or public endpoints.

After public endpoints are disabled, you can enable public endpoints only by using the private endpoints.

The public endpoint format is https://<region>.metrics-router.cloud.ibm.com/api/v3.

For more information about the list of ENDPOINTS that is available, see [Public endpoints](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpointsendpoints_api-public).