# Presentation: 249794

## Thoughts on a Discovery and Monitoring Schema Groupwithin GGF

- Jennifer Schopf for
- Swany, Tierney, Magowan, Smith, Gunter, Oevers, and more

## The need:

- By schema I mean
- description of the information needed to describe a piece of data, for use in a shared vocabulary
- In order for different testbeds to share info, we need to have a common schema defined
- standard could be defined
- even with out, could translate between current data implementations
- Time frame: yesterday!
- Many folks are doing this on their own -
- GCE, Perf, GIS all have been having separate conversations

## Current thought

- Focus on basic pieces of monitoring and discovery data
- Aim for 6 months
- Define the atomic parts
- Use English for now
- Aim for the 80%

## Charter

- Research existing schemas
- English for the “top n” monitoring and discovery elements
- define what we mean by target
- global names?
- note: this may not cover all future event schema needs
- Map English defs to basic tech.
- ldap, RD, xml
- Evaluate use of data models (for example relational, hierarchical, CIM, etc.)
- Evaluate use of schema languages (for example GOS/ XMLSchema/ RDF/ CIM )

## Top Ten List

- Primary
- CPU Load
- Bandwidth
- Round Trip Time
- Available memory
- Disk space

- Secondary
- Trace Route (# hops)
- Queue Length
- Server status
- Application status (pending, running, basic basic basic)
- Process Load (think top)

## Strawman: roundtripDelay

- Timestamp: time at which it was measured
- Target:
- source hostname, processor #
- dest hostname, processor #
- needs much more discussion
- Value: microsec units, integer
- Name: how the data was gathered, there is a MIB list with defined “constants” that will need to be extended
- Also needed - statistical technique?

## Strawman: availMem

- What is this: an instantaneous measurement of total available memory on a single processor
- Timestamp: when the measurement was taken
- Target: in this case, hostname, processor #
- Value: MB units, 64 bit unsigned integer
- Name: how the data was gathered, there is a MIB list with defined “constants” - vmstat, uptime, etc., will need to be extended

## What data goes in an event?

- Use RFC’s, MIB, CIM, etc heavily
- Different events refinements on this
- thought - 1 measurement per event, we’re defining atomic pieces
- Amalgamation should be next step
- Some events may want other kinds of info - for example, statistical technique used for a 1 minute average
- Open question - what’s in the name, what’s in a field

## What about units?

- Units can be handled in a variety of ways
- as part of event name
- as an extra field
- as an optional attribute
- We (currently) think fixing the units if you call the event, and then having a second event with the required field of unit is the way to go (think option attributes for RD for example)

## What about “target”

- This needs more discussion
- It may have structure
- Open issues abound

## Discovery data

- The event data won’t help us unless we have also defined the discovery data
- scenario - I want to know he load of the machines at a national lab running linux
- Given a hostname, what other data do we need?
- OS type, baseline for memory and disk capacity, etc.

## A possible plan

- MS1 - English for the “top ten”
- MS2 - What do we need to do about a data model?
- MS3 - Map English defs to basic tech.
- ldap, RD, xml
- MS4- evaluate use of sample GOS/XMLSchema

## We envision other work growing out of this

- Other areas of “words”
- security object for example
- Guidelines for portability across other schema languages
- Uber-schema language

## Comments/Suggestions

- What about the conglomerated data needed by current projects - how do you identify atomic? How can we make this easily adoptable?
- Suggestion - punt on atomic, define conglomerations as needed,

- Is bandwidth a topic of node?
- No - we’re currently avoiding the topic of structure
- This is related to the “target” black box

## What is the goal?

- Enable interoperability
- Why not do this through CIM now?
- Suggestion
- dmtf.org
- pegasus is open source CIM implementation
- Fred from Compact will give us some pointers
- What about ietf disman group?
- Could have current grids used cim?
- Maybe..

- Why did we leave off  packet loss on the top ten?
- Top ten list isn’t set - this can certainly be included
- Good suggestion-
- look at our needs and CIM definitions and go from there

## Sources of info

- Edg schemas
- globus schemas
- cim
- ietf rfcs (MIBs)
- NWS from ccgrid

## What should our name be?

- Discovery and Monitoring Schema for Interoperability Working Group
- DMSI WG
- Peter Clarke will suggest new name

## Charter

- Research existing schemas
- English for the “top n” monitoring and discovery elements
- define what we mean by target
- global names?
- note: this may not cover all future event schema needs
- Map English defs to basic tech.
- ldap, RD, xml
- Evaluate use of data models (for example relational, hierarchical, CIM, etc.)
- Evaluate use of schema languages (for example GOS/ XMLSchema/ RDF/ CIM )

- Co-chairs
- jms
- someone else - possibly james or manfred being from the EU (to be decided in drinking contest later on....)
- Mailing list
- New list - jms will set up
- Web page- tbd

- Meta comment- please make sure this will work with a resource broker
- What are the top *i* places this data might come from?
- Cim system
- Globus GIIS system - PPDG/EDG/GriPhyN/iVDGL/ATLAS/CMS/ plus more...
- plus...

- Suggestion - how have we defined what our top N are? Perhaps a requirements document
- sample a space vs picking the N most useful

## Step 1

- Table comparing
- edg, globus, ppdg - jms
- CIM - fred plus dan g.
- MIBs - bruce
- RDF - dan g.
- XML - ask dennis or mary thomas?

## Sample: 1 min load

- TimeStamp
- Target - in this case, host name and proc number, needs much more discussion
- Value - mib RFC 1514
- Name - how the data was gathered, there is a MIB list with defined “constants” - vmstat, uptime, etc., will need to be extended