[syslog-ng]Filtering Large Syslog Messages

[Brian E. Seppanen]

Hi Folks:

I have snmptrapd running so that any trap that it receives should be 
logged to local1.   I have  a filter taking anything received via local1 
to a specific file

filter snmptrap {facility(local1);};
destination snmptraps { file("/var/log/snmptraps";};

Unfortunately a number of traps are getting cut off at a specific 
point, and the remainder of the trap ends up in syslog and not in the 
proper destination.

I'm running syslog-ng 1.4.17, libol 0.2.24, redhat linux 7.2

Jan 29 12:34:43 hostname
ts.cerent454Mib.cerent454Objects.cerent454AlarmGroup.cerent454AlarmTable.cer
ent454AlarmEntry.cerent454AlarmSlotNumber.1.normalCondition = 0, 
enterprises.cerent.cerentProducts.c
erent454Mib.cerent454Objects.cerent454AlarmGroup.cerent454AlarmTable.cerent454AlarmEntry.cerent454Al
armPortNumber.1.normalCondition = 0, 
enterprises.cerent.cerentProducts.cerent454Mib.cerent454Objects
.cerent454AlarmGroup.cerent454AlarmTable.cerent454AlarmEntry.cerent454AlarmLineNumber.1.normalCondit
ion = 0

Here's the beginning of the trap that found its way to the proper file

Jan 29 12:34:43 hostname snmptrapd[11851]: 192.168.0.1 [192.168.0.1]: Trap system.sysUpTime.0 = Timeticks: (2968512686) 343 days, 13:52:06.86, 
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap.snmpTrapOID.0 
= OID: 
enterprises.cerent.cerentProducts.cerent454Mib.cerent454Events.cerent454V2Events.normalCondition, 
enterprises.cerent.cerentProducts.cerent454Mib.cerentCommonObjects.cerentCommonObjectsGroup.cerentNodeTime.0 
= 20030129123442D, 
enterprises.cerent.cerentProducts.cerent454Mib.cerent454Objects.cerent454AlarmGroup.cerent454AlarmTable.cerent454AlarmEntry.cerent454AlarmState.1.normalCondition 
= administrative(20), 
enterprises.cerent.cerentProducts.cerent454Mib.cerent454Objects.cerent454AlarmGroup.cerent454AlarmTable.cerent454AlarmEntry.cerent454AlarmObjectType.1.normalCondition 
= ne(10), 
enterprises.cerent.cerentProducts.cerent454Mib.cerent454Objects.cerent454AlarmGroup.cerent454AlarmTable.cerent454AlarmEntry.cerent454AlarmObjectIndex.1.normalCondition 
= 0, enterprises.cerent.cerentProduc

All of the message would be coming in via local1 so it's not that a 
pattern match is failing..    

Any ideas?



Brian Seppanen
seppy@chartermi.net
906-228-4226 ext 23