sentry-javascript VS opentelemetry-proto

I hope this tone comes across correctly as just a suggestion: I get a lot of mileage out of the "Send Feedback" option in DDG, which they claim actual humans do read. It can help move bug reports out of these HN threads into a more context-aware flow, and also makes me feel like any bad outcome has the possibility of improving, unlike systems that don't provide a "I feel bad about this experience" button

If you were thus inclined, https://gitlab.com/glitchtip/glitchtip#glitchtip is the actual open source Sentry implementation which (as far as I know) would enable gluing https://docs.sentry.io/platforms/javascript/user-feedback/#u... to the search results (which itself is still MIT: https://github.com/getsentry/sentry-javascript/blob/7.102.1/... )

Sentry JavaScript - Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their official JavaScript SDK. This move integrates Nx's capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on the benefits they've seen following the adoption of Nx in their monorepo (hint: reducing CI times by 35%).

We've just started this initiative and have already been able to help Sentry get optimized with task caching and task pipeline optimizations for their workspace!

In addition to the network call data we already attached, that does go through data PII scrubbing on the edges as you mentioned, we're discussing capturing request/response body. We even talked about it today: https://github.com/getsentry/sentry-javascript/issues/7103

Avoiding any PII from getting into the system is always top of mind. And we're considering this as an opt-in regardless of scrubbing on the edge ingestion service.

Add Sentry’s Next.js SDK to your next.js projects.

Get started with Sentry for Electron and drop us a line on GitHub, Twitter, or our Discord. And if you’re new to Sentry, you can try it for free today or write to [email protected] to get started.

Great idea! #4118

You can just send metrics via JSON to any otlphttp collector: https://github.com/open-telemetry/opentelemetry-proto/blob/v...

Yup! Since we're built on Otel, we suggest you can use the HTTP OTLP endpoint, which is yourdomain:4318/v1/logs, we have a quick blog post on that on how to curl a payload over: https://www.hyperdx.io/blog/testing-sending-opentelemetry-ev...

But you can also look at example payloads in the otel repo: https://github.com/open-telemetry/opentelemetry-proto/blob/m...

Great call out on CF workers, will make sure we get that updated :)

The OpenTelemetry spec is a mess. There's so much … abstract blah blah blah? … and very little actual details.

If I actually go to the part of the spec that I think gets down to "here is how to concretely write OpenTelemetry stuff [1], that seems to have the various attributes camelCased, for example, whereas the article has named them "spanID" and "traceID".

AFAICT the "spec" also just links you to the implementation. "Just" read this protobuf definition, translate that to JSON in your mind's eye. I "POST" this to a hard-coded path tacked onto a URL… but do I post individual traces/logs? Can I batch them? I'm sure there's a gRPC thing I could start guessing from…

But it seems like the JSON stuff is a second class citizen from the gRPC interface. Unless that's just as bad, too…

Actually getting set up in Python isn't too terrible, though there are a few classes that you're like "what's the point of this?" and most of them are apparently just undoc'd. (E.g., [2], ^F TraceProvider, get nothing.)

It is a bit depressing how this seems to be becoming The Chosen Spec.

I also sort of have 64-bit integers for span IDs (TFA never mentions it, but AFAICT this is required by spec). I'd much rather have "/span/ids/are/a/tree" span IDs, as this integrates much better with any logging system: I can easily ask my log viewer to filter to a specific span (span_id == "/spans/a/b/c") or to a subtree (span_id regex-matches /^\/spans\/a\/.*/)

[1]: https://opentelemetry.io/docs/specs/otlp/#otlphttp

[2]: https://opentelemetry-python.readthedocs.io/en/latest/api/tr...

Maybe, you are asking yourself: "But I already had instrumented my applications with vendor-specific libraries and I'm using their agents and monitoring tools, why should I change to OpenTelemetry?". The answer is: maybe you're right and I don't want to encourage you to update the way how you are doing observability in your applications, that's a hard and complex task. But, if you are starting from scratch or you are not happy with your current observability infrastructure, OpenTelemetry is the best choice, independently of the backend telemetry tool that you are using. I would like to invite you to take a look at the number of exporters available in the collector contrib section, if your backend tracing tool is not there, probably it's already using the Open Telemetry Protocol (OTLP) and you will be able to use the core collector. Otherwise, you should consider changing your backend telemetry tool or contributing to the project creating a new exporter.

Here's the example payloads for OTLP over JSON and example of how to ingest them: https://github.com/open-telemetry/opentelemetry-proto/tree/m...

An OTLP receiver can receive data via gRPC or HTTP using the OTLP format. There are advanced configurations that you can enable via the YAML file.

Cerbos fully transitioned from OpenCensus to OpenTelemetry, a move that significantly boosts our metrics and tracing capabilities. This shift allows for more efficient integration with a variety of observability products supporting the OpenTelemetry protocol (OTLP) but also offers the flexibility to use push metrics and fine-tune trace sampling. With this update, configuration through the tracing block in Cerbos files is deprecated in favor of using OpenTelemetry environment variables.

Networking is Easy (Really!) Since you install the agent directly into the environment where you are running your application, there is no complex networking. When developing in localMode, the agent listens on the common OpenTelemetry Line Protocol (OTLP) on ports 4317 & 4318 automatically.

Oh nice, thank you (and also solumos) for the links! It looks like oteps/pull/171 (merged June 2023) expanded and superseded the opentelemetry-proto/pull/346 PR (closed Jul 2022) [0]. The former resulted in merging OpenTelemetry Enhancement Proposal 156 [1], with some interesting results especially for 'Phase 2' where they implemented columnar storage end-to-end (see the Validation section [2]):

* For univariate time series, OTel Arrow is 2 to 2.5 better in terms of bandwidth reduction ... and the end-to-end speed is 3.1 to 11.2 times faster

* For multivariate time series, OTel Arrow is 3 to 7 times better in terms of bandwidth reduction ... Phase 2 has [not yet] been .. estimated but similar results are expected.

* For logs, OTel Arrow is 1.6 to 2 times better in terms of bandwidth reduction ... and the end-to-end speed is 2.3 to 4.86 times faster

* For traces, OTel Arrow is 1.7 to 2.8 times better in terms of bandwidth reduction ... and the end-to-end speed is 3.37 to 6.16 times faster

[0]: https://github.com/open-telemetry/opentelemetry-proto/pull/3...

[1]: https://github.com/open-telemetry/oteps/blob/main/text/0156-...

[2]: https://github.com/open-telemetry/oteps/blob/main/text/0156-...

We then modified the benchmark to encode our example data which is an opentelemetry trace data.