-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add source to analytics events. #2750
Conversation
778f37a
to
84adcdc
Compare
This allows for differentiation between state tool, offline installer, executors, etc.
84adcdc
to
44abffa
Compare
const AnalyticsCat = "installer" | ||
const AnalyticsFunnelCat = "installer-funnel" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved into analytics/constants.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should set this at construction time. We would never want to modify this on a per-event basis.
Also note with the svc that it handles two types of analytics:
- First, it has its own analytics that it sets up here:
Line 101 in 4087dc2
an := anaSync.New(cfg, auth, out) - This one should have the state-svc as the source
- It also facilitates analytics for the state tool itself, this one is constructed here:
anForClient := sync.New(cfg, auth, nil) - This one should have the state tool as the source.
Also improve forwarding events on behalf of executors.
fa538a8
to
1a6ad98
Compare
@@ -97,7 +97,7 @@ func (w *Watcher) check() { | |||
|
|||
func (w *Watcher) RecordUsage(e entry) { | |||
logging.Debug("Recording usage of %s (%d)", e.Exec, e.PID) | |||
w.an.Event(anaConst.CatRuntimeUsage, anaConst.ActRuntimeHeartbeat, e.Dims) | |||
w.an.EventWithSource(anaConst.CatRuntimeUsage, anaConst.ActRuntimeHeartbeat, anaConst.SrcExecutor, e.Dims) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks to me like all heartbeats come from executors, so that's why the source is this and not State Tool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call! I forgot about that caveat.
Good call with putting source in the analytics client. We still need some wiggle room to differentiate between state tool and executors (particularly in the runtime area), so state-svc cannot assume If you don't care to differentiate, let me know and I'll drop all that special handling. Or if you have another idea, let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! In addition to the one case I flagged for executor handling, I think we should also have our analytics integration tests specifically check for it.
IIRC the analytics tests are already triggering state tool events as well as executor events, so with the data we're already generating we could assert that they have the expected source set.
0e09d14
to
52b7462
Compare
…integration tests.
52b7462
to
e90f8ea
Compare
) | ||
|
||
var isExecutor bool | ||
|
||
func init() { | ||
if osutils.Executable() == constants.StateExecutorCmd { | ||
isExecutor = true | ||
if isExec, err := executors.IsExecutor(osutils.Executable()); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said executors do not use the analytics package directly, so I don't think we need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Executors can trigger runtime setup/use, right? That will send out analytics requests to state-svc, which should then forward them to GA: https://github.com/ActiveState/cli/pull/2750/files#diff-d6507bff98aa2549ce60b737f856f84e7a24e20bf39fef4a7ba6f05adf62ffe7R100-R103
Or am I missing something? When I checked the analytics int test event files, I'm seeing runtime-use:attempt, runtime-debug:download, and runtime-debug:success events for executors (e.g. python --version
). This is what I expected to see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right, but this code is checking the current executable. There is never a scenario in which an executor invokes the analytics code (whether sync or async) directly. Instead they talk directly to the svc without the analytics library. The svc then uses its analytics library to report the event.
In other words; I don't believe there is a scenario in which this conditional evaluates to true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, you're right. I went through a debugger and that code does not appear to be hit. I've removed it.
fmt.Sprintf("output:\n%s\n%s", | ||
cp.Snapshot(), ts.DebugLogs())) | ||
|
||
heartbeatInitialCount := countEvents(events, anaConst.CatRuntimeUsage, anaConst.ActRuntimeHeartbeat) | ||
heartbeatInitialCount := countEvents(events, anaConst.CatRuntimeUsage, anaConst.ActRuntimeHeartbeat, anaConst.SrcExecutor) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also assert here that we got both executor and state tool heartbeats?
ie. the state activate
should've triggered heartbeats from the state tool, whereas the executor would've triggered it from the executor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so my comment here is not valid, right? #2750 (comment) I want to confirm before I spend time on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry that's my bad. Your comment there is indeed incorrect, I should've known that but I guess I wasn't thinking it through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments.
Executors should not invoke this code directly, so there should be no analytics source confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I think you missed this comment though: #2750 (comment)
Sorry about that. Too many double negatives. I got confused and thought the opposite of what you were thinking :S |
edd93cc
to
5ab86e5
Compare
5ab86e5
to
a6928da
Compare
source := anaConst.SrcExecutor | ||
if filepath.Base(e.Exec) == constants.StateCmd+osutils.ExeExt { | ||
source = anaConst.SrcStateTool | ||
} | ||
w.an.EventWithSource(anaConst.CatRuntimeUsage, anaConst.ActRuntimeHeartbeat, source, e.Dims) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels too error prone to me. Could we instead add the source as an argument for the ReportRuntimeUsage resolver on the svc?
The only place executors call this is here:
Line 142 in be95799
_, err = resolver.ReportRuntimeUsage(context.Background(), pidNum, hb.ExecPath, dimsJSON) |
Any other place would be state tool. I'd be fine defaulting to state tool if the source is empty.
82a5165
to
85c050e
Compare
85c050e
to
bfef23d
Compare
The change got a bit involved since there's graphql involved, so let me know if you had something else in mind. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
This allows for differentiation between state tool, offline installer, executor, etc.