Merge branch 'open-telemetry:main' into elastic-exporter-els-format

Author: ShadowMaxLeb

CMakeLists.txt

@@ -287,6 +287,10 @@ option(WITH_ASYNC_EXPORT_PREVIEW "Whether to enable async export" OFF)
 option(WITH_METRICS_EXEMPLAR_PREVIEW
        "Whether to enable exemplar within metrics" OFF)
 
+option(OPENTELEMETRY_SKIP_DYNAMIC_LOADING_TESTS
+       "Whether to build test libraries that are always linked as shared libs"
+       OFF)
+
 #
 # Verify options dependencies
 #

api/include/opentelemetry/nostd/internal/absl/meta/type_traits.h

@@ -106,18 +106,6 @@ struct VoidTImpl {
   using type = void;
 };
 
-// This trick to retrieve a default alignment is necessary for our
-// implementation of aligned_storage_t to be consistent with any implementation
-// of std::aligned_storage.
-template <size_t Len, typename T = std::aligned_storage<Len>>
-struct default_alignment_of_aligned_storage;
-
-template <size_t Len, size_t Align>
-struct default_alignment_of_aligned_storage<Len,
-                                            std::aligned_storage<Len, Align>> {
-  static constexpr size_t value = Align;
-};
-
 ////////////////////////////////
 // Library Fundamentals V2 TS //
 ////////////////////////////////
@@ -619,10 +607,6 @@ using remove_extent_t = typename std::remove_extent<T>::type;
 template <typename T>
 using remove_all_extents_t = typename std::remove_all_extents<T>::type;
 
-template <size_t Len, size_t Align = type_traits_internal::
-                          default_alignment_of_aligned_storage<Len>::value>
-using aligned_storage_t = typename std::aligned_storage<Len, Align>::type;
-
 template <typename T>
 using decay_t = typename std::decay<T>::type;
 

api/test/CMakeLists.txt

@@ -10,4 +10,7 @@ add_subdirectory(metrics)
 add_subdirectory(logs)
 add_subdirectory(common)
 add_subdirectory(baggage)
-add_subdirectory(singleton)
+
+if(NOT OPENTELEMETRY_SKIP_DYNAMIC_LOADING_TESTS)
+  add_subdirectory(singleton)
+endif()

examples/plugin/CMakeLists.txt

@@ -2,4 +2,7 @@
 # SPDX-License-Identifier: Apache-2.0
 
 add_subdirectory(load)
-add_subdirectory(plugin)
+
+if(NOT OPENTELEMETRY_SKIP_DYNAMIC_LOADING_TESTS)
+  add_subdirectory(plugin)
+endif()

exporters/etw/README.md

@@ -12,215 +12,5 @@ subsequent data recording or forwarding to alternate pipelines and flows.
 Windows Event Tracing infrastructure is available to any vendor or application
 being deployed on Windows.
 
-## API support
-
-These are the features planned to be supported by ETW exporter:
-
-- [x] OpenTelemetry Tracing API and SDK headers are **stable** and moving
-  towards GA.
-- [ ] OpenTelemetry Logging API is work-in-progress, pending implementation of
-  [Latest Logging API spec
-  here](https://github.com/open-telemetry/oteps/pull/150)
-- [ ] OpenTelemetry Metrics API is not implemented yet.
-
-Implementation of OpenTelemetry C++ SDK ETW exporter on Windows OS is `header
-only` :
-
-- full definitions of all macros, functions and classes comprising the library
-are visible to the compiler in a header file form.
-- implementation does not need to be separately compiled, packaged and installed
-  in order to be used.
-
-All that is required is to point the compiler at the location of the headers,
-and then `#include` the header files into the application source. Compiler's
-optimizer can do a much better job when all the library's source code is
-available. Several options below may be turned on to optimize the code with the
-usage of standard C++ library, Microsoft Guidelines Support library, Google
-Abseil Variant library. Or enabling support for non-standard features, such as
-8-bit byte arrays support that enables performance-efficient representation of
-binary blobs on ETW wire.
-
-## Example project
-
-The following include directories are required, relative to the top-level source
-tree of OpenTelemetry C++ repo:
-
-- api/include/
-- exporters/etw/include/
-- sdk/include/
-
-Code that instantiates ETW TracerProvider, subsequently obtaining a Tracer bound
-to `OpenTelemetry-ETW-Provider`, and emitting a span named `MySpan` with
-attributes on it, as well as `MyEvent` within that span.
-
-```cpp
-
-#include <map>
-#include <string>
-
-#include "opentelemetry/exporters/etw/etw_tracer_exporter.h"
-
-using namespace OPENTELEMETRY_NAMESPACE;
-using namespace opentelemetry::exporter::etw;
-
-// Supply unique instrumentation name (ETW Provider Name) here:
-std::string providerName = "OpenTelemetry-ETW-Provider";
-
-exporter::etw::TracerProvider tp;
-
-int main(int argc, const char* argv[])
-{
-  // Obtain a Tracer object for instrumentation name.
-  // Each Tracer is associated with unique TraceId.
-  auto tracer = tp.GetTracer(providerName, "TLD");
-
-  // Properties is a helper class in ETW namespace that is otherwise compatible
-  // with Key-Value Iterable accepted by OpenTelemetry API. Using Properties
-  // should enable more efficient data transfer without unnecessary memcpy.
-
-  // Span attributes
-  Properties attribs =
-  {
-    {"attrib1", 1},
-    {"attrib2", 2}
-  };
-
-  // Start Span with attributes
-  auto span = tracer->StartSpan("MySpan", attribs);
-
-  // Emit an event on Span
-  std::string eventName = "MyEvent1";
-  Properties event =
-  {
-    {"uint32Key", (uint32_t)1234},
-    {"uint64Key", (uint64_t)1234567890},
-    {"strKey", "someValue"}
-  };
-  span->AddEvent(eventName, event);
-
-  // End Span.
-  span->End();
-
-  // Close the Tracer on application stop.
-  tracer->CloseWithMicroseconds(0);
-
-  return 0;
-}
-```
-
-Note that different `Tracer` objects may be bound to different ETW destinations.
-
-## Build options and Compiler Defines
-
-While including OpenTelemetry C++ SDK with ETW exporter, the customers are in
-complete control of what options they would like to enable for their project
-using `Preprocessor Definitions`.
-
-These options affect how "embedded in application" OpenTelemetry C++ SDK code is
-compiled:
-
-| Name        | Description                                                      |
-|---------------------|------------------------------------------------------------------------------------------------------------------------|
-| OPENTELEMETRY_STL_VERSION | Use STL classes for API surface. C++20 is recommended. Some customers may benefit from STL library provided with the compiler instead of using custom OpenTelemetry `nostd::` implementation due to security and performance considerations. |
-| HAVE_GSL      | Use [Microsoft GSL](https://github.com/microsoft/GSL) for `gsl::span` implementation. Library must be in include path. Microsoft GSL claims to be the most feature-complete implementation of `std::span`. It may be used instead of `nostd::span` implementation in projects that statically link OpenTelemetry SDK. |
-| HAVE_TLD      | Use ETW/TraceLogging Dynamic protocol. This is the default implementation compatible with existing C# "listeners" / "decoders" of ETW events. This option requires an additional optional Microsoft MIT-licensed `TraceLoggingDynamic.h` header. |
-
-## Debugging
-
-### ETW TraceLogging Dynamic Events
-
-ETW supports a mode that is called "Dynamic Manifest", where event may contain
-strongly-typed key-value pairs, with primitive types such as `integer`,
-`double`, `string`, etc. This mode requires `TraceLoggingDynamic.h` header.
-Please refer to upstream repository containining [Microsoft TraceLogging Dynamic
-framework](https://github.com/microsoft/tracelogging-dynamic-windows) licensed
-under [MIT
-License](https://github.com/microsoft/tracelogging-dynamic-windows/blob/main/LICENSE).
-
-Complete [list of ETW
-types](https://docs.microsoft.com/en-us/windows/win32/wes/eventmanifestschema-outputtype-complextype#remarks).
-
-OpenTelemetry C++ ETW exporter implements the following type mapping:
-
-| OpenTelemetry C++ API type | ETW type        |
-|----------------------------|-----------------|
-| bool                       | xs:byte         |
-| int (32-bit)               | xs:int          |
-| int (64-bit)               | xs:long         |
-| uint (32-bit)              | xs:unsignedInt  |
-| uint (64-bit)              | xs:unsignedLong |
-| double                     | xs:double       |
-| string                     | win:Utf8        |
-
-Support for arrays of primitive types is not implemented yet.
-
-Visual Studio 2019 allows to use `View -> Other Windows -> Diagnostic Events` to
-capture events that are emitted by instrumented application and sent to ETW
-provider in a live view. Instrumentation name passed to `GetTracer` API above
-corresponds to `ETW Provider Name`. If Instrumentation name contains a GUID -
-starts with a curly brace, e.g. `{deadbeef-fade-dead-c0de-cafebabefeed}` then
-the parameter is assumed to be `ETW Provider GUID`.
-
-Click on `Settings` and add the provider to monitor either by its Name or by
-GUID. In above example, the provider name is `OpenTelemetry-ETW-Provider`.
-Please refer to Diagnostic Events usage instructions
-[here](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-diagnostics-how-to-monitor-and-diagnose-services-locally#view-service-fabric-system-events-in-visual-studio)
-to learn more. Note that running ETW Listener in Visual Studio requires
-Elevation, i.e. Visual Studio would prompt you to confirm that you accept to run
-the ETW Listener process as Administrator. This is a limitation of ETW
-Listeners, they must be run as privileged process.
-
-### ETW events encoded in MessagePack
-
-OpenTelemetry ETW exporter optionally allows to encode the incoming event
-payload using [MessagePack](https://msgpack.org/index.html) compact binary
-protocol. ETW/MsgPack encoding requires
-[nlohmann/json](https://github.com/nlohmann/json) library to be included in the
-build of OpenTelemetry ETW exporter. Any recent version of `nlohmann/json` is
-compatible with ETW exporter. For example, the version included in
-`third_party/nlohmann-json` directory may be used.
-
-There is currently **no built-in decoder available** for this format. However,
-there is ongoing effort to include the ETW/MsgPack decoder in
-[Azure/diagnostics-eventflow](https://github.com/Azure/diagnostics-eventflow)
-project, which may be used as a side-car listener to forward incoming
-ETW/MsgPack events to many other destinations, such as:
-
-- StdOutput (console output)
-- HTTP (json via http)
-- Application Insights
-- Azure EventHub
-- Elasticsearch
-- Azure Monitor Logs
-
-And community-contributed exporters:
-
-- Google Big Query output
-- SQL Server output
-- ReflectInsight output
-- Splunk output
-
-[This PR](https://github.com/Azure/diagnostics-eventflow/pull/382) implements
-the `Input adapter` for OpenTelemetry ETW/MsgPack protocol encoded events for
-Azure EventFlow.
-
-Other standard tools for processing ETW events on Windows OS, such as:
-
-- [PerfView](https://github.com/microsoft/perfview)
-- [PerfViewJS](https://github.com/microsoft/perfview/tree/main/src/PerfViewJS)
-
-will be augmented in future with support for ETW/MsgPack encoding.
-
-## Addendum
-
-This document needs to be supplemented with additional information:
-
-- [ ] mapping between OpenTelemetry fields and concepts and their corresponding
-  ETW counterparts
-- [ ] links to E2E instrumentation example and ETW listener
-- [ ] Logging API example
-- [ ] Metrics API example (once Metrics spec is finalized)
-- [ ] example how ETW Listener may employ OpenTelemetry .NET SDK to 1-1
-  transform from ETW events back to OpenTelemetry flow
-- [ ] links to NuGet package that contains the source code of SDK that includes
-  OpenTelemetry SDK and ETW exporter
+It is recommended to consume this exporter via
+[vcpkg](https://vcpkg.io/en/package/opentelemetry-cpp).

exporters/otlp/src/otlp_grpc_client.cc

@@ -207,7 +207,7 @@ static sdk::common::ExportResult InternalDelegateAsyncExport(
   stub->experimental_async()
 #  endif
       ->Export(call_data->grpc_context.get(), call_data->request, call_data->response,
-               [call_data, async_data](::grpc::Status grpc_status) {
+               [call_data, async_data, export_data_name](::grpc::Status grpc_status) {
                  --async_data->running_requests;
                  ++async_data->finished_request_counter;
 
@@ -216,6 +216,13 @@ static sdk::common::ExportResult InternalDelegateAsyncExport(
                  {
                    call_data->export_result = opentelemetry::sdk::common::ExportResult::kSuccess;
                  }
+                 else
+                 {
+                   OTEL_INTERNAL_LOG_ERROR("[OTLP GRPC Client] ERROR: Export "
+                                           << export_data_name << " failed with status_code: \""
+                                           << grpc_status.error_code() << "\" error_message: \""
+                                           << grpc_status.error_message() << "\"");
+                 }
 
                  if (call_data->grpc_async_callback)
                  {

exporters/prometheus/include/opentelemetry/exporters/prometheus/exporter_options.h

@@ -28,6 +28,12 @@ struct PrometheusExporterOptions
 
   // Populating otel_scope_name/otel_scope_labels attributes
   bool without_otel_scope = false;
+
+  // Option to export metrics without the unit suffix
+  bool without_units = false;
+
+  // Option to export metrics without the type suffix
+  bool without_type_suffix = false;
 };
 
 }  // namespace metrics

exporters/prometheus/include/opentelemetry/exporters/prometheus/exporter_utils.h

@@ -30,12 +30,18 @@ class PrometheusExporterUtils
    * @param populate_target_info whether to populate target_info
    * @param without_otel_scope whether to populate otel_scope_name and otel_scope_version
    * attributes
+   * @param without_units exporter configuration controlling whether to append unit suffix in
+   * the exported metrics.
+   * @param without_type_suffix exporter configuration controlling whether to append type suffix in
+   * the exported metrics.
    * @return a collection of translated metrics that is acceptable by Prometheus
    */
   static std::vector<::prometheus::MetricFamily> TranslateToPrometheus(
       const sdk::metrics::ResourceMetrics &data,
       bool populate_target_info = true,
-      bool without_otel_scope   = false);
+      bool without_otel_scope   = false,
+      bool without_units        = false,
+      bool without_type_suffix  = false);
 
 private:
   /**
@@ -61,7 +67,9 @@ class PrometheusExporterUtils
 
   static std::string MapToPrometheusName(const std::string &name,
                                          const std::string &unit,
-                                         ::prometheus::MetricType prometheus_type);
+                                         ::prometheus::MetricType prometheus_type,
+                                         bool without_units,
+                                         bool without_type_suffix);
 
   /**
    * A utility function that returns the equivalent Prometheus name for the provided OTLP metric

exporters/prometheus/src/exporter_options.cc

@@ -48,10 +48,33 @@ inline bool GetPrometheusPopulateTargetInfo()
   return exists ? setting : true;
 }
 
+inline bool GetPrometheusWithoutUnits()
+{
+  constexpr char kPrometheusWithoutUnits[] = "OTEL_CPP_PROMETHEUS_EXPORTER_WITHOUT_UNITS";
+  bool setting;
+  const auto exists =
+      opentelemetry::sdk::common::GetBoolEnvironmentVariable(kPrometheusWithoutUnits, setting);
+
+  return exists ? setting : false;
+}
+
+inline bool GetPrometheusWithoutTypeSuffix()
+{
+  constexpr char kPrometheusWithoutTypeSuffix[] =
+      "OTEL_CPP_PROMETHEUS_EXPORTER_WITHOUT_TYPE_SUFFIX";
+  bool setting;
+  const auto exists =
+      opentelemetry::sdk::common::GetBoolEnvironmentVariable(kPrometheusWithoutTypeSuffix, setting);
+
+  return exists ? setting : false;
+}
+
 PrometheusExporterOptions::PrometheusExporterOptions()
     : url(GetPrometheusDefaultHttpEndpoint()),
       populate_target_info(GetPrometheusPopulateTargetInfo()),
-      without_otel_scope(GetPrometheusWithoutOtelScope())
+      without_otel_scope(GetPrometheusWithoutOtelScope()),
+      without_units(GetPrometheusWithoutUnits()),
+      without_type_suffix(GetPrometheusWithoutTypeSuffix())
 {}
 
 }  // namespace metrics