Telemetrie für Apps mit Application Insights (5)

In den letzten Teilen haben wir uns damit beschäftigt, was wir alles loggen können. An dieser Stelle sei der Hinweis erlaubt, dass das noch lange nicht alles war. Wer sich mit den Application Insights beschäftigt und es einfach mal ausprobiert, der wird aber gegebenenfalls auf ein paar Hindernisse stoßen, die Frust verursachen können.

Zum Einen wird man sich fragen, ob denn der Logging Aufruf auch tatsächlich funktioniert hat – und welche Werte jetzt denn wirklich geloggt wurden. Gerade bei Verwendung von Metriken und Dimensionen sind die entsprechenden Werte in der Regel dynamisch, so dass man gerne wüsste, was hier eigentlich geloggt wurde. Natürlich kann man debuggen und sich die Werte anzeigen lassen – aber will man das immer?

Des Weiteren will man natürlich wissen: Sind die Daten, die gesammelt wurden auch schon übertragen? Ist etwas fehlgeschlagen? Und nicht zuletzt: Was genau wird hier eigentlich übertragen? Werden da vielleicht heimlich noch weitere Daten gesammelt von denen nicht einmal der Programmierer was weiß?

Was wird geloggt?

Um herauszufinden, welche Werte geloggt werden, gibt es eine schöne Möglichkeit in Visual Studio genau diese Werte anzeigen zu lassen. Hierzu muss in den Projekteinstellungen der Phone Applikation unter den Debugsettings die Einstellung “Native only” vorgenommen werden.

Anschließend können wir im Output-Fenster den Application Insights beim Loggen zusehen. Damit wir hier auch das sehen, was uns interessiert, können wir im Kontextmenü alle anderen Logs abschalten:

Der Output sieht dann zum Beispiel so aus:

In diesem Screenshot wird noch etwas mehr geloggt, als wir bisher besprochen haben. Ggf. folgt das in einem weiteren Blogpost. Für uns ist erstmal wichtig zu erkennen, dass wir die einfachen Events (blau) die Metrik (gelb) und die Dimensionen (rot) wiederfinden.

Wann und was wird übertragen?

Wenn wir wissen wollen, wann eigentlich übertragen wird, dann können wir das natürlich über einen Netzwerksniffer wie z.B. Fiddler validieren. In unserem Fall können wir auch einfach einen Blick in den Output werfen: Zum Programmstart werden wir folgende Outputs finden:

Und außerdem:

Das heißt: Information angekommen – der Server hat jetzt die Information, kann sie verarbeiten und wird sie uns in ein paar Minuten anzeigen. Meistens dauert das gut 15 Minuten. Die Übertragung findet beim Windows Phone dann statt, wenn die App gestartet wird, oder wieder resumed wird. Also ist die Information potentiell nicht unmittelbar nach einem Test verfügbar, sondern erst, wenn man die App danach neu startet. Gut zu wissen!

Aber was ist mit diesem seltsam kryptischen File im ersten Output gemeint? Kann man das einsehen? Man kann: Es liegt im Isolated Storage der App. Und zwar wird es dorthin geschrieben, sobald die Loggingsession beendet ist (was zum Beispiel nach dem Beenden der App der Fall ist). Sobald die Daten übertragen sind wird es gelöscht.

Über den Isolated Storage Explorer können wir das Ganze auch nachvollziehen:

Der Isolated Storage Explorer kommt mit dem Windows Phone SDK und liegt in C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Tools\IsolatedStorageExplorerTool .

Über den Commandline Aufruf

ise.exe ts xd 000-000 c:\phoneexport

können wir auf unserem Default Simulator (Parameter xd)  den Isolated Storage der App mit der ID 000-000 nach c:\phoneexport exportieren. Die Id der App erfahren wir aus dem App Manifest.

Anschließend ist unter c:\phoneexport ein Ordner zu finden, der den Inhalt des Isolated Storage wiederspiegelt. Mein Vorschlag: Startet Eure App im Simulator, loggt ein paar Insights und schließt die App. Wenn Ihr anschließend den Isolated Storage auslest, dann findet Ihr einen Ordner mit folgendem Inhalt:

Unter MS.CA findet Ihr eine Datei mit komischem Namen.

Diese könnt Ihr mit dem Notepad öffnen. Und siehe da: Das wird also übertragen – seht es Euch einfach mal an!