tree b8254ca8d5a2fbfad5e5f6a38643d8f26611bc8e
parent 78673fdd0a1983fe5a49c49164adcf49374be719
author Jing Jin <jingjin@google.com> 1460417627 -0700
committer Jing Jin <jingjin@google.com> 1460491776 +0000

vmon,internal/monitoring: move some common functions from vmon to internal/monitoring.

I also removed "oncall collect" related files. See reasons below.

In this CL I only moved stuff from vmon/servicecommon.go to
internal/monitoring/monitoring.go and updated all the references.
I didn't change any code logic.

This is the first step of making the oncall-dashboard better.

Now, there are two components to make the oncall-dashboard work.
1. "oncall collect" command talks to GCM, collects all data needed in
   dashboard (all the metrics from all our services), and write the result to
   a (large) file in json in storage bucket. This runs every minute.
2. "oncall serve" serves the data file above and static resources
   to the frontend UI.

I don't remember exactly why I chose this approach, but it has many
flaws:
- The data shown in the dashboard is not in "real time". It depends on
  how often the "oncall collect" command runs. It basically just shows the data
  from the last "oncall collect" run.
- The data shown in the dashboard is kind of "static". For example,
  people cannot change data duration because the duration is hard-coded
  in the "oncall collect" code (1h by default).
- It is pretty wasteful. For example, the instance-level data is only needed
  when people are looking at the instance-level view.
- Hard to maintain. Too many moving parts.

I plan to remove the "oncall collect" part, and move data retrieval functions
to the "oncall serve" command so it becomes a single backend server for
the dashboard. It serves static resources, and gets requests from the frontend
UI and talks to GCM.

Change-Id: I1ca294fbfbcd7c25b192660e1a3f075a8b80d380