Software engineers build software systems and release them into the world. When building and afterwards, engineers want real-time feedback about how the system acts, performs and breaks.
This practice is called observability, which is the act of collecting signals, or telemetry, from an application while it’s live and using those signals to ask questions about the application. Observability’s value comes from a truth that all developers eventually learn: Stuff always happens when you release apps, and the best way to deal with that is to gather as much information as possible about the application to make hypotheses about the causes.
OpenTelemetry is a massively popular set of tools for asking just these kinds of questions. OpenTelemetry, or OTel for short, offers a standardized way for developers to transmit application information, currently metrics, logs, and traces, in nearly any popular programming language. Apps in any setting can send the same types of data to their observability backend, creating a standard that is recognizable, intelligible, and usable for any OTel-informed person.
One area of OpenTelemetry, and observability in general, that is still building toward a consensus is in observing mobile apps. Mobile observability has to take into account many factors that don’t exist for web services or databases, such as battery life or user experience. Let’s explore how OTel can still solve problems unique to mobile observability using the tools that already exist.