Scoping

Chas wanted to review the scope of the diagnostics project starting from a wide-angle view, and came up with five bullet points detailing what he believed to be broad goals of the project: these included supporting deployment efforts in the configuration and testing phases, reducing the amount of time needed to identify and analyze problems, and assisting apps developers in creating useful and accessible logs.

An opening comment was that detailing this scope in terms of the year out in which it were to be delivered would constrain the list further and give more actionable goals. Scott later made the observation that it's difficult to build a general forensic tool because many forensics are specific to individual software. He could envision queries for specific events, but wouldn't call that forensics.

The project of developing a common event record may be more significant than it immediately seems, given that formatting, vocabulary, and other aspects must accommodate many different applications and models. For example, Scott noted that if there are components that are utilized by multiple applications, those applications should have a unified way of referring to that component. Similarly, an event vocabulary would be extremely useful both for analytical tools and for tracking individual transactions. He thought that, in aggregate, the common event record alone would be "a big chunk for a first year."

Once this record is established, aspects such as development of front-end tools and parsers for the data become relatively straight-forward. This could be done in parallel with development of the federated aspects of these diagnostic tools, with the orthogonal question of what information would actually be distributed still to be addressed. Even a simple reporting application built on top of this common event log would be hugely useful, allowing users to view a campus status report to see which services were up.

Scott also wanted standard event record tags that could be used to label every record of a specific type. He would eventually like to push diagnostic contexts onto the stack as code is processed, so that if an event is triggered and logged, this information is attached to the event itself. Data dictionaries and glossaries could then be built around these services to make this information even more accessible.

Action Item, Chas will try to "take a cut on the scope" and send it out to the group in more detail.

Architecture Models

Scott and Chas were both in agreement that there should be relatively little user involvement assumed in the architecture. Everyone felt the idea of users taking a meaningful role in reporting and debugging problems was completely hopeless in this community, while acknowledging there may be other communities of users for which it would be more feasible.

Chas had envisioned as a first step a simple platform installed on a system as a basic diagnostic module that delivers a certain level of functionality for searching or filtering records. From there, collection modules would be compiled and ported or placed on any machine to return information back to the diagnostic model, which could itself be replicated as well. This would entail coming up with application-specific collection agents which would need to be written and a primer on adding them to an existing deployment written.

Scott preferred a much more homogeneous approach; to him, the diagnostic host is doing almost exactly what the collection modules do. A processing module whose job is to log and archive events is just another type of collection module, except that the data may come from different sources and already be somewhat parsed. Given that this information will be passed between hosts, this collection process is performed on multiple hosts. This leads to a very uniform model: the same set of components would be present on every platform, but they will be modified to speak whatever type of log in and log out necessary for that particular environment.

Regardless of the choice between these styles, security will need to be enforced at many places, especially in an inter-realm context. More complex queries which would require more intelligent modules and data were mentioned, but were agreed as being well beyond the scope of year one.

Action Items

Chas will try to "take a cut on the scope" and send it out to the group in more detail.