<html><body><p><font size="2">Hi,</font><br><br><font size="2">that message is still in memory. </font><br><font size="2">&quot;mmhealth node eventlog --clear&quot; deletes all old events but those which are currently active are not affected.</font><br><br><font size="2">I think this is related to multiple Collector Nodes, will dig deeper into that code to find out if some issue lurks there.</font><br><font size="2">As a stop-gap measure one could execute &quot;mmsysmoncontrol restart&quot; on the affected node(s) as this stops the monitoring process and doing so clears the event in memory.</font><br><br><font size="2">The data used for the event comes from mmlspool (should be close or identical to mmdf)</font><br><br><font size="2" face="Arial">Mit freundlichen Gren / Kind regards</font><p><b><font face="Arial">Norbert Schuld</font></b><p><br><br><br><img width="16" height="16" src="cid:1__=8FBB0847DFBB31ED8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for valdis.kletnieks---20/07/2018 00:15:33---So I'm trying to tidy up things like 'mmhealth' etc.  Got mo"><font size="2" color="#424282">valdis.kletnieks---20/07/2018 00:15:33---So I'm trying to tidy up things like 'mmhealth' etc.  Got most of it fixed, but stuck on one thing..</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">valdis.kletnieks@vt.edu</font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">gpfsug-discuss@spectrumscale.org</font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">20/07/2018 00:15</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">[gpfsug-discuss] mmhealth - where is the info hiding?</font><br><font size="2" color="#5F5F5F">Sent by:        </font><font size="2">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">So I'm trying to tidy up things like 'mmhealth' etc. &nbsp;Got most of it fixed, but stuck on<br>one thing..<br><br>Note: I already did a 'mmhealth node eventlog --clear -N all' yesterday, which<br>cleaned out a bunch of other long-past events that were &quot;stuck&quot; as failed /<br>degraded even though they were corrected days/weeks ago - keep this in mind as<br>you read on....<br><br># mmhealth cluster show<br><br>Component &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Total &nbsp; &nbsp; &nbsp; &nbsp; Failed &nbsp; &nbsp; &nbsp; Degraded &nbsp; &nbsp; &nbsp; &nbsp;Healthy &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Other<br>-------------------------------------------------------------------------------------<br>NODE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>GPFS &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>NETWORK &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>FILESYSTEM &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>DISK &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;102 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;102 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>CES &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 4 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;4 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>GUI &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>PERFMON &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br>THRESHOLD &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0<br><br>Great. &nbsp;One hit for 'degraded' filesystem.<br><br># mmhealth node show --unhealthy -N all<br>(skipping all the nodes that show healthy)<br><br>Node name: &nbsp; &nbsp; &nbsp;arnsd3-vtc.nis.internal<br>Node status: &nbsp; &nbsp;HEALTHY<br>Status Change: &nbsp;21 hours ago<br><br>Component &nbsp; &nbsp; &nbsp;Status &nbsp; &nbsp; &nbsp; &nbsp;Status Change &nbsp; &nbsp; Reasons<br>-----------------------------------------------------------------------------------<br>FILESYSTEM &nbsp; &nbsp; FAILED &nbsp; &nbsp; &nbsp; &nbsp;24 days ago &nbsp; &nbsp; &nbsp; pool-data_high_error(archive/system)<br>(...)<br>Node name: &nbsp; &nbsp; &nbsp;arproto2-isb.nis.internal<br>Node status: &nbsp; &nbsp;HEALTHY<br>Status Change: &nbsp;21 hours ago<br><br>Component &nbsp; &nbsp; &nbsp;Status &nbsp; &nbsp; &nbsp; &nbsp;Status Change &nbsp; &nbsp; Reasons<br>----------------------------------------------------------------------------------<br>FILESYSTEM &nbsp; &nbsp; DEGRADED &nbsp; &nbsp; &nbsp;6 days ago &nbsp; &nbsp; &nbsp; &nbsp;pool-data_high_warn(archive/system)<br><br>mmdf tells me:<br>nsd_isb_01 &nbsp; &nbsp; &nbsp; &nbsp;13103005696 &nbsp; &nbsp; &nbsp; &nbsp;1 No &nbsp; &nbsp; &nbsp; Yes &nbsp; &nbsp; &nbsp;1747905536 ( 13%) &nbsp; &nbsp; 111667200 ( 1%)<br>nsd_isb_02 &nbsp; &nbsp; &nbsp; &nbsp;13103005696 &nbsp; &nbsp; &nbsp; &nbsp;1 No &nbsp; &nbsp; &nbsp; Yes &nbsp; &nbsp; &nbsp;1748245504 ( 13%) &nbsp; &nbsp; 111724384 ( 1%)<br>(94 more LUNs all within 0.2% of these for usage - data is striped out pretty well)<br><br>There's also 6 SSD LUNs for metadata:<br>nsd_isb_flash_01 &nbsp; &nbsp;2956984320 &nbsp; &nbsp; &nbsp; &nbsp;1 Yes &nbsp; &nbsp; &nbsp;No &nbsp; &nbsp; &nbsp; 2116091904 ( 72%) &nbsp; &nbsp; &nbsp;26996992 ( 1%)<br>(again, evenly striped)<br><br>So who is remembering that status, and how to clear it?<br>[attachment &quot;attccdgx.dat&quot; deleted by Norbert Schuld/Germany/IBM] _______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2"><br></font></tt><br><BR>
</body></html>