mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
correcting capitalization: helm > Helm (#1018)
This commit is contained in:
+2
-2
@@ -66,7 +66,7 @@ In general, you want to scrape data from all the workloads running in your clust
|
||||
|
||||
### About Prometheus Exporters
|
||||
|
||||
A lot of 3rd party workloads like databases, queues or web-servers either already support exposing metrics in a Prometheus format, or there are so called exporters available that translate between the tool's metrics and the format that Prometheus understands. Usually you can add these exporters as additional sidecar containers to the workload's Pods. A lot of helm charts already include options to deploy the correct exporter. Additionally you can find a curated list of exports by SysDig on [promcat.io](https://promcat.io/) and on [ExporterHub](https://exporterhub.io/).
|
||||
Many 3rd party workloads, such as databases, queues, and web-servers, already support exposing metrics in a Prometheus format, or offer exporters that translate between the tool's metrics and a format that Prometheus understands. You can usually add these exporters as additional sidecar containers to the workload's Pods. Many Helm charts already include options to deploy the correct exporter. You can find a curated list of exports by SysDig on [promcat.io](https://promcat.io/) and on [ExporterHub](https://exporterhub.io/).
|
||||
|
||||
### Prometheus support in Programming Languages and Frameworks
|
||||
|
||||
@@ -74,7 +74,7 @@ To get your own custom application metrics into Prometheus, you have to collect
|
||||
|
||||
### ServiceMonitors and PodMonitors
|
||||
|
||||
Once all your workloads expose metrics in a Prometheus format, you have to configure Prometheus to scrape it. Under the hood Rancher is using the [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator). This makes it easy to add additional scraping targets with ServiceMonitors and PodMonitors. A lot of helm charts already include an option to create these monitors directly. You can also find more information in the Rancher documentation.
|
||||
Once all your workloads expose metrics in a Prometheus format, you have to configure Prometheus to scrape it. Under the hood Rancher is using the [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator). This makes it easy to add additional scraping targets with ServiceMonitors and PodMonitors. Many Helm charts let you create these monitors directly. You can also find more information in the Rancher documentation.
|
||||
|
||||
### Prometheus Push Gateway
|
||||
|
||||
|
||||
+3
-5
@@ -49,13 +49,11 @@ An example of where this might be used is with Istio. For more information, see
|
||||
|
||||
## Configuring Applications Packaged within Monitoring v2
|
||||
|
||||
We deploy kube-state-metrics and node-exporter with monitoring v2. Node exporter are deployed as DaemonSets. In the monitoring v2 helm chart, in the values.yaml, each of the things are deployed as sub charts.
|
||||
We deploy kube-state-metrics and node-exporter with monitoring v2. The node exporters are deployed as DaemonSets. Each of these entities are deployed as sub-charts through the monitoring v2 Helm chart, values.yaml.
|
||||
|
||||
We also deploy grafana which is not managed by prometheus.
|
||||
We also deploy Grafana, which is not managed by Prometheus.
|
||||
|
||||
If you look at what the helm chart is doing like in kube-state-metrics, there are plenty more values that you can set that aren’t exposed in the top level chart.
|
||||
|
||||
But in the top level chart you can add values that override values that exist in the sub chart.
|
||||
Many values aren’t exposed in the top level chart. However, you can add values to the top level chart to override values that exist in the sub-charts.
|
||||
|
||||
### Increase the Replicas of Alertmanager
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ helm upgrade --reuse-values rancher-webhook rancher-charts/rancher-webhook -n c
|
||||
```
|
||||
**Note:** This temporary workaround may violate an environment's security policy. This workaround also requires that port 9443 is unused on the host network.
|
||||
|
||||
**Note:** Helm uses secrets by default. This is a datatype that some webhook versions validate to store information. In these cases, directly update the deployment with the hostNetwork=true value using kubectl, then run the helm commands listed above to avoid drift between the helm configuration and the actual state in the cluster.
|
||||
**Note:** Helm uses secrets by default. This is a datatype that some webhook versions validate to store information. In these cases, directly update the deployment with the hostNetwork=true value using kubectl, then run the Helm commands listed above to prevent drift between the Helm configuration and the actual state of the cluster.
|
||||
|
||||
### Private GKE Cluster
|
||||
|
||||
|
||||
Reference in New Issue
Block a user