Published January 22, 2025
OpenTelemetry is an open-source observability framework that provides tools, APIs, and SDKs to collect, process, and export telemetry data like traces, metrics, and logs from applications. It is designed to help developers monitor and troubleshoot distributed systems by providing standardized data formats and integration points for observability tools. If you’re new to OpenTelemetry, you can learn more about it here.
Today, we’ll go through a guide to using OpenTelemetry in React Native, including the high-level concepts as well as how to send traces, errors, and logs to your OpenTelemetry backend of choice.
A provider is the API entry point that holds the configuration for telemetry data. The provider is responsible for setting up the environment and ensuring that all necessary configurations are in place. This can include configuring a vendor specific api key, or something as simple as setting the service name and environment. In our case, we will be using a TraceProvider to send traces that will be processed by the LaunchDarkly backend and converted to logs, errors, and traces.
In our example, the TracerProvider creates a resource, that builds attributes that we want to include with every trace. This includes the highlight.project_id to let LaunchDarkly know which project the traces below to, and other identifying data, such as service name and environment to help with monitoring and debugging.
Here’s a quick example of what this looks like in code:
An exporter sends the telemetry data to the backend. This is where you configure the endpoint and any other necessary settings related to the backend you’re sending data to. In our example, we built a custom exporter as a workaround to some OpenTelemetry package issues with the React Native’s bundler, Metro. A bundler-based solution is also in progress to use OpenTelemetry’s OTLPTraceExporter, and substitute out our custom exporter.
Here’s an example of how you might build a custom React Native exporter class that serializes and sends traces over http. Notice the majority of logic is serializing the batched spans:
After we build our exporter, we need to create an instance with the correct url to send the traces. This is done in the example below:
Finally, a processor defines any pre-processing that should be done on the created traces, such as batching, sampling, filtering or even enriching data. This is important because you may have specific needs on the machine that you’re sending data from that require customization. In our example, we will use a BatchSpanProcessor to collect spans in batches and send them to the exporter, which is more efficient than sending each span individually.
Here’s how we initialized the BatchSpanProcessor, and registered the traceProvider:
After we created our tracer, we can now use it to send LaunchDarkly traces, logs, and errors. We can also monkeypatch javascript’s console methods, so they will send to LaunchDarkly by default.
Tracing is possible by calling the created tracer’s startSpan method. This accepts a parameter for the name of the span, and returns the span itself. From there, the span can record an error, add attributes, and much more. We will signal the end of a span by calling the end method.
Here is an example, assuming the tracer is exportable from a file called highlight.ts:
Logging can be sent to LaunchDarkly with a few configurations to the trace method. First, the span name should be highlight.log to let the LaunchDarkly backend know it is, in fact, a log. Second, we will pass in a log.severity and a log.message attribute to be used when constructing the log object. It is recommended you set up a log function to complete this.
Here is an example of a log function below:
The benefit of using this log function is being able to pass in attributes more cleanly to be searched across in LaunchDarkly. However, this will only send to LaunchDarkly and will not be recorded in the dev tools. We will set up the monkeypatch to record console logs later. After you have created your function, you can export this function to be called in your application code.
In our solution, errors are also sent via traces to LaunchDarkly with some configuration details. Again, we will call the trace highlight.log to ensure this trace will create a log for you in LaunchDarkly. Second, we will record an exception and add any attributes to the span.
Here is an example of a error function below:
Again, the benefit of using this error function is flexibility of passing in a custom error name as well as attributes associated with the error. Monkeypatching the console method will send any error logs to LaunchDarkly which will then be processed as an error. After you have created your function, you can export this function to be called in your application code.
The functions above are great for flexibility and customization, but maybe all you want is to report what is happening in the console to LaunchDarkly. We have you covered. We created a hook to call in your code that will monkeypatch the console methods to send to LaunchDarkly in addition to printing in the console dev tools. This should be called on app load or early on in the lifecycle of the session.
Here is an example of how to monkeypatch the console methods:
In this function, we overwrite the console function if it has not been overwritten yet. It will then process the data, determine if its an error, and call the log function from above. There is some additional logic to safely stringify any data without going to deep into recursion.
Finally, this can be called in your application to start recording console data to LaunchDarkly:
In this guide, we’ve gone through everything you need to use OpenTelemetry in React Native to be able to send LaunchDarkly your logs, traces, and errors. OpenTelemetry is flexible, so this solution is not the only one. Feel free to edit resources, methods, and classes to what works best for your application.
Check out the example app and LaunchDarkly code snippets.
If you have any questions, please feel free to reach out to us on Twitter or Discord.