How to suppress the log?

[mama]

my system: ESXi 6.7 i5-6500 cpu / 1.03b(DS3615xs) / DSM6.2.3-25426 /

 

# tail -f / var / log / messages

 

The problem that occurs is "cache_monitor" code.

log:

2020-07-11T18:00:16+09:00 min synostoraged: SYSTEM:     Last message 'cache_monitor.c:1557' repeated 6 times, suppressed by syslog-ng on min
2020-07-11T18:00:16+09:00 min synostoraged: cache_monitor.c:1557 Can't support DS with cpu number (1)

This log repeats endlessly.

 

The way I tried was to add syntax.

 

Added to this syntax for convenience.

↓ ↓ ↓

 

# ESXiSmart.conf
# edit the [bracket values] with drive slots where SMART should be suppressed
# in this example /dev/sda through /dev/sdl are suppressed
# add cache_monitor.c:1557 Can't support DS with cpu number (1) drop

filter fs_disks { match("/sd[a-l]" value("MESSAGE")); };

filter fs_badsec { match("/exc_bad_sec_ct$" value("MESSAGE")); };
filter fs_errcnt { match("disk_monitor\.c:.*Failed\ to\ check" value("MESSAGE")); };
filter fs_tmpget { match("disk/disk_temperature_get\.c:" value("MESSAGE")); };
filter fs_health { match("disk/disk_current_health_get\.c:" value("MESSAGE")); };
filter fs_sdread { match("SmartDataRead.*read\ value\ /dev/.*fail$" value("MESSAGE")); };
filter fs_stests { match("SmartSelfTestExecutionStatusGet.*read\ value\ /dev/.*fail$" value("MESSAGE")); };
filter fs_tstget { match("smartctl/smartctl_test_status_get\.c:" value("MESSAGE")); };

filter fs_cachemonitor { match("cache_monitor\.c:" value("MESSAGE")); };
filter fs_cachemonitor2 { match("cache_monitor.*(1)$" value("MESSAGE")); };

filter fs_allmsgs { filter(fs_badsec) or filter(fs_errcnt) or filter(fs_tmpget) or filter(fs_health) or filter(fs_sdread) or filter(fs_stests) or filter(fs_tstget) or filter(fs_cachemonitor) or filter(fs_cachemonitor2); };
filter f_smart { filter(fs_disks) and filter(fs_allmsgs); };

log { source(src); filter(f_smart); };
 

But it doesn't work.
How can we suppress these logs?

 

>Referenced posts

 

 

 

 

[flyride]

Actually now that I'm looking at it, you are trying to filter non-disk messages.  All the other filters presume and require that there is a /dev/sdx reference in the log entry.

 

You'll need to modify the file in this way:

filter fs_cachemonitor { match("cache_monitor\.c:.*Can't support DS with cpu number" value("MESSAGE")); };
filter fs_allmsgs { filter(fs_badsec) or filter(fs_errcnt) or filter(fs_tmpget) or filter(fs_health) or filter(fs_sdread) or filter(fs_stests) or filter(fs_tstget); };
filter fs_smart { filter(fs_disks) and filter(fs_allmsgs); };
filter f_smart { filter(fs_smart) or filter(fs_cachemonitor); };

log { source(src); filter(f_smart); };
 

 

[flyride]

A couple of comments, most of which probably don't apply to your situation.

1. Use care not to suppress messages that are actually informative. Logs are there for a reason, so know what you are suppressing and why
    
2. If the log entry is visible in dmesg, then it's a kernel event and the stated strategy won't work without some minor modification
    
3. Your example only needs one filter (the 'repeat' message is derived from the source line).  I'd choose this filter over what you have so that it survives a version upgrade, as long as the text is not changed by Synology

   cache_monitor\.c:.*Can't support DS with cpu number

   Also, you can test your regular expression in this way:

   $ echo "2020-07-11T18:00:16+09:00 min synostoraged: cache_monitor.c:1557 Can't support DS with cpu number (1)" | grep -e "cache_monitor\.c:.*Can't support DS with cpu number"
   2020-07-11T18:00:16+09:00 min synostoraged: cache_monitor.c:1557 Can't support DS with cpu number (1)

    

4. Did you remember to add the exclusion file in not2msg?
    

5. Did you restart syslog-ng?

Edited July 12, 2020 by flyride

[mama]

13 minutes ago, flyride said:

Actually now that I'm looking at it, you are trying to filter non-disk messages.  All the other filters presume and require that there is a /dev/sdx reference in the log entry.

 

You'll need to modify the file in this way:

filter fs_cachemonitor { match("cache_monitor\.c:.*Can't support DS with cpu number" value("MESSAGE")); };
filter fs_allmsgs { filter(fs_badsec) or filter(fs_errcnt) or filter(fs_tmpget) or filter(fs_health) or filter(fs_sdread) or filter(fs_stests) or filter(fs_tstget); };
filter fs_smart { filter(fs_disks) and filter(fs_allmsgs); };
filter f_smart { filter(fs_smart) or filter(fs_cachemonitor); };

log { source(src); filter(f_smart); };
 

That's amazing. It's really cool. This issue has been resolved. 

But like you said, why is this happening?

so is this a common problem?

 

[polanskiman]

The question(s) in this topic have been answered and/or the topic author has resolved their issue. This topic is now closed. If you have other questions, please open a new topic.