Scribd
Upload
10 views

satya_to

The document outlines various performance metrics that can be tracked by Dynatrace, including app-level metrics, user experience, network performance, crash monitoring, resource usage, and custom metrics. It also discusses the capabilities and limitations of using ADB and Python for fetching certain metrics, highlighting what can be achieved with and without root access. Overall, it emphasizes the importance of SDK integration for comprehensive monitoring and analytics.

Uploaded by

Ratikant Biswal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
10 views

satya_to

The document outlines various performance metrics that can be tracked by Dynatrace, including app-level metrics, user experience, network performance, crash monitoring, resource usage, and custom metrics. It also discusses the capabilities and limitations of using ADB and Python for fetching certain metrics, highlighting what can be achieved with and without root access. Overall, it emphasizes the importance of SDK integration for comprehensive monitoring and analytics.

Uploaded by

Ratikant Biswal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 7

1.

App-Level Performance Metrics


These are automatically captured without manual instrumentation:

Metric Description
App launch time Cold and warm startup durations
App version Distribution of versions in use
App load time Time it takes for screens or views to render
App responsiveness Measures ANRs (Application Not Responding)
App crash rate Crash count and crash-free user/session rate
Session duration Length of user sessions
Session count Number of user sessions over time

User Experience & Behavior


Dynatrace tracks real user actions and their performance:

Metric Description
User actions Tap, scroll, swipe, navigation, custom actions
User action duration Time to complete each user action
UI responsiveness Time taken by views/screens to respond
Screen transitions Which screens are visited, and in what order
User journey Funnel analysis and drop-off points
Geolocation Country, region, and city of users
Carrier/network type Mobile network vs WiFi, carrier name

Network Performance
Dynatrace can trace network calls end-to-end:

Metric Description
HTTP request timing Total time, connect time, DNS lookup, etc.
Failed requests Count and type (timeout, error code)
Response times Per endpoint or URL
Throughput Data sent/received per session/user
Metric Description
Backend service calls Correlation with backend services (tracing)

Crash & Error Monitoring


Detailed crash diagnostics with root cause analysis:

Metric Description
Crash count Total crashes and trends
Crash rate Crashes per session or user
Stack traces Full stack trace for each crash
ANR reports Logs and timing of app not responding errors
Handled/unhandled exceptions Captured via SDK
Custom error reporting Using Dynatrace.error() manually in code

Resource Usage Metrics


Requires deeper SDK integration or OneAgent:

Metric Description
CPU usage CPU consumption of your app
Memory usage Java heap, native heap, total usage
Battery consumption Power usage by app (approximate)
Thread count Number of active threads
GC activity Garbage collection frequency and duration

Custom Metrics (via SDK)


You can add your own metrics:
Metric Description
Custom user actions e.g. dynatrace.enterAction("MyAction")
Web request tracing OneAgentSDK.traceWebRequest()
Business metrics Custom counters, values (e.g., cart size)

Backend Integration Metrics


If the app interacts with Dynatrace-monitored services:

Metric Description
Service response time Traced to backend microservices
Error hotspots Backend components causing slowdowns
Service flow End-to-end distributed tracing view
Database calls If backend databases are instrumented

Summary
Dynatrace gives you:
• Full-stack visibility (mobile + backend)
• Real-user monitoring
• Code-level crash diagnostics
• Network tracing
• Custom instrumentation for business logic

Would you like help setting up the SDK in your app or understanding how to map these to adb
equivalents or integrate them into a CI/CD pipeline?

=======================================================================
Metrics We CAN Fetch (or partially fetch) using ADB + Python:
• 10. OS Versions: Yes, directly fetchable for the connected device.
• 12. Network Type: Yes, directly fetchable for the connected device.
• 13. Device Type: Yes, directly fetchable (model, manufacturer) for the connected device.
• 14. Stack Traces: Yes, fetchable from logcat when crashes or unhandled exceptions occur
on the connected device.
• 17. Crash Count: Yes, can be counted by parsing logcat for crash signatures on the
connected device only.
• 20. Error: Yes, specific error messages/details can be fetched by parsing logcat if the
application logs them on the connected device.
Metrics We CAN Fetch Only If the App Explicitly Logs Them (Unlikely/Unreliable for Generic
Use):
• 1. User actions: Only if the app logs every action to logcat.
• 9. Web Request: Only if the app logs detailed network activity to logcat (uncommon).
• 19. Action Duration: Only if the app calculates and logs these durations to logcat.

Metrics We Generally CANNOT Fetch using only ADB + Python:


These almost always require an integrated Analytics or APM SDK within the app itself.
• 2. User Sessions
• 3. Session Count
• 4. Active Users
• 5. Apdex Rating
• 6. Crash Rate (Requires total sessions/users)
• 7. Error Count (Aggregate count)
• 8. Error Rate (Requires context like total actions/sessions)
• 11. Geolocation (App-specific usage is generally not exposed via ADB)
• 15. Session Duration
• 16. Session Replay On crashes
• 18. Crash Free users
• 21. Rage Tape
CAN Be Captured with ADB + Python
Metric ✅ How?
App launch time ✅ Via logcat → filter ActivityManager with Python
CPU usage ✅ adb shell top, dumpsys cpuinfo
Memory usage ✅ adb shell dumpsys meminfo <package>
Battery stats ✅ adb shell dumpsys batterystats
Network usage (basic) ✅ /proc/uid_stat/<uid>/*, dumpsys netstats
App crashes ✅ adb logcat -d, parse for FATAL EXCEPTION
ANR reports ✅ /data/anr/traces.txt
Thread count ✅ `adb shell ps -A
GC activity (indirectly) ✅ Parse logcat for GC logs (dalvikvm)
Screen transitions (manual logs) ✅ If you log transitions and parse them
Logs (any kind) ✅ adb logcat and Python regex parsing

CANNOT Be Captured with ADB + Python Alone


Metric ❌ Why Not?
Session tracking (user
❌ ADB has no user/session awareness
sessions)
User actions (taps, clicks,
❌ No access to UI events via ADB
flows)
User journey/funnel flow ❌ Needs app instrumentation or SDK
Backend tracing ❌ ADB can't correlate to backend APIs
Custom business metrics ❌ ADB has no app logic visibility
Web request timings
❌ Can’t trace at the HTTP layer per call
(accurate)
Geo-location / carrier info ❌ Not accessible via ADB
Real user behavior analytics ❌ Requires instrumentation and session correlation
App version distribution ❌ ADB gives only current version via dumpsys package
Crash-free sessions or users ❌ Requires session/user analytics
App responsiveness (UI Partially possible with dumpsys gfxinfo, but not full
❌
jank/fps) responsiveness
Smartscape service map ❌ Dynatrace-exclusive backend service topology
Partially Available Metrics (Can Be Approximated)
Metric ⚠️ How / Limitations
App load/render time ⚠️ From logs (Displayed time), but not complete
Network request latency ⚠️ Using tcpdump or packet count, but no URL context
Battery usage per app ⚠️ batterystats shows it, but estimation only
FPS (frame rate) ⚠️ dumpsys gfxinfo → needs heavy parsing and not continuous
Crash stack traces ⚠️ Capturable, but not always structured cleanly
GC activity ⚠️ Logcat parsing, but no exact quantification

TL;DR Summary
Type Can ADB + Python Do It?
System-level metrics ✅ Fully possible
App crash & logs ✅ Mostly possible
Session/user behavior ❌ Not possible
Backend tracing ❌ Not possible
Custom business metrics ❌ Not possible
Accurate UI responsiveness ⚠️Partially possible
Network telemetry ⚠️Possible but limited context

=======================================================================

What Root Access Unlocks (Even on Android 12/13+)

Metric Without Root With Root


Per-app network usage (/proc/uid_stat/) ❌ ✅
Access to /data/anr/ for ANR traces ❌ ✅
Battery usage per UID (via batterystats) ⚠️partial ✅ full
Reading full logs from logcat (system & other apps) ⚠️filtered ✅ full logs
Running tcpdump or Wireshark on the device ❌ ✅
CPU affinity, thread-level stats ⚠️ ✅
Access to app private data (optional) ❌ ✅
Extracting memory maps (/proc/<pid>/maps) ❌ ✅
System-wide perf events (like tracing) ❌ ✅
If you're just tracking your own app’s performance, you can get a good chunk using ADB +
permissions.

If you want deep system-wide monitoring like Dynatrace does (including other apps, kernel stats,
etc.), root access is required.

You might also like