Azure
[Feature Request]: Telemetry improvements
Description
We need to disable telemetry by default, if this library should be used in production for many reasons. Telemetry, especially in IaC environments should always be opt-in and as there is a GUID hardcoded, the customer cannot even take a look into the telemetry data that was collected using the GUID and no one really knows where it is reporting. From a compliance view, it's unacceptable to have telemetry enabled by default without the possibility to view it or without any documented details about which metrics are collected exactly and where they are sent to. In addition to disable telemetry by default, we also need to make the "Customer Usage Attribution ID" customizable. This ID is often used by CSPs and consulting companies to track deployments with their customers and should never be overwritten. It currently makes the life harder for these companies as they are normally the ones using this module library and they need to disable telemetry explicitly for every module and adding in their own CUAID deployments.
Hey @itpropro,
thanks for creating the issue - I'll make sure it is addressed. Until then I'll try to provide some context, based also on what is documented in the Wiki.
The main point is, that the ID, which is deployed as part of the modules, is actually not a CUA-ID and can not be used to track the metrics that are usually collected using it (Note: A CUA-ID deployment requires a specific naming pattern that we 'break' using a suffix). This is by design and can, internally, only be used to get insights into the number of deployments of a given module. This also means we don't actually overwrite any existing such deployment. If one wants to deploy a CUA-ID I'd further highly recommend to do this on a solution and not a module level.
While this answer may not be satisfying I hope it helps a bit. As initially stated, I'll forward the issue to the right parties.
Thanks for explaining @AlexanderSehr! My main concern is not in the technical implementation, but more in the transparency for customers. For the ones who never heard of the CUA-ID, it's confusing that it is deployed without consent and for the ones who know it (like me) it's even more confusing 😉
There is a general negative spirit towards telemetry from Microsoft, although it is absolutely essential to improve products. To avoid people feeling like modules can deploy anything without anyone recognizing, we should change it to opt-in and document the exact telemetry data in more detail.
Another argument for opt-in is that there is no concept of global variables currently in bicep. That means that with the way that 99% of the people are currently using the CARML module, which is copying one or the whole folder, as they are not in the bicep module registry yet, you have to disable telemetry in every single module reference.
To address the above questions/concerns, the Telemetry chapter in the "Library - Module design" article has been updated with additional information about Telemetry approach used in the CARML library.
