E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (9)
View Page History
...
{section}{column} - pattern: ".*"
{code}
{code}
* Add the following line to *petals-esb.sh*, just before the “_exec_” command at the very end of the script. If necessary, change the version number to match the jar file you downloaded. _8585_ is the port number on which HTTP metrics will be exposed (once gathered by the jmx_exporter), set ist as you see fit.{code}JAVA_OPTS="$JAVA_OPTS -javaagent:${PETALS_LIB_DIR}/jmx_prometheus_javaagent-0.3.1.jar=8585:${PETALS_CONF_DIR}/prometheus-jmx.yaml"{code}
* Run _petals-esb.sh_
* Metrics are available at *[http://localhost:8585/metrics|http://localhost:8484/metrics*]*
* Metrics are available at *[http://localhost:8585/metrics|http://localhost:8484/metrics*]*
...Jmx agent can be configured in its yaml config file.
{note}
Be wary that *Petals ESB anterior to version 5.3.0* exposes MBeans as complex Java types (such as Maps and Lists), which *are not compatible with the jmx agent and will be ignored*. In later versions this was reworked to expose MBeans as standard OpenMBean format (ComplexData and TabularData), which is natively compatible with the agent. It is advised to *upgrade to Petals 5.3.0 (or later) to avoid compatibility issues* and enable all metrics straight out of the box.
{note}
Be wary that *Petals ESB anterior to version 5.3.0* exposes MBeans as complex Java types (such as Maps and Lists), which *are not compatible with the jmx agent and will be ignored*. In later versions this was reworked to expose MBeans as standard OpenMBean format (ComplexData and TabularData), which is natively compatible with the agent. It is advised to *upgrade to Petals 5.3.0 (or later) to avoid compatibility issues* and enable all metrics straight out of the box.
{note}
Note that:
* Only *numeric values* are supported by Prometheus (though string can me interpreted as regexp to extract numeric values)
* Custom and complex objects may not be exported by the exporter, *having ‘\- pattern “.*”’ as only rule will return every metric available\* (useful for testing).
* Petals ESB container MBeans metrics are all typed as Map, so are ignored by the jmx agent (v0.3.1). As is, *you can monitor some components metrics but cannot monitor container metrics with Prometheus.*
* Custom and complex objects may not be exported by the exporter, *having ‘\- pattern “.*”’ as only rule will return every metric available\* (useful for testing).
* Petals ESB container MBeans metrics are all typed as Map, so are ignored by the jmx agent (v0.3.1). As is, *you can monitor some components metrics but cannot monitor container metrics with Prometheus.*
* Only *numeric values* are supported by Prometheus, complex types will be splitted in single numeric values by the agent. Strings can be interpreted as regexp to extract numeric values, or be stored as string labels under an arbitraty numeric value (a somewhat risky workaround for a temporal DB).
* Custom and complex objects (other than OpenMBeans) may not be exported by the exporter, *having ‘\- pattern “.\*”’ as only rule will return every metric available* (useful for testing or default rule).
* Custom and complex objects (other than OpenMBeans) may not be exported by the exporter, *having ‘\- pattern “.\*”’ as only rule will return every metric available* (useful for testing or default rule).
* Rules order is important: Eventually, *a single MBean attributes is processed by a single rule*\! To decide which rule is applied: MBean attributes will be parsed by each rule (in order) until a pattern matches, then this rule is applied to the MBean attribute. In other words, all rules are tested against each MBean attribute the first one to match is kept for the attribute. So very specific rules should be put first, and generic/default rules last.
* Prometheus can make extensive use of *labels* through queries to determine *metrics* sources. Think about your needs when designing your labels, more explanations on [the official documentation|https://prometheus.io/docs/concepts/data_model/] or [this blog post.|https://pierrevincent.github.io/2017/12/prometheus-blog-series-part-1-metrics-and-labels/]
* Prometheus can make extensive use of *labels* through queries to determine *metrics* sources. Think about your needs when designing your labels, more explanations on [the official documentation|https://prometheus.io/docs/concepts/data_model/] or [this blog post.|https://pierrevincent.github.io/2017/12/prometheus-blog-series-part-1-metrics-and-labels/]
* Metrics can be typed (conceptually, as gauge, counter or histogram) for Prometheus to know how to handle them. More details on the [official documentation|https://prometheus.io/docs/concepts/metric_types/].
* Metrics format: {code}<metric name>{<label name>=<label value>, ...}{code}
* Metrics format: {code}<metric name>{<label name>=<label value>, ...}{code}
...More information on ??[Prometheus documentation|https://prometheus.io/docs/prometheus/latest/configuration/configuration/]
h2. Reload configuration
...For an exhaustive documentation go to [Grafana website|http://docs.grafana.org/features/datasources/prometheus/]
In short, once logged as admin:
# Open the side menu by clicking the Grafana icon in the top header.
# Open the side menu by clicking the Grafana icon in the top header.
...*Note:* Grafana data sources can also be [configured by files|http://docs.grafana.org/administration/provisioning/#datasources]
h3. Creating a graph
...