Skip to content

Commit 82fc7e2

Browse files
authoredNov 28, 2024
[bitnami/*] docs: 📝 Add "Prometheus metrics" (batch 3) (#30666)
* [bitnami/*] docs: 📝 Add "Prometheus metrics" (batch 3) Signed-off-by: Javier J. Salmerón García <javier.salmeron@broadcom.com> * docs: 🚨 Add extra newline Signed-off-by: Javier J. Salmerón García <javier.salmeron@broadcom.com> * docs: 📝 Apply requested changes Signed-off-by: Javier J. Salmerón García <javier.salmeron@broadcom.com> --------- Signed-off-by: Javier J. Salmerón García <javier.salmeron@broadcom.com>
1 parent 50e0570 commit 82fc7e2

File tree

11 files changed

+292
-92
lines changed

11 files changed

+292
-92
lines changed
 

‎bitnami/influxdb/README.md

+18
Original file line numberDiff line numberDiff line change
@@ -51,6 +51,24 @@ Bitnami charts allow setting resource requests and limits for all containers ins
5151

5252
To make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcePreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
5353

54+
### Prometheus metrics
55+
56+
This chart can be integrated with Prometheus by setting `metrics.enabled` to `true`. This will expose the InfluxDB native Prometheus endpoint. Additionally, it will deploy a `metrics` service, which can be configured under the `metrics.service` section. This `metrics` service will have the necessary annotations to be automatically scraped by Prometheus.
57+
58+
#### Prometheus requirements
59+
60+
It is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the [Bitnami Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/prometheus) or the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) to easily have a working Prometheus in your cluster.
61+
62+
#### Integration with Prometheus Operator
63+
64+
The chart can deploy `ServiceMonitor` objects for integration with Prometheus Operator installations. To do so, set the value `metrics.serviceMonitor.enabled=true`. Ensure that the Prometheus Operator `CustomResourceDefinitions` are installed in the cluster or it will fail with the following error:
65+
66+
```text
67+
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
68+
```
69+
70+
Install the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) for having the necessary CRDs and the Prometheus Operator.
71+
5472
### [Rolling VS Immutable tags](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html)
5573

5674
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

‎bitnami/janusgraph/README.md

+110-92
Original file line numberDiff line numberDiff line change
@@ -51,6 +51,115 @@ helm delete my-release
5151

5252
The command removes all the Kubernetes components associated with the chart and deletes the release.
5353

54+
## Configuration and installation details
55+
56+
### [Rolling VS Immutable tags](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html)
57+
58+
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
59+
60+
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
61+
62+
### Prometheus metrics
63+
64+
This chart can be integrated with Prometheus by setting `metrics.enabled` to `true`. This will deploy a sidecar container with [jmx_exporter](https://github.com/prometheus/jmx_exporter) in all pods and a `metrics` service, which can be configured under the `metrics.service` section. This `metrics` service will have the necessary annotations to be automatically scraped by Prometheus.
65+
66+
#### Prometheus requirements
67+
68+
It is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the [Bitnami Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/prometheus) or the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) to easily have a working Prometheus in your cluster.
69+
70+
#### Integration with Prometheus Operator
71+
72+
The chart can deploy `ServiceMonitor` objects for integration with Prometheus Operator installations. To do so, set the value `metrics.serviceMonitor.enabled=true`. Ensure that the Prometheus Operator `CustomResourceDefinitions` are installed in the cluster or it will fail with the following error:
73+
74+
```text
75+
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
76+
```
77+
78+
Install the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) for having the necessary CRDs and the Prometheus Operator.
79+
80+
### External storage backend support
81+
82+
You may want to have JanusGraph connect to an external storage backend rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`storageBackend.external` parameter](#parameters). You should also disable the Cassandra installation with the `storageBackend.cassandra.enabled` option. Here is an example:
83+
84+
```console
85+
storageBackend.cassandra.enabled=false
86+
storageBackend.external.backend=<your_backend_type>
87+
storageBackend.external.hostname=<your_backend_host>
88+
storageBackend.external.port=<your_backend_port>
89+
#Auth only if needed#
90+
storageBackend.external.username=<your_backend_username>
91+
storageBackend.external.existingSecret=<secret_containing_the_password>
92+
storageBackend.external.existingSecretPasswordKey=<secret_key_containing_the_password>
93+
```
94+
95+
### External indexing backend support
96+
97+
You may want to have JanusGraph connect to an external indexing backend. To achieve this, the chart allows you to specify credentials for an external indexing backend with the [`indexBackend.external` parameter](#parameters). Here is an example:
98+
99+
```console
100+
indexBackend.external.backend=<your_backend_type>
101+
indexBackend.external.hostname=<your_backend_host>
102+
indexBackend.external.port=<your_backend_port>
103+
```
104+
105+
### Additional environment variables
106+
107+
In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property.
108+
109+
```yaml
110+
extraEnvVars:
111+
- name: LOG_LEVEL
112+
value: error
113+
```
114+
115+
Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values.
116+
117+
### Sidecars
118+
119+
If additional containers are needed in the same pod as JanusGraph (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter.
120+
121+
```yaml
122+
sidecars:
123+
- name: your-image-name
124+
image: your-image
125+
imagePullPolicy: Always
126+
ports:
127+
- name: portname
128+
containerPort: 1234
129+
```
130+
131+
If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter (where available), as shown in the example below:
132+
133+
```yaml
134+
service:
135+
extraPorts:
136+
- name: extraPort
137+
port: 11311
138+
targetPort: 11311
139+
```
140+
141+
> NOTE: This Helm chart already includes sidecar containers for the Prometheus exporters (where applicable). These can be activated by adding the `--enable-metrics=true` parameter at deployment time. The `sidecars` parameter should therefore only be used for any extra sidecar containers.
142+
143+
If additional init containers are needed in the same pod, they can be defined using the `initContainers` parameter. Here is an example:
144+
145+
```yaml
146+
initContainers:
147+
- name: your-image-name
148+
image: your-image
149+
imagePullPolicy: Always
150+
ports:
151+
- name: portname
152+
containerPort: 1234
153+
```
154+
155+
Learn more about [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/) and [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
156+
157+
### Pod affinity
158+
159+
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
160+
161+
As an alternative, use one of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters.
162+
54163
## Parameters
55164

56165
### Global parameters
@@ -230,7 +339,7 @@ The command removes all the Kubernetes components associated with the chart and
230339
| `persistence.dataSource` | Custom PVC data source | `{}` |
231340
| `persistence.resourcePolicy` | Setting it to "keep" to avoid removing PVCs during a helm delete operation. Leaving it empty will delete PVCs after the chart deleted | `""` |
232341

233-
### Prometheus metrics
342+
### Prometheus Metrics Parameters
234343

235344
| Name | Description | Value |
236345
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
@@ -342,97 +451,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/janus
342451
> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.
343452
> **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/blob/main/template/janusgraph/values.yaml)
344453

345-
## Configuration and installation details
346-
347-
### [Rolling VS Immutable tags](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html)
348-
349-
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
350-
351-
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
352-
353-
### External storage backend support
354-
355-
You may want to have JanusGraph connect to an external storage backend rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`storageBackend.external` parameter](#parameters). You should also disable the Cassandra installation with the `storageBackend.cassandra.enabled` option. Here is an example:
356-
357-
```console
358-
storageBackend.cassandra.enabled=false
359-
storageBackend.external.backend=<your_backend_type>
360-
storageBackend.external.hostname=<your_backend_host>
361-
storageBackend.external.port=<your_backend_port>
362-
#Auth only if needed#
363-
storageBackend.external.username=<your_backend_username>
364-
storageBackend.external.existingSecret=<secret_containing_the_password>
365-
storageBackend.external.existingSecretPasswordKey=<secret_key_containing_the_password>
366-
```
367-
368-
### External indexing backend support
369-
370-
You may want to have JanusGraph connect to an external indexing backend. To achieve this, the chart allows you to specify credentials for an external indexing backend with the [`indexBackend.external` parameter](#parameters). Here is an example:
371-
372-
```console
373-
indexBackend.external.backend=<your_backend_type>
374-
indexBackend.external.hostname=<your_backend_host>
375-
indexBackend.external.port=<your_backend_port>
376-
```
377-
378-
### Additional environment variables
379-
380-
In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property.
381-
382-
```yaml
383-
extraEnvVars:
384-
- name: LOG_LEVEL
385-
value: error
386-
```
387-
388-
Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values.
389-
390-
### Sidecars
391-
392-
If additional containers are needed in the same pod as JanusGraph (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter.
393-
394-
```yaml
395-
sidecars:
396-
- name: your-image-name
397-
image: your-image
398-
imagePullPolicy: Always
399-
ports:
400-
- name: portname
401-
containerPort: 1234
402-
```
403-
404-
If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter (where available), as shown in the example below:
405-
406-
```yaml
407-
service:
408-
extraPorts:
409-
- name: extraPort
410-
port: 11311
411-
targetPort: 11311
412-
```
413-
414-
> NOTE: This Helm chart already includes sidecar containers for the Prometheus exporters (where applicable). These can be activated by adding the `--enable-metrics=true` parameter at deployment time. The `sidecars` parameter should therefore only be used for any extra sidecar containers.
415-
416-
If additional init containers are needed in the same pod, they can be defined using the `initContainers` parameter. Here is an example:
417-
418-
```yaml
419-
initContainers:
420-
- name: your-image-name
421-
image: your-image
422-
imagePullPolicy: Always
423-
ports:
424-
- name: portname
425-
containerPort: 1234
426-
```
427-
428-
Learn more about [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/) and [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
429-
430-
### Pod affinity
431-
432-
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
433-
434-
As an alternative, use one of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters.
435-
436454
## Troubleshooting
437455

438456
Find more information about how to deal with common errors related to Bitnami's Helm charts in [this troubleshooting guide](https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues).

‎bitnami/jupyterhub/README.md

+18
Original file line numberDiff line numberDiff line change
@@ -164,6 +164,24 @@ After accessing the hub and creating a Single User instance, the deployment look
164164

165165
For more information, check the official [JupyterHub documentation](https://github.com/jupyterhub/jupyterhub).
166166

167+
### Prometheus metrics
168+
169+
This chart can be integrated with Prometheus by setting `*.metrics.enabled` (under the `hub` and `proxy` sections) to `true`. This will expose the JupyterHub native Prometheus ports in the containers, as well as a `metrics` service. This `metrics` service will have the necessary annotations to be automatically scraped by Prometheus.
170+
171+
#### Prometheus requirements
172+
173+
It is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the [Bitnami Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/prometheus) or the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) to easily have a working Prometheus in your cluster.
174+
175+
#### Integration with Prometheus Operator
176+
177+
The chart can deploy `ServiceMonitor` objects for integration with Prometheus Operator installations. To do so, set the value `*.metrics.serviceMonitor.enabled=true` (under the `hub` and `proxy` sections). Ensure that the Prometheus Operator `CustomResourceDefinitions` are installed in the cluster or it will fail with the following error:
178+
179+
```text
180+
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
181+
```
182+
183+
Install the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) for having the necessary CRDs and the Prometheus Operator.
184+
167185
### [Rolling vs Immutable tags](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html)
168186

169187
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

‎bitnami/kafka/README.md

+18
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,24 @@ Bitnami charts allow setting resource requests and limits for all containers ins
5050

5151
To make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcePreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
5252

53+
### Prometheus metrics
54+
55+
This chart can be integrated with Prometheus by setting `metrics.jmx.enabled` to `true`. This will deploy a sidecar container with [jmx_exporter](https://github.com/prometheus/jmx_exporter) in all pods and a `metrics` service, which can be configured under the `metrics.service` section. This `metrics` service will have the necessary annotations to be automatically scraped by Prometheus.
56+
57+
#### Prometheus requirements
58+
59+
It is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the [Bitnami Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/prometheus) or the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) to easily have a working Prometheus in your cluster.
60+
61+
#### Integration with Prometheus Operator
62+
63+
The chart can deploy `ServiceMonitor` objects for integration with Prometheus Operator installations. To do so, set the value `metrics.serviceMonitor.enabled=true`. Ensure that the Prometheus Operator `CustomResourceDefinitions` are installed in the cluster or it will fail with the following error:
64+
65+
```text
66+
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
67+
```
68+
69+
Install the [Bitnami Kube Prometheus helm chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) for having the necessary CRDs and the Prometheus Operator.
70+
5371
### [Rolling VS Immutable tags](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html)
5472

5573
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

0 commit comments

Comments
 (0)
Please sign in to comment.