Not a customer? Click the 'Start a free trial' link to begin a 30-day SaaS trial of our product and to join our community.
Existing Cisco AppDynamics customers should click the 'Sign In' button to authenticate to access the community
05-16-2022 08:53 AM
We are developing an Android app that uses AppDynamics 20.5.0 and Firebase Bill-of-Materials 26.8.0, which includes Firebase Performance. We recently received a report from a user who found that the background network data usage of our app was extremely high, on the order of gigabytes per month.
Upon investigation, we found that the call to the https://col.eum-appdynamics.com endpoint would consume a lot of data as requests were repeatedly made to it on app startup. We went through our app release history and noticed that this behavior started around the time we added Firebase Bill-of-Materials, and after digging some more, found that the high data usage stopped when we disabled Firebase Performance.
This behavior is present even when we update AppDynamics to its latest version (21.11.0) and Firebase Bill-of-Materials to its latest version (30.0.1).
Is this a known issue, and if so, is there anything that can be done on the mobile app side's AppDynamics configuration to prevent the high data usage? In the short term, we've disabled Firebase Performance in the app, but obviously it's not an optimal solution.
Solved! Go to Solution.
05-17-2022 04:17 PM
05-18-2022 11:44 AM - edited 05-20-2022 07:31 AM
Here's something you might find interesting. In order to figure out which Firebase network calls were getting captured by AppDynamics, I enabled Firebase Performance again and turned on AppDynamics logging with
Instrumentation.start(
AgentConfiguration.builder()
.withAppKey(BuildConfig.APPDYNAMICS_EUM_KEY)
.withContext(applicationContext)
.withLoggingEnabled(true)
...
I did see captures of a Firebase URL (https://firebaselogging-pa.googleapis.com/v1/firelog/legacy/batchlog) in the logs, like this:
I/AppDynamics: [{"type":"network-request","ec":5216,"eid":"032d59a6-8e77-455c-8e8e-c3605d8dafcf","sessionCounter":-1,"st":1652898366005,"sut":1311277514,"et":1652898366960,"eut":1311278468,"bkgd":false,"url":"https://firebaselogging-pa.googleapis.com/v1/firelog/legacy/batchlog","hrc":200,"crg":"f2629914-c6ab-4a8e-8a2e-3fae504f1274","bts":[],"see":false,"is":"AppDynamics.URLConnection","avi":52,"av":"4.0.8","agv":"20.5.0","ab":"e7031ad7","dm":"samsung","dmo":"SM-G781U1","ds":110167,"tm":"5628","cf":"1804800","cc":8,"osv":"12","ca":"unknown","ct":"wifi","bid":"33518b01-0b6f-496e-bc1b-8810a92469b6"}]
So I tried filtering them out with this:
Instrumentation.start(
AgentConfiguration.builder()
.withAppKey(BuildConfig.APPDYNAMICS_EUM_KEY)
.withContext(applicationContext)
.withLoggingEnabled(true)
.withExcludedUrlPatterns(
setOf(
"^https:\\/\\/firebaselogging\\-pa\\.googleapis\\.com.*\$",
)
)
But they were fairly infrequent, and the high data usage was still present.
What I did see being printed repeatedly were entries like these, which seemed to be logging calls made to the AppDynamics collection URL (https://col.eum-appdynamics.com/eumcollector/mobileMetrics?version=2
2022-05-18 14:29:25.005 28372-28457/? I/AppDynamics: [2:29:25 PM Eastern Daylight Time] Agent sending beacons to collector (https://col.eum-appdynamics.com/eumcollector/mobileMetrics?version=2) [AD-AAB-AAC-NMJ]:
2022-05-18 14:29:25.006 28372-28457/? I/AppDynamics: [{"type":"network-request","ec":5381,"eid":"6e02c4f4-fe8a-4c7e-9a7b-45297837b2be","sessionCounter":-1,"st":1652898564881,"sut":1311476390,"et":1652898564999,"eut":1311476508,"bkgd":false,"url":"https://col.eum-appdynamics.com/eumcollector/mobileMetrics?version=2","pcl":2,"hrc":200,"crg":"da9ee96c-db86-4174-a35e-535d02f60736","bgan":"appdynamics_eee1d4f8-67a2-498e-a725-47e29803822e","bts":[{"btId":"559464","time":-1,"estimatedTime":0}],"see":false,"is":"AppDynamics.URLConnection","avi":52,"av":"4.0.8","agv":"20.5.0","ab":"e7031ad7","dm":"samsung","dmo":"SM-G781U1","ds":110167,"tm":"5628","cf":"1804800","cc":8,"osv":"12","ca":"unknown","ct":"wifi","bid":"8f6360f2-6186-46d0-ac36-d9f340cff65b"}]
It almost seems like AppDynamics is capturing calls to its own collection URL, repeatedly, but only when Firebase Performance is enabled.
If I filter out the AppDynamics collection URL as well, like this:
Instrumentation.start(
AgentConfiguration.builder()
.withAppKey(BuildConfig.APPDYNAMICS_EUM_KEY)
.withContext(applicationContext)
.withLoggingEnabled(true) // set default INFO logging. Tagged "AppDynamics".
.withExcludedUrlPatterns(
setOf(
"^https:\\/\\/firebaselogging\\-pa\\.googleapis\\.com.*\$",
"^https:\\/\\/col.eum\\-appdynamics.com\\/eumcollector.*\$",
)
)
then the high data usage stops.
05-19-2022 08:57 AM - edited 05-19-2022 08:59 AM
Hi @Joseph.Kreiser @Tony.Zhang
Your reply is now live on the thread. It was being caught by spam since you had a post with a large amount of text and code. I have gone ahead and approved your replies and deleted all but the first one.
Going forward you should not have this problem.
Thanks,
Ryan, Cisco AppDynamics Community Manager
Found something helpful? Click the Accept as Solution button to help others find answers faster.
Liked something? Click the Thumbs Up button.
Check out Observabiity in Action
new deep dive videos weekly in the Knowledge Base.
05-19-2022 10:43 AM
Hi Joseph,
Thank you for the detailed followup. Good to know that this resolves the problem. We are not familiar with internal workings of Firebase performance, but its likely due to mutual instrumentation between the plugins. Will look into how this issue can be more easily avoided in the future and address it in a future release. Meanwhile this workaround, or the one I suggested should suffice. Let us know if you run into any more issues!
05-20-2022 07:35 AM
I should also mention that I tried excluding Firebase classes, like this:
adeum {
...
excludeClasses = ['com.google.firebase.*']
}
but the high data usage was still present.
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form