Project

General

Profile

Actions

Bug #39646

closed

ceph-mgr log is flooded with pgmap info every two seconds

Added by Ricardo Dias almost 5 years ago. Updated almost 2 years ago.

Status:
Won't Fix
Priority:
High
Assignee:
-
Category:
ceph-mgr
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

The ceph-mgr daemon with debug-mgr=0 logs pgmap information every two second:

Example:

2019-05-08 17:15:54.443 7fc43d8b5700  0 log_channel(cluster) log [DBG] : pgmap v188: 480 pgs: 480 active+clean; 4.7 KiB data, 71 MiB used, 216 GiB / 228 GiB avail; 5.0 KiB/s rd, 4 op/s
2019-05-08 17:15:56.443 7fc43d8b5700  0 log_channel(cluster) log [DBG] : pgmap v189: 480 pgs: 480 active+clean; 4.7 KiB data, 71 MiB used, 216 GiB / 228 GiB avail; 3.3 KiB/s rd, 3 op/s
2019-05-08 17:15:58.443 7fc43d8b5700  0 log_channel(cluster) log [DBG] : pgmap v190: 480 pgs: 480 active+clean; 4.7 KiB data, 71 MiB used, 216 GiB / 228 GiB avail; 5.0 KiB/s rd, 4 op/s
2019-05-08 17:16:00.443 7fc43d8b5700  0 log_channel(cluster) log [DBG] : pgmap v191: 480 pgs: 480 active+clean; 4.7 KiB data, 71 MiB used, 216 GiB / 228 GiB avail; 3.3 KiB/s rd, 3 op/s
2019-05-08 17:16:02.443 7fc43d8b5700  0 log_channel(cluster) log [DBG] : pgmap v192: 480 pgs: 480 active+clean; 4.7 KiB data, 71 MiB used, 216 GiB / 228 GiB avail; 3.3 KiB/s rd, 3 op/s
2019-05-08 17:16:04.447 7fc43d8b5700  0 log_channel(cluster) log [DBG] : pgmap v193: 480 pgs: 480 active+clean; 4.7 KiB data, 71 MiB used, 216 GiB / 228 GiB avail; 5.0 KiB/s rd, 4 op/s

Do we really need to show this info in the log?

Actions #1

Updated by Lenz Grimmer almost 5 years ago

Is this related to #37886 by any chance?

Actions #2

Updated by Sebastian Wagner almost 5 years ago

I'd be :+1: for remove this, Iff creating a new pgmap every two seconds is not a bug.

Actions #3

Updated by Vikhyat Umrao almost 5 years ago

Hi - This is not a bug this was changed because of some reason during troubleshooting/RCA we need previous historic IOPS data. If you want to stop these messages just simply change the log level to `info`.

ceph tell mon.* injectargs '--mon_cluster_log_file_level info'
Actions #4

Updated by Sebastian Wagner almost 5 years ago

Vikhyat Umrao wrote:

Hi - This is not a bug this was changed because of some reason during troubleshooting/RCA we need previous historic IOPS data. If you want to stop these messages just simply change the log level to `info`.

[...]

Interesting, thanks for the backgroud. To me, this raises the question, if there are better places to store history IOPS data, like prometheus and if the MGR log file is really the best place for this. Especially as this pgmap output is spamming the mgr log file in vstart clusters.

Actions #5

Updated by Vikhyat Umrao almost 5 years ago

Sebastian Wagner wrote:

Vikhyat Umrao wrote:

Hi - This is not a bug this was changed because of some reason during troubleshooting/RCA we need previous historic IOPS data. If you want to stop these messages just simply change the log level to `info`.

[...]

Interesting, thanks for the backgroud. To me, this raises the question, if there are better places to store history IOPS data, like prometheus and if the MGR log file is really the best place for this. Especially as this pgmap output is spamming the mgr log file in vstart clusters.

I think you can fix vstart issue by adding mon_cluster_log_file_level = info in vstart.sh [global] section.

Actions #6

Updated by Joao Eduardo Luis almost 5 years ago

  • Status changed from New to Fix Under Review
  • Assignee set to Joao Eduardo Luis
  • Pull request ID set to 28917
Actions #7

Updated by Vikhyat Umrao over 4 years ago

  • Pull request ID changed from 28917 to 29357
Actions #8

Updated by Joao Eduardo Luis over 3 years ago

  • Priority changed from Normal to High
Actions #9

Updated by Sebastian Wagner about 2 years ago

  • Status changed from Fix Under Review to New
  • Assignee deleted (Joao Eduardo Luis)
  • Pull request ID deleted (29357)
Actions #10

Updated by Radoslaw Zarzynski almost 2 years ago

  • Status changed from New to Won't Fix

Closing as for over 3 years there is no consensus but feel to reopen anytime.

Actions

Also available in: Atom PDF