feat: [Collector Metric Exporter][1/x] Rename CollectorExporter to CollectorTraceExporter

[davidwitten]

Summary

This PR addresses Issue #1109.

Currently, the Collector Exporter only sends traces to the collector. In Python, Java, and Go, for example, metric exporting already exists for the collector. This PR adds that feature. I created two versions, one for Node and the other for browser. The node version uses gRPC, and the browser uses Beacon or XHR. It's up to date with all previous collector exporter commits.

What this PR does

I previously made a long PR. I'm splitting it up into multiple PRs to make it easier to review.

This PR renames CollectorExporter to CollectorTraceExporter. Additionally, I move CollectorExporterConfig to the types file, as it will be reused by the Collector Metric Exporter.

Next Steps

The next diffs will be as follows (Thanks to @mayurkale22 for the suggestion):

1. Add CollectorMetricExporterBase class
2. E2E Metric exporter for Browser with tests
3. E2E Metric exporter for Node with tests
4. Update examples and Documentation etc.

[codecov]

Codecov Report

Merging #1256 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #1256   +/-   ##
=======================================
  Coverage   93.29%   93.29%           
=======================================
  Files         126      126           
  Lines        3597     3597           
  Branches      724      724           
=======================================
  Hits         3356     3356           
  Misses        241      241           

Impacted Files	Coverage Δ
.../opentelemetry-exporter-collector/src/transform.ts	96.34% <ø> (ø)
...porter-collector/src/CollectorTraceExporterBase.ts	89.74% <100.00%> (ø)
...ages/opentelemetry-exporter-collector/src/types.ts	100.00% <100.00%> (ø)

[mayurkale22]

Thanks for chopping the PR, overall LGTM.

[dyladan]

Much easier to review. Naming change LGTM

[obecny]

All examples will stop working when this PR will be merged:

• examples/collector-exporter-node
• examples/tracer-web
  So I think they should be updated as well.
  Also the master should always be in state "ready to release" so I think the documentation should be updated as well. Otherwise we will be blocked from releasing or making more updates to collector (currently opened PR for json over http and next will be coming for proto over http)

[dyladan]

All examples will stop working when this PR will be merged:

• examples/collector-exporter-node
• examples/tracer-web
  So I think they should be updated as well.
  Also the master should always be in state "ready to release" so I think the documentation should be updated as well. Otherwise we will be blocked from releasing or making more updates to collector (currently opened PR for json over http and next will be coming for proto over http)

Think @mayurkale22 asked him to break it up this way, but I generally agree that if it does not blow up the PR and make it too big, the docs and examples changes should probably also be included. Since this is just a naming change it shouldn't be too huge of a difference with them.

[obecny]

All examples will stop working when this PR will be merged:

• examples/collector-exporter-node
• examples/tracer-web
  So I think they should be updated as well.
  Also the master should always be in state "ready to release" so I think the documentation should be updated as well. Otherwise we will be blocked from releasing or making more updates to collector (currently opened PR for json over http and next will be coming for proto over http)

Think @mayurkale22 asked him to break it up this way, but I generally agree that if it does not blow up the PR and make it too big, the docs and examples changes should probably also be included. Since this is just a naming change it shouldn't be too huge of a difference with them.

yes the examples and doc for it - it should be just renaming, nothing more

[mayurkale22]

Sure, makes sense to me.

[obecny]

Why the files from protos folder are being updated ?, I don't see to which revision the folder were updated, is this intentional ?

[davidwitten]

@obecny Thanks, I'll add documentation. Updating protos is necessary, otherwise it won't work with the latest version of the collector. For example, in the previous version (which was from March I believe), the proto still used OpenCensus names (e.g. Gauge). I'll update the documentation for the protos as well.

[obecny]

@obecny Thanks, I'll add documentation. Updating protos is necessary, otherwise it won't work with the latest version of the collector. For example, in the previous version (which was from March I believe), the proto still used OpenCensus names (e.g. Gauge). I'll update the documentation for the protos as well.

Ok but which sha commit are you updating to ? "Normally" when you update the submodule to certain revision you should see the changes under folder and then it will have only a different sha, nothing more, but here I see a files instead of sha so not sure how did you update that ?

[obecny]

I'm talking about this https://imgur.com/a/VG14xcE

[davidwitten]

@obecny I thought I just followed the directions in the readme, I'll try to do it again.

[dyladan]

I'm talking about this imgur.com/a/VG14xcE

This is just new UI for github submodule updates which gives you some idea of how big of a change you are introducing. It is the same thing "under the hood".

[obecny]

I'm talking about this imgur.com/a/VG14xcE

This is just new UI for github submodule updates which gives you some idea of how big of a change you are introducing. It is the same thing "under the hood".

ok thx :),

[obecny]

lgtm, thx for updating examples and docs :)