open-telemetry
Adding mishmash io to vendors list
Adding mishmash io to the vendors list.
Generally, we use OpenTelemetry as a tool in our software development process. Recently we started open-sourcing our code here:
https://github.com/mishmash-io/opentelemetry-server-embedded
At the moment the repository above contains only a few tools:
- a simple java OTLP server
- an Apache Druid ingestion extension - to load OTLP data into Apache Druid
Coming up:
- Apache Superset visualizations
- ... a few more integrations...
All of the above is released under Apache lincense.
Would be nice to add some links, hopefully people might find our tools helpful! :)
![linux-foundation-easycla[bot] avatar](https://avatars.githubusercontent.com/in/17893?v=4 "Published by a pub.dev verified publisher"){kind=small}
@arusevm what you shared here does not look like a vendor. It's a tool and you have added it to the registry already.
Generally, we use OpenTelemetry as a tool in our software development process. Recently we started open-sourcing our code here:
Based on that I would argue that you are an "adopter": https://opentelemetry.io/ecosystem/adopters/
@svrnm Well, you might right, I'm a bit confused too...
I got into this PR (towards the vendors list) because of this text (taken from the current vendors page:
A non-exhaustive list of organizations offering solutions that consume OpenTelemetry natively via OTLP, such as observability backends and observability pipelines.
True, we only started open-sourcing what we've accumulated internally (the Druid extension is among the very first), but the way I get the OpenTelemetry docs - an observability backend refers to where an OTEL pipeline ends, right? Or am I wrong? Like - OpenTelemetry users set up their agents, build pipelines with the collector and ultimately point these pipelines to an OTLP backend?
(Sorry about the long question - I'm currently trying to 'harmonize' the docs on our side so that they fit better - avoiding, for example, confusing use of terminology...)
Back to the topic - true, our open sources (current and coming) are not a complete backend (just like Skywalking is, for example), but they're - I would say - tools for people to build their own observability backends. Say, we've released the Druid extension and we're currently publishing Superset visualizations, there will be soon a PR towards the demo app repo where you get the demo app + extended Druid + ready-made Superset visualizations...
And on top of all that - we mostly open-source our code for the benefit of software developers (as opposed to DevOps, for example) - those who would like to develop their own OTLP-based solutions...
So, yeah, that's confusing me - I don't really know where should all of that go, eventually... if at all. :) Suggestions are welcome!
hey @arusevm,
no worries with your long questions and explanations, this really helps me to understand what you try to accomplish. From what I read you provide "building blocks" of a backend/pipeline leveraging existing OSS solutions (druid, superset), which is an unusual take on that topic, but an interesting one for sure, and especially since it is also open source one valuable to end users. Kudos to that.
I think the problem I see is that you write "mishmash.io" as the name of that backend/vendor but then I am clicking on a link and land on "OpenTelemetry Data Sources for Java (and other)" while I would expect that mismash is able to consume OpenTelemetry directly, which seems not to be the case?
So (while very long) a more fitting name would be "OpenTelemetry Data Sources for Java by mishmash.io", or you give that project a name and link to that (you can still write "PROJECT NAME (by mishmash.io)" in the description.
Note, that there are guidelines how to use the OpenTelemetry trademark (owned by Linux Foundation):
https://www.linuxfoundation.org/legal/trademark-usage
They ask you to not name something "OpenTelemtry <X>", so "OpenTelemetry Data Sources" is already something you might want to change.
Hi @svrnm,
Thanks for the heads up! :) Also, if you think that building blocks for... is an unusual take on the topic... Wait until we get to publishing tests instrumentation (like - unit/integration tests)... 'cos that's how we ended up adopting OpenTelemetry - instrumenting various tests (on our own code) - so that we can track the quality of our software... And it's also why we started open-souring all those little components - we just think it is, yes, very unorthodox, but still - a really good practice in software development, good enough to be worth sharing...
Thanks for the suggestions too! There's is (in our content, not only on GitHub) a lot of confusion about what's our product, what are integrations of our product with something else, and what are just tools that we built for ourselves, like it is the case above with OTEL. There's another ongoing effort to clarify these, I just happen to be several laps ahead of it :)
I will change the title based on your suggestion, yes. Also, I know about the trademark violations ... Sorry about that :( Will fix them too, thanks for pointing it out. There are a number of these throughout, including, say, cases where it says OpenTelemetry, but should technically be OTLP, there are a couple of sections where I'm not 100% sure it is clear that what we say about OpenTelemetry is our opinion. Not that it differs too much from what OpenTelemetry thinks of itself, but still, it's good manners, if you like :)
Will be fixing the above pretty soon and will come back here once I think it's okay. In the meantime though - will really appreciate other feedback you (or somebody else at OTEL) might come up with... Don't know if there's a Slack channel or something that's more appropriate for the topics here?
Alright, changed the title and description a bit... If you have some spare time - you can take a look at it again, see if you have new suggestions or anything :)
Alright, changed the title and description a bit... If you have some spare time - you can take a look at it again, see if you have new suggestions or anything :)
thanks for the update and apologies for the delay in response, I was out of office.
The title seems to be in line with the guidelines (I am not a lawyer, disclaimer).
For this to be added I still don't think it's correct to have "mishmash io" as the name of the entry and then linking to the OSS project. It's still confusing for end users that if they go to mishmash.io the official product you are offering is distinctly different from that.
For this to be added I still don't think it's correct to have "mishmash io" as the name of the entry and then linking to the OSS project. It's still confusing for end users that if they go to mishmash.io the official product you are offering is distinctly different from that.
Alright, sounds reasonable... Plus, I don't really insist on having 'mishmash io' there, or adding an entry to the vendors list...
What I would like really is, if possible, to add somewhere a message of the sort "Hey, if you'd like to do some analytics on your telemetry - here are some fully open source things you can combine to build yourselves some analytics backends".
Or, another way of looking at it - in the ecosystem registry we'll publish some more components, but the intent there is to list individual components, does not put a focus on how people can combine them...
Don't know if you've envisoned something like this (probably not :) ... Just asking for suggestions now, if anything comes to mind. Again, I don't insist on mentioning 'mishmash io' at all - I can change the name of the 'vendor'. Or I can drop this PR too... Just asking if you have any suggestions before I do anything :)
following up on this, sorry for the delay:
Thanks for your feedback and suggestions. I recognize that ecosystem pages are far from optimal and there are many ways to optimize them, but we currently do not have the capacity to improve them. If you (or anyone) is willing to work on that, I would be happy, until then we keep them as they are today.