[receiver/aerospikereceiver] Proposed collaboration

[dwelch-spike]

Hi, I'm an engineer from Aerospike, we recently started looking at contributing an Aerospike receiver to OpenTelemetry and found this one. We would like to collaborate on the project. Here are a few of the changes/additions we have in mind.

Expand the receiver to scrape all the metrics currently scraped by our prometheus exporter. https://github.com/aerospike/aerospike-prometheus-exporter . This includes more namespace metrics, job metrics, Sindex metrics, etc.

We had it in mind to make a receiver that, when used with a OpenTelemetry Prometheus exporter, would work with our monitoring stack https://github.com/aerospike/aerospike-monitoring . The main change required here would be renaming or creating new resources, attributes, and metrics to match the labels used by the prometheus queries in our Grafana dashboards, see for example.

Expand the configuration options to include TLS, PKI auth, and more. (options similar to our Prometheus exporter)

After metric scraping is supported we planned to work on log scraping as well.

@antonblock @djaglowski please let me know what direction you are planning to take this receiver and wether collaborating seems like a good idea to you. We are happy to provide PRs for the changes listed above. We could also create another receiver if that seems best.

@rbotzer

[djaglowski]

Hi @dwelch-spike. First of all, it's great that there's an opportunity for collaboration here. I think it will make sense to have a single aerospike receiver. Adding more metrics and more robust configuration seems like a natural next step too.

One area we'll need to work out is naming. OpenTelemetry has its own semantic conventions and naming guidelines, to which we will typically need to adhere. That said, it may be the case that the receiver emits names that are aligned with OTel's conventions, but that we make sure these can be renamed (or reshaped, etc) as necessary for your stack.

I think probably the next step would be for you to propose specifics for what you'd like to see. Then we can iron out details and make sure we're all on the same page.

[dwelch-spike]

Hi @djaglowski. That all sounds good to me. The first PR we want to do is a performance change. Changing the collect_cluster_metrics mode to request info from nodes in parallel instead of sequentially. The goal is to reduce the total scrape and emit time for large clusters. This won't change anything user facing. Changes will probably include adding another client object that satisfies the aerospike interface and then refactoring some of the scrapeDiscoveredNode code to use it.

The next thing we are thinking about is expanding the configuration. I'll post more information when we decide which configuration items we want to add first.

I understand that I'll need to post some details about the proposed renaming, I will do that when we take a closer look at the necessary changes.

If this all sounds good to you I will work on creating a PR for the mentioned performance change. Should I create a feature issue for each proposed change as we get to them? Or is continuing to post here ok?

[djaglowski]

@dwelch-spike, excellent. This sounds great.

Should I create a feature issue for each proposed change as we get to them?

Please do it this way so we can track and discuss changes individually.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/aerospike: @djaglowski @antonblock

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.