Skip to content
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

Point URL for VuNet Systems to documentation #4151

Closed
svrnm opened this issue Mar 13, 2024 · 9 comments
Closed

Point URL for VuNet Systems to documentation #4151

svrnm opened this issue Mar 13, 2024 · 9 comments
Labels
bug Something isn't working

Comments

@svrnm
Copy link
Member

svrnm commented Mar 13, 2024

Follow up to #4115, as my comment has not been addressed before merging:

url: 'https://vunetsystems.com/vuapp360/'

This URL does not point to a documentation showing OTLP integration. We also need to know where and how the distribution looks like as distrubtion: true is set.

cc @rahjesh-vunet, @cartermp

@svrnm svrnm added the bug Something isn't working label Mar 13, 2024
@rahjesh-vunet
Copy link
Contributor

rahjesh-vunet commented Mar 13, 2024

@svrnm

The vuapp360 is our application observability solution. It uses traces, logs and metrics from application to get the insights on application performance. It uses the opentelemetry for traces collection from the applications. We use the opentelemetry auto instrumentation for collecting traces from Java, .NET, NodeJS and JavaScript applications. We are using our own distribution of Opentelemetry collector.

In the product page of vuapp360 (https://vunetsystems.com/vuapp360/) in the "Instrumentation and Ingestion through OpenTelemetry" section, you can see high level architecture which explains what I mentioned above.

We have our own distribution of opentelemetry collector with our own exporter. This is part of our observability backend. The traces is one of the data stream for our solution. So our distribution of opentelemetry is an integrated part of our solutions.

Some of them are not available as a public documentation. Please advise what needs to be done from my end.

@svrnm
Copy link
Member Author

svrnm commented Mar 13, 2024

@rahjesh-vunet, from your description this sounds like you are not providing native OTLP ingestion for your endpoint (I am inferring that from "with our own exporter")

@rahjesh-vunet
Copy link
Contributor

@svrnm

Applications are sending the traces to our OTel collector distribution using grpc and http receivers. We are having a set of processors which we use in our distribution. We are using the Kafka exporter from the contrib to send it to our backend. The otlp and otlphttp exporters are available in our distribution. Sometimes we use these for sending the traces to other systems.

The data ingestion uses the OTLP only.

@svrnm
Copy link
Member Author

svrnm commented Mar 13, 2024

@rahjesh-vunet are those collectors running on your premises or run by a customer of yours?

@rahjesh-vunet
Copy link
Contributor

@svrnm

The collectors are running on the customer's premises.

@svrnm
Copy link
Member Author

svrnm commented Mar 13, 2024

@svrnm

The collectors are running on the customer's premises.

So, if your customers are using kafka exporter to communicate with your backend, your backend is not "native OTLP" as per the definition of our vendor page, please update that entry accordingly.

@rahjesh-vunet
Copy link
Contributor

@svrnm

You can see the below diagram in our product documentation page. https://vunetsystems.com/vuapp360/

image

As you can see, the vuapp360 contains everything including the Otel collector. The vuapp360 is not a saas product like others. It is installed in the customer premises. It can also be available as saas in the future.

We will install vuapp360 on the customer premises and provide the ingestion URL to them. The ingestion url is the URL of the OTel collector. Our client will use the otel SDK to instrument their application and send the traces to Otel collector of vuapp360.

@svrnm
Copy link
Member Author

svrnm commented Mar 13, 2024

That image does not really indicate where the opentelemetry collector lives, but I can infer that from your text. So if I understand you correctly the OpenTelemetry collector is part of your solution, to provide OTLP ingestion. So then, yes, this makes sense. Thanks for clarification.

@rahjesh-vunet
Copy link
Contributor

@svrnm

Yes.

Thanks.

@svrnm svrnm closed this as completed Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants