the following description of the preferred embodiment ( s ) is merely exemplary in nature and is in no way intended to limit the invention , its application , or uses . referring to fig1 an exemplary network is illustrated at 15 . it includes a plurality of storage devices , such as devices 10 . these devices can be storage area network ( san ) systems or direct attached storage devices . users or customers , such as customers 20 and 22 access these devices over network 15 . the system includes a management system 60 which maintains a data store 40 associated with each device 10 . as will be more fully explained below , the data store contains information about various attributes relating to the storage devices and relating to the storage resources defined by those devices . a storage collector 50 communicates over the network 15 with the management system 60 . the storage collector creates and stores usage information until needed by a billing application 80 . the storage collector 50 serves as the primary interface between the billing application 80 and the management system 60 . [ 0020 ] fig2 shows an exemplary billing application in which customers 20 and 22 access different logical units within storage devices 10 a and 10 b . the logical units , depicted generally by referenced numeral 20 , have different service levels ( costs ) associated with them . each customer is billed based on a calculation whereby the service level and size of the logical unit are taken into account . while the storage devices 10 a and 10 b can be of any configuration , they have been illustrated here as storage area network systems , each having a plurality of controller modules 16 and 18 . when attributes of a storage resource changes , the data store 40 ( fig1 ) issues an event message through the management system 60 . the management system thus serves as a mediation engine that monitors usage of all devices and outputs information indicative of such use in a common format . in general , the management system can provide data for a variety of different applications , aside from the billing application illustrated here . the storage collector 50 subscribes to certain usage events and then processes those events as they occur , in order to generate the necessary billing information in real time . because an event can issue at any time , the storage collector 50 is designed to respond in asynchronous fashion . the event serves as a trigger which the storage collector then processes to gather the necessary information needed for the billing function . [ 0024 ] fig3 shows how the presently preferred system operates . when a user accesses a logical unit on a storage device , causing that device to change state with respect to one or more of its attributes , the management system 60 detects this and issues change event messages . the storage collector 50 listens to these event messages and filters them so that only those pertinent to the billing function are acted upon . upon receipt of pertinent messages , the storage collector accesses the data store 40 to determine whether there are any related data objects that are important to the billing function . the storage collector gathers these additional pieces of information , even though they may not be directly involved in the change event . this is done to ensure that the snapshots taken by the storage collector of the state of the storage system has all pertinent information needed to perform the billing function . it is important that the storage collector access the database and ascertain the state of associated objects quickly upon having received the initial change event message . this is necessary because the system is designed with multi - user access in mind . other users may access associated objects and change them without notice . thus the system is designed to quickly and efficiently acquire the state of associated objects before third parties have the opportunity to change them . the presently preferred storage collector collects usage events and outputs them to a data store or file system accessible to the billing application . it is preferably designed to match a particular source and is thus configured with knowledge of a set of relevant attributes for that source . the attributes upon which the billing application will charge a customer must be determined and denoted through external configuration file . in this manner , the storage collector 50 will be able to identify events affecting those attributes as pertinent to the billing or metering system . a time stamp should always be included in a usage event to indicate when a pertinent event took place . the storage collector 50 runs in an endless loop , creating a new usage record each time a pertinent event is seen . each usage event is then stored to an external data store or output file for use by the billing system . the billing application will typically specify that billing is based on ownership of a storage resource . illustrated in fig1 the storage collector 50 interfaces with the management system 60 to drive the creation of usage records for storage - related events . the architecture of the invention permits the management system to monitor usage on networks of all sizes . the storage collector can be used , for example , to implement a billing application 80 that tracks attributes of the logical unit on a storage device , such as logical unit 20 of storage device 10 . whenever some attribute of the logical unit is altered , an event will be generated to indicate that billing might have to be adjusted starting at the time of this change . changed attributes could range from device specific changes , such as a size change , to assignment changes such as a new owner or price . interrupted service is also an important concern for billing applications ; if a storage resource becomes inaccessible , the user of that resource should not be billed for it . however , because the management system is simply a server on a network , there are several scenarios where the management system might not be able to access the resource , but the owner of the resource can access it . the billing system needs to be able to handle this by allowing a possible credit for the time registered as down . information collected in this module is written to a permanent location on a periodic basis . typically this period will be much shorter than an actual billing cycle to ensure that no data gets lost if a system wide failure occurs and the current period &# 39 ; s information is lost . furthermore , it allows for easier clean up since each group of output records can be deleted without affecting any other records after the information is used by the billing application . upon first startup of the storage collector 50 , information pertaining to each storage resource currently residing in the database is stored to a permanent output location ( file or database ) immediately . this allows for a starting point from which changes to each storage resource can be recorded . if the storage collector starts up several times during a billing cycle , extraneous and duplicate information will be saved but it should serve to sync up possibly out of date data rather than allowing out of date or overlapping information . in the preferred implementation , the storage collector 50 runs continuously . a mechanism is provided for writing and retrieving recovery information . this is used to make sure that the storage collector &# 39 ; s information is in a good state to continue collecting events since the last shutdown . finally , a flushing mechanism is provided by the storage collector 50 to flush the contents of its currently collected event information to a permanent output location . this is used periodically and causes the event information up to this point to be placed in a form retrievable by the billing system . in the presently preferred embodiment , the storage collector 50 , illustrated in fig1 is the primary interface between the billing or metering application and the management system 60 . it is responsible for accessing the data store 20 when required and for receiving events generated by any changes in the objects being managed through the data store . [ 0036 ] fig4 is a data flow diagram indicating the data flow across the storage collector 50 . the storage collector 50 is initially set up by reading information necessary to initialize itself during the configuration process . this would include the attributes upon which the billing system is based to help determine which events are pertinent . it sets up some kind of event listener which initiates the acceptance of change events . when an event is seen , pertinence to the billing system is determined . once pertinence is established , an extraction function will pull out the appropriate information needed for the billing system . upon returning , the event &# 39 ; s complete and appropriate informationis written to a temporary output location , either a file or a temporary data store , until such time as the storage collector &# 39 ; s flushing mechanism is invoked . further processing may be done on the event prior to the storing of the event information , but that is not covered in this invention . a special startup mode is recommended . if the storage collector 50 is first being entered , it will initially read the state of each storage resource currently known in the database and store an event representing each one . this will allow a starting state from which event - driven changes can be recorded . a recovery mechanism implemented by the storage collector 50 should only be called upon startup and will clean up any temporary information from prior to the shutdown by initiating the flushing mechanism . this will ensure a valid starting state for further event information . the only other kind of error recovery that could be addressed in here is missing events . however , this invention puts certain conditions on the system that will avoid events being lost ; any implementation should ensure that precautions are taken to eliminate the missing of events . this is most important during a period in which the management system was down and storage resource configurations changed . when the management system starts back up again , those changes should be caught and the changed information should be seen as events . once the system is started , events should occur reliably and there should exist no case in which a database object is added , changed or deleted where the listener isn &# 39 ; t notified . the description of the invention is merely exemplary in nature and , thus , variations that do not depart from the gist of the invention are intended to be within the scope of the invention . such variations are not to be regarded as a departure from the spirit and scope of the invention .