JP2000322364A - Device state monitoring device and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent the concentration of inquiry from clients to a device when trap is generated. SOLUTION: In this device state monitoring device, when an error is generated, the agent of a device 30n communicates trap to the manager of each client 10m. Then, the agent receives inquiry from the manager, and in the case of the first client, the agent preserves the address of the first client, and successively communicates the detail information to the first client. In the case of the non-first client, the agent communicates the address of the first client. The manger of the client which receives the address of the first client obtains the state information of the device from the first client.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a device state monitoring technique using a trap.

[0002]

2. Description of the Related Art In a device state monitoring system using a trap, when a state change such as an error occurs in a device, the device (agent) notifies each client (manager) of the trap. Each client that receives this trap can monitor the status of the device by inquiring the device about the detailed status. By the way, if the number of clients monitoring the device increases, after the device notifies the trap, inquiries from the client concentrate and load on the device side. It may be.

FIG. 5 shows a conventional SNMP (Simple).
Network Management Proto
2 shows a monitoring mode of the device status monitoring system using the client 11 and 12 connected to a network (LAN), and individually monitors the status of the device 13. That is, when the clients 11 and 12 receive the trap from the device 13, GET, GET
The device status information is acquired by the NEXT command.

FIG. 6 specifically shows information exchange conventionally performed between a client and a device when an error occurs (for example, when a jam occurs) in the network environment of FIG. First, when a jam occurs, the device 13 refers to the trap table and sends a trap notification to the corresponding client, for example, the clients 11 and 12 (,). Next, the manager of the client 11 sequentially requests the paper feed tray state, the discharge tray state, the discharge tray state, and the job state using the GET command (,,). In response to this, the agent of the device 13 sequentially notifies the paper feed tray state, the discharge tray state, the discharge tray state, and the job state (,,). The client 11 specifies the one with the highest priority and displays the state of the place on the screen. Next, the same processing is performed between the client 12 and the device 13 (-).

[0005] In such a configuration, as described above, the load is concentrated on the device 13 and causes a timeout error and the like. The present invention is intended to cope with such a situation.

The prior art related to the present invention is disclosed in Japanese Patent Application Laid-Open No. 7-334445 and Japanese Patent Application Laid-Open
There is 51476 gazette. In Japanese Patent Laid-Open No. Hei 7-334445, a sub-manager is arranged between an SNMP manager and an SNMP agent to form a hierarchical structure. While this configuration may allow the addition of devices to be distributed, sub-managers may also be placed on small networks, reducing efficiency. Also,
In Japanese Patent Application Laid-Open No. H10-5147, devices to be monitored are shared among clients (managers), thereby avoiding concentration of loads on the devices. However, this prior art cannot perform flexible management according to the performance of each device.

[0007]

SUMMARY OF THE INVENTION The present invention has been made in consideration of the above circumstances, and has as its object to reduce the load on a device so that inquiries from clients to the device are not concentrated.

[0008]

According to the present invention, there is provided a device status monitoring apparatus for monitoring the status of a device in a network connecting a device and a client, in order to achieve the above object. A means for generating a trap; a means provided in the device for supplying status information to the predetermined client in response to a status information request from a predetermined client; a means provided for the device and provided from another client. Means for supplying information about the predetermined client in response to a request for status information; provided in the other client, for acquiring information about the status of the device from the predetermined client based on the information about the predetermined client Means are provided.

The information on a predetermined client is, for example, the address and host name of the client.

In this configuration, a predetermined client executes a procedure for acquiring a device state from a device,
Other clients, once accessing the device, obtain information of a predetermined client from the device, and thereafter obtain desired device state information from the predetermined client. Therefore, access to the device does not concentrate. Further, since information about a predetermined client is notified from the device to another client, flexible processing becomes possible.

In this configuration, the predetermined client may be a client that first supplies a status information request to the device that has issued the trap. In this case, the address and the like of the first client are stored on the device side or the like.

[0012] The predetermined client may be previously determined in the network. For example, the client with the best performance is selected.
In this case, depending on the network environment, access from other clients to the device may be omitted.

The present invention can be realized as an agent device mounted on a device, a manager device mounted on a client, and also as a method, and at least a part thereof can be realized as computer software. It is possible.

[0014]

Embodiments of the present invention will be described below.

FIG. 1 shows a network environment to which the present invention is applied. In FIG.
1, 102,..., 10 m is a network (LAN) 2
00 is connected. Also, the devices 301 and 30
, 30n are also connected to the network 200. The client 101, 102,..., 10m operates as a management station, and management managers 401, 402,. The devices 301, 302,... 30n are managed systems, and management agents 501, 502,. Each agent has a management information base (MIB), and notifies management information in response to a request from a manager.

FIG. 2 shows devices 301, 302,.
FIG. 3 shows the operation of the client 1.
, 10m side operation is shown. FIG. 4 shows an exchange between the devices 301, 302,... 30n and the clients 101, 102,.

The procedure of FIG. 2 is as follows. [Step S10]: When an error occurs, the device 30
, 30n notify traps to the managers of the clients 101, 102,..., 10m. [Step S11]: Next, the agents 501 and 50
2, 50n are managers 401, 402, ...
Receive an inquiry from 40m. [Step S12]: It is determined whether the inquiring client is the first client. If it is the first client, the process proceeds to step S13. If it is not the first client, the process proceeds to step S15. [Step S13]: The address of the first client is stored. [Step S14]: Notify the client of the detailed information. [Step S15]: If the client is not the first client, the address of the first client is notified.

The processing in the client shown in FIG. 3 is as follows. [Step S20]: When a trap notification is received from the device, the first inquiry is sent to the device. [Step S21]: Receive a notification from the device. [Step S22]: It is determined whether the received notification is a notification of an address of another client or a notification of a device state. If it is a notification of an address of another client, the process proceeds to step S23. If it is a notification of the device state, the process proceeds to step S25. [Step S23]: Request to send information about the state of the display target to the other client. [Step S24]: Information about the status received from the other client is displayed. After this, the process ends. [Step S25]: The following inquiry is made. [Step S26]: Receive notification of the inquiry from the device. [Step S27]: It is determined whether all inquiries have been completed. When all is completed, step S2
Proceed to 7. If not, the process returns to step S25. [Step S28]: When all inquiries have been completed, a place having a higher priority is specified, and its state is displayed. Save that state. After that, the process ends.

The stored information is notified to another client in response to a request from another client.

FIG. 4 shows an example of information exchange executed by the above processing. In this figure, parts corresponding to those in FIG. 6 are denoted by corresponding reference numerals. As is clear from FIG. 4, the client 10 making the second or subsequent inquiry
1, 102,..., 10 m is the device 30 only once.
, 30n are inquired (x1). And devices 301, 302,.
The address of the client (101 in the figure) that first made the inquiry is received from n (x2). These clients are hereinafter referred to as devices 301, 302,.
The first inquiry is made, not to the 30n, the other client that stores the display information is inquired (x3), and the display information is received (x3).
4). The inquiry is performed in a small number of steps, unlike the conventional SNMP procedure, and is efficient. In this example, a problem such as a timeout error does not occur without inquiries being concentrated on the device.

It is also conceivable that the client that first makes an inquiry and obtains detailed information cannot respond to an inquiry request from another client due to power off or the like. In this case, the other clients make an inquiry to the device again. The device may return detailed information when an inquiry is made again (from a plurality of clients), or may return an address (the address of a client newly identified as the first inquiring client). You may do so. Further, the client may explicitly notify that detailed information is to be returned instead of the address. Further, in the device, after a certain period of time has elapsed after the trap is generated, the address of the first client that is stored may be discarded, and the address of the client that has made the first inquiry after that may be stored again.

In the above-described embodiment, the status information is notified by the SNMP procedure to the client that first makes the inquiry, and the status information is obtained from the client that first makes the inquiry to the other clients. However, the client may supply the status information to the next client in a chain. Alternatively, device management may be assigned to a predetermined client in advance, and this client may supply status information to another client. In this case, efficient operation can be performed by assigning device management to a high-performance client or a client that is constantly operating.

[0023]

As described above, according to the present invention, it is possible to avoid concentration of inquiries from a client to a device when a trap occurs, to solve a problem such as a timeout error, and to provide another device. Performance degradation such as processing (print execution) can be prevented.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an overall network environment to which an embodiment of the present invention is applied.

FIG. 2 is a flowchart illustrating an operation of the device according to the embodiment.

FIG. 3 is a flowchart illustrating an operation on the client side in the embodiment.

FIG. 4 is a diagram for explaining data exchange between a device and a client in the embodiment.

FIG. 5 is a diagram illustrating an operation of the conventional SNMP protocol when a trap occurs.

FIG. 6 is a diagram for explaining data exchange between a device and a client when a trap of the conventional SNMP protocol occurs.

[Explanation of symbols]

 101, 102,... 10m Client 200 Network 301, 302,... 30n Device 401, 402,.

Claims (7)

[Claims] 1. A device status monitoring apparatus for monitoring the status of a device in a network connecting the device and a client, comprising: means for generating a trap provided in the device; and a predetermined client provided for the device. Means for supplying status information to the predetermined client in response to a status information request from the device; and means provided in the device for supplying information on the predetermined client in response to a status information request from another client; A device provided on the other client, for obtaining information on the status of the device from the predetermined client based on the information on the predetermined client. 2. The device state monitoring apparatus according to claim 1, wherein the predetermined client is a client that first supplies a state information request to the device that has issued the trap. 3. The device status monitoring apparatus according to claim 1, wherein the predetermined client is determined in advance in the network. 4. An agent device mounted on a device connected to a network and notifying the status of the device, means for generating a trap, and status information based on a status information request from a predetermined manager device in response to the trap. To the predetermined manager; and a means for supplying information on the predetermined manager to the other manager device based on a status information request from another manager device in response to the trap. Agent device. 5. A manager device for monitoring the status of a device connected to a network, comprising: a means for requesting status information to the agent based on a trap generated by an agent mounted on the device; A manager device comprising: means for receiving status information; and means for supplying information on the status of the device to the other manager based on a request from another manager. 6. A manager device for monitoring the status of a device connected to a network, comprising: means for making a status information request to the agent based on a trap generated by an agent mounted on the device; Means for receiving information on the manager of the device, means for requesting the other manager to supply information on the state of the device based on the received information on the other manager, and information sent from the other manager. Means for receiving information on the status of the device. 7. A device status monitoring method for monitoring the status of a device in a network connecting the device and a client, comprising the steps of: generating a trap according to the status of the device; and status information from a predetermined client. Supplying status information of the device to the predetermined client in response to a request; supplying information about the predetermined client to the other client in response to a status information request from another client; Requesting the predetermined client to supply information on the state of the device from the other client based on the information about the client of the device; and responding to the request from the predetermined client to the other client to the other client. Regarding the state Device status monitoring method characterized by having a step of supplying that information.