Can DD upload logs when app is in "active" state even with disabled "Background Fetch | | Background App Refresh"?

[oharbo]

Question

Hello DD team, thank you for your library. I have a question regarding the log uploading. The issue we are experiencing right now is the fact that logs sending is disabled on DataDog when the user has enabled the "Low Power Mode" or disabling "Background App Refresh" either globally or per app. I am aware of the impact of Low Power Mode on the backgroundFetch, and question that I have, taking into account what is mentioned above:

• Is there a way to enable DD to send the logs even if "Low Power Mode" or "Background App Refresh" is disabled - when the app is in an "active" state?

[marco-saia-datadog]

Hello @oharbo, thank you for reaching out!

Currently there is no way to override the default behaviour, but keep in mind that the SDK still collects and persists data in Low Power Mode, so it will be uploaded as soon as the "Low Power Mode" is disabled and other upload conditions are met.

This behaviour is intentional, as we don't want to negatively impact the user experience when the battery is low or Low Power Mode is enabled. For iOS, we are following the Apple recommendations from Energy Efficiency Guide for iOS Apps

If you want to make sure to get the most out of your use case, there are ways in which you can tweak the batch behaviour through the SDK init configuration. For example:

• batchSize: Defines the Datadog SDK policy when batching data together before uploading it to Datadog servers.
• trackBackgroundEvents: Enables tracking of RUM event when no RUM View is active.
• uploadFrequency: Sets the preferred frequency for uploading batches of data.

If your users don't use the app frequently, my suggestion is to try configure the SDK to collect and send data more frequently and in more cases:

{
   "trackBackgroundEvents": true,
   "uploadFrequency": "FREQUENT",
   "batchSize": "SMALL"
}

This won't prevent the Low Power Mode use case that you have described, but it would significantly increase the chances that - as soon as Low Power Mode is turned off and the app is re-opened - your logs will be collected and sent.

We may think of providing logs importance level API, so that critical data can be send even in constrained environment, but there's no ETA for this feature - we must discuss it widely in the team and plan carefully.

If this behaviour is critical for your business, feel free to open a feature request, so that we can assess its priority more accurately.

[oharbo]

@marco-saia-datadog Thank you for your prompt response and the valuable suggestions on improving our log-sending process. I will give try to implement your recommendations and see how they enhance our logging experience.

Regarding the current setup, I am aware of where the Datadog library stores logs and how to access them at the application level, particularly when the app is in the foreground.

However, our application's intensive resource usage, especially in terms of power and network usage, prompts many users to frequently enable "Low Power Mode" to conserve battery life. Unfortunately, this postpones the uploading of logs to your platform until "LPM" is disabled.

To address this challenge, we're open to the idea of initiating additional upload requests specifically for the Datadog log files. Given this context, we're exploring the possibility of copying or moving the log files from the Datadog /tmp location and directly uploading them to a designated endpoint on your platform.

Could you please assess the feasibility of this approach and provide any guidance or recommendations on how we can effectively implement it? Specifically, I am concerned regarding the ways to avoid logs duplication or logs missing in case we would be leveraging the logs uploads when "LPM" enabled or "backgroundFetch" disabled on a system level.

Your insights would be greatly appreciated. Thank you.

[marco-saia-datadog]

Hi @oharbo

Sorry for the long wait!

Could you please assess the feasibility of this approach and provide any guidance or recommendations on how we can effectively implement it?

It is a non-standard approach for which we cannot guarantee support, but in theory it should be feasible, as long as you can access the logs, verify that they exist and implement the correct logic to upload them. Have you tried this approach yet? And if so, did you encounter any specific issues you would like us to address?

Specifically, I am concerned regarding the ways to avoid logs duplication or logs missing in case we would be leveraging the logs uploads when "LPM" enabled or "backgroundFetch" disabled on a system level.

Avoiding duplicates might be difficult, as we don't provide a mechanism to clear the log batch or access it from the SDK itself. However, given that each log has a context, you can identify the log by one of its properties and create appropriate filters on the Datadog browser UI.

Would that work for you?

If you encounter any issues you can always reach out to us, and we will be happy to help you!

[oharbo]

@marco-saia-datadog thank you a lot for updates, we've decided to go with a standard approach of receiving logs from DD, instead focused on optimisation of app resource usage.