Jump to content
XPEnology Community
  • 0

How to suppress the log?


mama

Question

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

 

 

 

 

Link to comment
Share on other sites

4 answers to this question

Recommended Posts

  • 0

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); };
 

 

  • Thanks 1
Link to comment
Share on other sites

  • 0

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 by flyride
Link to comment
Share on other sites

  • 0
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?

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...