azuremauiazure-application-insights

Application Insights TelemetryClient for .NET maui in offline mode results. Bug or by design?


TLDR: got mixed results on how TelemetryClient is capable of holding data, collected while device is offline. Short offline periods allow data to be flushed to Azure Insights successfully once the connection is restored. However, longer offline periods result in data loss, possibly due to the client attempting to flush while offline.

TelemetryClient uses InMemoryChannel by default.

I ran a few experiments to see how well in works in offline mode.

I launched Android Emulator, turned internet for the whole device off with the following first 2 adb shell commands

enter image description here

Then I made some interactions inside the .NET maui app that add TelemetryClient's pageViews and customEvents data, then turned connection back on and wait couple of min before running Kusto queries. These is to give a chance for TelemetryClient to flush my Azure Insights (I do not execute Flush manually).

Then I went Azure Insights and checked the data:

pageViews
| where timestamp >= ago(45m)

customEvents
| where timestamp >= ago(45m)

Results:

When I do not wait for longer than several seconds in between connection is on and off moments, then it works fine, - I can see "offline" click events and page views when the device is back online.

However when I leave it for like 10-15 min I does not work. I assume if it tries to flush the changes while connection if off it loses the collected data. I think by default Flush occurs every 30 sec or when it reaches like 500 messages in memory.

Not sure if the "sometimes data lost" behavior is a bug or per design, sounds like a bug to me.

When connection is restored new clicks provide events to Azure Insights successfully though.

If anyone had such experience please share or advise on why it might happen. If the TelemetryClient stores data in-memory and unable to flush them due to connection lost, why would it delete it, why not hold them till connection is on. Something does not add up.


Solution

  • Not sure if the "sometimes data lost" behavior is a bug or per design, sounds like a bug to me.

    Well, the docs says:

    This channel offers minimal reliability guarantees because it doesn't retry sending telemetry after a failure. This channel also doesn't keep items on disk. So any unsent items are lost permanently upon application shutdown, whether it's graceful or not.

    In your case you should configure Application Insights to use the `ServerTelemetryChannel` :

    A more advanced channel that has retry policies and the capability to store data on a local disk. This channel retries sending telemetry if transient errors occur. This channel also uses local disk storage to keep items on disk during network outages or high telemetry volumes. Because of these retry mechanisms and local disk storage, this channel is considered more reliable. We recommend it for all production scenarios.