[FEATURE] Prometheus metric endpoint

[AlexsJones]

Requirements

In order to capture data we should add a prometheus metrics endpoint.

Initial proposal:

flagd_total_request_count
flagd_request_bucket
flagd_request_per_minute
flagd_resolve_boolean_value_count
flagd_resolve_string_value_count
flagd_resolve_int_value_count
flagd_resolve_object_value_count

[toddbaert]

I like this idea.

Somewhat related: I'd also like to add OpenTelemetry spans. Do you think it's worth creating a new issue for that? It would allow use to get timing data for various aspects of evaluation (parsing, evaluation, etc). I can create one if you think it's a good idea

[AlexsJones]

I like this idea.

Somewhat related: I'd also like to add OpenTelemetry spans. Do you think it's worth creating a new issue for that? It would allow use to get timing data for various aspects of evaluation (parsing, evaluation, etc). I can create one if you think it's a good idea

I would say a new issue, it's a different kind of implementation.
Thing about spans are you need to send them somewhere, otherwise they are just firing into nothing.

[beeme1mr]

It may be worth considering OTel metrics. It looks like the metric support is still alpha though.

https://github.com/open-telemetry/opentelemetry-go

The push model of OTel may work better when FlagD is running as a sidecar.

[AlexsJones]

I wouldn't want to use a push model for flagD, I would caution that as we're adding dependencies and requirements.
A Prometheus scrappable endpoint feels like a light weight enough implementation to be useful without mandating additional infrastructure.

[AlexsJones]

#188