MicroProfile OpenTelemetry group

153 views
Skip to first unread message

Emily Jiang

unread,
May 6, 2021, 6:06:34 PMMay 6
to MicroProfile

In MicroProfile 2021 program plan, we need to adopt OpenTelemetry and replace MicroProfile OpenTracing, mentioned in this issue. Since Pavol who was driving this effort has left MicroProfile, we really need to form a new group to start this activity. I would like to initiate the effort to form a group. I have created a doodle poll to form a group and choose a time slot to have an initial meeting. If you are interested in working on this, please add your name there and indicate your availability.

Thanks
Emily

Emily Jiang

unread,
May 13, 2021, 6:56:27 PMMay 13
to MicroProfile
Please join in the poll asap if you are interested. I will announce the first meeing tomorow. It looks like the slot on Monday has the most vote. I will create a meeting calendar tomorrow.

Thanks
Emily

Emily Jiang

unread,
May 14, 2021, 11:40:19 AMMay 14
to MicroProfile
Further to the previous notes, I have chosen the Monday slot 2:30-3:00 UK time when most of the interesting parties are available. I have added the meeting details to the MicroProfile google calendar. For the first meeting, we will use an alternative zoom and I will then work with MP marketing to have the future call details set up. Please look here for the joining details on Monday 17th May.

Thanks
Emily

Jason Lee

unread,
May 14, 2021, 1:09:22 PMMay 14
to microp...@googlegroups.com
Sounds good. Thanks, Emily!

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fb3a5d07-2821-49f2-bef3-3f847423010bn%40googlegroups.com.


--

Cesar Hernandez

unread,
May 14, 2021, 3:59:11 PMMay 14
to MicroProfile
Hi Emily,

Will the call be recorded for further distribution for those, like me, in America's time zone that won't be able to attend Monday 17th call?

Emily Jiang

unread,
May 14, 2021, 5:40:25 PMMay 14
to MicroProfile
Hi Cesar,
Sure, I will record the meeting.
Thanks
Emily

Emily Jiang

unread,
May 17, 2021, 11:33:07 AMMay 17
to MicroProfile
We met up today to discuss the plan for MicroProfile OpenTelemetry. For more details, please see the minutes and 1st recording (temporary link - this recording will be moved to the youtube playlist in due course). From now on, we will meet up weekly to move along this spec. John will create a playlist for MicroProfile OpenTelemetry to host meeting recordings. Once the playlist is created, all of the recordings will be located there.

The MP OpenTelemetry group proposed to create a github repo microprofile-opentelemetry to get the ball rolling. If I don't hear any objections by COB tomorrow, I will fire a bugzilla ticket to have the repo created. If you would like to join the upcoming calls, please find the time slot from MP calendar (see the Monday slot). From next week, we will use the zoom link from MicroProfile (Thank you John for setting it up for us!)

Thanks
Emily

Cesar Hernandez

unread,
May 17, 2021, 2:55:49 PMMay 17
to Eclipse MicroProfile
Thank you, Emily, for sharing the recording and agenda.

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/KrK47t_Dm0k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/95c1d675-aa3a-40fe-9a4c-a3473c40a364n%40googlegroups.com.


--
Atentamente:
César Hernández.

Ken Finnigan

unread,
May 20, 2021, 9:16:41 AMMay 20
to MicroProfile
Personally, I think this is premature.

I'm in the process of implementing OpenTelemetry for Quarkus, and right now I don't have a view on what, if anything, actually needs to be included in a specification.

Has anyone else implemented OpenTelemetry directly that would have a view on what could, or should, be specified? Until there's more than one vendor with implementation experience, I don't see how we can define a specification for it.

Ken

Amelia Eiras

unread,
May 20, 2021, 10:55:32 AMMay 20
to MPCommunity

Mark Little

unread,
May 20, 2021, 3:27:25 PMMay 20
to Micro Profile

Emily Jiang

unread,
May 20, 2021, 5:33:10 PMMay 20
to MicroProfile
Hi Ken,
The group will work together to collaborate on smallrye-opentelemetry and try it out first while working on the spec. The process might take time. We have to start working instead of waiting for others to implement it first. I think we have been talking about implementing MP OpenTelemtry early last year. Unfortunately, I have not seen much happening, hence a few of us get together to get the ball rolling.
Thanks
Emily

Jason Lee

unread,
May 20, 2021, 5:44:46 PMMay 20
to microp...@googlegroups.com
At this point, I think I agree, Ken. I've done some very preliminary work with OpenTelemetry in WildFly, and it's not clear what, if anything, an MP spec might include/add. To be completely transparent, I have little actual experience with OpenTelemetry to be able describe any rough edges, though I'm working to address that. :)

My interest in the group at this point is finding the answer to that question. Much like Micrometer and MP, it almost feels like a Ctrl-C+Ctrl-V scenario, but that's probably somewhat naive. :P I think, though, that such a group is a good forum for interested parties to meet and discuss that question. It was not my impression from the sole meeting that we're hoping to produce a spec soon, but that it was merely the kickoff of the process to determine the whats and whens of the topic.


Mark Little

unread,
May 21, 2021, 4:04:45 AMMay 21
to 'Emily Jiang' via MicroProfile
I think it’s good for people to have a forum in which to discuss. However, if the only implementation of this is SmallRye and everyone uses that in their own MP implementations, there’s still no compelling need for a specification. We should only be creating specifications where multiple approaches/implementations are in use and have been so for years. De facto open source standards (no specs) are still powerful and useful for communities.

Mark.


Emily Jiang

unread,
May 21, 2021, 6:32:20 AMMay 21
to MicroProfile
Mark, I think you meant to reply to this thread rather than just me. By the way, I disagree with this extra requirement for multiple implementations to exist in order for a spec to be released. I think it should be discussed under a different thread as it is not directly related to this thread. One thing I would like to point out is that some runtime will implement the spec after the spec was finalized.

In Jakarta EE, only one impl is required for a spec to be released and MicroProfile has been using this practice from the beginning. Is MP still trying to demonstrate agility and fail fast? MP community have been releasing specs with one implementation and then later on more implementations come in. If we wait for multiple implementations to release a spec, I fear it might run into a chick egg situation.
If more responses are happening on the process topic, please start a new thread.

Thanks,
Emily



--
Thanks
Emily

Emily Jiang

unread,
May 21, 2021, 6:35:50 AMMay 21
to MicroProfile
Well said, Jason!
Thanks
Emily

Mark Little

unread,
May 21, 2021, 7:26:29 AMMay 21
to MicroProfile
Hi Emily.

Yes, I meant to hit ReplyAll.

We'll have to agree to disagree then on how good standards are meant to be driven :) And within Red Hat we'll review whether involvement with single-specification efforts is something we want to do. It may not be.

Mark.

Ken Finnigan

unread,
May 21, 2021, 7:59:59 AMMay 21
to MicroProfile
On Fri, May 21, 2021 at 6:32 AM 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> wrote:
Mark, I think you meant to reply to this thread rather than just me. By the way, I disagree with this extra requirement for multiple implementations to exist in order for a spec to be released. I think it should be discussed under a different thread as it is not directly related to this thread. One thing I would like to point out is that some runtime will implement the spec after the spec was finalized.

Mark wasn't saying there need to be multiple implementations of a spec for it to be released. He's saying there need to be multiple implementations using an idea or piece of innovation before a spec is even warranted. It's what I was saying previously about there being no need for a specification until vendors other than Red Hat have explored OpenTelemetry, understand it, and have experiences implementing it.
 

Erin Schnabel

unread,
May 21, 2021, 8:12:12 AMMay 21
to MicroProfile
 I would add: OpenTelemetry is _already_ a spec. Do we need another one?

Ken Finnigan

unread,
May 21, 2021, 8:16:16 AMMay 21
to MicroProfile
A specification body is not the place to experiment with new technology for the first time and come up with a spec at the same time. Maybe it makes sense to have a group playing in the MP Sandbox with ideas, that's fine, but creating an MP OpenTelemetry call, an MP OpenTelemetry repository, etc, has implicitly indicated a specification WILL come out of it. And I just don't see that as being the case at present.

If vendors are waiting for others to implement OpenTelemetry first, then maybe it's a good thing for MP to wait as well.

Totally agree there hasn't been much happening around OpenTelemetry in MP, but that's because we've been working with the OpenTelemetry Java community on solving any issues.

A specification should be a place to align different vendors towards a common solution. Right now, that's happening in OpenTelemetry as most APM vendors (Datadog, Splunk, Honeycomb, New Relic, Lightstep, etc) are all working in the OpenTelemetry communities to coalesce around a common solution. If MP doesn't become a part of that community and help drive solutions to our problems, we risk coming up with a lopsided solution that might suit MP vendors but doesn't gel with the wider OpenTelemetry community.

Ken

Mark Little

unread,
May 21, 2021, 8:50:02 AMMay 21
to MicroProfile

Jason Lee

unread,
May 21, 2021, 10:18:58 AMMay 21
to microp...@googlegroups.com
On Fri, May 21, 2021 at 7:12 AM Erin Schnabel <ebul...@redhat.com> wrote:
 I would add: OpenTelemetry is _already_ a spec. Do we need another one?


That's what I'm wondering (which is where my copy/paste "joke" came from :). It doesn't make sense to make a new spec just to check a box. Time will tell, I guess.

Jason Lee

unread,
May 21, 2021, 10:36:18 AMMay 21
to microp...@googlegroups.com


On Fri, May 21, 2021 at 7:16 AM Ken Finnigan <k...@kenfinnigan.me> wrote:
A specification body is not the place to experiment with new technology for the first time and come up with a spec at the same time. Maybe it makes sense to have a group playing in the MP Sandbox with ideas, that's fine, but creating an MP OpenTelemetry call, an MP OpenTelemetry repository, etc, has implicitly indicated a specification WILL come out of it. And I just don't see that as being the case at present.

If vendors are waiting for others to implement OpenTelemetry first, then maybe it's a good thing for MP to wait as well.

Totally agree there hasn't been much happening around OpenTelemetry in MP, but that's because we've been working with the OpenTelemetry Java community on solving any issues.

A specification should be a place to align different vendors towards a common solution. Right now, that's happening in OpenTelemetry as most APM vendors (Datadog, Splunk, Honeycomb, New Relic, Lightstep, etc) are all working in the OpenTelemetry communities to coalesce around a common solution. If MP doesn't become a part of that community and help drive solutions to our problems, we risk coming up with a lopsided solution that might suit MP vendors but doesn't gel with the wider OpenTelemetry community.

Absolutely. Innovation in specs rarely works out well. To be honest, at this point, I'd be happy with simply adopting (and joining in on) what's going on in the OpenTelemetry community, but, again, I'm pretty new to the space, so a big grain of salt. :) I don't know that an MP-specific spec for just marketing purposes, say, makes a whole lot of sense. (I'm not saying that's where we're heading, but it *could* happen :).

And you're probably right that creating repos, etc. might be a bit premature, but I still think the calls/emails are a good forum to discuss *if* something should happen under the MP umbrella. A must, though, for those of us on the MP side, is to make sure we're involved in things Over There. I think that will give us a better view of what the technology currently offers, as well as making any possible future efforts better received by the community, rather than a bunch of tag-alongs riding coattails. :) From what I've used of it so far, it seems pretty solid, though telemetry is not my strong suit.

So, for my part, I'm absolutely interested in being part of the conversation (both here and in otel proper). I think it wise that we discuss as a group and have our ducks in a row should we see a need (that we can't work with upstream to fill), but I'm with Ken that we shouldn't rush to something just to have something. 

Roberto Cortez

unread,
May 21, 2021, 11:09:16 AMMay 21
to microp...@googlegroups.com
Hi,

To clarify something on the technical part and the usar of SmallRye OpenTelemetry: https://github.com/smallrye/smallrye-opentelemetry.

This is just a PoC project, is not being used in any place and it was abandoned in favour of doing the OpenTelemetry work in Quarkus directly.

Of course, this is open-source, and everyone is more than welcome to use it and contribute to it (even to other SmallRye projects :) ). 

Cheers,
Roberto

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

Bruno Baptista

unread,
May 21, 2021, 11:44:07 AMMay 21
to microp...@googlegroups.com

On 21/05/21 13:12, Erin Schnabel wrote:
>  I would add: OpenTelemetry is _already_ a spec. Do we need another one?
>

I think Erin's point is important.

MP OpenTracing was also based on an existing spec. I don't think this is
about having just one implementation, it's about creating a standard
Java way to interact with the existing OpenTelemetry spec.

I'm concerned on using MP OpenTracing, which has no future now. I would
prefer to have an evolution and be able to use it.

Also, the new standard could be used to instrument other MP specs, if
needed, in the way we use MP Config.

In this case, having just one implementation is not very important
because there is a Standard already, we should just define how to use it
in Java.

Cheers

Bruno


Emily Jiang

unread,
May 21, 2021, 5:46:33 PMMay 21
to MicroProfile


>  I would add: OpenTelemetry is _already_ a spec. Do we need another one?
>
OpenAPI, Open Tracing are also specs. MP OpenAPI, MP Open Tracing were created by trying to bring these specs to cloud native world:o. Hence the need to look at OpenTelemetry.

As Bruno pointed out, since MP OpenTracing is pretty dead technology. We need to look whethher and how to swap it out and replace with the successor which is OpenTelemetry.

The group gets together to brainstrom and tries to look for a way how to get OpenTelemetry to replace OpenTracing. This is open community. Why not encourage people come together to solve a common problem? I would be quite worried if developers were told not to get together to work on a problem. Maybe at the end of the experiment, the group conclude just using OpenTelemetry directly and here is why. That is also something useful. On the other hand, maybe the best way is to use what the current MP OpenTracing way to consume OpenTelemetry. There are many outcomes. Some time and effort need to be spent to answer the questions of whether, why, hows.
Emily

Reza Rahman

unread,
May 21, 2021, 5:53:33 PMMay 21
to microp...@googlegroups.com
I agree with Emily. I would expect MicroProfile to explore adding some kind of support for OpenTelemetry at some point. To me this kind of exploration is one of the true value adds for MicroProfile.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On May 21, 2021, at 5:46 PM, 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> wrote:



>  I would add: OpenTelemetry is _already_ a spec. Do we need another one?
>
OpenAPI, Open Tracing are also specs. MP OpenAPI, MP Open Tracing were created by trying to bring these specs to cloud native world:o. Hence the need to look at OpenTelemetry.

As Bruno pointed out, since MP OpenTracing is pretty dead technology. We need to look whethher and how to swap it out and replace with the successor which is OpenTelemetry.

The group gets together to brainstrom and tries to look for a way how to get OpenTelemetry to replace OpenTracing. This is open community. Why not encourage people come together to solve a common problem? I would be quite worried if developers were told not to get together to work on a problem. Maybe at the end of the experiment, the group conclude just using OpenTelemetry directly and here is why. That is also something useful. On the other hand, maybe the best way is to use what the current MP OpenTracing way to consume OpenTelemetry. There are many outcomes. Some time and effort need to be spent to answer the questions of whether, why, hows.
Emily


On Friday, May 21, 2021 at 4:44:07 PM UTC+1 Bruno Baptista wrote:

On 21/05/21 13:12, Erin Schnabel wrote:
>  I would add: OpenTelemetry is _already_ a spec. Do we need another one?
>

I think Erin's point is important.

MP OpenTracing was also based on an existing spec. I don't think this is
about having just one implementation, it's about creating a standard
Java way to interact with the existing OpenTelemetry spec.

I'm concerned on using MP OpenTracing, which has no future now. I would
prefer to have an evolution and be able to use it.

Also, the new standard could be used to instrument other MP specs, if
needed, in the way we use MP Config.

In this case, having just one implementation is not very important
because there is a Standard already, we should just define how to use it
in Java.

Cheers

Bruno


--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

Mark Little

unread,
May 24, 2021, 4:41:14 AMMay 24
to 'Emily Jiang' via MicroProfile
Emily, innovate in some upstream community, ideally communities. Then bring those findings back to MP to determine if a standard needs to be created.

Mark.


On 21 May 2021, at 22:46, 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> wrote:



>  I would add: OpenTelemetry is _already_ a spec. Do we need another one? 
> 
OpenAPI, Open Tracing are also specs. MP OpenAPI, MP Open Tracing were created by trying to bring these specs to cloud native world:o. Hence the need to look at OpenTelemetry.

As Bruno pointed out, since MP OpenTracing is pretty dead technology. We need to look whethher and how to swap it out and replace with the successor which is OpenTelemetry.

The group gets together to brainstrom and tries to look for a way how to get OpenTelemetry to replace OpenTracing. This is open community. Why not encourage people come together to solve a common problem? I would be quite worried if developers were told not to get together to work on a problem. Maybe at the end of the experiment, the group conclude just using OpenTelemetry directly and here is why. That is also something useful. On the other hand, maybe the best way is to use what the current MP OpenTracing way to consume OpenTelemetry. There are many outcomes. Some time and effort need to be spent to answer the questions of whether, why, hows. 
Emily


On Friday, May 21, 2021 at 4:44:07 PM UTC+1 Bruno Baptista wrote:

On 21/05/21 13:12, Erin Schnabel wrote: 
>  I would add: OpenTelemetry is _already_ a spec. Do we need another one? 
> 

I think Erin's point is important. 

MP OpenTracing was also based on an existing spec. I don't think this is 
about having just one implementation, it's about creating a standard 
Java way to interact with the existing OpenTelemetry spec. 

I'm concerned on using MP OpenTracing, which has no future now. I would 
prefer to have an evolution and be able to use it. 

Also, the new standard could be used to instrument other MP specs, if 
needed, in the way we use MP Config. 

In this case, having just one implementation is not very important 
because there is a Standard already, we should just define how to use it 
in Java. 

Cheers 

Bruno 



-- 
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

Emily Jiang

unread,
May 24, 2021, 5:36:09 AMMay 24
to MicroProfile
Mark,
I think there might be a misundestanding here. This initative is not about adding any innovation to OpenTelemetry, but to bring OpenTelemetry to be consumable by Cloud-Native applications via MP OpenTelemetry. This effort is to replace MP OpenTracing with MP OpenTelemetry to align with the new spec OpenTelemetry, the successor of OpenTracing.
Thanks,
Emily

Mark Little

unread,
May 24, 2021, 5:46:51 AMMay 24
to microp...@googlegroups.com
Why does this have to be under MP? There’s an existing OpenTelemetry open source community :)


Mark.


Bruno Baptista

unread,
May 24, 2021, 7:08:17 AMMay 24
to microp...@googlegroups.com

Can you use MP Config to configure opentelemetry-java-instrumentation ?

Bruno

Erin Schnabel

unread,
May 24, 2021, 7:27:41 AMMay 24
to microp...@googlegroups.com
Quarkus will be able to via an extension, yes. And Liberty should also have no trouble figuring out how to configure open telemetry in a way native to liberty (which may or may not be mp config based, but no one needs to know)

There is a push for open telemetry to be fine using agents, which changes the config picture a lot (every runtime for themselves to sort out what their favorite recommendation is).

Unless/until more participants try working with open telemetry on their runtimes, it is premature to think about a spec. There is a learning curve here. Climb some of it first, is all we are saying.

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/KrK47t_Dm0k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f13dec48-7351-2233-d5fb-847ca14f04e1%40gmail.com.
--
Thanks,
Erin
 
------
Erin Schnabel <ebul...@redhat.com>
@ebullientworks

Erin Schnabel

unread,
May 24, 2021, 7:29:42 AMMay 24
to microp...@googlegroups.com
Ugh. I should not attempt email via phone on Monday morning. I hope you understand what I am saying despite messed up prepositions. 

Bruno Baptista

unread,
May 24, 2021, 7:35:59 AMMay 24
to microp...@googlegroups.com

All good Erin,

This just saddens me a bit because I will soon drop the use of MP OpenTracing and move away from a MP lib, probably to never come back...

Bruno

Erin Schnabel

unread,
May 24, 2021, 8:08:24 AMMay 24
to microp...@googlegroups.com
I will say the hard thing: that may be ok. 

Ken Finnigan

unread,
May 26, 2021, 9:23:23 AMMay 26
to MicroProfile
I have a few additional comments:
  • It was mentioned we do the same thing with OpenAPI. Frankly, the more I've played with MP OpenAPI the more I lean towards it being another candidate for removal and just use Swagger directly. That's a whole other discussion though
  • A comment was made that MP needs a spec to make OpenTelemetry "consumable by Cloud-Native applications". MP is not the sole arbiter of what makes an application cloud-native, and it's not productive to have the view that a project, such as OpenTelemetry, which is hosted/run/promoted by CNCF, wouldn't be cloud-native. If it is proven to not be "cloud-native" in any way, then we should be helping OpenTelemetry fix it rather than creating customizations for MP only.
  • https://docs.google.com/document/d/1BaABdTDjDL6OnYAKm4WQxdBSvKS7-GKzn4v6iOPE-uY/edit#heading=h.5is7rlg2ew9f already defines a proposed spec release in Feb 2022, which already pushes any exploration towards the perspective of seeking a spec in the future, which is not the correct approach to this problem
  • OpenTelemetry is far more than tracing. From an API perspective, it also includes metrics and logging! It's not possible to only bring in OpenTelemetry for tracing, there needs to be a wider discussion around metrics (such as Micrometer) and how all the pieces will fit together.
  • Having a forum for discussion and exploration is completely fine, but past experience shows having those discussions in MicroProfile leads to the presumption of a spec in the future. Maybe there will be, but there shouldn't be the expectation of a spec from day one as it sets the discussions on that path without considering and exploring all possibilities.
Ken

Amelia Eiras

unread,
May 26, 2021, 9:28:59 AMMay 26
to microp...@googlegroups.com
Beautifully stated, Ken! 💛
Specially point 5. 

Sent from my IPhone

On May 26, 2021, at 6:23 AM, Ken Finnigan <k...@kenfinnigan.me> wrote:



Mark Little

unread,
May 27, 2021, 5:19:41 AMMay 27
to 'Emily Jiang' via MicroProfile
+1


---
Mark Little
mli...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873





Emily Jiang

unread,
May 27, 2021, 6:53:11 AMMay 27
to MicroProfile
We all have views on the specifications, sometimes the views are different and it is fine. Besides, I am not sure whether there is a single spec from Jakarta and MicroProfile is liked by everyone. As long as majority of end users find a spec is useful, I would say the spec is useful.
One thing I would like to clarify: MP OpenTelemetry group is to start collaborating and understand how, why and what questions. There is no promise that a spec will be released. Besides, releasing a spec requires MP WG to vote. We have formal process for this.

With this, I think we are in agreement that the group is starting the discussion and exploration. Whether a spec will be released or not will depend on the experiment and progress review etc.

Thanks
Emily

Bruno Baptista

unread,
May 27, 2021, 7:07:31 AMMay 27
to microp...@googlegroups.com

Hi All,

I think it's wise to have an OpenTelemetry group to explore without the promise of a MP OpenTelemtry spec.

As someone suggested, it might be preferable to just contribute to OpenTelemtry directly. We need to hack around it.

Anyway, Observability is key to cloud native apps and MP should do some work around it.  To start with, a working group for OpenTelemetry would be great.

Cheers

Bruno

Emily Jiang

unread,
May 27, 2021, 7:18:41 AMMay 27
to MicroProfile
+1 Bruno! Thank you Bruno for sharing your thoughts from an end user's perspective and putting effort to contribute towards this experiment!

Thanks
Emily



--
Thanks
Emily

Reply all
Reply to author
Forward
0 new messages