Closed Bug 972030 Opened 10 years ago Closed 10 years ago

[meta] Server needs telemetry

Categories

(Hello (Loop) :: Server, defect)

Product:
Hello (Loop)
Component:
Server
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: abr, Assigned: alexis+bugs)

References

Details

User Story

* As a product manager I can create reports on number of browser instances which have activated the Loop service (database queries)
* As a product manager I can create reports on the number of links created per unique browser instance (database queries)

These are both believed to be stretch goals for MLP; needs confirmation w/rtested.
      No description provided.
Blocks: loop_mvp
Blocks: loop_mlp
Depends on: 972992
No longer depends on: 972992
User Story: (updated)
Component: General → Server
No longer blocks: loop_mlp
Services has a tool named heka: http://heka-docs.readthedocs.org/en/latest/ and the node.js library associated with it: https://github.com/mozilla-services/heka-node
Given the number of bleeding edge technologies/uses we're already going to be using, I'm mildly concerned about picking something with a 0.4.1 version number for something as mission critical as monitoring, given that there are likely to be more mature things out there.

That said, I know effectively nothing about the _actual_ stability/reliability of the heka code.  So don't this concern overly seriously.
That's actually what we're already using for persona and new deployment of Sync.
I suggest the call is for ops to make, but I'm fairly confident that this codebase is stable.

ccing Ben who's one of the authors of this tool for feedback, and bob for ops feedback.
The heka code is quite solid, its in production for sync and Telemetry is using it. We have 2-3 staff on the project to resolve any issues as well as help other groups get up to speed.

cc'ing Rob who leads the heka project.
Thirding the sentiment. Heka is new, which will show up in the rough edges you'll find in the still rudimentary UI, but the core has proven pretty solid for us so far. We're building it to handle serious, sustainable load; any significant operational issues immediately jump to the top of our priority queue.
Romain, can you confirm we want these two metrics (and add some additional explanations there):

- "Number of browser instances which have activated the Loop service (database queries)". I'm not sure what database queries means here.

- "The number of links created per unique browser instance (database queries)". Same applies here.

Currently we cannot identify a browser instance, so the only thing we'll be able to provide is the number of links created by user session (users will have a different session per device so that may be what we want).
Flags: needinfo?(rtestard)
What I meant is that we don't need a pretty interface exposing the data. Running reports on demand is fine. This does not require a database if you don't have one - I was assuming the data is stored on a database but I may be wrong.

Can you define "user session" ? If I generate a link, close my browser and generate another link are these 2 sessions?
Flags: needinfo?(rtestard) → needinfo?(alexis+bugs)
A session is currently a cookie we set on the client to identify him later. So in your case that would be only one session.

Data will be sent to telemetry servers via heka, I don't know what they're using to store the data :)
Flags: needinfo?(alexis+bugs)
OK great, sounds good to me!
Assignee: nobody → alexis+bugs
https://github.com/mozilla-services/loop-server/commit/4e35922e2a2d8b42e055862944249f81c8ab1c6a
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
And, we are now using Heka for log aggregation.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.