Highlighted
Super Contributor.. Super Contributor..
Super Contributor..
1281 views

Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

All,

   

Device Status Monitoring does work correctly on 85% to 90%
of our devices.  However, for about 10 to
15% of our devices it either fails to recognize the device is sending events or
it doesn’t update the Last Event Received and Event Count SLC fields.  Doing a “Get Status” command on the
SmartConnector, proves the device is not even being recognized by the Device
Status Monitoring feature even thought it is logging.   The other issue the Last Event Received and
Event Count SLC fields are not getting updating on devices that are logging.  I’m not sure whats causing this issue as it
appears to work fine for 85% to 90% of our other devices.  This is a basic Syslog SmartConnector running
on a new ArcMC ConApp version 7.1.1.7348.0. 
We do have a lot of different types of devices sending syslog to
it.  I have the “Enable Device Status
Monitoring” set to 3600000 millisecond.  Is that time too long for it?  However I’m not sure if it will help since
some devices are not even being recognized by it. 

   

Any help or direction you can provide is very appreciated,

Thanks,

    

Eric

Labels (2)
0 Likes
Reply
7 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

How many devices you have per connector? device status information is kept only for the first 1000.

0 Likes
Reply
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

Ofer,

I just did another get status and copied the results into Excel.  The number of the "devices" stops at 1000. So, it appears that I have more than 1000 devices sending to it.   Due to the way the device status is generated we have multiple devices for a single device, so it's driving the count over 1000.

 

Is there a way to flush out or eliminate the "devices" I don't
want? Is there more information on Device Status Monitoring that I could read
up on?

 

Thanks this has been very helpful knowledge to solving this issue,

Eric

0 Likes
Reply
Highlighted
Honored Contributor.
Honored Contributor.

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

You can try deleting the host and syslog.properties files in your user directory. This will make the connector build a new list of devices and their used parsers. I don't know how the connector keeps track of devices, but this may be worth a try to see if you can at least flush out unused devices.


Other than that you can add a second SmartConnector on a different port and let devices that allow sending to to non-default sylog port send to that Connector.

0 Likes
Reply
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

Hi Eric,

The Device Status monitoring will tell you the Following information useful for device status monitoring only.

  • Device Vendor and Product information
  • Source address and hostname gives the Device ip/host information
  • Including the last log received message.

Capture.JPG

U better run the below report to see what devices are unwanted and then apply connector filter as mentioned below:

If you want to filter out the devices. U can do that by applying device address in filter out condition. Follow the thread attachment.

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

thanks Bala

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

I am having the same issue as Eric. I have an active list that is populating based off of agent:043 events. Many devices do not have a value for last event received. We initially had the connector doing name resolution for source/dest only and I'm wondering if this increased the number of monitored devices beyond the threshold of 1,000. I've since disabled name resolution on the connectors and would like to flush the connector monitored devices to see if it helps.

Is there a document that goes into detail on how device status monitoring works on the connectors as far as time outs, etc?

0 Likes
Reply
Highlighted
Respected Contributor.
Respected Contributor.

Re: Device Status Monitoring \Connector Device Status (agent:043 events) is not completely working correctly

We have a similar issue.  We have a connector that is reporting that a device has a 'last event received' of 3/31.  That device was decommissioned and shouldn't be reporting events via syslog anymore.

I tried flushing the hosts.txt and syslog.properties files with no success.

I then tried just restarting the container that hosts the connector and it seems to have worked.  It seems that when the connector restarts it rebuilds the list of devices it is monitoring. 

However, this clears out the entire list of devices that are being monitored.  If you had 3 decom'd devices not reporting and 4 that were in an error state that you need to know about, you lose the "last event received" monitoring on all of those devices.

Is there any way to remove specific devices without losing all the monitoring?

0 Likes
Reply
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.