Initial implementation

[dhontecillas]

Please, take a look at the README.md for information about how to configure the library, and at implementation details to have an initial explanation of the packages that compose the library.

The provided example is currently working, and easy to check the reported traces, however some work must be done, to create some dashboard, and check the metrics.

Also, there are still pending tests to be written.

But this implementation is ready to start receiving some feedback.

[taik0]

Yo optaría por hacerlo al revés. Si service_name está definido se usa, si no existe se usa el ServiceConfig.Name y si tampoco existe, un default tipo KrakenD.

[taik0]

En opencensus usabamos lo contrario. disable_metrics o disable_traces para que el default de la struct sea que esté activado (que entiendo es lo que nos interesa).

[taik0]

If we customize a layer, the rest will be disabled, that can be confusing since not setting anything enables everything by default. May be, each layer should be checked independently. We can also reverse the option so the default struct value (false) mimics this behaviour.

[taik0]

mm can't be nil?

[dhontecillas]

should not happen, but since we are not sure, I will add the check as in line 91 , good catch!

[kpacha]

I'd rather move the skip_path option to the router instead of having it at the backend, so a set of pipes could be ignored

[alombarte]

Thinking in external tools and config validation, I would rather avoid having a "free text" key, and convert exporters to an array instead. Something like:

"exporters": [
{
  "name": "my_prometheus_fashion_Exporter",
  "kind": "prometheus",
  "config": {
     "port": 9090,
     "process_metrics": true,
     "go_metrics": true
   }
 },
....
]```

[dhontecillas]

A better format for the exporters would be:

exporters": {
                    "prometheus": [
                        {
                            "name": "remote_prometheus",
                            "port": 9092,
                            "process_metrics": true,
                            "go_metrics": true
                        },
                        {
                            "name": "local_prometheus",
                            "port": 9092,
                            "process_metrics": true,
                            "go_metrics": true
                        }]
                }

[Harnoor7]

nit, we should take context from params

[Harnoor7]

shutting down meter provider gracefully is also TODO

[Harnoor7]

@dhontecillas any reason for not using otel-go net/http standard instrumentation support library?

[dhontecillas]

@dhontecillas any reason for not using otel-go net/http standard instrumentation support library?

@Harnoor7 Main reason is that I was not aware of it. But now that I've taken a first look at it, I think the library is missing some stuff (like metrics for the http client data, or keeping track of the readed bytes from the client). I might be wrong, and I will carefully review the differences there. The focus now is on having this PR in a usable state, then I will review and check we can have the same metrics / traces with the contrib library .. in that case I will use what I can from there, and if I miss something, we might think about trying to make a PR there.

I will keep an eye on it. Thanks for pointing out.

[Harnoor7]

@dhontecillas Got it. Yes, you are correct client-side metric instrumentation is missing, which will be added probably in the next release. There is an active PR for it: open-telemetry/opentelemetry-go-contrib#4707