Як мені отримати повідомлення про помилки ECC в Linux?

Як мені отримувати сповіщення, коли машина Linux, оснащена пам'яттю ECC, розпізнає збій пам'яті? Мене цікавлять як виправлені, так і непоправні помилки.

• якщо повідомлення написано на dmesg / syslog, це вже добре, але я хотів би знати, що шукати
• встановлення додаткових демонів (наприклад, smartmontools для жорстких дисків) є прийнятним
• Моніторинг Nagios / Icinga був би іншим способом
• не всі машини, що підлягають моніторингу, мають IPMI

Цікавими системами є плати Supermicro (X9SCM-F), що стосуються мікросервера HP N54L. У всіх системах працює Debian або Ubuntu Linux.

Linux ядро підтримує виявлення та виправлення помилок ( EDAC ) особливість деяких чіпсетів. У підтримуваній системі з ECC стан вашого контролера пам'яті доступний через sysfs:

/sys/devices/system/edac/mc

Дерево каталогів у цих місцях має відповідати вашому обладнання, наприклад:

/sys/devices/system/edac/mc/mc0/csrow2/power
/sys/devices/system/edac/mc/mc0/csrow0/power
/sys/devices/system/edac/mc/mc0/dimm2/power
/sys/devices/system/edac/mc/mc0/dimm0/power
/sys/devices/system/edac/mc/mc1/power
...

Залежно від обладнання, можливо, вам доведеться явно завантажити правильний драйвер edac, пор .:

find /lib/modules/$(uname -r) -name '*edac*'

У edac-utilsпакеті надається командний рядок і бібліотека для доступу до цих даних, наприклад:

edac-util -rfull          
mc0:csrow0:mc#0memory#0:CE:0
mc0:csrow2:mc#0memory#2:CE:0
mc0:noinfo:all:UE:0
mc0:noinfo:all:CE:0
mc1:noinfo:all:UE:0
mc1:noinfo:all:CE:0

Ви можете налаштувати якусь роботу cron, яка періодично викликає eac-utilта подає результати у вашу систему моніторингу, де потім можна налаштувати деякі сповіщення.

На додаток до цього, біг, mcelogяк правило, хороша ідея. Залежить від системи, але помилки ECC / виправлення ECC, ймовірно, також повідомляються як виняток машинної перевірки ( MCE ). Я маю на увазі, що навіть короткі періоди прискорення процесора через підвищення температури відображаються як MCE.

mcelogбуде контролювати контролер пам'яті та повідомляти про події помилок пам’яті в syslog, а в деяких конфігураціях може відключати сторінки поганої пам’яті . Це, звичайно, на додаток до його звичайного використання для моніторингу винятків машинної перевірки та безлічі інших апаратних помилок.

Більшість дистрибутивів Linux має сервіс, створений для запуску його як демон, наприклад для EL 6:

chkconfig mcelog on
service mcelog start

Це залежить від обладнання вашого сервера. Система Whitebox або Supermicro буде вирішувати це не так, як Dell, HP або IBM ...

Однією з особливостей додаткової вартості серверів високого класу є те, що існує рівень апаратної / ОС інтеграції. Приємніші сервери повідомлятимуть про те, що ви шукаєте, як частину агентів управління та / або рішення поза межами діапазону управління (ILO, DRAC, IPMI).

Ви повинні використовувати інструменти, створені на вашій апаратній платформі.

Витяг із серверів HP ProLiant під управлінням Linux та агентів HP Management:

Trap-ID=6056
ECC Memory Correctable Errors  detected.

і

Trap-ID=6052
Advanced ECC Memory  Engaged

або більш важкий

Trap-ID=6029
A correctable memory log entry indicates a memory module needs to be
replaced.

або найгірше ... Ігнорування помилки протягом 6 днів, поки сервер не вийде з-за поганої ОЗУ

0004 Repaired       22:21  12/01/2008 22:21  12/01/2008 0001
LOG: Corrected Memory Error threshold exceeded (Slot 1, Memory Module 1)

0007 Repaired       02:58  12/07/2008 02:58  12/07/2008 0001
LOG: POST Error: 201-Memory Error Single-bit error occured during 
memory initialization, 
Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.

0008 Repaired       19:31  12/08/2009 19:31  12/08/2009 0001
LOG: ASR Detected by System ROM

Вони були зареєстровані, плюс SNMP пастки та електронні листи.

Загалом, ви побачите машинні перевірки винятків у буфері кільця ядра, тому ви можете перевірити dmesgабо запустити mcelog . З мого досвіду роботи з передачею Supermicro без IPMI, це не все сприймало, і в мене все-таки помилки оперативної пам’яті прослизали через тріщини і викликали відключення. На жаль, це призвело до архаїчної політики спалювання ОЗУ перед розгортанням системи.