# Presentation: 261107

## Discovery and Monitoring Event Descriptions Working GroupSession 1

- Dan Gunter
- Brian Tierney

- Experiences with the “Top N” Event Names

## Agenda for meeting

- Discuss “experiences”, proposed changes to event names
- URL: http://www-didc.lbl.gov/damed/
- Future directions for DAMED-WG
**Note: Combined NM/CGS/DAMED session 2-3:30pm Sheraton Ohio**

## Review: Top ‘N’ Events

- _[Top10 Events strawman version 1.htm](file:///Top10%20Events%20strawman%20version%201.htm)_

## Context: How we are using the DAMED Event Names

- Distributed monitoring infrastructure
- Storing the information in a MySQL archive
- Using NetLogger (name=value pairs) to transport events from the probes to the archive
- Each event is self-contained
- Comparing tools that measure the same *characteristic* of the network

## Usage Example

*iperf* and *netest *both measure “throughput”
- we run each tool periodically on a full mesh of half a dozen hosts
- each probe produces event(s) containing:
- timestamp
- the DAMED event name
- program name, e.g., “iperf” or “netest”
- source, destination host
- measurement value

## Opinions, biases, goals

- unique event names are necessary
- “single-valued” events are convenient
*but* more than just a name and value are needed for real interoperability
- but for our (LBNL) purposes, restricting this to be easily represented with name/value pairs (i.e. NetLogger) is adequate

## Issues

- “network”,”host”,etc. prefix
- Program / event name boundary
- Additional event-specific parameters
- Standard target, e.g. (source,dest)
- Representing data aggregation
- Network names and NM-WG
*on the next page are the events we are using..*

## Slide 8

## Issue: stripped off ‘prefix’

- bandwidth.achievable.tcp.singleStream
*not* network.bandwidth.achievable.tcp.singleStream
- reasons:
- redundant
- name was already quite long
- prefix alone not useful; never needed just “some” network measurement

## Issue: program/event name boundary 

- We did _not_ include the program name in the event name ~ delay.roundtrip.ping
- NetLogger already provides program name field
- Advantage: easy to compare two different programs measuring the same thing
- Disadvantage: distinguishing between programs is implementation-dependent
- Subtlety: what about the program / program-parameter boundary?

## Issue: additional event parameters

- some events:
- DATE=20020926202204.179808 NL.EVNT=**bandwidth.achievable.TCP.singleStream** HOST=140.173.170.41 PROG=web100_iperf_c **REPORT=Interval** PID=30661 DST=140.173.155.14 FD=1 DUR=1.037321 VAL=19.206152 BYTES=2490368
- all events:
- Aggregation:
- agg_ival and agg_type for mean, max, etc.
- but haven’t used this much yet

## Issue: standard target

- To search the archive, we needed a standard way to represent targets
- SRC and DST hosts required for all measurements (even CPU load)
- Is this enough?
- HOP_NUM needed for hop-by-hop measurements, but this is currently “just another attribute” for us

## Issue: data aggregation

- If we have a measurement series, need to distinguish between:
- one measurement in the series
- the summary of the series computed by the tool
- different types of tool summaries (max/min/avg)
- Also need to provide (rough) sampling rate
- Proposed solution:
- AGG_IVAL,AGG_TYPE
- REPORT_RUN, REPORT_INTERVAL

## Issue: NM-WG names

- We tried to synchronize with NM-WG names, since they are essentially defining the hierarchy
- (see spreadsheet)
- This wasn’t hard
- But no reason that work should go on in both groups..

## NM-WG Characteristics

## What next?

- Top ‘N’ document is finished?
- a mapping to XML/SQL/NetLogger exists