Avoid exposing OpenCensus reference in public APIs

[mxiamxia]

Description:
Hide OpenCensus references from public APIs in obsreport and obsreporttest packages, there are 3 public APIs in obsreport are using OpenCensus View.

Changes

1. Moved obsreport.Configure() and AllViews() into internal folder obsreportconfig and made AllViews private, only keep the necessary telemetry APIs in obsreport. It helps to separate obsreport telemetry setup and collector telemetry reporting. Also, it hides the unnecessary public APIs.
2. Moved the OpenCensus metrics(stats) defines for each components into internal folder obsreportconfig/obsmetrics

TODO

1. Remove obsreport.ProcessorMetricViewsfrom the package and update it's consumer
2. update contrib package for above changes.

Checklist,
obsreport

• doc.go
• observability.go
• obsreport.go
  • func Configure(level configtelemetry.Level) (views []*view.View) {}
  • func AllViews() (views []*view.View) {}
• obsreport_exporter.go
• obsreport_processor.go
  • func ProcessorMetricViews(configType string, legacyViews []*view.View) []*view.View {}
• obsreport_receiver.go
• obsreport_scraper.go
• obsreport_test.go
• obsreporttest
  • obsreporttest.go
  • obsreporttest_test.go

Link to tracking Issue:
#2648

Testing:
make all

[bogdandrutu]

Can we put this in internal so external users cannot construct it?

[mxiamxia]

obsreport.ProcessorMetricViews uses it as input in a few components in contrib. We'll need it for contrib changes.

[bogdandrutu]

I think we should remove these calls, we should look into why is this called, and how we can get rid of it. I think they are mainly call into the ProcessorMetricViews to standardize the name, but we have the BuildProcessorCustomMetricName so mostly they can change to just build the name of the metrics with that call.

What do you think?

[mxiamxia]

Yes, you're right. I'll make the changes in separate PR since I've made this PR enough now to hide Configure() and AllViews() from external. Updated description as well. PTAL! Thanks

[bogdandrutu]

Probably this should be moved in internal if possible since this API will no longer exists when switching to otel metrics.

[mxiamxia]

Yes, made the changes and updated the PR description.

[bogdandrutu]

@mxiamxia need a rebase the circleCI is fix on head

[mxiamxia]

@mxiamxia need a rebase the circleCI is fix on head

yes, rebased with the latest on head.

[tete17]

Hey @mxiamxia & @bogdandrutu sorry to hijack this old MR.

I am updating https://github.com/grafana/tempo to make use of the latest version of this component. It seems they made use of this views to expose opencesus metrics from their embedded receivers. grafana/tempo#1142

This PR mentions these api's are hidden in order to expose Opentelemetry metrics but I don't seem to see if that is already possible. They are wondering if we can keep these metrics (accepted_spans, & refused_spans for example) after updating the library or we will need to find another way of doing this.