Coder Social home page Coder Social logo

aiven-open / prometheus-exporter-plugin-for-opensearch Goto Github PK

View Code? Open in Web Editor NEW
116.0 15.0 36.0 708 KB

Prometheus exporter plugin for OpenSearch & OpenSearch Mixin

License: Apache License 2.0

Java 100.00%
prometheus-exporter opensearch opensearch-plugins prometheus metrics mixin opensearch-mixin

prometheus-exporter-plugin-for-opensearch's Introduction

Prometheus Exporter Plugin for OpenSearch

The Prometheus® exporter plugin for OpenSearch® exposes many OpenSearch metrics in Prometheus format.


Preface

This repository contains two projects that are related, but each can be used independently:

  1. The first project is a Java plugin – Prometheus Exporter Plugin for OpenSearch® – this code lives in the main branch.
  2. The second project is a Jsonnet bundle – OpenSearch® Mixin – this code lives in the mixin branch.

Introduction

This plugin was started as a fork of Prometheus exporter for Elasticsearch® (it was forked in version 7.10.2.0; commit hash: 8dc7f85) utilizing OpenSearch plugin template. It uses the official Prometheus Java Simpleclient.

Currently, the available metrics are:

  • Cluster status
  • Nodes status:
    • JVM
    • Indices (global)
    • Transport
    • HTTP
    • Scripts
    • Process
    • Operating System
    • File System
    • Circuit Breaker
  • Indices status
  • Cluster settings (notably disk watermarks that can be updated dynamically)

Compatibility Matrix

NOTE: OpenSearch plugins much match exactly in major.minor.path version to the OpenSearch instance it's running in, e.g. plugins versions 2.8.0.x work only with OpenSearch 2.8.0, see also Opensearch Plugins. Therefore you must keep your prometheus-exporter-plugin-for-opensearch version in sync with your OpenSearch version.

OpenSearch Plugin Release date
2.16.0 2.16.0.0 Aug 08, 2024
2.15.0 2.15.0.0 Jun 26, 2024
2.14.0 2.14.0.0 May 20, 2024
2.13.0 2.13.0.0 Apr 05, 2024
2.12.0 2.12.0.0 Feb 27, 2024
2.11.1 2.11.1.0 Dec 06, 2023
2.11.0 2.11.0.0 Oct 24, 2023
2.10.0 2.10.0.0 Sep 27, 2023
2.9.0 2.9.0.0 Aug 01, 2023
2.8.0 2.8.0.0 Jun 13, 2023
2.7.0 2.7.0.0 May 10, 2023
2.6.0 2.6.0.0 Mar 03, 2023
2.5.0 2.5.0.0 Jan 30, 2023
2.4.1 2.4.1.0 Dec 19, 2022
2.4.0 2.4.0.0 Nov 18, 2022
2.3.0 2.3.0.0 Sep 19, 2022
2.2.1 2.2.1.0 Sep 5, 2022
2.2.0 2.2.0.0 Aug 13, 2022
2.1.0 2.1.0.0 July 13, 2022
2.0.1 2.0.1.0 July 12, 2022
2.0.0 2.0.0.0 May 27, 2022
2.0.0-rc1 2.0.0.0-rc1 May 19, 2022
1.3.17 1.3.17.0 Jun 26, 2024
1.3.16 1.3.16.0 May 21, 2024
1.3.15 1.3.15.0 Apr 05, 2024
1.3.14 1.3.14.0 Dec 20, 2023
1.3.13 1.3.13.0 Sep 27, 2023
1.3.12 1.3.12.0 Aug 31, 2023
1.3.11 1.3.11.0 Jul 06, 2023
1.3.10 1.3.10.0 May 23, 2023
1.3.9 1.3.9.0 Mar 20, 2023
1.3.8 1.3.8.0 Mar 03, 2023
1.3.7 1.3.7.0 Dec 19, 2022
1.3.6 1.3.6.0 Oct 10, 2022
1.3.5 1.3.5.0 Sep 05, 2022
1.3.4 1.3.4.0 Jul 15, 2022
1.3.3 1.3.3.0 Jun 15, 2022
1.3.2 1.3.2.0 May 10, 2022
1.3.1 1.3.1.0 Apr 08, 2022
1.3.0 1.3.0.0 Mar 22, 2022
<= 1.2.4 (*) (*)

(*) If you are looking for plugin releases supporting earlier (<= 1.2.4) OpenSearch versions please visit https://github.com/aparo/opensearch-prometheus-exporter/releases.

Install or Remove Plugin

You need to install the plugin on every OpenSearch node that will be scraped by Prometheus.

To install the plugin:

./bin/opensearch-plugin install https://github.com/aiven/prometheus-exporter-plugin-for-opensearch/releases/download/2.16.0.0/prometheus-exporter-2.16.0.0.zip

To remove the plugin.

./bin/opensearch-plugin remove prometheus-exporter

For more info about plugin CLI, visit: https://opensearch.org/docs/latest/opensearch/install/plugins/

Plugin Configuration

Static settings

Static settings are configured in config/opensearch.yml.

Metric name prefix

All metric names share common prefix, by default set to opensearch_.

The value of this prefix can be customized using setting:

prometheus.metric_name.prefix: "opensearch_"

Dynamic settings

Dynamic settings are configured in config/opensearch.yml but they can also be updated at any time via REST API.

Index level metrics

Whether to export detailed index level metrics or not. Default value: true.

Detailed index level metrics can represent a lot of data and can lead to high-cardinality labels in Prometheus. If you do not need detailed index level metrics it is recommended to disable it via setting:

prometheus.indices: false

Cluster settings

To disable exporting cluster settings use:

prometheus.cluster.settings: false

Nodes filter

Metrics include statistics about individual OpenSearch nodes. By default, only statistics from the node that received the request are included.

Prometheus exporter can be configured to include statistics from other nodes as well. This filter is directly utilizing OpenSearch Node filters feature. Default value: "_local".

For example to get stats for all cluster nodes from any node use settings:

prometheus.nodes.filter: "_all"

Indices filter

Prometheus exporter can be configured to filter indices statistics from selected indices. To target all indices, use "" or * or _all or null. Default value: "".

For example to filter indices statistics:

prometheus.indices_filter.selected_indices: "log-*,*log,*log*,log*-test"

Users can select which option for filtering indices statistics. Default value: "STRICT_EXPAND_OPEN_FORBID_CLOSED".

For example to select an option:

prometheus.indices_filter.selected_option: "LENIENT_EXPAND_OPEN"

Here is a list of indices options available for selection

STRICT_EXPAND_OPEN: indices options that requires every specified index to exist, expands wildcards only to open indices and allows that no indices are resolved from wildcard expressions (not returning an error).
STRICT_EXPAND_OPEN_HIDDEN: indices options that requires every specified index to exist, expands wildcards only to open indices, includes hidden indices, and allows that no indices are resolved from wildcard expressions (not returning an error).
STRICT_EXPAND_OPEN_FORBID_CLOSED: indices options that requires every specified index to exist, expands wildcards only to open indices, allows that no indices are resolved from wildcard expressions (not returning an error) and forbids the use of closed indices by throwing an error.
STRICT_EXPAND_OPEN_HIDDEN_FORBID_CLOSED: indices options that requires every specified index to exist, expands wildcards only to open indices, includes hidden indices, and allows that no indices are resolved from wildcard expressions (not returning an error) and forbids the use of closed indices by throwing an error.
STRICT_EXPAND_OPEN_FORBID_CLOSED_IGNORE_THROTTLED: indices options that requires every specified index to exist, expands wildcards only to open indices, allows that no indices are resolved from wildcard expressions (not returning an error), forbids the use of closed indices by throwing an error and ignores indices that are throttled.
STRICT_EXPAND_OPEN_CLOSED: indices option that requires every specified index to exist, expands wildcards to both open and closed indices and allows that no indices are resolved from wildcard expressions (not returning an error).
STRICT_EXPAND_OPEN_CLOSED_HIDDEN: indices option that requires every specified index to exist, expands wildcards to both open and closed indices, includes hidden indices, and allows that no indices are resolved from wildcard expressions (not returning an error).
STRICT_SINGLE_INDEX_NO_EXPAND_FORBID_CLOSED: indices option that requires each specified index or alias to exist, doesn't expand wildcards and throws error if any of the aliases resolves to multiple indices.
LENIENT_EXPAND_OPEN: indices options that ignores unavailable indices, expands wildcards only to open indices and allows that no indices are resolved from wildcard expressions (not returning an error).
LENIENT_EXPAND_OPEN_HIDDEN: indices options that ignores unavailable indices, expands wildcards to open and hidden indices, and allows that no indices are resolved from wildcard expressions (not returning an error).
LENIENT_EXPAND_OPEN_CLOSED: indices options that ignores unavailable indices, expands wildcards to both open and closed indices and allows that no indices are resolved from wildcard expressions (not returning an error).
LENIENT_EXPAND_OPEN_CLOSED_HIDDEN: indices options that ignores unavailable indices, expands wildcards to all open and closed indices and allows that no indices are resolved from wildcard expressions (not returning an error).

Usage

Metrics are directly available at:

http(s)://<opensearch-host>:9200/_prometheus/metrics

As a sample result, you get:

# HELP opensearch_process_mem_total_virtual_bytes Memory used by ES process
# TYPE opensearch_process_mem_total_virtual_bytes gauge
opensearch_process_mem_total_virtual_bytes{cluster="develop",node="develop01",} 3.626733568E9
# HELP opensearch_indices_indexing_is_throttled_bool Is indexing throttling ?
# TYPE opensearch_indices_indexing_is_throttled_bool gauge
opensearch_indices_indexing_is_throttled_bool{cluster="develop",node="develop01",} 0.0
# HELP opensearch_jvm_gc_collection_time_seconds Time spent for GC collections
# TYPE opensearch_jvm_gc_collection_time_seconds counter
opensearch_jvm_gc_collection_time_seconds{cluster="develop",node="develop01",gc="old",} 0.0
opensearch_jvm_gc_collection_time_seconds{cluster="develop",node="develop01",gc="young",} 0.0
# HELP opensearch_indices_requestcache_memory_size_bytes Memory used for request cache
# TYPE opensearch_indices_requestcache_memory_size_bytes gauge
opensearch_indices_requestcache_memory_size_bytes{cluster="develop",node="develop01",} 0.0
# HELP opensearch_indices_search_open_contexts_number Number of search open contexts
# TYPE opensearch_indices_search_open_contexts_number gauge
opensearch_indices_search_open_contexts_number{cluster="develop",node="develop01",} 0.0
# HELP opensearch_jvm_mem_nonheap_used_bytes Memory used apart from heap
# TYPE opensearch_jvm_mem_nonheap_used_bytes gauge
opensearch_jvm_mem_nonheap_used_bytes{cluster="develop",node="develop01",} 5.5302736E7
...

Configure the Prometheus target

On your Prometheus servers, configure a new job as usual.

For example, if you have a cluster of 3 nodes:

- job_name: opensearch
  scrape_interval: 10s
  metrics_path: "/_prometheus/metrics"
  static_configs:
  - targets:
    - node1:9200
    - node2:9200
    - node3:9200

Of course, you could use the service discovery service instead of a static config.

Just keep in mind that metrics_path must be /_prometheus/metrics, otherwise Prometheus will find no metric.

Build from Source

To build the plugin you need JDK 17:

./gradlew clean build

If you have doubts about the system requirements, please check the CI.yml file for more information.

Testing

Project contains:

Complete test suite is run using:

./gradlew clean check

To run individual integration rest test file use:

./gradlew :yamlRestTest \
  -Dtests.method="test {yaml=/20_11_index_level_metrics_disabled/Dynamically disable index level metrics}"

License

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Trademarks & Attributions

Prometheus is a registered trademark of The Linux Foundation. OpenSearch is a registered trademark of Amazon Web Services. Elasticsearch is a registered trademark of Elasticsearch BV.

prometheus-exporter-plugin-for-opensearch's People

Contributors

cesium147 avatar cmur2 avatar davidkarlsen avatar dependabot[bot] avatar dmivankov avatar docemmetbrown avatar dustinchaloupka avatar duxet avatar foxdalas avatar gokul-radhakrishnan avatar grechaw avatar greut avatar jeroenhabets avatar kbecic avatar lruslan avatar lukas-vlcek avatar maglore avatar maratkalibek avatar martbhell avatar mattias- avatar michael-kuss avatar nikolay avatar psalaberria002 avatar reta avatar rsmilyanov avatar rursprung avatar vinylen avatar vvanholl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

prometheus-exporter-plugin-for-opensearch's Issues

migration instructions when coming from ES exporter

is there a list of things (relevant for consumers) which changed between the original ES plugin (on 7.10.2) and this one? i can see that starting with #10 the default prefix is now opensearch_ and not es_ anymore (but can be configured). it might be good if a small migration guide (ES 7.10.2 -> OpenSearch 1.x -> OpenSearch 2.x) could be added to the README.
thanks!

Add cluster_uuid as a label

Currently, the metrics include label cluster holding the cluster name but we should add also cluster_uuid to better support cases where metrics from multiple clusters are collected into shared storage. At this moment if multiple clusters have the same name we can not distinguish between them.

Setup release process and clean leftowers

There are still some places where the code and configuration files need more love:

  • build.gradle file (this file has been updated many times since the migration and I now consider it up-to-date)
  • gradle.properties file (this file has been updated many times since the migration and I now consider it up-to-date)
  • setup checkstyle (most of the work here has been already merged in #167, except it is turned off now)
  • review CONTRIBUTING.md (see #199 and #78)
  • define security policy (see #19)
  • verify trademarks and attributions (see #17)
  • select Code of Conduct (see #15)
  • review .github/CODEOWNERS (see #30)
  • still some leftovers in tests from original plugin template (Rename*.java files) (see #191)
  • final updates to README.md (there are some TODOs and TBDs in it) (see #27)
  • rename the repository before it is moved to a new organisation (see here for more details about why the repository needs to change its name opensearch-project/opensearch-plugin-template-java#23)

Deprecated tasks:

  • missing automated release process: We will document the release process (see #42) and automate later (if possible).

opensearch_indices_indexing_index_current_number reports very low values

Hello,

First i would like to say a big thank you for providing this exporter, it's much appreciated.

Second, we have been looking into graphing the rate of indexed documents in our OpenSearch clusters and found the gauge "opensearch_indices_indexing_index_current_number". The description reads:

# HELP opensearch_indices_indexing_index_current_number Current rate of documents indexed

If we take a look in prometheus it looks like this. The indexing rate reported by the plugin is either constant 0 or spikes around 1.0-2.0.

If we look at the amount of logs indexed by our opensearch cluster in opensearch-dashboards we have around 100k logs in the last 15 min.

How come the values reported by the prometheus plugin is so low?

Our setup:

OpenSearch 1.3.2 with 3 master and 3 data nodes. Ingest is handled via Logstash -> Redis -> Logstash -> OpenSearch.

Please let me know if there is any information missing or if i am missing something obvious :)

Thanks!

Document the release process

Releasing a new version of Prometheus exporter plugin for OpenSearch is manual process. In order to make it replicable (and possibly more automated in the future) we shall document individual steps of the process and best practices.

Test uses or overrides a deprecated API

Possible issue in the future:

> Task :compileTestJava
Note: /Users/lukas.vlcek/projects/prometheus-exporter/src/test/java/org/opensearch/plugin/prometheus/PrometheusPluginIT.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

Make the metric prefix configurable

With migration to OpenSearch the metric prefix will be configurable with the default value of opensearch_.

Note: With the prefix value being configurable one can still set it to the original value of es_ which can be handy if there is other system that rely on original names of the metrics.

exporter for 1.3.1

Hello. I am were Update opensearch to 1.3.1 version and get this error.

Exception in thread "main" java.lang.IllegalArgumentException: Plugin [prometheus-exporter] was built for OpenSearch version 1.3.0 but version 1.3.1 is running
	at org.opensearch.plugins.PluginsService.verifyCompatibility(PluginsService.java:392)
	at org.opensearch.plugins.InstallPluginCommand.loadPluginInfo(InstallPluginCommand.java:815)
	at org.opensearch.plugins.InstallPluginCommand.installPlugin(InstallPluginCommand.java:870)
	at org.opensearch.plugins.InstallPluginCommand.execute(InstallPluginCommand.java:275)
	at org.opensearch.plugins.InstallPluginCommand.execute(InstallPluginCommand.java:249)
	at org.opensearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:100)
	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138)
	at org.opensearch.cli.MultiCommand.execute(MultiCommand.java:104)
	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138)
	at org.opensearch.cli.Command.main(Command.java:101)
	at org.opensearch.plugins.PluginCli.main(PluginCli.java:60)

Deprecation warnings

There are some deprecation warning (in 2.2.1.0):

> Task :compileJava
/Users/lukas.vlcek/projects/prometheus-exporter/src/main/java/org/opensearch/action/NodePrometheusRequestBuilder.java:26: warning: [deprecation] MasterNodeReadOperationRequestBuilder in org.opensearch.action.support.master has been deprecated
public class NodePrometheusRequestBuilder extends MasterNodeReadOperationRequestBuilder<NodePrometheusMetricsRequest,
                                                  ^
/Users/lukas.vlcek/projects/prometheus-exporter/src/main/java/org/opensearch/action/NodePrometheusRequestBuilder.java:26: warning: [deprecation] MasterNodeReadOperationRequestBuilder in org.opensearch.action.support.master has been deprecated
public class NodePrometheusRequestBuilder extends MasterNodeReadOperationRequestBuilder<NodePrometheusMetricsRequest,
                                                  ^
/Users/lukas.vlcek/projects/prometheus-exporter/src/main/java/org/opensearch/action/NodePrometheusMetricsRequest.java:28: warning: [deprecation] MasterNodeReadRequest in org.opensearch.action.support.master has been deprecated
public class NodePrometheusMetricsRequest extends MasterNodeReadRequest<NodePrometheusMetricsRequest> {
                                                  ^
/Users/lukas.vlcek/projects/prometheus-exporter/src/main/java/org/opensearch/action/NodePrometheusMetricsRequest.java:28: warning: [deprecation] MasterNodeReadRequest in org.opensearch.action.support.master has been deprecated
public class NodePrometheusMetricsRequest extends MasterNodeReadRequest<NodePrometheusMetricsRequest> {
                                                  ^
4 warnings

[Proposal] Make it possible to include/exclude metric types

Current metrics collection process is very strightforward – for every single scraping request all the metrics are pulled from the cluster. It is always "all or nothing" (except it is possible to skip detailed index level metrics with a cluster config setting).

Not only is it not efficient from the OpenSearch cluster perspective (i.e. pulling some metric types from the cluster may be more expensive than the other) but it also does not give user any option to include/exclude specific metrics.

The proposal is to give users control over the type(s) of metrics they want to pull from the cluster.

Currently, for a single scraping request there are several API calls excecuted internally in OpenSearch cluster (like Cluster health API, Nodes stats API, Indices Stats API, ... etc). The proposal is to make it possible to control which types of internal APIs will be called (hence making it possible to limit the number of metrics returned in response).

The API can look like this:

# To pull all stats (the default)
/_prometheus/metrics

# To pull only cluster health and nodes stats
/_prometheus/metrics?include=cluster_health,nodes_stats

# To pull only indices stats
/_prometheus/metrics?include=indices_stats

In combination with already implemented nodes filter this feature will allow for very flexible schema of metric collection. It will allow to collect specific type(s) of metrics from pre-defined sets of nodes at different intervals.

For example it will allow to pull the following sets of stats independently:

  • system nodes statistics (Host stats, JVM stats, ...)
  • cluster indices statistics (number of shards, segments, ...)
  • ML tasks statistics

As a result users will be able to setup more scraping jobs in their Prometheus, each can run at different interval and pulling different type of metrics. This will make overall metric collection more efficient both for OpenSearch and Prometheus storage.

This may not be a breaking change. The default behaviour will be to pull "all metrics" at once. But users will be encouraged to setup more fine-grained scraping jobs instead. Examples will be provided.

[Integration tests] Adapt integration tests to _type removal

All integration tests were originally implemented for Elasticsearch 5.x and 6.x
This means they should be updated to reflect "_type removal" breaking change.

WARNING: request [PUT http://127.0.0.1:57608/twitter/foo/1?error_trace=true] returned 1 warnings:
  [299 OpenSearch-1.2.3-8a529d77c7432bc45b005ac1c4ba3b2741b57d4a "[types removal] Specifying
  types in document index requests is deprecated, use the typeless endpoints instead
  (/{index}/_doc/{id}, /{index}/_doc, or /{index}/_create/{id})."]

Support release candidate builds

Release candidate (rc) builds are not supported at this moment. It is a legacy of the original project this plugin was forked from (i.e. Elasticsearch Prometheus exported plugin started by @vvanholl while ago). At that time the release process was fully automated and the idea was that the plugin code was either in -SNAPSHOT version or not (in which case the automated release process has been executed). More important rc build were quite rare with Elasticsearch, if my memory serves me well we never did rc release of Prometheus exporter plugin for Elasticsearch.

In order to make it possible a modification in build.gradle is needed.

Introduce nodes filter setting to control which nodes statistics are included in a single response

Currently, the node statistics pulled from individual OpenSearch node is relevant to that node only.
This is limiting in cases when Prometheus is not scraping every OpenSearch node.

We can start using nodes filter to pull node statistics of more nodes via single scrape request.
Currently, the node filter is hardcoded to "_local". The goal is to add a new configuration option to specify custom node filter (such as "_master", "_all", "coordinating_only:true", ... etc).

Check this forum thread for more context:
https://discuss.opendistrocommunity.dev/t/add-exporter-plugin-to-opensearch/7115/19

ERROR: Unknown plugin prometheus-exporter-1.3.3.0.zip

Hi, is it possible to save plugin file localy and install later?
I saved prometheus-exporter-1.3.3.0.zip. I tried to install, but I had an error:

# wget https://github.com/aiven/prometheus-exporter-plugin-for-opensearch/releases/download/1.3.3.0/prometheus-exporter-1.3.3.0.zip
# opensearch-plugin install prometheus-exporter-1.3.3.0.zip
-> Installing prometheus-exporter-1.3.3.0.zip
-> Failed installing prometheus-exporter-1.3.3.0.zip
-> Rolling back prometheus-exporter-1.3.3.0.zip
-> Rolled back prometheus-exporter-1.3.3.0.zip
A tool for managing installed opensearch plugins

Non-option arguments:
[String] -- command  

Option             Description        
------             -----------        
-E <KeyValuePair>  Configure a setting
-h, --help         Show help          
-s, --silent       Show minimal output
-v, --verbose      Show verbose output
ERROR: Unknown plugin prometheus-exporter-1.3.3.0.zip

But, if I'm installing like this, it is successful.

# /usr/share/opensearch/bin/./opensearch-plugin install https://github.com/aiven/prometheus-exporter-plugin-for-opensearch/releases/download/1.3.3.0/prometheus-exporter-1.3.3.0.zip
-> Installing https://github.com/aiven/prometheus-exporter-plugin-for-opensearch/releases/download/1.3.3.0/prometheus-exporter-1.3.3.0.zip
-> Downloading https://github.com/aiven/prometheus-exporter-plugin-for-opensearch/releases/download/1.3.3.0/prometheus-exporter-1.3.3.0.zip
[=================================================] 100%   
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.lang.RuntimePermission accessClassInPackage.sun.misc
* java.lang.RuntimePermission accessDeclaredMembers
* java.lang.reflect.ReflectPermission suppressAccessChecks
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.

Continue with installation? [y/N]y
-> Installed prometheus-exporter with folder name prometheus-exporter

Reduce the amount of metrics by flipping the default settings

The following two settings have impact on the amount of metrics pulled from OpenSearch. In the past (*) they were enabled by default which can lead to high cardinality issues in Prometheus (especially the indices level metrics).

(*) "In the past" means in the original Elasticsearch plugin which this OpenSearch plugin has been forked from. I think the forking process is the best opportunity for introducing breaking changes.

Let's switch the default value of these settings to false – meaning they will be disabled OOTB.

  • prometheus.indices: false
  • prometheus.cluster.settings: false

Notice: this feature will require improvement of integration tests. In particular we will need to configure two OpenSearch test clusters:

  • One with these (^^) settings enabled for both the indices and settings metrics, without these settings enabled there will be some integration tests failing.
  • Second cluster with the default settings (ie. indices and settings metrics disabled) that will be used to test only limited set of IT tests.

documentation for usage in combination with security plugins

background

this is the third attempt in the third repo to get an answer to vvanholl/elasticsearch-prometheus-exporter#324 and aparo/opensearch-prometheus-exporter#4 🙂

there are various security plugins available for OpenSearch (OpenSearch Security and SearchGuard with their upcoming release) and OpenSearch Security is included and enabled by default in the normal distribution.
is there any documentation on how to use opensearch-prometheus-exporter in combination with them?

problems

i see two aspects to this:

  • this plugin does REST calls to elasticsearch, so if security is enabled there it needs to be able to
    • provide authentication
    • validate & accept the TLS cert (it might well be a self-signed CA at the top which isn't accepted by the prometheus scrapper!)
  • since the prometheus plugin exposes a new path on the existing 9200 port instead of opening a dedicated port it is behind HTTPS (if this is enabled in the security plugin) and behind authentication. but when using prometheus in a kubernetes environment with automatic scrapping there's no good way to configure the scraper to accept self-signed CAs or provide authentication

our workaround (solution?)

this is how we got it to work:

there's a role for prometheus (both to access the prometheus metrics as well as for the prometheus plugin itself to access the internal metrics; mixed here because as you can see in the role mapping below it's anyway using the same mechanism):

read_prometheus:
  cluster_permissions:
    - "cluster:monitor/prometheus/metrics" # allow access to the prometheus plugin (the prometheus metrics collector doesn't send authentication information)
    # allow the plugin to access the required metrics (the plugin also doesn't send authentication information)
    - "cluster:monitor/health"
    - "cluster:monitor/state"
    - "cluster:monitor/nodes/info"
    - "cluster:monitor/nodes/stats"
  index_permissions:
    - index_patterns:
      - "*"
      allowed_actions:
      - "indices:monitor/stats"

this is then mapped for all anonymous users in a role mapping (which IMHO is bad practice as it requires enabling anonymous auth in the first place):

read_prometheus:
  backend_roles:
    - opendistro_security_anonymous_backendrole

this of course requires config.dynamic.http.anonymous_auth_enabled: true to be set in the security config.
note: this is currently undocumented in OpenSearch, i've raised the corresponding docs ticket: opensearch-project/documentation-website#627

if the prometheus scrapper doesn't know the CA used for the TLS certificates on the http port then you might also have to disable TLS on OpenSearch (or re-configure the prometheus scrapper).

with this in place it's then possible for prometheus to scrap the metrics.

alternatives

it would also be possible to set up basic authentication on OpenSearch with a dedicated user for prometheus and then let the prometheus scrapper use this user to read the data. however, this also isn't particularly secure (e.g. when using the k8s annotations for prometheus and having to define the username/password there...) and requires having basic auth enabled in the first place (which isn't what we want given that we have no other usage for it and adding a new auth realm for one single use-case opens a whole new can of worms).

required solution

preferred solution

  • no config is needed for the plugin to be able to access the metrics, it handles this internally (at least for OpenSearch Security as it should IMHO have first-party integration with that)
  • no config is needed for the plugin to be accessible from the outside (to avoid both the authentication issues and the certificate issues you could potentially spin up your own HTTP(-only) server rather than relying on the OpenSearch mechanism to provide the endpoint)

minimal solution

  • the best practices for the (manual) security setup are documented

Remove NodePrometheusRequestBuilder class

The NodePrometheusRequestBuilder class is no longer needed because the method that was returning instance of this class has been removed from upstream classes (see below). Now, it is just a leftover from past refactoring and can be removed.


  1. First the method Action.newRequestBuilder(client) was removed from Elasticsearch (see: elastic/elasticsearch#30966, specifically here elastic/elasticsearch@46e8d97#diff-34311f69b4f5ea90a3e88cabb8d3167f6c0651e5172f906750efc8a8276e4320L37).

  2. Then it was removed from the Elasticsearch Prometheus exporter NodePrometheusMetricsAction class (see: vvanholl/elasticsearch-prometheus-exporter@deb496d#diff-d4bd29c3b4f015bf843e60db39c318a2560c6d9384942bbb271ed662ecf0d507L41).

Example dashboard

Hey Aiven, your exporter is great!
I just wanted to ask if you have a default dashboard that I can use with it?

Provide Grafana dashboard and Prometheus Rules & Alerts

Use mixin approach to generate Grafana compatible dashbhoard, Prometheus Rules and Alerts.

Sources of inspiration (all AL2):

The idea is that the repository will get new sub-project folder to host related source files, on top of that there will be a new gradle task implemented to process mixin sources and run alerts tests. This means that as part of each new release of the prometheus-exporter plugin we could also run automated release of Grafana dashboard and Prometheus Rules & Alerts as well.

Installing the exporter on k8s env

Hey all!
Im running my OpenSearch cluster on k8s env and i want to install the exporter on the OpenSearch nodes (pods), from a quick look on your repo i noticed that a restart is needed after installing the exporter on a node.
what will be the best why to install it? init container to the pods ?

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.