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
lib/protoparser: adds opentelemetry parser #2570
Conversation
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
0439bdf
to
88c4b16
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #2570 +/- ##
==========================================
- Coverage 61.06% 57.58% -3.48%
==========================================
Files 385 310 -75
Lines 71951 52184 -19767
==========================================
- Hits 43939 30052 -13887
+ Misses 25605 20237 -5368
+ Partials 2407 1895 -512
☔ View full report in Codecov by Sentry. |
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
This pull request increases VictoriaMetrics binary size from 19MB to 29MB, e.g. by around 50%. This is too big price to pay for the inclusion of OpenTelemetry-compatible JSON and protobuf data ingestion protocols :( All the existing data ingestion protocols supported by VictoriaMetrics increase binary size by a few tens of kilobytes in worst case. It would be great trying to decrease the binary size overhead for this change before merging it into VictoriaMetrics. In the mean time it is possible to export data from OpenTelemetry collector client to VictoriaMetrics via one of the supported data ingestion protocols: |
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.
See #2570 (comment)
@valyala might be nice to add to the VictoriaMetrics docs, some If native OLTP could be implemented without increasing the footprint requirements for VictoriaMetrics, that would be nice too, but is a longer discussion/implementation. |
+1 Hope you can find a solution to this one, this would be a great addition. |
@f41gh7 Is there any news on the merger of this feature? it would be great to have native support for this new protocol |
Hi VictoriaMetrics Developers! |
Will take a look and update dependency soon. |
a1990f0
to
c6f3384
Compare
@valyala PR was updated, but any way it increases result binary size by 5MB because of protobuf json parser dependencies. It's possible to optimize it further, but I'm not sure, that it worth it. |
+5MB is better than +10MB from the previous attempt, but is is still too much for a simple parser for metrics in OpenTelemetry protocol when comparing to binary footprints for other data ingestion protocols supported by VictoriaMetrics :( I believe we can write our own implementation for the OpenTelemetry metrics parser, which will increase the resulting binary size by no more than 100Kb in the worst case. |
c6f3384
to
c17d5b1
Compare
@valyala changed implementation - rewritten parser from scratch with default protobuf generator. Produced binary size almost the same as it was before adding this feature. |
c17d5b1
to
db514d9
Compare
@f41gh7 Do you guys have an rough idea when you will be releasing a version with this? |
We had plans to merge this pull request in the upcoming v1.86.0 release, but it won't be included there because of issues with the increased binary size :( The latest version of the pull request still increases VictoriaMetrics binary size by 4MiB from 19MiB to 23MiB. I hope these issues will be resolved until the next release, so the support for OpenTelemetry protocol will be added into the next release after v1.86.0. Side note: the OpenTelemetry metrics protocol specification is an over-engineered nightmare comparing to other popular data ingestion formats such as Influx line protocol, Graphite plaintext protocol and Prometheus text exposition format. This introduces non-trivial overhead to users, clients and server, which have to deal with it. For example, a simple
|
4fa7282
to
7dfec41
Compare
@valyala changed proto compiler. Without any external dependency it increases binary size for 1MB approx. |
not all heroes wear capes) |
@hagen1778 @f41gh7 Small PR to fix the lint issues in this branch: #3943 |
Great work guys! Hope this is comming soon. |
Any good news on this merger? |
Any update on this by any chance? |
85a3381
to
8d10087
Compare
app/{vmagent,vminsert}: adds opentelemetry ingestion path Adds ability to ingest data with opentelemetry protocol protobuf and json encoding is supported data converted into prometheus protobuf timeseries each data type has own converter and it may produce multiple timeseries from single datapoint (for summary and histogram). only cumulative aggregationFamily is supported for sum(prometheus counter) and histogram. Apply suggestions from code review Co-authored-by: Roman Khavronenko <roman@victoriametrics.com> updates deps fixes tests wip wip wip wip lib/protoparser/opentelemetry: moves to vtprotobuf generator go mod vendor lib/protoparse/opentelemetry: reduce memory allocations
8d10087
to
b3c955a
Compare
Closer and closer to have this merged, there will be a big party for this one 🥳 |
I hope to see some updates soon. |
- Remove support for JSON parsing, since it is too fragile and is rarely used in practice. The most clients send OpenTelemetry metrics in protobuf. The JSON parser can be added in the future if needed. - Remove unused code from lib/protoparser/opentelemetry/pb and lib/protoparser/opentelemetry/proto - Do not re-use protobuf message between ParseStream() calls, since there is high chance of high fragmentation of the re-used message because of too complex nested structure of the message.
@f41gh7 , thanks for the pull request! |
* lib/protoparser: adds opentelemetry parser app/{vmagent,vminsert}: adds opentelemetry ingestion path Adds ability to ingest data with opentelemetry protocol protobuf and json encoding is supported data converted into prometheus protobuf timeseries each data type has own converter and it may produce multiple timeseries from single datapoint (for summary and histogram). only cumulative aggregationFamily is supported for sum(prometheus counter) and histogram. Apply suggestions from code review Co-authored-by: Roman Khavronenko <roman@victoriametrics.com> updates deps fixes tests wip wip wip wip lib/protoparser/opentelemetry: moves to vtprotobuf generator go mod vendor lib/protoparse/opentelemetry: reduce memory allocations * wip - Remove support for JSON parsing, since it is too fragile and is rarely used in practice. The most clients send OpenTelemetry metrics in protobuf. The JSON parser can be added in the future if needed. - Remove unused code from lib/protoparser/opentelemetry/pb and lib/protoparser/opentelemetry/proto - Do not re-use protobuf message between ParseStream() calls, since there is high chance of high fragmentation of the re-used message because of too complex nested structure of the message. * wip * wip * wip --------- Co-authored-by: Aliaksandr Valialkin <valyala@victoriametrics.com>
No way! |
FYI, this pull request has been included in VictoriaMetrics v1.92.0. |
Hi @valyala , When I use
The way I get the json data for the metrics is by dumping the state in a file like this: reader = InMemoryMetricReader()
provider = MeterProvider(metric_readers=[reader])
set_meter_provider(provider)
meter = get_meter_provider().get_meter("MIT-Metrics", "0.1.2")
state = reader.get_metrics_data().to_json()
logging.info(f"State:\n {state}")
with open(output_file, "w") as f:
json.dump(state, f) Is this a supported way of reporting metrics into Victoria metrics? |
@sumukhs VictoriaMetrics supports opentelemetry only with protobuf encoding. json isn't supported atm. |
FYI, VictoriaMetrics v1.93.0 has the following enhancements for Opentelemetry:
|
FYI, the commit dd25049 switches parsing of OTEL protobuf messages from |
app/{vmagent,vminsert}: adds opentelemetry ingestion path
Adds ability to ingest data with opentelemetry protocol
protobuf and json encoding is supported
data converted into prometheus protobuf timeseries
each data type has own converter and it may produce multiple timeseries
from single datapoint (for summary and histogram).
only cumulative aggregationFamily is supported for sum(prometheus
counter) and histogram.
For #2424