Summary:
Adds an optional "plugin" field to the tracked metrics. The idea is to be able to see failures in plugins.
Added it around all desktop -> sdk "call"s, so it won't require any effort from developers but we'll get lots of immediate data. E.g. How often layout -> getNodes fails. I think we can go modify the existing pipeline to take both platform and plugin data so we can get session roll-ups too.
Corresponding change to the puma app: D13882629, adds a plugin field to all tables so we can filter by plugin, or null for platform failures.
I'm thinking it will be worthwhile to expose some method to plugin developers, that lets them explicitly track failures. It would be better if it encapsulated their plugin id etc, so they just need to say what failed. But that can be done any time, I don't have any particular use cases in mind yet.
Reviewed By: passy
Differential Revision: D13878379
fbshipit-source-id: 2e2ef6b98f763e6edcfe937741d6988dae4b92d1
Summary: Will allow us to look into bad sessions if necessary.
Reviewed By: passy
Differential Revision: D13695386
fbshipit-source-id: 2cfc8ec28ef4cb387ef7a5a58b02aa77a367ae81
Summary:
The advantage of this is that anyone can now log without needing to carry around a Logger object.
Primary reason is for making metrics less intrusive in the codebase.
Reviewed By: passy
Differential Revision: D13671368
fbshipit-source-id: 162ab1351a124683aef13983fc3bcec01385cd1a
Summary:
This is semi-explorative to see how far we can get with this approach, but I think it'l be useful. If it is, we can factor the code into a nicer utility, that perhaps wraps promises or even just has succeeded/failed methods.
Using 1 and 0 instead of true and false so we can do numerical aggregates on it, like average, which will give the success rate.
This will allow queries such as:
* What percentage of attempts fail? - Not very useful because they get retried if they fail.
* What percentage of sessions that attempt, encounter a failure? - More useful, but still not perfect because they could retry and succeed.
* What percentage of sessions attempt and don't ever succeed? - Better but still not perfect because one device might succeed and another fail, but this will be rare.
Reviewed By: passy
Differential Revision: D13625987
fbshipit-source-id: 2b9f45cc888247d068cc52281443e9ece7985da8
Summary:
I've left InteractionTracker without a store, so it doesn't know the sessionId. It really should have one, but that will have to be a different change.
We don't actually use the InteractionTracker at the moment so it's not a major deal for now.
The idea is to be able to get data like what percentage of sessions encounter an error, and how many errors sessions usually have etc.
Reviewed By: passy
Differential Revision: D13624031
fbshipit-source-id: 664e7ac5023166c2f72df3058c219901be7ff77a
Summary:
We've replaced the global console.* methods with those in the Logger.
The OSS Logger uses a different implementation to the internal fb one, and it still calls back to console.*, causing a stack overflow.
Fix it by removing the console calls from Logger.js.
Logging to the original console methods is done by the Proxy in App.js.
Fixes#101
Closes https://github.com/facebook/Sonar/pull/102
Reviewed By: priteshrnandgaonkar
Differential Revision: D8617042
Pulled By: jknoxville
fbshipit-source-id: 055bf0e1a2fba8ad5312c88fa97a44389eb52390
