Hi Joe,

thanks for your reply.

I read something about faulty filter settings in another thread and I checked the filters once again.

The only filter I enabled is a filter for all syslog messages from one device which has a problem we can't fix at the moment.

Please have a look on the screenshots.

Is there a possibility to see which syslog messages are forwarded, invalid, filtered, dropped and received?

There is a gap between the received and forwarded, invalid, filtered and dropped.

I thought that forwarded + invalid + filtered + dropped =  received.

The strange thing is, that I see the SYS-5-CONFIG_I message in the device center view of my test device, but the config fetch will not be started.

Thanks!

Sven

This has all the visible symptoms of CSCtc18888.  However, the logs aren't jiving.  Can you post new SyslogCollector.log, AnalyzerDebug.log, and syslog.log over the same time period showing one specific CONFIG_I message?

Hello,

I will check this.

I created an email allert for SYS-5-CONFIG_I messages and sometimes last night I got this emails.

Is it possible that syslog messages from wireless controllers make this trouble to LMS?

Thanks!

Yes.  The bug states that if an unexecpted message arrives in the buffer at the same time as a message to be processed, the automated action engine will skip both messages.  A patch is available from TAC to correct this behavior.

Thanks a lot, Joe!

I opened a case to get the patch.

One more question to the Collector Status.

Is it possible to get informations about which devices are responsible for the "Invalid messages"?

This would be very useful to figure out which devices are wrong configured or something like that.

Chances are these messages are not coming from devices, but from Daemon Manager.  On Windows, the syslog.log is shared by device messages and dmgtd messages.  The latter are all considered invalid by SyslogCollector.  But, if you do get invalid device messages, you'd have to comb through the SyslogCollector.log to find the device generating them.

Hello,

I got the patch, but the situation is the same.

I attached the the syslogCollector.log starting with the restart of the process syslog Collector.

Before I disabled all syslog filters and set the filter type to "keep".

Debug level is DEBUG.

I saw that the collector in collector status was not working. I did unsubscribe and a subscribe once again. Now I see new messages.

Thanks!

Hello,

I did the test and all I can find in the AnalyzerDebug.log is the following message:

[ Tue Jun 15  08:40:23 CEST 2010 ],INFO ,[Thread-18],newsyslogqueue Dropping the syslog as queue is full 100000

I found another thread here in the community with that message, but now solution for it.

Thanks!

After I restarted the processes the syslog queue is empty and the config fetch works :-)

Output from syslog.log:

Jun 15 09:37:51 4.72.80.13 3131: Jun 15 09:36:59.881: %SYS-5-CONFIG_I: Configured from console by shru1307 on vty0 (4.26.16.20)

Output from AnalyzerDebug.log:

[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,74,Invoking Config collection for syslog message
[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,81,Before triggering syslog config fetch
[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,83,Syslog Timestamp Tue Jun 15 09:37:51 CEST 2010
[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,85,DCMA Endtime String 2010-06-10 00:51:02.94
[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,90,DCMA Endtime String after formatting Thu Jun 10 00:51:02 CEST 2010
[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,98,Buffer Time after adding 5 minutes Thu Jun 10 00:56:02 CEST 2010
[ Tue Jun 15  09:37:52 CEST 2010 ],INFO ,[Thread-2],com.cisco.nm.rmeng.dcma.client.RmeSaDcmaActionHandler,act,101,Triggering fetch on syslog since Timestamp > bufferTime

My last question is now, what can I do that the syslog queue will not getting full one more time?

Is logrot a solution? My syslog.log will be rotated at 128 MB.

Thanks a lot!

Sven