[Instrumentation.Runtime] Update OTel API version to 1.4.0-beta.2 and change runtime metrics type to ObservableUpDownCounter

[xiang17]

Update OTel API version to 1.4.0-beta.2 and change runtime metrics type to ObservableUpDownCounter now that it's ready. (Released in 1.4.0-beta.1: https://github.com/open-telemetry/opentelemetry-dotnet/releases/tag/core-1.4.0-beta.1)

For significant contributions please make sure you have completed the following items:

• Appropriate CHANGELOG.md updated for non-trivial changes
• Design discussion issue #

[codecov]

Codecov Report

Merging #675 (967011e) into main (52585a1) will not change coverage.
The diff coverage is 85.71%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #675   +/-   ##
=======================================
  Coverage   77.74%   77.74%           
=======================================
  Files         176      176           
  Lines        5343     5343           
=======================================
  Hits         4154     4154           
  Misses       1189     1189           

Impacted Files	Coverage Δ
...elemetry.Instrumentation.Runtime/RuntimeMetrics.cs	85.10% <85.71%> (ø)

[Kielek]

I have doubts if the beta version should be included into the contrib.
The changes does not looks huge and probably could be included together with 1.4.0 release.

[xiang17]

I have doubts if the beta version should be included into the contrib. The changes does not looks huge and probably could be included together with 1.4.0 release.

I have similar doubts on how to integrate beta version. If there happen to be any changes needed for the stable version, we'd need to create a branch from a past commit and maintain two branches. However, there are some benefits for doing it early:

1. More changes coming to this PR to upgrade to 1.4.0, because netcoreapp3.1 should be removed. I need to remove netcoreapp3.1 in TargetFrameworks, and potentially in GitHub actions. Refer to warnings in the build:

/home/runner/.nuget/packages/system.diagnostics.diagnosticsource/7.0.0-rc.1.22426.10/buildTransitive/netcoreapp2.0/System.Diagnostics.DiagnosticSource.targets(4,5): warning : System.Diagnostics.DiagnosticSource 7.0.0-rc.1.22426.10 doesn't support netcoreapp3.1 and has not been tested with it. Consider upgrading your TargetFramework to net6.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk. [/home/runner/work/opentelemetry-dotnet-contrib/opentelemetry-dotnet-contrib/src/OpenTelemetry.Instrumentation.Runtime/OpenTelemetry.Instrumentation.Runtime.csproj]
/home/runner/.nuget/packages/system.diagnostics.diagnosticsource/7.0.0-rc.1.22426.10/buildTransitive/netcoreapp2.0/System.Diagnostics.DiagnosticSource.targets(4,5): warning : System.Diagnostics.DiagnosticSource 7.0.0-rc.1.22426.10 doesn't support netcoreapp3.1 and has not been tested with it. Consider upgrading your TargetFramework to net6.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk. [/home/runner/work/opentelemetry-dotnet-contrib/opentelemetry-dotnet-contrib/test/OpenTelemetry.Instrumentation.Runtime.Tests/OpenTelemetry.Instrumentation.Runtime.Tests.csproj]

2. Early access to anyone who needs to test/preview/integrate with the UpDownCounter or OTel 1.4.0 version.

@utpilla Do you have any suggestion? Especially for removing netcoreapp3.1 in Github action, it may apply to all projects in this repo.

[cijothomas]

I have doubts if the beta version should be included into the contrib. The changes does not looks huge and probably could be included together with 1.4.0 release.

Each component can chose the version they want. We have no reason to prevent any component from moving to a newer version.

[cijothomas]

Do you think this is a breaking change? For sure OTLP Exporters see dif. data type now, but exporter like Prometheus would be fine...
@alanwest Can you check from NR stand point, if this will be breaking for anyone sending to NR via OTLP?

[alanwest]

Apologies for delay. No this is not breaking for New Relic. NR has its own gauge data type. Both OTLP gauges and OTLP non-monotonic sums are transformed to a NR gauge, so there will be no difference for end users querying this data in NR.

Though, it may be possible this could be breaking for other backends.

[cijothomas]

We can bring this to the next SIG to make a call about do we need to major version bump or not.

[Kielek]

@lachmatt checked changes with Splunk OTLP endpoint and it is working correctly.

[Kielek]

BTW I would consider it as a bugfix not a breaking change. There were no possibility to set it correctly with older dependencies.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[cijothomas]

do we need it here?

[cijothomas]

changes look good!
Based on most comments I am proposing to release this as minor version bump only. But will discuss this in next SIG meeting to finalize. (Stable cannot anyway occur before 1.4.0 of the API itself is stable, expected November 2022)