signoz VS opentelemetry-specification

Give https://github.com/SigNoz/signoz a look

Sure, we will include dynatrace and elastic in our next update. The line items are mostly based on how the product does the billing u/RabidWolfAlpha. Datadog has an SKU-based billing structure. If you visit their pricing page, they list down a lot of products, and they bill each of them separately. For example, APM and infrastructure monitoring are two separate paid products. SigNoz is based on usage-based pricing; only pay for how much data you ingest. Billing is based on how much logs, metrics and traces you ingest. There is no separate billing for APM and infrastructure monitoring. SigNoz has most features that Datadog provides, except things like network monitoring, Cloud SIEM, etc. Are you looking for any specific feature? p.s SigNoz is also open source: our github repo.

We are building OpenSource Observability at SigNoz. Have a look at https://github.com/SigNoz/signoz

SigNoz? https://github.com/SigNoz/signoz

Folks on this thread might want to check out SigNoz (https://github.com/SigNoz/signoz). It's an open source alternative to Datadog.

I am one of the maintainers at SigNoz. We have come across many more horror stories around Datadog billing while interacting with our users.

We recently did a deep dive on pricing, and found some interesting insights on how it is priced compared to other products.

Datadog's billing has two key issues:

I am not sure when you tried OpenTelemetry, but it is decently mature now, esp. for tracing. I am a maintainer at SigNoz (https://github.com/signoz/signoz) and we have good support for tracing using Otel for most of the common frameworks.

I agree it was a bit rapidly evolving in early days, but now its much more mature.

You can check out our docs for distributed tracing here - https://signoz.io/docs/instrumentation/

We are building SigNoz (https://github.com/SigNoz/signoz) - an open source alternative to DataDog. We are natively based on opentelemetry and see lots of our users very interested in that.

As mentioned in some other places in the thread, DataDog pricing is very unpredictable and high - and I think more open standards based solutions are the way forward which provides users more predictability and flexibility

You should check out SigNoz (https://github.com/SigNoz/signoz) - It's an open source alternative to DataDog with metrics, traces and logs in a single application. You can just self host it yourself or try the hosted version.

PS: I am one of the maintainers at SigNoz

There's also Signoz (https://signoz.io) a YC-backed company but open source with (recently) paid hosted.

One update to this: we proposed replacing the count suffix in OpenTelemetry with total to match Prometheus/OpenMetrics. That discussion resulted in the count suffix being removed from the OpenTelemetry semantic conventions. We'll soon update our metric from being called function.calls.count to just function.calls and the generated Prometheus queries will refer to function_calls_total. That resolves one of the main conflicts between the two specs.

OpenTelemetry is a standard for implementing telemetry in your applications. It provides a specification, containing the requirements that all implementations should follow as well as some implementations for major languages, including an API and a SDK to interact with it.

At this point, we are about to do the real work where we have to configure OpenTelemetry and export telemetry data to New Relic. Exporting this kind of data relies on a specific protocol; the OpenTelemetry Protocol or OTLP.

OpenTelemetry provides instrumentation libraries for your application. The development of these libraries is guided by the OpenTelemetry specification. The OpenTelemetry specification describes the cross-language requirements and design expectations for all OpenTelemetry implementations in various programming languages.

It follows a specification-driven development. The OpenTelemetry specification has design and implementation guidelines for how the instrumentation libraries should be implemented. In addition, it provides client libraries in all the major programming languages which follow the specification.

Today we learned how to manually configure OpenTelemetry for Python to connect to Lightstep (this also works for any Observability back-end that ingests the OTLP format). We also learned how to link related services together through manual context propagation.

According to the opentelemetry specification for messaging systems, When a process receives messages in a batch it is impossible for this process to determine the parent span for the span that it is currently creating.

That's why you have otel logging: https://github.com/open-telemetry/opentelemetry-specificatio...

OTLP protocol for shipping telemetry data

Lightstep ingests data in native OpenTelemetry Protocol (OTLP) format, so we will use the OTLP Exporter. The exporter can be called either otlp or follow the naming format otlp/. We could call it otlp/bob if we wanted to. We're calling our exporter otlp/ls to signal to us that we are using the OTLP exporter to send the data to Lightstep.