while working on this, I feel I want to move type keys handling from c code to prometheus.rb because, if I understand correctly, types are actually expressing the type of kinda appearance and they depend on the consumer of JSON data (in this case: prometheus).
So how about doing like the following in prometheus.rb?

(snip)
      keys.each { |k,v|
        type = if k =~ /\Auptime|connections|num-sessions\z/
          'gauge'
        elsif k =~ /-[0-9]+\z/
          'gauge'
        else
          'counter'
        end

        s += "#HELP #{k}\n"
        s += "#TYPE #{k} #{type}\n"
        s += "#{k}{version=\"#{version}\"} #{v}\n"
      }
(snip)

I think it's clearer than the current way, WDYT @deweerdt @kazuho ?

This looks awesome.

The mruby script acts as a wrapper ("middleware" in terms of Rack), removing the need to use HTTP in order to fetch the status information from another handler.

@deweerdt Would you mind reviewing the PR?

@i110 thanks! This is a nice improvement. I'm not sure how i feel about the type being derived from the appearance. It does work for now, and skipping the C part of the PR is an advantage. On the other hand, whether a stat is a counter or a gauge is something that the consumer can't tell, so we'll have to be cognizant of this when adding new counters.

Thanks again :) LGTM.

@deweerdt Thank you for the review.

I'm not sure how i feel about the type being derived from the appearance. It does work for now, and skipping the C part of the PR is an advantage. On the other hand, whether a stat is a counter or a gauge is something that the consumer can't tell, so we'll have to be cognizant of this when adding new counters.

My view is that generally speaking "deriving type from appearance" is the correct thing to do. Consider time_t. It's better than using int because it represents the semantics of the value.

Having that said, to me the questions seems to be if we would be fine with using a naming convention that is capable of distinguishing between gauges and other types (welcome to the world of Hungarian notation!), or if we need to associate the "types" as attributes. I do not have a strong opinion on the matter.

I pushed 0035ed9, which does type-related things in mruby script, and also make some changes regarding the doc: https://prometheus.io/docs/instrumenting/writing_exporters (e.g. sanitizing the keys, removing not numeric fields, etc)

What do you think? Personally I'm gladI could remove c code changes. Anyway we may have to read the above doc more..

Having that said, to me the questions seems to be if we would be fine with using a naming convention that is capable of distinguishing between gauges and other types (welcome to the world of Hungarian notation!), or if we need to associate the "types" as attributes. I do not have a strong opinion on the matter.

Yes, agreed. I think the approach take here is good.

For record:
kazuho and me discussed, and reached to the conclusion that the current approach (0035ed9) is good because it decouples prometheus specific concepts from status JSON. Even if the concepts like count, gauge and others are widely used there's no guarantees in the future that all metrics in status JSON can be classified in those types: they are designed for prometheus, not for h2o. The above commit encapsulates prometheus things in prometheus.rb that is nice layering.

@kazuho @deweerdt thank you for discussing with me. I think this PR is ready for merge if you have no concerns

d8eb74c added h2o_ prefix to comply with https://prometheus.io/docs/practices/naming/