hello @excalq sorry for long time to respond, but i was so tired i wanted to hold looking on the issue
about

• logstash_stats_process_cpu_load_average_Xm- I am not sure about that:
  
  source: (https://prometheus.io/docs/instrumenting/writing_exporters/)
  you should achieve the same result by grafana query + this metric
  I can help you if you encounter any problems with that

for elasticsearch output plugin i think you can implement that, however for version 2.x i would like to implement a way to scrape custom plugin metrics, just not sure about that. but for 1.x it should be really useful and apperciated!

I haven't checked each of the metrics that you provided, but they all seem reasonable to add.

If it is not a problem, please split them into 3 separate PRs (this will make PR review process easier):

• logstash_stats_pipeline_plugins_outputs_bulk_requests_successes and logstash_stats_pipeline_plugins_outputs_bulk_requests_with_errors
• rest of the logstash_stats_pipeline_plugins_*
• other metrics that you mentioned

Thank you for contributions to this project!
Please tell me if you need any help with them. Also, if you want to have a faster way of communication with me and/or want to ask questions that aren't directly related to this repo, you can find my email in my github profile. I am working in GMT+2 timezone, so I am not always responsive.
Again thanks for all the contributions!

Thanks! Agree on the pre-calculated stats, if they're aggregating another metric... However, the load average really shouldn't be considered a "CPU" load as much as a "system load", as it's the metric of processes using or waiting on the CPU. https://scoutapm.com/blog/understanding-load-averages is a good article on it as well. Situations like high I/O waits will manifest as low CPU utilization but very high system load averages - a common failure mode for data pipeline systems. (Though likely more common in Elasticsearch than Logstash).

I can make commits into a tranche of small PRs, which helps me get them out while doing all the other things! And for v2.x custom metrics, especially for plugins is a great idea. For these, I'm only planning to gather common metrics to all pipeline inputs/filters/outputs, with the exception of the Elasticsearch/OpenSearch output plugins.