public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 04:28:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #296 from btat/v1-tools

Browse Source 
Remove references to v1 tools
This commit is contained in:
Billy Tat
2022-11-15 17:14:47 -08:00
committed by GitHub
parent 6fc361b469 eeb69cba8a
commit 3597c79a43
11 changed files with 4 additions and 350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md
-129
View File
@@ -1,129 +0,0 @@
---
title: Migrating to Rancher v2.5+ Monitoring
---
If you previously enabled Monitoring, Alerting, or Notifiers in Rancher before v2.5, there is no automatic upgrade path for switching to the new monitoring/alerting solution. Before deploying the new monitoring solution via Cluster Explore, you will need to disable and remove all existing custom alerts, notifiers and monitoring installations for the whole cluster and in all projects.
## Monitoring Before Rancher v2.5
As of v2.2.0, the global view in the legacy Rancher UI allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster.
When Monitoring is enabled, Monitoring V1 deploys [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/docs/grafana/latest/getting-started/what-is-grafana/) onto a cluster to monitor the state of processes of your cluster nodes, Kubernetes components, and software deployments and create custom dashboards to make it easy to visualize collected metrics.
Monitoring V1 could be configured on both a cluster-level and on a project-level and would automatically scrape certain workloads deployed as Apps on the Rancher cluster.
When Alerts or Notifiers are enabled, Alerting V1 deploys [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) and a set of Rancher controllers onto a cluster that allows users to define alerts and configure alert-based notifications via Email, Slack, PagerDuty, etc. Users can choose to create different types of alerts depending on what needs to be monitored (e.g. System Services, Resources, CIS Scans, etc.); however, PromQL Expression-based alerts can only be created if Monitoring V1 is enabled.
## Monitoring and Alerting via Cluster Explorer in Rancher 2.5
As of v2.5.0, Rancher's Cluster Explorer now allows users to enable Monitoring & Alerting V2 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) together within a cluster.
Unlike in Monitoring & Alerting V1, both features are packaged in a single Helm chart found [here](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring). The behavior of this chart and configurable fields closely matches [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack), a Prometheus Community Helm chart, and any deviations from the upstream chart can be found in the [CHANGELOG.md](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/CHANGELOG.md) maintained with the chart.
Monitoring V2 can only be configured on the cluster level. Project-level monitoring and alerting is no longer supported.
For more information on how to configure Monitoring & Alerting V2, see [this page.](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md)
## Changes to Role-based Access Control
Project owners and members no longer get access to Grafana or Prometheus by default. If view-only users had access to Grafana, they would be able to see data from any namespace. For Kiali, any user can edit things they don’t own in any namespace.
For more information about role-based access control in `rancher-monitoring`, refer to [this page.](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md)
## Migrating from Monitoring V1 to Monitoring V2
While there is no automatic migration available, it is possible to manually migrate custom Grafana dashboards and alerts that were created in Monitoring V1 to Monitoring V2.
Before you can install Monitoring V2, Monitoring V1 needs to be uninstalled completely. In order to uninstall Monitoring V1:
* Remove all cluster and project specific alerts and alerts groups.
* Remove all notifiers.
* Disable all project monitoring installations under Cluster -> Project -> Tools -> Monitoring.
* Ensure that all project-monitoring apps in all projects have been removed and are not recreated after a few minutes
* Disable the cluster monitoring installation under Cluster -> Tools -> Monitoring.
* Ensure that the cluster-monitoring app and the monitoring-operator app in the System project have been removed and are not recreated after a few minutes.
#### RKE Template Clusters
To prevent V1 monitoring from being re-enabled, disable monitoring and in future RKE template revisions via modification of the RKE template yaml:
```yaml
enable_cluster_alerting: false
enable_cluster_monitoring: false
```
#### Migrating Grafana Dashboards
You can migrate any dashboard added to Grafana in Monitoring V1 to Monitoring V2. In Monitoring V1 you can export an existing dashboard like this:
* Sign into Grafana
* Navigate to the dashboard you want to export
* Go to the dashboard settings
* Copy the [JSON Model](https://grafana.com/docs/grafana/latest/dashboards/json-model/)
In the JSON Model, change all `datasource` fields from `RANCHER_MONITORING` to `Prometheus`. You can easily do this by replacing all occurrences of `"datasource": "RANCHER_MONITORING"` with `"datasource": "Prometheus"`.
If Grafana is backed by a persistent volume, you can now [import](https://grafana.com/docs/grafana/latest/dashboards/export-import/) this JSON Model into the Monitoring V2 Grafana UI.
It is recommended to provide the dashboard to Grafana with a ConfigMap in the `cattle-dashboards` namespace that has the label `grafana_dashboard: "1"`:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-dashboard
namespace: cattle-dashboards
labels:
grafana_dashboard: "1"
data:
custom-dashboard.json: |
{
...
}
```
Once this ConfigMap is created, the dashboard will automatically be added to Grafana.
### Migrating Alerts
It is only possible to directly migrate expression-based alerts to Monitoring V2. Fortunately, the event-based alerts that could be set up to alert on system component, node or workload events, are already covered out-of-the-box by the alerts that are part of Monitoring V2. So it is not necessary to migrate them.
To migrate the following expression alert
![](/img/monitoring/migration/alert_2.4_to_2.5_source.png)
you have to either create a PrometheusRule configuration like this in any namespace
```yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: custom-rules
namespace: default
spec:
groups:
- name: custom.rules
rules:
- alert: Custom Expression Alert
expr: prometheus_query > 5
for: 5m
labels:
severity: critical
annotations:
summary: "The result of prometheus_query has been larger than 5 for 5m. Current value {{ $value }}"
```
or add the Prometheus Rule through the Cluster Explorer
![](/img/monitoring/migration/alert_2.4_to_2.5_target.png)
For more details on how to configure PrometheusRules in Monitoring V2 see [Monitoring Configuration](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md).
### Migrating Notifiers
There is no direct equivalent for how notifiers work in Monitoring V1. Instead you have to replicate the desired setup with Routes and Receivers in Monitoring V2.
### Migrating for RKE Template Users
If the cluster is managed using an RKE template, you will need to disable monitoring in future RKE template revisions to prevent legacy monitoring from being re-enabled.
docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md
-3
View File
@@ -38,7 +38,6 @@ The following table lists the permissions and actions that a `restricted-admin`
| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
| | Create Projects/namespaces | Yes | No | No | |
| | Add cluster/project members | Yes | No | No | |
| | Deploy MulticlusterApp in local cluster | Yes | No | No | |
| | Global DNS | Yes | No | No | |
| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
| | Save as RKE Template | Yes | No | No | |
@@ -60,8 +59,6 @@ The following table lists the permissions and actions that a `restricted-admin`
| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
| Settings | | | | | |
| | Manage Settings | Yes | No (Can list) | No (Can list) | |
| Apps | | | | | |
| | Launch Multicluster Apps | Yes | Yes | Yes | Not in local cluster |
| User | | | | | |
| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/windows-linux-cluster-feature-parity.md
-4
View File
@@ -22,13 +22,9 @@ Fleet | Supported | Supported
EKS Operator | Supported | Not Supported
AKS Operator | Not Supported | Not Supported
GKE Operator | Not Supported | Not Supported
Alerting v1 | Supported | Supported
Monitoring v1 | Supported | Supported
Logging v1 | Supported | Supported
Monitoring/Alerting v2 | Supported | Supported
Logging v2 | Supported | Supported
Istio | Supported | Not Supported
Catalog v1 | Supported | Not Supported
Catalog v2 | Supported | Not Supported
OPA | Supported | Not Supported
Longhorn | Supported | Not Supported
docs/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md
-188
View File
@@ -1,188 +0,0 @@
---
title: Migrating to Rancher v2.5 Logging
---
Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [logging operator](https://github.com/banzaicloud/logging-operator) from Banzai Cloud has been adopted; Rancher configures this tooling for use when deploying logging.
Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ.
## Installation
To install logging in Rancher v2.5+, refer to the [installation instructions](../../pages-for-subheaders/logging.md#enabling-logging).
### Terminology
In v2.5+, logging configuration in the **Cluster Dashboard**. To configure logging custom resources after the Logging application is installed, go to the left navigation bar and click **Logging**. It is from this menu option that logging for both cluster and namespace is configured.
:::note
Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster.
:::
There are four key concepts to understand for v2.5+ logging:
1. Outputs
`Outputs` are a configuration resource that determine a destination for collected logs. This is where settings for aggregators such as ElasticSearch, Kafka, etc. are stored. `Outputs` are namespaced resources.
2. Flows
`Flows` are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which `Outputs` to send the logs to. `Flows` are namespaced resources, and can connect either to an `Output` in the same namespace, or a `ClusterOutput`.
3. ClusterOutputs
`ClusterOutputs` serve the same functionality as `Outputs`, except they are a cluster-scoped resource. `ClusterOutputs` are necessary when collecting logs cluster-wide, or if you wish to provide an `Output` to all namespaces in your cluster.
4. ClusterFlows
`ClusterFlows` serve the same function as `Flows`, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. `ClusterFlows` are also where mutations and filters are defined, same as `Flows` (in functionality).
## Cluster Logging
To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs.
:::note Important:
`ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace.
:::
In legacy logging, in order to collect logs from across the entire cluster, one only needed to enable cluster-level logging and define the desired `Output`. This basic approach remains in v2.5+ logging. To replicate legacy cluster-level logging, follow these steps:
1. Define a `ClusterOutput` according to the instructions found under [Output Configuration](#output-configuration)
2. Create a `ClusterFlow`, ensuring that it is set to be created in the `cattle-logging-system` namespace
1. Remove all _Include_ and _Exclude_ rules from the `Flow` definition. This ensures that all logs are gathered.
2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
3. Define your cluster `Output` or `Outputs`
This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`.
## Project Logging
Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces.
To collect logs from a specific namespace, follow these steps:
1. Define an `Output` or `ClusterOutput` according to the instructions found under [Output Configuration](#output-configuration)
2. Create a `Flow`, ensuring that it is set to be created in the namespace in which you want to gather logs.
1. If you wish to define _Include_ or _Exclude_ rules, you may do so. Otherwise, removal of all rules will result in all pods in the target namespace having their logs collected.
2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
3. Define your outputs - these can be either `ClusterOutput` or `Output` objects.
This will result in logs from all sources in the namespace (pods) being collected and sent to the `Output` (or `Outputs`) you defined in your `Flow`.
:::note
To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label.
:::
## Output Configuration
In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+.
### Elasticsearch
| Legacy Logging | v2.5+ Logging | Notes |
|-----------------------------------------------|-----------------------------------|-----------------------------------------------------------|
| Endpoint | Target -> Host | Make sure to specify Scheme (https/http), as well as Port |
| X-Pack Security -> Username | Access -> User | |
| X-Pack Security -> Password | Access -> Password | Password must now be stored in a secret |
| SSL Configuration -> Client Private Key | SSL -> Client Key | Key must now be stored in a secret |
| SSL Configuration -> Client Certificate | SSL -> Client Cert | Certificate must now be stored in a secret |
| SSL Configuration -> Client Key Password | SSL -> Client Key Pass | Password must now be stored in a secret |
| SSL Configuration -> Enabled SSL Verification | SSL -> Certificate Authority File | Certificate must now be stored in a secret |
In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the `Output` object by editing as YAML and inputting the following values:
```yaml
...
spec:
elasticsearch:
...
logstash_format: true
logstash_prefix: <desired prefix>
logstash_dateformat: "%Y-%m-%d"
```
Replace `<desired prefix>` with the prefix for the indices that will be created. In legacy logging, this defaulted to the name of the cluster.
### Splunk
| Legacy Logging | v2.5+ Logging | Notes |
|------------------------------------------|----------------------------------------|----------------------------------------------------------------------------------------|
| HEC Configuration -> Endpoint | Target -> Host | Protocol (https/http) and port must be defined separately from the host |
| HEC Configuration -> Token | Access -> Token | Token must now be stored as a secret |
| HEC Configuration -> Index | Edit as YAML -> `index` | `index` field must be added as YAML key under `spec.splunkHec` |
| HEC Configuration -> Source | Edit as YAML -> `source` | `source` field must be added as YAML key under `spec.splunkHec` |
| SSL Configuration -> Client Private Key | Edit as YAML -> `client_key` | `client_key` field must be added as YAML key under `spec.splunkHec`. See (1) |
| SSL Configuration -> Client Certificate | Edit as YAML -> `client_cert` | `client_cert` field must be added as YAML key under `spec.splunkHec`. See (1) |
| SSL Configuration -> Client Key Password | _Not Supported_ | Specifying a password for the client private key is not currently supported. |
| SSL Configuration -> SSL Verify | Edit as YAML -> `ca_file` or `ca_path` | `ca_file` or `ca_path` field must be added as YAML key under `spec.splunkHec`. See (2) |
_(1) `client_key` and `client_cert` values must be paths to the key and cert files, respectively. These files must be mounted into the `rancher-logging-fluentd` pod in order to be used._
_(2) Users can configure either `ca_file` (a path to a PEM-encoded CA certificate) or `ca_path` (a path to a directory containing CA certificates in PEM format). These files must be mounted into the `rancher-logging-fluentd` pod in order to be used._
### Kafka
| Legacy Logging | v2.5+ Logging | Notes |
|-----------------------------------------|----------------------------|------------------------------------------------------|
| Kafka Configuration -> Endpoint Type | - | Zookeeper is no longer supported as an endpoint type |
| Kafka Configuration -> Endpoint | Target -> Brokers | Comma-separated list of brokers (host:port) |
| Kafka Configuration -> Topic | Target -> Default Topic | |
| SSL Configuration -> Client Private Key | SSL -> SSL Client Cert | Certificate must be stored as a secret |
| SSL Configuration -> Client Certificate | SSL -> SSL Client Cert Key | Key must be stored as a secret |
| SSL Configuration -> CA Certificate PEM | SSL -> SSL CA Cert | Certificate must be stored as a secret |
| SASL Configuration -> Username | Access -> Username | Username must be stored in a secret |
| SASL Configuration -> Password | Access -> Password | Password must be stored in a secret |
| SASL Configuration -> Scram Mechanism | Access -> Scram Mechanism | Input mechanism as string, e.g. "sha256" or "sha512" |
### Fluentd
As of v2.5.2, it is only possible to add a single Fluentd server using the "Edit as Form" option. To add multiple servers, edit the `Output` as YAML and input multiple servers.
| Legacy Logging | v2.5+ Logging | Notes |
|------------------------------------------|-----------------------------------------------------|----------------------------------------------------------------------|
| Fluentd Configuration -> Endpoint | Target -> Host, Port | Input the host and port separately |
| Fluentd Configuration -> Shared Key | Access -> Shared Key | Shared key must be stored as a secret |
| Fluentd Configuration -> Username | Access -> Username | Username must be stored as a secret |
| Fluentd Configuration -> Password | Access -> Password | Password must be stored as a secret |
| Fluentd Configuration -> Hostname | Edit as YAML -> `host` | `host` field set as YAML key under `spec.forward.servers[n]` |
| Fluentd Configuration -> Weight | Edit as YAML -> `weight` | `weight` field set as YAML key under `spec.forward.servers[n]` |
| SSL Configuration -> Use TLS | - | Do not need to explicitly enable. Define client cert fields instead. |
| SSL Configuration -> Client Private Key | Edit as YAML -> `tls_private_key_path` | Field set as YAML key under `spec.forward`. See (1) |
| SSL Configuration -> Client Certificate | Edit as YAML -> `tls_client_cert_path` | Field set as YAML key under `spec.forward`. See (1) |
| SSL Configuration -> Client Key Password | Edit as YAML -> `tls_client_private_key_passphrase` | Field set as YAML key under `spec.forward`. See (1) |
| SSL Configuration -> SSL Verify | Edit as YAML -> `tls_insecure_mode` | Field set as YAML key under `spec.forward`. Default: `false` |
| SSL Configuration -> CA Certificate PEM | Edit as YAML -> `tls_cert_path` | Field set as YAML key under `spec.forward`. See (1) |
| Enable Gzip Compression | - | No longer supported in v2.5+ logging |
_(1) These values are to be specified as paths to files. Those files must be mounted into the `rancher-logging-fluentd` pod in order to be used._
### Syslog
As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging.
## Custom Log Fields
In order to add custom log fields, you will need to add the following YAML to your `Flow` configuration:
```yaml
...
spec:
filters:
- record_modifier:
records:
- foo: "bar"
```
(replace `foo: "bar"` with custom log fields you wish to add)
## System Logging
In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways:
1. Gather all cluster logs, not specifying any match or exclusion rules. This results in all container logs from the cluster being collected, which includes system logs.
2. Specifically target system logs by adding match rules for system components. Specific match rules depend on the component being collected.
docs/integrations-in-rancher/monitoring-and-alerting/windows-support.md
-9
View File
@@ -6,13 +6,6 @@ _Available as of v2.5.8_
Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).
## Comparison to Monitoring V1
Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`.
In addition, Monitoring V2 for Windows will no longer require users to keep port 9796 open on Windows hosts since the host metrics will published directly onto a port exposed on the windows-exporter Pod. This feature was powered by recent changes made by `wins` v0.1.0 to support publishing ports exposed on the hostNetwork on Pods that use wins to run a privileged Windows binary as a host process.
## Cluster Requirements
Monitoring V2 for Windows can only scrape metrics from Windows hosts that have a minimum `wins` version of v0.1.0. To be able to fully deploy Monitoring V2 for Windows, all of your hosts must meet this requirement.
@@ -25,8 +18,6 @@ If the cluster was provisioned before Rancher 2.5.8 (even if the current Rancher
To facilitate this upgrade, Rancher 2.5.8 has released a brand new Helm chart called `rancher-wins-upgrader`.
> **Prerequisite:** Make sure Monitoring V1 for Windows is uninstalled.
1. Deploy `rancher-wins-upgrader` with the following override:
```yaml
# Masquerading bootstraps the wins-upgrader installation via
docs/pages-for-subheaders/istio.md
+1 -9
View File
@@ -65,14 +65,6 @@ Refer to the [setup guide](istio-setup-guide.md) for instructions on how to set
To remove Istio components from a cluster, namespace, or workload, refer to the section on [uninstalling Istio.](../integrations-in-rancher/istio/disable-istio.md)
## Migrate From Previous Istio Version
There is no upgrade path for Istio versions less than 1.7.x. To successfully install Istio through **Apps & Marketplace,** you will need to disable your existing Istio from the global view in the legacy Rancher UI.
If you have a significant amount of additional Istio CRDs you might consider manually migrating CRDs that are supported in both versions of Istio. You can do this by running `kubectl get <resource> -n istio-system -o yaml`, save the output yaml and re-apply in the new version.
Another option is to manually uninstall istio resources one at a time, but leave the resources that are supported in both versions of Istio and that will not be installed by the newest version. This method is more likely to result in issues installing the new version, but could be a good option depending on your situation.
## Accessing Visualizations
> By default, only cluster-admins have access to Kiali. For instructions on how to allow admin, edit or views roles to access them, see [this section.](../integrations-in-rancher/istio/rbac-for-istio.md)
@@ -93,7 +85,7 @@ To access the Kiali visualization,
1. In the left navigation bar, click **Istio**.
1. Click **Kiali**. From here you can access the **Traffic Graph** tab or the **Traffic Metrics** tab to see network visualizations and metrics.
By default, all namespace will picked up by prometheus and make data available for Kiali graphs. Refer to [selector/scrape config setup](../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) if you would like to use a different configuration for prometheus data scraping.
By default, all namespace will picked up by prometheus and make data available for Kiali graphs. Refer to [selector/scrape config setup](../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) if you would like to use a different configuration for prometheus data scraping.
Your access to the visualizations depend on your role. Grafana and Prometheus are only available for `cluster-admin` roles. The Kiali UI is available only to `cluster-admin` by default, but `cluster-admin` can allow other roles to access them by editing the Istio values.yaml.
docs/pages-for-subheaders/logging.md
+1 -2
View File
@@ -5,8 +5,7 @@ description: Rancher integrates with popular logging services. Learn the require
The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
For an overview of the changes in v2.5, see [this section.](../integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](../integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md)
For an overview of the changes in v2.5, see [this section.](../integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v2-5)
## Enabling Logging
docs/pages-for-subheaders/monitoring-alerting-guides.md
-1
View File
@@ -8,4 +8,3 @@ title: Monitoring Guides
- [Customizing Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)
- [Persistent Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)
- [Debugging high memory usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
- [Migrating from Monitoring V1 to V2](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md)
docs/pages-for-subheaders/monitoring-and-alerting.md
-1
View File
@@ -60,7 +60,6 @@ For information on configuring access to monitoring, see [this page.](../integra
- [Customizing Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)
- [Persistent Grafana dashboards](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)
- [Debugging high memory usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
- [Migrating from Monitoring V1 to V2](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md)
# Configuration
docs/pages-for-subheaders/monitoring-v2-configuration-guides.md
+2 -2
View File
@@ -10,9 +10,9 @@ For information on configuring custom scrape targets and rules for Prometheus, p
The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)
:::note
:::tip
On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.
On an idle cluster, Monitoring may have high CPU usage. To improve performance, turn off the Prometheus adapter.
:::
sidebars.js
-2
View File
@@ -703,7 +703,6 @@ const sidebars = {
"how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard",
"how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard",
"how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage",
"how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring",
{
type: 'category',
label: 'Prometheus Federator Guides',
@@ -1184,7 +1183,6 @@ const sidebars = {
},
items: [
"integrations-in-rancher/logging/logging-architecture",
"integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging",
"integrations-in-rancher/logging/rbac-for-logging",
"integrations-in-rancher/logging/logging-helm-chart-options",
"integrations-in-rancher/logging/taints-and-tolerations",