-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the in-memory metrics exporter. #1481
Conversation
|
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1481 +/- ##
==========================================
+ Coverage 85.73% 85.79% +0.06%
==========================================
Files 171 171
Lines 5240 5240
==========================================
+ Hits 4492 4495 +3
+ Misses 748 745 -3
|
Could you please alse add cmake targets in |
Sure, I can add that. I feel supporting/maintaining two build systems is a little bit inconvenient. Do we consider using some tools like, https://github.com/google/bazel-to-cmake, so that CMakeLists.txt can be generated from the BUILD and WORKSPACE, or using cmake and bazel (https://github.com/bazelbuild/rules_foreign_cc) supports importing cmake projects. |
Good point, I think it require more discussion. In most case, I think cmake users do not want to install another bazel toolset, and bazel users do not want install cmake toolset either. BTW: We had a discussion before and try to find a way to use bazel to build both with legacy gcc 4.8 and the latest compiler here #666 , do you has any suggestion about it? |
Yes, I do agree it's inconvenient to maintain both these build systems. The decision to support both was made much before any of the existing contributors joined the team. The SIG work was initiated by the folks from Google and Microsoft, and it was defacto choice to support the build systems used by these companies :). Having said that, most of the existing C++ projects use either(or both) of these build systems, and so it makes sense to keep supporting both. |
The 2 build systems issue were discussed in the past as @lalitb and @owent mentioned. As there are users for both of them, we will try our best to keep both up to date and consistent. For the https://github.com/google/bazel-to-cmake, it has not been updated for a few years, not sure it could work, together with that we've already have full set of cmake files which is not expected to be overwriten. |
Thanks for the PR @yxue. This is your first PR here, and it is nicely done :) Just thinking whether the InMemoryExporter should have any dependency on the protobuf. For Logs and Traces, the memory/ostream exporters are not dependent on any external library. Is it possible to achieve this for Metrics too - Eg by letting CircularBuffer contain the list of MetricData or ResourceMetrics ? We can discuss further if it is something not feasible/or difficult to achieve with the current SDK implementation. |
Thanks @lalitb! I was thinking about using the CircularBuffer with the ResourceMetrics but then we need the special process for the pointers inside the structure. Having the MetricData with CircularBuffer might work but some info is lost. Another thing is about comparing these structure objects. With protobuf message, the objects can be easily compared. Since we don't define the == for MetricsData and ResourceMetrics, comparing them in the unit test is not trivial. |
Thanks @lalitb @owent and @ThomsonTan for the info about the building system. I am not sure about fixing the gcc 4.8 and grpc compatibility. I do see the building systems are right now used by multiple teams/companies. I also saw there are already some divergence problems between these two systems, e.g., #1428. I think we might need some tools to reconcile that if the community is going to keep two building systems. |
Yes, I thought so too. Should be fine to keep the dependency unless someone has any concern :) |
Sure, no worries. The PR was updated. PTAL, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
exporters/memory/include/opentelemetry/exporters/memory/in_memory_data.h
Outdated
Show resolved
Hide resolved
Could you please revert changes in |
The change under exporters/otlp is for fixing the missing part of conversion between protobuf and structure. Remove that will fail the unit test. |
OK. we can solve this conflict later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after in_memory_metric_exporter
is also added into cmake/opentelemetry-cpp-config.cmake.in
.
Good point. @yxue this file contains the rules to enable opentelemetry-cpp included in other projects cmake files using |
Updated, thanks! |
exporters/memory/CMakeLists.txt
Outdated
opentelemetry_exporter_in_memory_metric | ||
PUBLIC "$<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}/include>" | ||
"$<INSTALL_INTERFACE:include>" | ||
"$<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}/../otlp/include>") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
target_link_libraries(opentelemetry_exporter_in_memory_metric PUBLIC opentelemetry_otlp_recordable)
would be a better alternative here.But when we building without WITH_OTLP
, opentelemetry_otlp_recordable
will be unavailable.
Maybe this module should also be disabled when we build without WITH_OTLP
now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/** | ||
* @return Returns a shared pointer to this exporters InMemoryMetricData. | ||
*/ | ||
inline InMemoryMetricData &GetData() noexcept { return *data_; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment is outdated, this does not return a shared pointer.
@yxue could you please resolve the merge conflicts? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in C++ SIG meeting,
the in memory storage structure should not depend on protobuf:
using InMemoryMetricData =
opentelemetry::exporter::memory::InMemoryData<proto::metrics::v1::ResourceMetrics>;
Some refactoring needed to address this part.
617b90b
to
56ae726
Compare
Fixes # (issue) 1405
Changes
Please provide a brief description of the changes here.
For significant contributions please make sure you have completed the following items:
CHANGELOG.md
updated for non-trivial changes