-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
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. |
@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") |
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. |
@rahjesh-vunet are those collectors running on your premises or run by a customer of yours? |
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. |
You can see the below diagram in our product documentation page. https://vunetsystems.com/vuapp360/ 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. |
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. |
Yes. Thanks. |
Follow up to #4115, as my comment has not been addressed before merging:
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
The text was updated successfully, but these errors were encountered: