[metrics-team] Pad discussion about notifications and package names today at 14:30 UTC

[Karsten Loesing]

On 2017-11-08 11:23, Karsten Loesing wrote:
> Quick reminder: we scheduled another pad discussion for today at 14:30 UTC

Hi team,

iwakeh, irl, and I had a very useful discussion today that irl wrote a
fantastic summary for which I'm pasting below. Thanks so much for that!

All the best,
Karsten



Service Notifications

Previous discussions can be found at:
https://lists.torproject.org/pipermail/metrics-team/2017-November/000510.html

We discussed notification methods for getting the attention of service
operators. E-mail seems to be the primary preferred method but secondary
notifications by IRC (assisted by metrics-bot) may increase the speed of
responses.

We discussed two approaches to monitoring our services, white box (with
access to logs produced locally on the hosts running services) and black
box (testing only publicly available endpoints). We decided that a
combined approach should be explored.

For general system monitoring, for example disk, CPU and memory usage,
the sysadmin team is likely monitoring for all hosts anyway, but we
should work out what acceptable thresholds are for hosts running metrics
services and communicate those to make sure the existing monitoring is
doing what we want it to do.

This gives three categories of new monitoring checks:

 1. New Nagios scripts for querying remote resources, similar to the
Onionoo check (black box).
 2. New Nagios scripts for parsing logs for warnings and errors (white box).
 3. Use more existing Nagios notifications (from the sysadmin team),
possibly with tweaked configuration, to check system things.

Our next steps for implementing these service checks and notifications
will be:

 - To summarize the notifications wanted for each category
 - To find out from the Nagios admins, what they prefer, allow and don't
want



A Unified Java Package Naming Scheme

Previous discussion, and ongoing discussion, can be found at:
https://trac.torproject.org/projects/tor/ticket/24036

We discussed moving interfaces between metrics team applications into
metrics-lib to avoid these needing to be implemented twice.

We discussed moving onionoo.docs, which provides classes for Onionoo
documents. Currently metrics-bot has a reimplementation of these
documents and also an Onionoo client and so moving onionoo.docs would
already be useful to reduce code duplication within metrics team
applications. OONI are using Swagger with their Measurement API, and
this is something that we may look at in the future, but this will need
its own ticket.

We discussed creating a util package in metrics-lib for collecting
generally useful classes and functions, including fingerprint
calculations and commonly used regular expressions. The
descriptor.internal package will not be moved, as it does not provide
utility package but does provide a more detailed interface into
descriptors than is available through the public API.

The collector.index package is actually the scheduled task that creates
the index.json file for collector, so we won't move that to metrics-lib
but will rename it to collector.indexer to make its purpose clearer.

Though we may move interfaces to metrics-lib to allow them to be used by
metrics applications, we will distinguish between packages intended for
internal use only and packages we advertise to users and that we promise
not to change in backward-incompatible ways without prior notice and
only when doing major version bumps. Private packages will not have
JavaDoc on the Tor Metrics website.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20171108/b0d324e4/attachment.sig>