Microsoft/alguidelines
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

deploy: 1653ec32cc

Browse source
This commit is contained in:
JeremyVyska 2022-03-25 15:10:30 +00:00
parent 9f8ffa7eca
commit 3680a904e2
203 changed files with 214 additions and 214 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/bestpractices/index.xml
View file

@ -100,7 +100,7 @@ All APIs pages apply the behavior to first specify all field values and then ins
<ul>
<li>SystemId
<ul>
<li>This field should be exposed wit the name <code>id</code></li>
<li>This field should be exposed with the name <code>id</code></li>
</ul>
</li>
<li>SystemModifiedAt
@ -255,7 +255,7 @@ Some examples</p>
<p>Telemetry data includes information about the object that emitted the telemetry signal. It’s recommended to call Session.LogMessage() <strong>from within the object</strong> that causes a situation that you want to have telemetry for. That will make it easier to analyze where exactly in the code an issue occurred.</p>
<p>Of course it is possible to have a single object as a central place to emit telemetry signals. The telemetry data includes a callstack, so eventually it would be possible to trace back to the exact place where an issue occurred. But that requires a more complicated query, so it would be better to emit telemetry signals right from place in the code where an issue occurred.</p>
<h2 id="candidate-data-for-telemetry">Candidate data for telemetry</h2>
<p>Telemetry must be <strong>actionable</strong> for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database)</p>
<p>Telemetry must be <strong>actionable</strong> for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database).</p>
<p>Also, note that customers pay for data ingestion. So be mindful to not flood their telemetry resources. Consider to use TelemetryScope::ExtensionPublisher by default and only use TelemetryScope::All in case the customer can also act on the data.</p>
<p>If you do not know where to start, consider using telemetry for deflection. In Dynamics 365 Business Central, they started with signal about authorization (successful/failed) to deflect support cases that was due to disabled users/wrong licenses.</p>
<h2 id="how-customers-use-telemetry">How customers use telemetry</h2>