The Metrics project is an Incubator project that provides tools for measuring the use of software in a distributed manner. These measurements are valuable because they substantiate the case for continued sponsorship of work on open source software and because they provide data on usage patterns that can be used to help prioritize work on Globus software.
This dev.globus area contains information for project committers and contributors. Please use the email@example.com list (see below) to obtain user information about the Metrics project's products.
A website designed for users of Metrics products is available at http://incubator.globus.org/metrics/.
About the Metrics Project
The Metrics project serves other Globus projects by providing a set of tools for measuring the use of their products. These products are all available from the user website at http://incubator.globus.org/metrics/.
- We provide a usage-reporting code module (implemented in both C and Java) that is used by a number of Globus software products (including several in GT4) to report usage data to one or more listener services. The data to be transmitted and the recipient(s) of the data are configurable by the calling software.
- Our listener service receives usage reports from running code and stores the reports in a database for later summarization and analysis. The code is also available so that others may deploy their own listener services.
- We have developed a set of data summarization tools that produce summary reports from the usage data for GT4 components.
What Can You Do With The Metrics Code?
- If you are a software developer, you can use the usage-reporting code module (available in C and Java) to instrument your code. You decide what information ought to be reported, and then when someone uses your code, usage reports will be automatically generated and delivered via the network to a configured listener service. You can deploy your own listener service and receive reports on the use of your code. Or, you can include the listener service in your distributions and tell users how to monitor their own usage. You or your users can use the report generators to create aggregate reports on usage over time.
- If you are a system deployer, you can deploy your own listener service and configure your Globus software to sent it usage reports. You can then use the report generators to create aggregate reports on usage over time, which you can use to understand how your users are using the Globus software on your systems.
A Few Exemplary Users
- The NSF CDIGS project (Community Driven Improvement of Globus Software) operates a listener service and pre-configures Globus software to send usage reports to it. The project monitors usage and uses the data to understand how Globus software is used (to help plan/prioritize improvements) and to justify continued funding support for Globus software development. The project provides a mailing lists (firstname.lastname@example.org) to which anyone can subscribe to receive daily summaries of the usage reports received by the CDIGS project's listener service each day.
- The TeraGrid project operates a listener service and configures its Globus deployments to send usage reports to its service in addition to the CDIGS service. It then uses its own report generators to provide a web interface for generating usage charts and graphs, which are used to understand how Globus software is being used on TeraGrid in order to plan/prioritize support, documentation, and add-on development work.
- The Globus GridFTP development team has instrumented its GridFTP server code to send usage reports, and using the CDIGS project's listener service and usage database, they use the data to understand which features of GridFTP are being used, what kinds of failures are being encountered, and what the typical usage patterns (scenarios) GridFTP servers are involved in.
- How do I get the latest source code?
You can get the latest source of the Metrics project through anonymous CVS:
cvs -d:pserver:email@example.com:/home/globdev/CVS/globus-packages login cvs -d:pserver:firstname.lastname@example.org:/home/globdev/CVS/globus-packages checkout usage
- Where can I browse the source code?
You can browse the source code with ViewCVS.
- How do I file a new bug or see existing bugs?
- How do I build the Metrics project source code?
Please see the Building code page for more information.
- How do I add a new packet handler to the usage receiver?
Please see the Adding a new packet handler page for more information.
- How do I write a new usage statistics report?
Please see the Adding a new usage statistics report page for more information.
- How do I configure and start the usage receiver daemon?
To configure the usage receiver daemon edit the $GLOBUS_LOCATION/etc/globus_usage_receiver/receiver.properties file. Make sure the database-driver and database-url properties are configured properly. To start the usage receiver daemon execute $GLOBUS_LOCATION/bin/globus-usage-receiver.
- What is globus-usage-babysitter program used for?
You can use $GLOBUS_LOCATION/bin/globus-usage-babysitter to connect to the usage receiver daemon and obtain or reset its statistics. The following actions are supported by the usage receiver daemon:
- check - return receiver statistics
- clear - return and reset receiver statistics
- stop - shuts down the receiver
$ globus-usage-babysitter check
- How are packet components versions assigned?
Send mail to email@example.com. The current list is available on dev.globus.org.
The status of Metrics is: newly accepted Incubator Project, as defined by the Incubator Process Guidelines found at http://dev.globus.org/wiki/Incubator/Incubator_Process .
|Developer discussion (metrics-dev)||archive/subscribe/unsubscribe|
|User discussion (metrics-user)||archive/subscribe/unsubscribe|
|Commit notifications (metrics-commit)||archive/subscribe/unsubscribe|
Lee Liming (chair)
The Metrics project gratefully acknowledges the following contributions.
The following projects have modified their own code to send usage reports using the Metrics code, and have contributed packet handlers, database schema, and report generators to the Metrics project:
- C WS Core
- Java WS Core
- OGSA DAI
Joe Bester has contributed significantly to the test suites for the listener service and has integrated many of the packet handlers listed above into the listener service framework.
In addition to the Globus Alliance Project Guidelines, the Metrics project adheres to the following policies:
Data Use Policies
The Metrics incubator project is limited to developing software and making the software available. This work does not include using the Metrics code to collect data on users, so we don't have any special policies on data use.
However, most of the committers on this incubator project are also members of the NSF CDIGS project, which does use the Metrics code to collect data on use of Globus software. The CDIGS project observes the terms and conditions of the Globus community's privacy statements. In particular, the use of the data collected as described in the Globus Software Privacy Statement.
Users of the Metrics code are responsible for their own data collection activities. If you use the code, we recommend that you establish and publicize policies or informational statements about your own collection, management, and use of usage data.
Guidelines for committers
- Describe specific rules for your project here
Guidelines for individual contributors
If you use the Metrics code to instrument your software to send usage reports, it would be helpful if you also contribute a packet handler to the Metrics project so that we can add that handler to the listener service. This will allow anyone who has a listener service (including you!) to corectly process any usage report packets that they receive from your code.
If you use the Metrics code to instrument your software to send usage reports, it would be helpful if you also contribute one or more report generators so that data collected from your software can be analyzed. The Metrics project has two frameworks for report generators: one for writing report generators to reduce code redundancy, and one to execute report generators automatically on a monthly basis.
All packet handler contributions should come with a test module for the JUnit test suite that verifies that the packet handler is working properly. This is essential to maintaining the stability of the listener service.