Point URL for VuNet Systems to documentation about opentelemetry.io HOT 9 CLOSED

@svrnm

Yes.

Thanks.

from opentelemetry.io.

@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.

from opentelemetry.io.

@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")

from opentelemetry.io.

@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.

from opentelemetry.io.

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

from opentelemetry.io.

@svrnm

The collectors are running on the customer's premises.

from opentelemetry.io.

@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.

from opentelemetry.io.

@svrnm

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.

from opentelemetry.io.

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.

from opentelemetry.io.