Before you can deploy the timeserver, you need to be able to track its performance. There are many parameters you may wish to monitor, but for the purposes of the exercise you will monitor:
login:
number of login requests (timeserver only)
time-user:
number of
/time
requests with logged-in user (timeserver only)
time-anon
number of
time
requests with anonymous user (timeserver only)
set-cookie:
numer of times
/set
is called (authserver only)
get-cookie
numer of times
/get
is called (authserver only)
no-cookie
number of times get returns negative results (authserver only)
200s:
number of 200s (timeserver and authserver)
400s:
number of 400s (authserver only)
404s:
number of 404s (timeserver and authserver)
Modify timeserver and authserver to use your counters module from Assignment 5.
/monitor URI
When the
/monitor
request
is sent to one of the servers,
the server should respond with a JSON-encoded dictionary of the
variables and their values.
Use the
json
package from the standard library.
Create a server program called
monitor
that will periodically call /monitor on the
timeserver(s) and authserver.
Use a command-line flag
--targets
as a comma-separated list of URLs to monitor.
You will probably want to use the
Split
from the
strings
package to turn the comma-separated list into a slice.
The flag
--sample-interval-sec
should specify the interval
(in seconds) between sample requests.
Each request to the
/monitor
target gets a dictionary of counter values.
Collect the values into a sequence
map[string] []Sample
where the key is the counter and
Sample
is a pair (time, value) representing the sample.
Normally, the collected statistics would be used to generate console
pages and/or alerts. Counters are converted into rates by taking
the difference between values in the series and dividing by the
interval (e.g. the requests counter becomes requests-per-second).
To keep this assignment manageable, run the monitor for
--runtime-sec
seconds then halt and print the json-encoded collected statistics to
standard output.
This is not a hand-in requirement, but
to test out the system, you will need to run everything to date:
authserver,
timeserver,
loadgen,
and
monitor.