Observability and OpenTelemetry in React Native
Subtitles
Show
00:00 Welcome to the React Universe
make observability sexy again in mobile development. I like to think or say about myself that I'm on this topic the most uh I don't know emotionally invested person in our company. I see a difference and I go to the Android team and I say, "Hey, the iOS team is sending this telemetry in this way. How come you're sending it in that?" And React Native is a great opportunity to drive those conversations. The fragmentation between the platforms, types of devices, it's not like a single server somewhere uh you have full control of. So guys, tough question time. What is still missing? What is still unsolved in observability in React Native? and unsolved. Oh man. Um yeah, I mean I think I think there's um I don't think it's this tough. React Universe on Air, your go-to podcast for all things crossplatform. Hey everyone, this is React Universe on Air podcast by Colstack. I'm Mukashinski. I'm host of this podcast and today with me I have Jonathan Monz01:07 Meet our guests
from Embrace and Adam Horodski. Hey. Hello guys. How are you? Pretty good. How are you? So, I brought you here today to discuss the broad observability topic and then narrower open telemetry topic. So, I guess I chose my guests really wisely because then you introduce yourself and tell us why are you good guests for this episode. Great. Uh, I can start. I'm Jonathan Muns. I'm a a senior software developer at Embrace. Uh worked on a couple different things there uh including our React Native SDK and yeah, I mean Embrace has been uh doing observability for a long time and and more recently switching over to open telemetry. So we're very much in that space kind of thinking of that kind of dayto-day and and that's what I'm hoping to talk about today. How about you Adam? Uh so my name is Adam. uh day-to-day I work as a regative expert at Coloss and I like to think or say about myself that I'm on this topic the most uh I don't know emotionally invested person in our company. So it just anytime we have to touch on obility or telemetry with our clients I just every time feel the urge to step in and and and make things sort of better. So I guess that's it. Great. And I'm I'm glad I have you and I'm glad you said that you are emotionally invested because hear me out. Observability is not usually that sexy topic for developers. It's really important for products. It's really important for the business part of the product. It's not really that um sexy again for implementing. Right? So yeah, let's try to decipher why is that and why is it as important as we think it is. Starting with the difference between03:07 Defining observability and OpenTelemetry
observability and open telemetry. Those are not the same topics. Like Jonathan mentioned, Embrace was doing observability for a long time and only recently recently I'm uh this is like loosely saying this probably for the past two three years, right? Two years. Yeah. Yeah. About that. Yeah. you've invested in open telemetry. So maybe Jonathan, you can start start us up with just explaining the observability topic in general. Yeah, I mean the difference there observability is kind of the general term. It's what you're trying to get out of whatever framework you're using, whatever tooling you're using. It's the idea that your application out in the wild, people are using it, things are going on, and you want that visibility into what's happening, are there problems, are users doing the things I want to do? And open telemetry is really kind of a codification of that. It's a standard that's okay, given I care about observability and I want to get that insight, you know, how do I do it? And observability um uh in open telemetry is a way to have a sort of standard framework for thinking about all the various uh bits and pieces and signals that you actually want to collect and what those look like and how you would collect them. So it's sort of a means to that goal of observability. what would be the the04:32 Signals in observability
signals you said that we use like uh examples of s of signals that we use in observability. So um in open telemetry um tried to keep this sort of general model as simple as possible. Those really come down to three buckets that you can kind of think about everything fitting into as either uh a span, a log or a metric. And these really come down to again what's going on in the application. So a span would represent something happening over time. So you know if there's uh a really expensive operation uh that you're doing the span would represent okay I started calculating this thing at this time. It took me this long that was this and maybe a few things happened while I was calculating that. Maybe a network request went out or or something. So that's a span. A log is an event at a moment in time. So hey, this error happened at this moment in time or this important thing happened at this moment of time. And metric is really anything you can sort of take a measurement on uh throughout the lifetime of your application. So you know what was the CPU usage at moment x? What was the memory usage? So you know signals in really everything you care about and then open telemetry is trying to bucket that and trying to control some of that complexity by putting it in these three different categories. So like bridging this from development environment to production, we are able as developers to take all of those measurements ourselves, all of those logs ourselves and verify that on my machine it works and it works well. And then observability is answering the question, what about our user base? Do they have the same experience? Are logs coming in the same order or do they have some issues that we are not familiar with in our development environment? Exactly. And that's where you get into uh sort of another umbrella term or another buzzword of real user monitoring and and that's exactly that when you're there's only so much it's all important but there's only so much you can do sort of in the environment you control you can do a bunch of testing locally. uh you can have integration tests. You can even have synthetic traffic where you you know hammer your application with a bunch of simulated calls or simulated traffic and then you get to this point of okay I'm pretty confident but at some point you have to put your application out in the wild and that's where real users are going to interact with and that's where you have way less control.You don't know what kind of devices uh a user has. you don't know what kind of network connectivity and that's when you need that observability to understand okay worked for me does it work for these you know million other uh people that also connects nicely with the with the one caveat that I mentioned at the beginning of the episode so that's how the observability is sexy for the business case cuz we as a business we want to know we want to be datadriven and we want to know where to invest our effort for example if on my develop velment machine something is slow it doesn't mean that all of my user base encounters the same issues and then again I can lose something when I only monitor my development machine what you mentioned at the very start was that it feels like it is only not only sexy on this level of production environments but it is super usable or it could be super usable for developers in these environments before that. So if you have a development one, staging one, there is a lot you can get out of signals in these. It just like the state of uh the tooling around it uh for now is uh it's super hard if you're not using some fancy tooling. It's super hard to set it up I believe uh to make use of it in these lower environments. And then uh one brilliant thing I I heard lately uh sort of expanding on what uh Ya you you told us about the signals different types of them. I really like one metaphor that I heard from uh Ryan Dal recently on one of the talks for integrating open telemetry into Dino. We all know logs from our systems that we build daily. So a log is like a unit that we pretty much understand. There's a lot of uh momentum behind open telemetry in the standard and around the protocol. But really what uh these signals could be uh like translated into is if we know a log which is point in time sort of type of information then a trace is a fancy log because it has some causality to it. uh and spans uh you mentioned all these spans they contribute to traces that we we can record and then a trace is pretty much a set of logs that are more fancy and then metric is something that can be derived from both of these. So if you just like get a bunch of your logs, aggregate them, then you can have an average latency on on some endpoint for example or an average time to render a screen.
And this yeah, this feels more like a businessoriented language now. But it really nicely goes from one to the other. I guess I could, if I was very naive, I could try to set it up all by myself in my production application. I can first make my developers use it and my testers use it and then contribute to those uh metrics, those logs and then I can just ship it to the world and then try to navigate that data. Why I shouldn't be doing that? I mean, you could. You're going to hit a lot of a lot of walls on the way, but technically you could. Yeah. Yeah. And I think it it goes back to your previous point. You know, why wouldn't a developer think of it as sexy or or why does it seem like a chore, right? And I think that's not unique to observability. I we're all working on certain problems because we find those are interesting. every time we're distracted like, "Oh, now I'd have to deal with sending out marketing emails for my application or now I'd have to deal with, you know, any of these things that distract us from sort of our core interesting problem that we're trying to solve." It's going to be less interesting and it's it's time we're taken away from our core competencies. So, observability is difficult and there's a lot of challenges, particularly on the client side. You're in an environment you don't control. There's millions of devices. Some of them are offline. Some of them are really old. There's a lot of problems you're going to have to solve if you want to do this from scratch. And so to make that sort of chore of, hey, I need observability easier. It is really helpful to look to tools, look to things that are being developed by people who spend the 100% of their time trying to solve these problems. And yeah, like Adam said, I mean, you can you can do it yourself. It's just a question of are you willing to make that same kind of investment and solve all these tricky problems that you're gonna you're going to run into.
Yeah, let's talk about those. Let's talk about those like challenging of front end and mobile in particular observability. I know from my brief research that observability came from backends really from like systems that we have control over from our servers and those are really easy. Okay, I have I have not set it up but that is in my notes like it's much easier to set up an observability on something that you control on your back end for example in your servers than on something that users just hold in their hands. So can you talk briefly about the challenges that we have as a mobile developers, React Native developers or React developers on the web with observability? Yeah. So I think we'll talk to the back I can start talking about the back end a a little bit because I think part of the benefit there and or why it's a bit you know there are different challenges but why we think of it as a little more easy or a little more solved I mean that is where as you said observability has been thought about it has matured for a lot longer and so a lot of those problems tend to be if not easy at least sort of known quantities and and we have sort of approaches that we understand And there are some benefits like you say you control the environment. You know your backend infrastructure ideally is always online. There's no oh this thing you know went in a tunnel your backend server didn't go in a tunnel for for uh 20 minutes and lose connectivity. You know it should always be online. And really scale-wise even if you have large backend infrastructures you're talking about hundreds or maybe thousands of machines. So when you're talking about mobile devices, you're talking about potentially millions of devices that are all over the world that are fragmented in terms of their capabilities and again something you don't control. So there's sort of technical challenges and there's also kind of semantic challenges like what does it mean for an interaction on a mobile device? Like what is a session on a mobile device? You don't really have these questions on the back end.
you know, a back-end infrastructure handles a request and it does its thing. It's not there's not this human element that that you then have to kind of think about what that actually means. On a back end, it's really easy to see kind of the entirety of a thing. If you hit an end point, that's when something starts, right? If you return something out of it, it's already done. So, anything in between, it's easy to like like give it a grasp look and wrap things in spades and whatnot. And then if you try to translate that's what I think that's where where the challenge really is. If you try to translate this uh the same APIs for example uh into the mobile space where you all of a sudden have all the front end frameworks uh their different rendering queries here and there tens probably it's not hundreds of of libraries per each project all of the stuff that probably needs to be sort of I won't be speaking jargon probably but all the instrumented in the background for you uh it's really hard to get the the whole picture you you would naively probably think of uh okay if I press this button now I want to start collecting something and then if I navigate to some screen I want to like finish up my measurement and then see what's going on in between on the back end if you hit an end point you return from it you can measure this in between here you have probably more real realistically tens hundreds of different let's say redux sagas running in u in between right network requests all the different type of traffic that could be running in in the background and you might be really interested in in these it's really more complex and then what what J mentioned the fragmentation between the platforms types of devices it's not like a single server somewhere uh you have full control of I guess like that that is answering the question what is so challenging about mobile instrumentation mobile observability and also that is directing us towards the standards Right. Let me try and make um
16:04 Standardization and OpenTelemetry protocol
anecdote is a strange word for this but like some kind of picture for you so that you understand my train of thinking. So on the one hand as developers as products we want the standardization. So I could either create my own framework for observability and call it call stack framework for observ observability. I set up my own instrumentation on the app side. I set up my own dashboards and data visualization software on the front end on like the admin side, right? But that's like you said that's cumbersome. That's really easy. I could fall into creating my own framework instead of focusing on my product. So there are a bunch of different solutions out there in the market like Embrace, like data dog, like graphana that handle either some of those parts of that instrumentalization or like all of it for you through SDKs. So that's like fullyfledged solutions that you can try out and implement and just use. And then on the other hand, if I really want to do my own instrumentalization, I don't have to do it from scratch. I don't have to figure out how to do it myself. The standard already exists. So on the other hand, we have the OTL which is open telemetry. So somewhere in between there will be tools and uh libraries that handle I either all of it or some of it or none of it. But I can sometimes like mix and match those, right? So like the the scope of the observability market, let's say, is is pretty broad. So Embrace is on this end of the spectrum where you have all of those things packaged in one nice product, one nice service that you can use. And there are a bunch of others as well that I mentioned. But you are unique in a way18:08 Embrace and OpenTelemetry
that you are still trying and pushing for conforming with the OTL standard. So can you explain maybe why why are you pushing that road and not some other proprietary things? Yeah and I I think that's a great summary. I mean I think because there is this broad spectrum and there's so many different ways that you may want to collect telemetry. There may be so many sort of end business goals of uh you know what you're trying to get out of any given observability tool. The thing about and we we've talked about open telemetry a fair bit already. The thing about all these different areas is it is really hard to be great at all of them. where at embrace we have built up a lot of domain expertise is observability in the client side. So whether that's react native or web or or native Android and iOS and we um try to collect and and do the best job we can of giving you insights in that sort of client side telemetry but we recognize that that's only part of the picture. You do have telemetry coming from your backend systems. you have data that's being collected from other tools and other places. So that's where the standard becomes important because if everyone starts adopting open telemetry or whatever the open standard is uh and starts collecting all this telemetry in the same way and talking the same language you really open things up where you can start exporting data and sending data back and forth to different places. So with Embrace, that's why we really go heavy into the open telemetry because we want us to be the thing that collects your client side telemetry in the best way possible, but we don't want to lock you into our system. We want to make sure that that data, if you have another team that's looking at Grafana, that's looking at another observability system, you can send the data we collect to that system. So you can look at your client side and you can look at your backend telemetry together and there's back links to embrace. So okay, everyone on your team speaking the same language look at the same dashboard. I need more context. Let me click from this graphana dashboard back to Embrace. So that's all possible because things are being collected in a standard way and and is speaking the same language. We think that's really the the special sauce, you know, that we can do what we do well, but also play nice with the rest of this ecosystem so that data is free to sort of go back and forth.You're listening to React Universe on Air, your go-to podcast for all things crossplatform with React and React Native. Adam, I know that you spent a lot of time thinking about this and you like like you said, you are emotional about this subject. I think it's it's a wise thing to do. Maybe I can direct a question to you because like Jonathan said, we were talking about open telemetry but maybe not in a very structured way. So let me ask you what is your twominut pitch of open what is open telemetry for mobile cuz like that's a new thing open
21:29 Future of OpenTelemetry in mobile
telemetry had been backend standard and I know that embrace contributed to creating this mobile standard for open telemetry. So what it is now and like how it still evolves. You know what? I don't particularly like to think about it what it is now but what it could be aims to be in the near future. Yeah. What what it should aim to be. So right now I wouldn't say for React Native for example it is a standard because every project I join I don't see being used everywhere and everywhere as the golden standard for collecting telemetry. For example, if we were to like limit ourselves to this collection uh and instrumentation phase, what I wanted it to be is this standard. So the true power as you mentioned it's not in the open telemetry itself which is uh but I think by their quote is a set of APIs SDKs and and standards and anything that is within the scope but in the OTLP which is the open telemetry protocol and this is where the true power of it really is because it is the same language now that you can speak and then the barrier for example really lowers for companies like Embrace that they could show their product to a whole lot bigger audience now because if you were to speak this language in your product but you're trying to figure out it on yourself with graphana dashboards for example which is not a bad thing to do but in general you're trying and you think you're struggling with something now by using the same protocol you can try better tools for some parts of this job and maybe you would love them right maybe you get far better insights from uh these other tools and that's fine as long as you stick with this protocol. And this is I I guess like my biggest pain with it. It's not yet like this widely adopted and it's it doesn't have as much exposure as I would love it to have. I wouldn't even try to pitch what it is right now, what it is right now for me in this space, but I'm just focused on where it could be a few I would say if not months, years from now.And that's where where I sort of aim. So giving it more exposure and at the same time I think you're uh trying to aim for me to mention the library. Right. So in the last few months or I've been misinterpreting this one. Uh the last few months uh I've been working on react native open telemetry which by the way I since we started preparing for this I think it's going to get like a rebrand uh and and be decoupled from React Native really uh or not. I'll see. But what I'm missing is the protocol itself and the standard behind it is really well, but it is really complex for products and product companies to adopt. So even though it is brilliant, I myself had to spend a nice few months to really get a grasp on what is what and what I can use for different tasks. If I were to onboard, they want to sell other uh service like embrace for example I would not have to spend this time but maybe there are companies uh and I see this with with our clients as well there are companies which try to stick with honing this part of of the code and that that's fine with them but it's not so easy to onboard them then to open telemetry because it is getting more and more complex. So what I wanted to play around with was uh creating this library that lowers the barrier for using this open standard and then exposing the same APIs and and whatnot but the library could be gone the protocol that uh different companies could onboard into is the true value and then once they're using it they could try different tools uh maybe build it themselves somewhere or not depends on them and their needs really wasn't 2 minutes right I think it was thanks for the great explanation and thanks for mentioning the react native open telemetry. Is that correct? Okay. Oh yeah. So from what you said I got that open telemetry standard is not a product. Oh yeah it's no company owns open telemetry. Probably there's some kind of consortium uh people are still working on it and maintaining the standard. The second thing that I got from your answer is that if I were to use it directly, I can and it's still going to be a better experience than just like re-implementing the whole standard myself, but it's going to require me to understand a lot of underlying framework dependencies, underlying standard. You might not necessarily want to do that. you just want to onboard your developer to like using observability.
So I know that I can use open telemetry directly. So those are like standard native SDKs that I communicate with open telemetry with. Depends on the platform but yeah you could use u SDK uh swift SDK C++ one and JavaScript one. And what this library for example tries to accomplish uh is coupling this all together for you. So technically and probably months from now I could imagine this being like a nice wrapper on top of these SDKs. So you you wouldn't have to worry if it's a C++ SDK underneath that is more performant for you but you'll be using the same APIs on the JavaScript for example. If you were to stick with uh the raw SDKs that open totro provides, you can use separate SDKs on each platform and you'll be good to go technically technically because it requires a lot of work. Yeah. And like follow up to this is this
29:54 Community involvement in OpenTelemetry
go. Jonathan, does it sound familiar at all? Uh are you working on similar problems that Adam is on this open source project? Are you working on similar problems at Embrace as well? Yeah, definitely. And and I think yeah I think this is a good um this is an important point because I think we've been talking you know about open telemetry more of you know the benefit of it providing a standard and it providing you know similar rules but in addition to sort of the semantics and the standards there are folks working on implementations in different languages and actual you know as as Adam mentioned uh you know cotlin packages swift packages javascript packages so that's where the community involvement becomes important because there is this additional challenge once you all agree okay open standard is great this is the protocol we want to use this is how we want to talk in in sort of the same language you then need to actually implement this in code on all these different platforms and that's where React Native is in a very interesting place and where there isn't that same level of community engagement for React Native as there are potentially for other platforms so JavaScript's a example where there is a whole sort of group working on open telemetry JavaScript but in the same sort of you know trend of maturity we talked about that would have started as being built for node environments and and serverside JavaScript and then browser support would have come next and that's um gaining traction you know there was recently a special interest group formed specifically for these JavaScript packages working well in browser environments React Native is sort of at the end of that train. You know, it it can leverage all this code that's been written for Swift, that's been written for iOS, Android, and and and JavaScript, but it's not been the primary focus or the direct thing that those developers in the community has been thinking about. So all these challenges are very familiar because you know if you come to React Native and you want to gain those same benefits. It's like the pieces exist but there hasn't been sort of a concerted effort amongst developers to okay what does this mean for React Native? Can I just take this JavaScript package or is it making a bunch of assumptions that might be true in node that aren't true in React Native and how do I, you know, make that easier for a developer to come in and just solve that problem for them rather than them having to figure out all these sort of nuances. And so I think we're kind of at that stage with React Native where we're all kind of figuring that out and sort of the next drive is getting that sort of community focus and realizing that oh this is a platform a lot of people care about. So let's get some of that common tooling figured out and then we can leverage each other's work and then you know build forward. That's how it kind of works in these other platforms that you get these nice auto instrumentations because folks can leverage sort of an existing pool of these community developed tools and then say, "Oh, now for framework X, I want to add some nice auto instrumentation. I want to collect some telemetry for that. I can start building that and I can start plugging in these different uh libraries that the community has developed because we're all sort of driving towards making open telemetry collection on that platform easier. So yeah, we're not quite there yet in React Native and that's where a lot of this work uh is driving towards like how do we make this simpler? How do we make this you know uh tooling? I was going to ask like where is that layer of community engagement that you need like from both ends from like really lowlevel end of people just reimplementing this from scratch on like a a little bit more higher end where Adam and his library comes in and gives you this nice abstraction and this nice unification for platforms and then on the much higher end we have like the fullyfledged solution like Embrace. So where is that layer when you need the common interest, the common glue that figures out those best practices, those patterns?It's a good question. I think um you know Embrace has been doing this a fair bit on sort of the native Android and OS sides and I think it's a mix because any community like open telemetry is large and there will be a lot of folks talking about the pieces they care about. So at a first stage is just being involved in a bunch of different conversations because you might not know what's relevant. You know, for something like a clientside session, it's important to figure out what that means on your platform, but it's also important to figure out what that means sort of in general for any platform. Like what does a user session sort of mean in the abstract? And then what are the differences? You know, that might be very different on web and mobile. So then you need to be involved in the conversations with the browser special interest group and the Android special interest groups and and sort of come together. So I think the key is and open telemetry um is nice where they have these special interest groups that meet on various cadences on on Zoom and and and talk about problems that are relevant to them. And you'll see similar folks if you go to different meetings. Oh, this same person was in the semantic convention special interest group and they were in the Android special interest groups. I think that's how you have to kind of go forward is you need to care about solving the problem for your platform but also care about solving it sort of at the semantic level and those things kind of need to come together and it is messy like I think the way it goes with some of these newer client side semantic conventions is people are just going to try it like hey on Android here's our proposal for how you track a user session and then another platform is going to see that and say that oh that's great but I need to tweak it slightly for what that means. on web and then we need Adam on both meetings. Yes. So he can say I want I need to bridge this to React Native. So I want both implementations to be as close to each other as possible so that it's easier for React Native implementation to like bridge those two and still have unified experience. You said like this is messy.
React Native is messy, right? Is messy in a way that we need to support all of those like underlying platforms. We need to establish common patterns for JavaScript layer and then we have to somehow work around the differences and there will be differences like with notifications with like all of those others payments Android and iOS they differ but we still need to provide that unification layer for React Native. Yeah, I forgot my question. I got emotional. Adam, I was just saying that that's why I actually think React Native is such a great opportunity to drive those conversations in in the community. I I found this at Embrace as we're working on a React Native SDK, those same things pop up. I because our our Embrace React Native SDK is built on top of our Android and iOS SDKs. I see a difference and I go to the Android team and I say, "Hey, the iOS team is sending this telemetry in this way. How come you're sending it in?" And React Native is a great opportunity to drive those conversations because it is by its nature the confluence of these different ideally, you know, that should be consistent from the beginning, but sometimes you have to force those conversations and React Native is a great opportunity to force those conversations cuz you have to actually implement it um uh in a way that's consistent. We're talking open telemetry
37:34 Real observability in React Native
and smart tooling, but what does real observability look like in React Native at scale? Too often monitoring gets split across teams, platforms, and tools. That's when issues slip through and appel suffers. At Colstack, we help teams build unified observability for React Native. So metrics, traces, and logs actually tell the same story. That means connected dashboards, alert that reflect user experience, and KPIs that guide product decisions, not just firefights. Want a full picture of what's really going on in your app? Book a consultation with us and get clarity. Tough question time. What is still missing? What is still unsolved in observability in React Native and unsolved? Oh man, I don't think it's this tough. Yeah, we start. I think there's um uh the sort of just nuts and bolts sort of technical problems. You know, how can I leverage this JavaScript's open telemetry package that is built to work in a node environment in React Native without having to rewrite all this code? You know, that's that's one is how can we kind of share, you know, this wealth of code that's already been written for all these different platforms and kind of make it work in React Native. Another is just um you know interesting auto instrumentations and and and telemetry. Uh you know it's great if you can add a package and your network tra all your network requests are automatically uh captured which you know is is is is fairly um doable today with with with sort of um what exists. Uh but there's a lot more you're using on React Native. You're using different libraries for navigating between screens. you're using Redux, potentially using other state management. The more and more of those platform framework specific libraries just have telemetry being reported out of the box, the more data you're going to get as a developer from just adding, you know, an SDK that understands open telemetry. and the more you're going to be sold on it. If if if you do all this work and add an open telemetry SDK to your rack native app, it's nice to then be rewarded with a wealth of data instead of just, you know, oh, I see one or two logs and and that's it. You mentioned something that I I was not aware of just a minute ago. So I'm aware that React Native is this big soup of like different libraries floating around and you can combine your app with like either Redux or Mobox or Stadex or whatever and then you can use another library for navigation etc etc and then I'm aware that observability like fullyfledged observability frameworks will give me that plugins to some of those libraries that I can collect data from. Is there an effort like that of making a standard way of exposing that data not from the providers of solutions but from the bottom up from library creators to instrument their libraries in such a way.Yeah. So the nice thing about open telemetry, the way it's sort of approached this problem is that the API is very stable in terms of those signals we talked about before. How do I emit a log? How do I emit a span? How do I record a metric? And the idea is that as a library developer, as someone working on a package, you can make use of those APIs and by default they're all just noops. So I'm a developer of a React Native navigation library. I want to play nice in the observability ecosystem. Every time you know I switch screens, I'm going to say that that is I'm going to create a new span. I'm going to create a new log. You can do that as a library developer and nothing happens in your application. These are all no ops. You've just added these hooks where you're emitting this interesting telemetry when something happens in your framework that you think would be relevant for observability and then adding in the embrace SDK or uh you know react native open telemetry SDK. Those SDKs then turn those noops into hey I'm actually going to capture that. So you get all that out of the box because the library developer has added in those hooks. So that's kind of the gold standard. In reality, I guess is again where you sort of need that drive uh and that and that um momentum from the community doesn't happen super often with uh you know that's where can you give us an example of a library that is instrumented in such a way that's a good qu I don't know if I can think of any on react native specifically no just like whatever works in like JS web ecosystem or whatever you can think of dino for example which got auto instrument auto instrumented right I believe so yeah do you know specifically sort of what what pieces they they have added that for I don't think I remember the talk really uh by Ryan but I'm trying to to remind myself if it was on the internals really I think so that was on some internals of uh of it yeah the funny thing is we have to think about it so it's not good enough right it's not that common right so I know I know that there are hm there is something familiar in redux for example I remembered turning on or maybe this is like external library that provides re redux with this with this possibility but on each action it would print out the previous state the action and then the next state to your output to your console log and then I I turned this on in in one of the projects that I worked with few years ago and I forgot had to switch it off for production. So our app started to be really slow and then client noticed that after a few weeks and he say oh we need to fix that the app is slow. So I looked into the problem I fixed it and I got praises for fixing my own.
What a hero. What a hero. Yeah I I I I can agree it's Yeah. I mean that's sort of evidence that it's it's it's not that common. I think so that is the gold standard you know someone hooking into the open telemetry API just admitting this but I think a close second is just h when you're developing these libraries thinking about having those life cycle hooks and then so um for uh embraces react native SDK we had auto instrumentations for various navigation libraries like expo router and things like that and that wasn't too difficult because there's clear sort of things you could hook into to those libraries like hey I started a new route hey I ended this new route so then that's that one extra step for that instrumentation to then okay emit a span when this happens emit a log when this happens so that's helpful too and that comes down to sort of an observability mindset if you're developing a library like this where would someone care to be notified that something interesting has happened even if they're not necessarily using the open telemetry APIs directly those hooks then allows someone to create an instrumentation like that and then if you have an SDK which is playing nice with the ecosystem you can pull in those instrumentations even if you know embrace can't write every instrumentation but it can accept an instrumentation that you've pulled in for someone somewhere else that follows the open telemetry standard and just plug into that SDK and now you have that extra information without embrace having to have written it without you having to have written it just leveraging that that exists out there somewhere the ecosystem which is something that Adam said right it would be hard for everyone to just like reinstrument all of that in each product. It it would be much easier if we can just say hey embrace that instrument uh navigation or react native open telemetry instrument my navigation or instrument my redux or whatever. Yeah.
Yeah. Few last topics. I already asked you guys about this, but I'm going to try one more time. What are we still missing in React Native observability and like how are you approaching this? Like how do you work on in those open groups to make that happen? So library instrumentation would be the first thing. It's pretty tough to actually accomplish because there is so many third parties involved with the community libraries etc. what would be other challenges that you will still face in React Native observability open telemetry that we want to solve and then maybe we'll ask our listeners to uh to
46:41 Future of React Native observability
help out. The first thing that comes to our mind is once we let's say are able to solve making data collection easier, telemetry collection easier. How do I pipe this to some company's product that does really well the other part which is it's a whole new challenge that comes after collecting uh a bunch of data right how do I present it to myself or to my team whatever in a way that is understandable and that is a whole new thing to to even tackle I'm not even thinking about this part of the challenge even though I sort of have to with uh the parts I'm working on but How do I narrow this gap really? So let's say I use like the very raw openometry as the case. I have some other instrumentations in place and then my hope is as some product company hey who's going to accept this data and and then uh how do we make use out of it? So hopefully like my hope is I can pay somebody money for getting really great insights based on uh whatever I have uh collected already within my product. it is super hard hard as hell to to do yourself. Uh I would say so that's one of the one of the things I'm really missing. Uh maybe the story for getting from okay I collected something myself is compatible with the protocol now how do I make use out of uh somebody else's products to have great insights. Maybe Jonathan you could you could help me with this one. No, that's exactly where you know the benefit of uh again maybe another non-s sexy topic but like this benefit of having good semantic conventions come in. So as an example there's very well understood semantic conventions for you know what a network request looks like. So if you're going to collect information about a network request, send it to an observability tool, they can as you're saying build some very nice insights, very very nice visualizations, very nice analytics around that because they understand, hey, this is network requests. This is what everything means. This means it was successful, this means it wasn't. That same kind of semantic conventions does not exist for uh let's say what a crash looks like on a mobile device or what a navigation looks like. But once they do, then if you're collecting in a way that follows that, then these observability tools can start building experiences around what those semantics mean and drive richer insights instead of just, hey, this is a span. You know, that might be useful, but it's way more useful to say, hey, this is a span that represents this type of user action in an application. So, I'm going to build a tailored experience around that. So that definitely opens up a lot of possibilities for collecting from different sources and then getting those insights um uh from the tool you've actually sent it to. I do think the JavaScript community is a good example of where this special interest group for browser specifically branched off of that. I think that's missing for React Native. I think you know there's a lot of challenges and we could kind of list them off but what you really need is a group of people who are you know as we said emotionally invested and meeting on a regular basis thinking about that and that that's where you get a lot of you know stuff coming up that you maybe didn't even think about as you're working on it um kind of in isolation.Adam I guess you have some more calls to attend after this podcast. I think that that's one thing for for myself like personally to to do I don't personally attend because I have bunch of other stuff but I don't know at least I didn't so far attend any of these meetings. So that's one of probably my personal to-dos is to also join this force outside of coast again and and work we do as part of our R&D. So so guys I at the end of the episode I have a surprise for you. Imagine you have unlimited power, right? And you can, this is your superpower right now. You can direct people that are listening to this episode right now to do one thing after this podcast and hopefully it is related with observability and OTL and not with like cleaning your house or whatever. So like what are you directing them to do right now after listening to to this episode? Um I guess uh you know we've we've talked a bunch about community. So there is you know the open telemetry is under the umbrella of the uh CNCF which of the the cloudnative uh computing foundation. Uh they have a slack um you know they have a community page on GitHub going there and and and getting involved. I'll also plug it embraces community slack where we also talk about uh uh open telemetry quite a bit. I think that's if anything we talked about is interesting, I think that's a great next step because you'll find a bunch of other folks in in those community slacks who are also interested and would uh uh be happy to answer uh whatever questions you had. Maybe one thing that that is not really obvious, at least wasn't to me lately was that we really look into observability as sort of this production thingy that's going on somewhere in some environment. I would love to see more and I have plenty of but I just have like a 24hour days more ideas on how we could leverage the same data collection pipelines. So like libraries SDKs that are getting better and will with more exposure how we could leverage this in development environments. So I see a lot of potential in tooling that could be built development tooling that could be built for developers to make use of the same data collection pipeline for resolving some performance regressions in their products. Understanding better what actually is happening without recording fancy like herb traces and try to understand them. Understanding better their product and how they implement features with within their app. how they solve bugs with data collected that is getting collected or should be collected with the open telemetry standard with OTLP with this protocol. So as we are trying to bring uh the protocol more into products and give it more exposure and making it easier to use now how do we outloft more and more ideas in the space on how do we make use of it in the development space. So before it within heat any of the other environments what could be built potentially uh in this stage I think that that's one way my request to all of our listeners would be to if you are not doing observability in your product start doing it now just pitch it to your product owner pitch it to your stakeholders you should be doing observability and like Adam said it's not only about production it's also about your environment. So before people can contribute to those topics just Jonathan mentioned or Adam mentioned, we should all be just playing around with observability, understanding it more, understanding the benefits more, understanding the implementation better and then we can contribute to all of that higher level items of what are the patterns that we should be using. If I have not tried a few wrong patterns, I don't really have an opinion what good pattern would look like. So I just figured it out. Make observability sexy again in mobile development. I don't know what the acronym is, but like you can figure it out. Jonathan, do you want to add something?
No, that that sounded great. Yeah, I think you're right that it's it starts with that sort of mindset of like understanding it's important and thinking about it as you're developing code like you would unit test or anything else that we're we're used to thinking about as developers. So that's
Timestamps
Show
Guests
Adam Horodyski
Software Engineer
@
Callstack
Jonathan Munz
Software Engineer
@
Embrace
Observability is critical for understanding how apps behave in the wild, but in React Native, platform fragmentation, diverse device conditions, and varied network environments add complexity. With this React Universe On Air episode, we want to bring clarity to the topic, covering what observability means, how OpenTelemetry works, and why standardization matters for mobile.
Guest & episode summary
To do so, Łukasz Chludziński interviews:
- Jonathan Munz, Senior Software Engineer at Embrace, who brings experience in client-side observability and OpenTelemetry adoption, along with insights on the Embrace React Native SDK and its integration into broader observability pipelines
- Adam Horodyski, React Native Expert at Callstack, who leads observability and telemetry work for our clients and co-creates the React Native OpenTelemetry library.
Their discussion spans the nuances of implementing observability in a fragmented mobile ecosystem, bridging the gap between open standards and production-grade solutions.
Understanding observability vs. OpenTelemetry
Łukasz and hit guests clarify how observability is the end goal (knowing what’s happening in your app in real-world usage), while OpenTelemetry is the means to achieve it. They discuss signal types (spans, logs, metrics), the OTLP protocol, and why aligning on shared semantics is critical for combining client-side and backend data.
Challenges in mobile & React Native observability
From unpredictable device conditions and network variability to the complexity of tracking user sessions across platforms, Adam and Jonathan explain why mobile instrumentation is harder than server-side telemetry. The episode also highlights the lack of consistent auto-instrumentation for popular React Native libraries, and how this slows adoption.
Tools, standards & community efforts
Jonathan explains how Embrace leverages OpenTelemetry to keep data portable while delivering ready-to-use SDKs. Adam shares the vision behind React Native OpenTelemetry as an abstraction layer that hides platform-specific complexity. Together, they outline the role of open standards in enabling interoperability, the need for semantic conventions tailored to mobile, and how community-led efforts can accelerate auto-instrumentation for navigation, state management, and other key libraries.
What you’ll learn
- How observability and OpenTelemetry differ, and where they overlap in practice.
- The three signal types in OpenTelemetry (spans, logs, metrics) and their mobile use cases.
- Common pitfalls in DIY instrumentation for mobile apps.
- Why standardizing on OTLP (OpenTelemetry Protocol) improves interoperability between tools.
- How community involvement accelerates auto-instrumentation and best practices for React Native.
- The role of vendor solutions like Embrace in reducing developer overhead while keeping data portable.
Resources
- Łukasz Chludziński on X, Bluesky, GitHub, and LinkedIn
- Adam Horodyski on X, GitHub, and LinkedIn
- Jonathan Munz on GitHub and LinkedIn
- Embrace: User-focused observability for mobile and web
- Embrace React Native SDK: Open-source SDK for React Native apps
- Embrace Community Slack: Connect with Embrace engineers and other developers
- CNCF Community Slack: Join the Cloud Native Computing Foundation community
- React Native OpenTelemetry: Library for adopting OpenTelemetry in React Native
Looking to improve observability for your app?
We help teams enhance monitoring and debugging in React Native apps.
Let’s chat
//
Insights
Learn more about
Observability
Here's everything we published recently on this topic.
//
Observability
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
Release Process Optimization
Ship faster with optimized CI/CD pipelines, automated deployments, and scalable release workflows for React Native apps.
