If you think about it, mobile apps are among the production services most in need of real observability: nearly countless hardware platforms and operating systems in combination with your app’s code result in a dizzying matrix of possible sources for any given issue, which means you need the power of true high-cardinality search to solve your problems.
Have no fear, though–here are some tips for thinking about observing a mobile app:
Take advantage of Honeycomb’s support for high-dimensionality + high-cardinality
In our own production services, we have a standard set of metadata that we know will be useful when debugging production problems / understanding the production “normal,” so we make sure to send them on every event. (You can see some of them listed out in the first section of this dogfooding blog post.) Going through this exercise early on and standardizing among your various mobile clients will make your life easier later on by establishing a set of common field names.
Commonly-useful metadata when slicing and dicing mobile traffic include fields like: device type, OS version, app version, the SDK versions of any crucial third-party SDKs, customer ID. The question to ask yourself at this stage is: what are the attributes / measurements that tend to correlate to customer pain? For an API we measure latency of all sorts; for client-side JS, we measure a whole host of painting/navigation timers; for mobile… what matters most to you, and your use case?
(Important note: anytime you’re writing directly to Honeycomb from a client-side application, be it browser JS or mobile apps, we recommend creating a client-specific write key to retain the ability to rotate a key for a subset of your traffic — just in case a key gets compromised.)
Think through where and when you want to capture each event
We tend to think of Honeycomb events as each capturing a single “unit of work.” On an HTTP server, that often translates naively to one event = one HTTP request served. For mobile, a common pattern (e.g. the Google Analytics SDK relies on this approach) is to trigger an event per screen load — and this is a fine starting point. (Especially if you’re also able to capture timers like “how long did viewDidLoad actually take to run?“)
You may also find yourself wanting to track individual, detailed user actions like:
// User just sent a message!
event.send({
event_type: "message_sent",
roundtrip_dur_ms: now - start_ms,
sender: sender.name,
payload: message.length,
})
… But wait! There’re a couple of different angles to think about this here. On one hand, tracking an event like this directly from the client side lets you measure latencies as the user perceives them — but if this particular “interesting unit of work” already triggers a round-trip HTTP request to your servers, is it worth adding another HTTP call to Honeycomb’s? What would it look like if you just sent all the metadata along with requests to your server, then in your server’s logic, you extract out the message_sent data?
Upside: fewer HTTP requests from the client.
Downside: you lose the ability to factor in network latency, and it’s a little more complicated to reason about when you have “mobile app” events being emitted from your servers and your mobile clients into the same dataset.
While you’re still fairly low volume, I would recommend being aware of the tradeoffs 🙂 and then blithely going ahead with the simplest solution for you at this time.
Honeycomb is in the sweet spot
When it comes to mobile, Honeycomb is a great middle ground between specialized behavioral analytics tools and specialized operations tools. We believe that life is better (and simpler) when both sides (mobile devs and ops) can view the same set of data as a single source of truth, and we feel pretty strongly that — until you need the sorts of more advanced funneling / retention graphs that mature BI tools provide you — Honeycomb provides enough of the flexibility / ad-hoc investigation that you need to understand what’s going on with your app.
Let us know if you’re thinking about using Honeycomb for mobile — we’d love to hear about your use case and point you at some helpful libraries we’ve got in the works–try us out for free!
