1 / 16

Events Hierarchy

Events Hierarchy. Author: Anna Bekkerman abekkerm@ecs.umass.edu. Events Are Everywhere. Node. Client. LMM. Control signals. Node. Server. Data. Target system. LMM. Events. Data. Events. Node. LMM. Client. Basic Types. Messaging events

armen
Download Presentation

Events Hierarchy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Events Hierarchy Author: Anna Bekkerman abekkerm@ecs.umass.edu

  2. Events Are Everywhere Node Client LMM Control signals Node Server Data Target system LMM Events Data Events Node LMM Client

  3. Basic Types • Messaging events • Occur when data is being read from/written to communication channels used in the DCAS system • Can be matched to form messages • Application events • Generated by DCAS applications • Metrics • Measurements of resource utilization

  4. Messaging Events’ Characteristics

  5. LDM Events • Each event has a number of properties • Type: pq_insert or pq_remove • Feed type: class of a data product coming from a common source • Sequence number associated with the data product • Product size: number of bytes in data section of the product • Product ID: usually a string describing a product • For example: “Reflectivity_20070603_0112.netcdf.gz” • Two LDM events are matched if their types are different and the rest of the properties are equal • Source: pq_insert • Destination: pq_remove

  6. WDSS Events • Each event has a number of properties • Type: lb_read or lb_write • Linear buffer ID: a number associated with the linear buffer • Message length • Linear buffers contain messages describing which products/meteorological features have been processed • Message: a string describing a product/feature • Two WDSS events are matched if their types are different and messages are equal • Source: lb_write • Destination: lb_read

  7. Socket Events • Each event has a number of properties • Type: socket_write or socket_read • Sender address and port • Receiver address and port • Sequence number associated with the message • Message length • Message • For example: “control”, “features” • Two socket events are matched if their types are different and the rest of the properties are equal • Source: socket_write • Destination: socket_read

  8. Application Events • Must be explicitly generated using RAPIDS API calls • Need not be matched • Types: • Error • Variable • Algorithm • Debug

  9. Error events • Generated when an error occurs • Have three significance levels • Warning, Severe and Fatal • On the message diagram are depicted with cross ( )

  10. Variable events • Generated to report the current value of a variable • On the message diagram are depicted with five pointed star ( )

  11. Algorithm events • Have a type associated with them: start and end • Generated to report beginning/ending of some action • Algorithm, procedure, cycle etc. • On the message diagram are depicted with: • Start: small arrow pointing up ( ) • End: small arrow pointing down ( )

  12. Dedug events • Generated to report debug messages • On the message diagram are depicted with vertical bar ( )

  13. Common Properties • Each messaging and application event has the following properties: • Timestamp • PID and name of the process which generated the event • ID of the node where the event came from • Detailed information about events can be obtained: • From log files • From the message diagram if RAPIDS visualization client is employed to view the events

  14. Obtaining Process Name Events know names of the processes which generated them signatures • The name of a process might be very long! • Solution: generate a signature for the process name and send it along with the events • When RAPIDS server receives an event it compares its process signature with signatures of monitored processes provided in the configuration file • Drawback: if a process has not been mentioned in the configuration file, its events will be ignored • Even ownerless events are logged!

  15. Metrics • Each metric has a key and value • Process metrics also have a PIDs • Often a group of metrics must be used to calculate utilization of a resource • For example: to calculate utilization of the memory the following metrics are needed • The amount of free and used physical memory • The amount of free and used swap memory

  16. Implementation of Events Hierarchy event events <<interface>> Loggable byte[] toBytes() int key; Object value; int nodeID; Date occurredAt; Event String processName; int mark; DiagramEvent Metric boolean correspondTo(Event e) ApplicationEvent ProcessMetric MessagingEvent LDMEvent ErrorEvent DebugEvent TCPEvent AlgorithmEvent VariableEvent WDSSEvent

More Related