jsanda · January 22, 2015 14:52
diff --git a/gistfile1.txt b/gistfile1.txt
 mstruk: jsanda: sure, let's discuss it
 08:02 jsanda: which means we also need to consider queries
 08:02 mstruk: jsanda: yeah, in this case I hide something akin to stored procs behind /rhq-metrics/event-log endpoint
 08:03 mstruk: jsanda: well … hardcoded in java ...
 08:03 mstruk: jsanda: this needs to be made more generic
 08:03 jsanda: yeah, i figured that, but it looks like a great start from what i saw
 08:04 jsanda: not sure if it is a good starting point, but i'm looking at https://github.com/mstruk/rhq-metrics/blob/liveoak/core-api/src/main/java/org/rhq/metrics/core/LogEvent.java
 08:04 jsanda: here's my first question
 08:04 jsanda: what fields minimally describe an event?
 08:05 mstruk: jsanda: for my purposes I have two types of events actually
 08:06 tcrawley-away is now known as tcrawley
 08:06 mstruk: jsanda: one is a web request which is a typical HTTP request / response pair
 08:06 mstruk: jsanda: but then I also have a notification
 08:07 mstruk: jsanda: which is a server side event triggered by some resource change … sent to client subscribers via STOMP
 08:08 mstruk: jsanda: both of these have a clientAddress, a timestamp, a (response) status
 08:09 mstruk: jsanda: they have a uri that identifies a resource but it has a slightly different meaning - in one case it's the resource requested through HTTP GET/POST …
 08:09 jsanda: mstruk: brb
 08:09 mstruk: jsanda: in the other it is the resource that was changed - some STOMP client subscribed for changes and that uri identifies the resource that was changed
 08:10 mstruk: jsanda: ok
 08:12 mstruk: jsanda: application identifies the application that produced an event … multiple apps can be deployed in LiveOak in parallel, each one getting its own context underneath root
 08:13 mstruk: jsanda: if request is performed by an authenticated connection then userId will be set to user's id
 08:13 jsanda: does the LogEvent class cover both types?
 08:14 mstruk: jsanda: yes, it makes things simpler … common structure, common access logic …
 08:15 jsanda: makes sense
 08:15 jsanda: thanks for the explanation, helpful
 08:15 mstruk: jsanda: an it makes sense when you want to list events by time … you want them all rther than combining to sources in one timeline
 08:16 mstruk: to -> two
 08:17 jsanda: what about the userId field?
 08:18 mstruk: jsanda: no problem, if you have more questions just let me know
 08:19 jsanda: for queries, would you want to filter by application?
 08:20 jsanda: specifically, i'm wondering how data should be segmented
 08:20 lholmquist has joined ([email protected])
 08:20 lholmquist has left IRC (Changing host)
 08:20 lholmquist has joined (~lholmquis@redhat/jboss/lholmquist)
 08:21 jsanda: is it the case that a user of one application should not see data of another application, or can there be multiple applications for a user
 08:22 mstruk: jsanda: typical use case for me is to filter by application yes … as each application has its own analytics page that shows stats for that specific application
 08:23 tcrawley is now known as tcrawley-away
 08:25 mstruk: jsanda: I can image that we might have a full container view that might show analytics for all the applications … in that case there would be no per app filtering applied
 08:26 jsanda: that makes sense
 08:28 jsanda: and there will be multiple events per uri, right?
 08:37 mstruk: jsanda: right, you can GET an uri multiple times, and an uri can be updated multiple times resulting in notification events for the same uri
 08:40 jsanda: i'm wondering if we might be able to store userId as a tag
 08:40 jsanda: currently we have the concepts of tags and meta data
 08:40 jsanda: i'm in the processing of combining them since they really are the same
 08:40 nscavell has joined ([email protected])
 08:40 nscavell has left IRC (Changing host)
 08:40 nscavell has joined (~nscavell@redhat/jboss/nscavell)
 08:41 jsanda: and just calling them tags which are key/value pairs where the value is optional
 08:41 jsanda: so if an event includes the userId, a "userId" tag could be set
 08:42 jsanda: and then you could search/filter on that userId to find events by that user
 08:42 mstruk: jsanda: I added in there a notion of tags in LogEvent, I knew you were working on tags … I guess userId could be a tag yes
 08:43 jsanda: i'm just thinking out loud
 08:43 jbossbot has joined (~JBossBot@redhat/jbossbot)
 08:43 jsanda: don't hesitate to let me know if it sounds like a bad/scary idea :)
 08:46 mstruk: jsanda: :) as far as userId goes it is used for determining unique users, so for that query it needs to have access to userId on EventLog … so if it becomes a tag it would have to be loaded for that query
 08:47 mstruk: jsanda: other than that the only other use I see might be inspecting a specific user activity … not really something that plays a role in analytics views …
 08:47 mstruk: jsanda: ATM that's not an issue anyway as the only impl is in-memory
 08:48 jsanda: hmmm
 08:48 jsanda: interesting
 08:48 jsanda: i've not actually seen liveoak in action. by any chance are there any demos?
 08:49 mstruk: jsanda: we have some videos … they're not the latest though
 08:50 jsanda: if you think it would be informative, i'd be happy to watch them. i will also download liveoak and play around some
 08:50 kenfinnigan has joined (~ken@redhat/jboss/kenfinnigan)
 08:50 ChanServ has changed mode: +o kenfinnigan
 08:51 mstruk: jsanda: http://liveoak.io/docs/#getting-started
 08:51 jbossbot: Title: LiveOak - The Open Source Mobile Services Platform
 08:51 jsanda: mstruk: perfect. let me do that and then follow back up on the data model.
 08:52 mstruk: jsanda: there used to be links to videos there … can't see them now … hmm
 08:53 kenfinnigan: mstruk, jsanda: http://liveoak.io/docs/#gs-screencasts
	mstruk: jsanda: sure, let's discuss it
	08:02 jsanda: which means we also need to consider queries
	08:02 mstruk: jsanda: yeah, in this case I hide something akin to stored procs behind /rhq-metrics/event-log endpoint
	08:03 mstruk: jsanda: well … hardcoded in java ...
	08:03 mstruk: jsanda: this needs to be made more generic
	08:03 jsanda: yeah, i figured that, but it looks like a great start from what i saw
	08:04 jsanda: not sure if it is a good starting point, but i'm looking at https://github.com/mstruk/rhq-metrics/blob/liveoak/core-api/src/main/java/org/rhq/metrics/core/LogEvent.java
	08:04 jsanda: here's my first question
	08:04 jsanda: what fields minimally describe an event?
	08:05 mstruk: jsanda: for my purposes I have two types of events actually
	08:06 tcrawley-away is now known as tcrawley
	08:06 mstruk: jsanda: one is a web request which is a typical HTTP request / response pair
	08:06 mstruk: jsanda: but then I also have a notification
	08:07 mstruk: jsanda: which is a server side event triggered by some resource change … sent to client subscribers via STOMP
	08:08 mstruk: jsanda: both of these have a clientAddress, a timestamp, a (response) status
	08:09 mstruk: jsanda: they have a uri that identifies a resource but it has a slightly different meaning - in one case it's the resource requested through HTTP GET/POST …
	08:09 jsanda: mstruk: brb
	08:09 mstruk: jsanda: in the other it is the resource that was changed - some STOMP client subscribed for changes and that uri identifies the resource that was changed
	08:10 mstruk: jsanda: ok
	08:12 mstruk: jsanda: application identifies the application that produced an event … multiple apps can be deployed in LiveOak in parallel, each one getting its own context underneath root
	08:13 mstruk: jsanda: if request is performed by an authenticated connection then userId will be set to user's id
	08:13 jsanda: does the LogEvent class cover both types?
	08:14 mstruk: jsanda: yes, it makes things simpler … common structure, common access logic …
	08:15 jsanda: makes sense
	08:15 jsanda: thanks for the explanation, helpful
	08:15 mstruk: jsanda: an it makes sense when you want to list events by time … you want them all rther than combining to sources in one timeline
	08:16 mstruk: to -> two
	08:17 jsanda: what about the userId field?
	08:18 mstruk: jsanda: no problem, if you have more questions just let me know
	08:19 jsanda: for queries, would you want to filter by application?
	08:20 jsanda: specifically, i'm wondering how data should be segmented
	08:20 lholmquist has joined ([email protected])
	08:20 lholmquist has left IRC (Changing host)
	08:20 lholmquist has joined (~lholmquis@redhat/jboss/lholmquist)
	08:21 jsanda: is it the case that a user of one application should not see data of another application, or can there be multiple applications for a user
	08:22 mstruk: jsanda: typical use case for me is to filter by application yes … as each application has its own analytics page that shows stats for that specific application
	08:23 tcrawley is now known as tcrawley-away
	08:25 mstruk: jsanda: I can image that we might have a full container view that might show analytics for all the applications … in that case there would be no per app filtering applied
	08:26 jsanda: that makes sense
	08:28 jsanda: and there will be multiple events per uri, right?
	08:37 mstruk: jsanda: right, you can GET an uri multiple times, and an uri can be updated multiple times resulting in notification events for the same uri
	08:40 jsanda: i'm wondering if we might be able to store userId as a tag
	08:40 jsanda: currently we have the concepts of tags and meta data
	08:40 jsanda: i'm in the processing of combining them since they really are the same
	08:40 nscavell has joined ([email protected])
	08:40 nscavell has left IRC (Changing host)
	08:40 nscavell has joined (~nscavell@redhat/jboss/nscavell)
	08:41 jsanda: and just calling them tags which are key/value pairs where the value is optional
	08:41 jsanda: so if an event includes the userId, a "userId" tag could be set
	08:42 jsanda: and then you could search/filter on that userId to find events by that user
	08:42 mstruk: jsanda: I added in there a notion of tags in LogEvent, I knew you were working on tags … I guess userId could be a tag yes
	08:43 jsanda: i'm just thinking out loud
	08:43 jbossbot has joined (~JBossBot@redhat/jbossbot)
	08:43 jsanda: don't hesitate to let me know if it sounds like a bad/scary idea :)
	08:46 mstruk: jsanda: :) as far as userId goes it is used for determining unique users, so for that query it needs to have access to userId on EventLog … so if it becomes a tag it would have to be loaded for that query
	08:47 mstruk: jsanda: other than that the only other use I see might be inspecting a specific user activity … not really something that plays a role in analytics views …
	08:47 mstruk: jsanda: ATM that's not an issue anyway as the only impl is in-memory
	08:48 jsanda: hmmm
	08:48 jsanda: interesting
	08:48 jsanda: i've not actually seen liveoak in action. by any chance are there any demos?
	08:49 mstruk: jsanda: we have some videos … they're not the latest though
	08:50 jsanda: if you think it would be informative, i'd be happy to watch them. i will also download liveoak and play around some
	08:50 kenfinnigan has joined (~ken@redhat/jboss/kenfinnigan)
	08:50 ChanServ has changed mode: +o kenfinnigan
	08:51 mstruk: jsanda: http://liveoak.io/docs/#getting-started
	08:51 jbossbot: Title: LiveOak - The Open Source Mobile Services Platform
	08:51 jsanda: mstruk: perfect. let me do that and then follow back up on the data model.
	08:52 mstruk: jsanda: there used to be links to videos there … can't see them now … hmm
	08:53 kenfinnigan: mstruk, jsanda: http://liveoak.io/docs/#gs-screencasts