[camel-k] 03/04: chore(doc): Polish monitoring.adoc

[as...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

astefanutti pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel-k.git

commit 98b48d3717abefbd7c422b4bac0a33d27c3d3217
Author: Antonin Stefanutti <an...@stefanutti.fr>
AuthorDate: Mon Jul 20 15:36:07 2020 +0200

    chore(doc): Polish monitoring.adoc
---
 .../ROOT/pages/observability/monitoring.adoc       | 45 +++++++++++++---------
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/docs/modules/ROOT/pages/observability/monitoring.adoc b/docs/modules/ROOT/pages/observability/monitoring.adoc
index af8ef92..bff3d57 100644
--- a/docs/modules/ROOT/pages/observability/monitoring.adoc
+++ b/docs/modules/ROOT/pages/observability/monitoring.adoc
@@ -15,15 +15,17 @@ To take fully advantage of the Camel K monitoring capabilities, it is recommende
 
 You can deploy the Prometheus operator by running:
 
-```sh
+[source,sh]
+----
 $ kubectl apply -f https://raw.githubusercontent.com/coreos/prometheus-operator/v0.38.0/bundle.yaml
-```
+----
 
 WARNING: Beware this installs the operator in the `default` namespace. You must download the file locally and replace the `namespace` fields to deploy the resources into another namespace.
 
 Then, you can create a `Prometheus` resource, that the operator will use as configuration to deploy a managed Prometheus instance:
 
-```sh
+[source,sh]
+----
 $ cat <<EOF | kubectl apply -f -
 apiVersion: monitoring.coreos.com/v1
 kind: Prometheus
@@ -35,7 +37,7 @@ spec:
       - key: camel.apache.org/integration
         operator: Exists
 EOF
-```
+----
 
 By default, the Prometheus instance discovers applications to be monitored in the same namespace.
 You can use the `serviceMonitorNamespaceSelector` field from the `Prometheus` resource to enable cross-namespace monitoring.
@@ -83,15 +85,17 @@ The xref:traits:prometheus.adoc[Prometheus trait] automates the configuration of
 
 The Prometheus trait can be enabled when running an integration, e.g.:
 
-```sh
+[source,sh]
+----
 $ kamel run -t prometheus.enabled=true ...
-```
+----
 
 Alternatively, the Prometheus trait can be enabled globally once, by updating the integration platform, e.g.:
 
-```sh
+[source,sh]
+----
 $ kubectl patch ip camel-k --type=merge -p '{"spec":{"traits":{"prometheus":{"configuration":{"enabled":"true"}}}}}'
-```
+----
 
 The underlying instrumentation mechanism depends on the configured integration runtime.
 As a result, the set of registered metrics, as well as the naming convention they follow, also depends on it.
@@ -102,9 +106,10 @@ When the default, a.k.a. _main_, runtime is configured for the integration, the
 
 A custom configuration for the JMX exporter can be used by setting the `prometheus.configmap` parameter from the Prometheus trait with the name of a ConfigMap containing a `prometheus-jmx-exporter.yaml` key, e.g.:
 
-```sh
+[source,sh]
+----
 $ kamel run -t prometheus.enabled=true -t prometheus.configmap=<jmx_exporter_config>...
-```
+----
 
 Otherwise, the Prometheus trait uses a default configuration.
 
@@ -131,15 +136,17 @@ The Prometheus trait automatically configures the resources necessary for the Pr
 By default, the Prometheus trait creates a `ServiceMonitor` resource, with the `camel.apache.org/integration` label, which must match the `serviceMonitorSelector` field from the `Prometheus` resource.
 Additional labels can be specified with the `service-monitor-labels` parameter from the Prometheus trait, e.g.:
 
-```sh
+[source,sh]
+----
 $ kamel run -t prometheus.service-monitor-labels="label_to_be_match_by=prometheus_selector" ...
-```
+----
 
 The creation of the `ServiceMonitor` resource can be disabled using the `service-monitor` parameter, e.g.:
 
-```sh
+[source,sh]
+----
 $ kamel run -t prometheus.service-monitor=false ...
-```
+----
 
 More information can be found in the xref:traits:prometheus.adoc[Prometheus trait] documentation.
 
@@ -153,7 +160,8 @@ The Prometheus Operator declares the `AlertManager` resource that can be used to
 
 Assuming an `AlertManager` resource already exists in your cluster, you can register a `PrometheusRule` resource that is used by Prometheus to trigger alerts, e.g.:
 
-```sh
+[source,sh]
+----
 $ cat <<EOF | kubectl apply -f -
 apiVersion: monitoring.coreos.com/v1
 kind: PrometheusRule
@@ -169,7 +177,7 @@ spec:
     - alert: CamelKAlert
       expr: application_camel_context_exchanges_failed_total > 0
 EOF
-```
+----
 
 More information can be found in the Prometheus Operator https://github.com/coreos/prometheus-operator/blob/v0.38.0/Documentation/user-guides/alerting.md[Alerting] user guide. You can also find more details in https://docs.openshift.com/container-platform/4.4/monitoring/monitoring-your-own-services.html#creating-alerting-rules_monitoring-your-own-services[Creating alerting rules] from the OpenShift documentation.
 
@@ -180,7 +188,8 @@ If you have an OpenShift cluster, you can follow https://docs.openshift.com/cont
 
 Assuming you have the Prometheus adapter up and running, you can create a `HorizontalPodAutoscaler` resource, e.g.:
 
-```sh
+[source,sh]
+----
 $ cat <<EOF | kubectl apply -f -
 apiVersion: autoscaling/v2beta2
 kind: HorizontalPodAutoscaler
@@ -202,6 +211,6 @@ spec:
         type: AverageValue
         averageValue: 1k
 EOF
-```
+----
 
 More information can be found in https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Horizontal Pod Autoscaler] from the Kubernetes documentation.