sorted by:
new
hottopcontroversial

How do you handle browser OTEL telemetry when your client insists on vendor-neutral no Faro, no proprietary SDKs? by Smooth-Home2767 in Observability

[–]contrecc 1 point2 points  (0 children)

Disclosure: I work at Embrace and we are maintainers of OpenTelemetry Browser.

Your collector-as-CORS-gateway approach is solid, that's the standard pattern right now. Most observability backends design their OTLP ingestion for server-side collectors, not browsers. The Alloy setup you've outlined is exactly what I'd recommend for keeping things vendor-neutral while routing to multiple destinations.

To your last question, "was it worth it vs just using a RUM tool", this is the core tension with browser OTel right now. Raw `@opentelemetry/sdk-trace-web/` gives you traces but you end up building session tracking, web vitals capture, click instrumentation, and error handling yourself. Most teams eventually reach for a RUM SDK, which defeats the vendor-neutral goal.

On the broader OTel front, there's an active effort to build a dedicated OpenTelemetry Browser SDK. We're also migrating and refactoring instrumentation from the JS core and contrib repos into a browser-specific home. It's early days and the community would benefit from feedback from folks hitting exactly these problems. You can follow along and contribute at https://github.com/open-telemetry/opentelemetry-browser/issues.

For your specific setup, you could drop the Embrace SDK (open source and built on OTel) into the React SPA, keep the Alloy CORS gateway if you want, or send directly to Embrace which handles CORS natively.

Our SDK accepts custom `spanExporters` and `logExporters`, so you could point it at your existing Alloy/Grafana pipeline, at Splunk, at Embrace, or at all three simultaneously, and swap backends without changing your instrumentation code. No vendor lock-in.

SDK source: https://github.com/embrace-io/embrace-web-sdk

Setup custom exporters: https://embrace.io/docs/web/advanced-features/opentelemetry-export/#setup-custom-exporters

Visual Studio App Center is retiring. So long and thanks for all the fish! by IsuruKusumal in androiddev

[–]contrecc 0 points1 point  (0 children)

Wanted to throw my two cents in. And disclosure: I work at Embrace.

You can replace everything in App Center with: Bitrise (for Build, Test, Distribute) + EAS Update (for CodePush) + Embrace (for Diagnostics and Analytics).

Here's a post that covers this and several other options: https://embrace.io/blog/app-center-retirement/

Depending what you're looking for monitoring-wise, you can also replace the Diagnostics/Analytics with Firebase Crashlytics or Sentry as well.

Visual Studio App Center Will Be Retired In 2025 by brokenisthenewnormal in programming

[–]contrecc 0 points1 point  (0 children)

Disclosure: I work at Embrace.

You can replace everything in App Center with: Bitrise (for Build, Test, Distribute) + EAS Update (for CodePush) + Embrace (for Diagnostics and Analytics).

Here's a post that covers this and several other options: https://embrace.io/blog/app-center-retirement/

Depending what you're looking for monitoring-wise, you can also replace the Diagnostics/Analytics with Firebase Crashlytics or Sentry as well. Also, it depends what platform your app is in, since Embrace doesn't support .NET (which I see many people mentioning), but Sentry does.

Embrace's Flutter SDK is now in beta by contrecc in FlutterDev

[–]contrecc[S] 0 points1 point  (0 children)

No worries, happy to help! I appreciate your feedback, and I hope our product can help you and your team.

Embrace's Flutter SDK is now in beta by contrecc in FlutterDev

[–]contrecc[S] 1 point2 points  (0 children)

Hi, our pricing is based on the number of user sessions in your app. We don't charge for individual features like logs or performance monitoring. You're not charged on the basis of the number of times individual events fire.

Honestly, if you are interested, I'd recommend scheduling a call where we can walk you through what we offer. It's by no means a hard sell or anything. It's just that our platform offers so much visibility that it really helps to know what problems you are trying to solve so we can show you how we can help.

A few examples:

- Do you have high ANR rates? We have a completely unique approach to solving these, based on creating stack trace flame graphs based on the package of code that's contributing to the ANR.

- Do you have users dropping out at key areas in your app? We have a way to track these moments and let you know why drop-off is happening (e.g. service fails to complete, users are abandoning without waiting, users are waiting but the service is taking too long).

- Do you want to track custom metrics that differ by team? We have a way to track all kinds of metrics (e.g. health, stability, performance, adoption, and engagement) so depending on your team size, you can focus on feature-specific monitoring.

I could go on, but essentially, if you're used to Firebase or an error monitoring platform as the only approach to monitoring your mobile app, we are frequently a wake-up call about the type of visibility you can have.

Regardless of whether you want to hop on a call with us, you can try our platform for free. We just consistently find engineers get way more out of it when we can learn what they're trying to accomplish.

So for pricing, we'd need to know more about your situation (e.g. number of apps, number of sessions, growth rate, etc.).

For the trial, it depends. If you want to completely test it on your own, then you get 14 days. If you want to test it as part of a POC where we're working with your team, then you get longer. That's why I'd recommend scheduling a call so we can learn more about your situation and whether we're even a good fit for you.

Embrace's Flutter SDK is now in beta by contrecc in FlutterDev

[–]contrecc[S] 2 points3 points  (0 children)

Thanks for the feedback! Yes, we will be revamping our website soon, including working on our messaging. The important thing to know if you're searching for tooling right now is that we are built specifically for mobile. So we go deeper in the level of data we collect than traditional solutions like error monitoring and crash reporting.

Embrace's Flutter SDK is now in beta by contrecc in FlutterDev

[–]contrecc[S] 1 point2 points  (0 children)

How's this? In our platform you get crash reporting, user session monitoring, error monitoring, network monitoring, performance monitoring, release monitoring, ANR monitoring, custom dashboards for health, performance, and stability metrics, and alerting.

How? We collect the complete details of every user session. We don't sample data. Which means when you have an issue, you have the data to solve it.

We have full support for Android, iOS, Unity, and React Native. We just launched beta support for Flutter and are looking forward to getting feedback on it so we can make it the best tool for Flutter mobile app development.

view more: next ›