• 0
mama

How to suppress the log?

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

 

 

 

 

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

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

Share this post


Link to post
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?

 

Share this post


Link to post
Share on other sites
  • 0
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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.