CN107608829A - 一种验证服务器是否存在硬件丢失的方法 - Google Patents
一种验证服务器是否存在硬件丢失的方法 Download PDFInfo
- Publication number
- CN107608829A CN107608829A CN201710882718.1A CN201710882718A CN107608829A CN 107608829 A CN107608829 A CN 107608829A CN 201710882718 A CN201710882718 A CN 201710882718A CN 107608829 A CN107608829 A CN 107608829A
- Authority
- CN
- China
- Prior art keywords
- hardware
- test
- log
- lost
- restarted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
本发明公开了一种验证服务器是否存在硬件丢失的方法,所述方法通过对某个硬件进行测试、重启和分析,根据该次测试的重启次数和硬件日志信息中该测试硬件的记录次数进行对比,检测重启过程中是否存在该测试硬件是否有丢失的情况。本发明充分利用了office办公软件Excel表格工具对日志信息进行快速的分析,在不另外产生成本的前提下,避免了大量对比的时间以及遗漏的概率,提高了测试验证分析的效率和提高了分析的质量,极大的提高了产品质量,减少了后续的客诉数量。
Description
技术领域
本发明涉及PCB 系统板卡设计技术领域,具体涉及一种验证服务器是否存在硬件丢失的方法。
背景技术
我们在进行服务器Reboot重启测试时,工程师往往只能查看系统日志及BMC log;这里可能会出现的问题:其中某次启动和上一次关机间隔时间过长而无法发现;CPU、内存或HDD在某次启动后出现丢失、信息显示错误或者系统没有抓取到的情况;BMC log里面出现大量信息(一些正常信息及报警信息),需要工程师一一去排查浪费时间以及不知道出现的问题的时间及出现这个错误LOG的次数。
现有技术的技术方案:
/etc/rc.local 是使用者自订开机启动程序,把需要开机自动运行的程序写在这个脚本里。控制重启reboot的程序编辑在这个Linux开机启动的程序里面,这样每次Linux开机进系统后自动将调用reboot程序,进行重启测试。
Linux系统下系统重启操作的日志信息,都是/var/log/messages目录下下保存着,查看方法如下:cat /var/log/messages |more,可以从messages几千上万条信息中去查看每次重启产生的日志信息。
/etc/rc.local 下编辑要测试的CPU、内存、硬盘等硬件信息的log,让其每次开机都记录本次开机的这些硬件信息,方法如下:
1.echo ---------------------- >> /root/cpu.log
创建CPU的log文件
2.dmidecode -t 4 >> /root/cpu.log
将本次启动的CPU信息写进CPU log文件中,下次启动的信息将会保存,且不会覆盖。
3.echo ------------------------->> /root/memory.log
创建memory的log文件
4.dmidecode -t 17 >> /root/memory.log
将本次启动的内存信息写进内存 log文件中,下次启动的信息将会保存,且不会覆盖。
5.echo ------------------------- >> /root/HDD.log
创建硬盘#0的log文件
6.fdisk -l >> /root/HDD.log
将本次启动的硬盘分区信息写进硬盘#0 的log文件中,下次启动的信息将会保存,且不会覆盖。
7.echo ---------------------- >> /root/HDD1.log
创建硬盘#1的log文件
8.lsscsi >> /root/HDD1.log
将本次启动的硬盘信息写进硬盘#1的log文件中,下次启动的信息将会保存,且不会覆盖。
9.service ipmi start
Linux下启动ipmitool功能
10.echo ------------------------------- >> /root/BMCSEL.log
创建SEL 的log文件
11.ipmitool sel elist >> /root/BMCSEL.log
将本次启动的BMC SEL信息写进sel的log文件中,下次启动的SEL信息将会保存,且不会覆盖。
12.ipmitool sel clear
清除本机的BMC 的LOG信息
1.2.1.4、当服务器本次reboot48小时或1000次后,可以打开其中对应的LOG来分析。
现有技术一的缺点如下:
从messages几千上万条信息中去查看每次重启产生的日志信息,显然只能发现其中关键的Fail、Error等报错或警告的信息,无法得到CPU、内存或HDD等服务器关键硬件是否丢失的信息,或者某2次启动时间过长等问题无法从这种日志中分析得出。
单个的CPU、内存、硬盘信息日志,数据也相当大;需要每条每条信息去比对,需要数十个小时以上的对比,这将花费较长的时间,效率低下;并且比对数据容易遗漏,降低了测试的质量。
发明内容
本发明要解决的技术问题是:针对上述问题,由于reboot测试较为常用,且客户常会重启到服务器,所以本发明提供一种验证服务器是否存在硬件丢失的方法。
本发明所采用的技术方案为:
一种验证服务器是否存在硬件丢失的方法,所述方法通过对某个硬件进行测试、重启和分析,根据该次测试的重启次数和硬件日志信息中该测试硬件的记录次数进行对比,检测重启过程中是否存在该测试硬件是否有丢失的情况。
所述方法通过将控制重启的程序编辑到Linux开机启动程序/etc/rc.local中,实现测试过程中的重启。
所述方法通过在所述开机启动程序/etc/rc.local中,编辑需要测试的CPU、内存、硬盘等待测硬件信息的日志,使测试过程中每次重启开机都记录本次开机的这些硬件信息。
所述测试过程中的重启开机的日志信息,保存于/var/log/messages目录下,通过cat /var/log/messages |more命令,从messages几千上万条信息中去查看每次重启产生的日志信息。
所述方法实现步骤包括:
测试完成后,统计本次测试重启的次数;
对测试产生的硬件测试日志信息进行分析,得到日志信息中所测试硬件的统计次数;
对比本次测试重启的次数和所测试硬件的统计次数;
如果本次测试重启的次数和所测试硬件的统计次数一致,得出结论:所测试硬件每次重启中都被发现;
如果本次测试重启的次数和所测试硬件的统计次数不一致,单独将日志信息导出分析。
所述方法通过数据统计工具对硬件测试日志信息进行分析。
所述数据统计工具为Excel软件。
Microsoft Excel是微软公司的办公软件Microsoft office的组件之一,是由Microsoft为Windows和Apple Macintosh操作系统的电脑而编写和运行的一款试算表软件。Excel 是微软办公套装软件的一个重要的组成部分,它可以进行各种数据的处理、统计分析和辅助决策操作。其中的筛选功能,可以将所有的数据信息进行统计:相同的归类、并且这个相同的信息有多少条。
如果Excel软件统计的被测试硬件次数和本次测试重启的次数不一致,表明此硬件在本次测试中出现丢失,并计算出丢失的次数和概率。
所述方法通过Excel软件表查看重启时硬件丢失的时间。
本发明的有益效果为:
本发明充分利用了office办公软件Excel表格工具对日志信息进行快速的分析,在不另外产生成本的前提下,避免了大量对比的时间以及遗漏的概率,提高了测试验证分析的效率和提高了分析的质量,极大的提高了产品质量,减少了后续的客诉数量。
具体实施方式
根据具体实施方式对本发明进一步说明:
一、在/etc/rc.local开机启动的程序里面编辑控制重启的程序;
二、将需要测试的CPU、内存、硬盘等硬件信息的log编辑到开机启动的程序log/etc/rc.local中,让其每次开机都记录本次开机的这些硬件信息,方法如下:
1.echo ---------------------- >> /root/cpu.log
创建CPU的log文件
2.dmidecode -t 4 >> /root/cpu.log
将本次启动的CPU信息写进CPU log文件中,下次启动的信息将会保存,且不会覆盖。
3.echo ------------------------->> /root/memory.log
创建memory的log文件
4.dmidecode -t 17 >> /root/memory.log
将本次启动的内存信息写进内存 log文件中,下次启动的信息将会保存,且不会覆盖。
5.echo ------------------------- >> /root/HDD.log
创建硬盘#0的log文件
6.fdisk -l >> /root/HDD.log
将本次启动的硬盘分区信息写进硬盘#0 的log文件中,下次启动的信息将会保存,且不会覆盖。
7.echo ---------------------- >> /root/HDD1.log
创建硬盘#1的log文件
8.lsscsi >> /root/HDD1.log
将本次启动的硬盘信息写进硬盘#1的log文件中,下次启动的信息将会保存,且不会覆盖。
9.service ipmi start
Linux下启动ipmitool功能
10.echo ------------------------------- >> /root/BMCSEL.log
创建SEL 的log文件
11.ipmitool sel elist >> /root/BMCSEL.log
将本次启动的BMC SEL信息写进sel的log文件中,下次启动的SEL信息将会保存,且不会覆盖。
12.ipmitool sel clear
清除本机的BMC 的LOG信息
三、当reboot重启测试完成后,使用命令:cat count统计本次测试重启的次数例如,运行测试302cyc次重启;
四、将本次reboot测试产生的硬件测试日志信息通过Excel办公软件分析;
1、将CPU log日志信息导入Excel办公软件,点击要筛选的行 “dmidecode 2.11”;由于d midecode -t 4 >> /root/cpu.log命令每次调用都会先记录 dmidecode的版本,统计记录 “dmidecode 2.11”的次数,可以得到CPU重启的次数302次,与重启的总数302一致;
2、点击要筛选的CPU行“Socket Designation: CPU0”(本次验证在4路服务器上测试,所以有4个CPU), “CPU0”的次数302次,与重启的总数302一致;同理,筛选CPU1、CPU2、CPU3来分析,结果均为302次,和上面重启次数一致,可以得出结论:4个CPU在302次重启中,每次都被发现;
3、将内存memory日志信息导入Excel办公软件,点击要筛选的行 “Speed:1600MHz”或者“Size: 16384 MB”(本次验证在4路服务器上安装了8条16G的内存),得到内存频率或者条数的总次数为2416(8条内存*302次=2416);和上面重启次数一致,可以得出结论:8条内存在302次重启中,每次都被发现;
4、将硬盘信息日志HDD信息导入Excel办公软件,点击要筛选的行 “Disk /dev/sda:598GB” (本次验证只安装了一个RAID硬盘,如果多个硬盘则分别勾中sdb、sdc等),得到硬盘记录的总次数为302次;和上面重启次数一致,可以得出结论:硬盘在302次重启中,每次都被发现;
5、当筛选的结果和重启测试结果次数不同时,再单独将日志信息导出分析。如内存数量不一致,则内存出现丢失,再单独分析内存的日志,不用将每个日志都打开分析。
实施方式仅用于说明本发明,而并非对本发明的限制,有关技术领域的普通技术人员,在不脱离本发明的精神和范围的情况下,还可以做出各种变化和变型,因此所有等同的技术方案也属于本发明的范畴,本发明的专利保护范围应由权利要求限定。
Claims (9)
1.一种验证服务器是否存在硬件丢失的方法,其特征在于,所述方法通过对某个硬件进行测试、重启和分析,根据该次测试的重启次数和硬件日志信息中该测试硬件的记录次数进行对比,检测重启过程中是否存在该测试硬件是否有丢失的情况。
2.根据权利要求1所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述方法通过将控制重启的程序编辑到开机启动程序/etc/rc.local中,实现测试过程中的重启。
3.根据权利要求2所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述方法通过在所述开机启动程序/etc/rc.local中,编辑待测试硬件信息的日志,使测试过程中每次重启开机都记录本次开机的待测试硬件信息。
4.根据权利要求3所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述测试过程中的重启开机的日志信息,保存于/var/log/messages目录下,通过cat /var/log/messages |more命令查看每次重启产生的日志信息。
5.根据权利要求4所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述方法实现步骤包括:
测试完成后,统计本次测试重启的次数;
对测试产生的硬件测试日志信息进行分析,得到日志信息中所测试硬件的统计次数;
对比本次测试重启的次数和所测试硬件的统计次数;
如果本次测试重启的次数和所测试硬件的统计次数一致,得出结论:所测试硬件每次重启中都被发现;
如果本次测试重启的次数和所测试硬件的统计次数不一致,单独将日志信息导出分析。
6.根据权利要求1-5任一所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述方法通过数据统计工具对硬件测试日志信息进行分析。
7.根据权利要求6所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述数据统计工具为Excel软件。
8.根据权利要求7所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,如果Excel软件统计的被测试硬件次数和本次测试重启的次数不一致,表明此硬件在本次测试中出现丢失。
9.根据权利要求8所述的一种验证服务器是否存在硬件丢失的方法,其特征在于,所述方法通过Excel软件表查看重启时硬件丢失的时间。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710882718.1A CN107608829A (zh) | 2017-09-26 | 2017-09-26 | 一种验证服务器是否存在硬件丢失的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710882718.1A CN107608829A (zh) | 2017-09-26 | 2017-09-26 | 一种验证服务器是否存在硬件丢失的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107608829A true CN107608829A (zh) | 2018-01-19 |
Family
ID=61058585
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710882718.1A Pending CN107608829A (zh) | 2017-09-26 | 2017-09-26 | 一种验证服务器是否存在硬件丢失的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107608829A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111679943A (zh) * | 2020-06-10 | 2020-09-18 | 浪潮商用机器有限公司 | 一种服务器测试系统 |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1484147A (zh) * | 2002-09-20 | 2004-03-24 | 联想(北京)有限公司 | 实现自动开关机测试的系统及方法 |
CN101334754A (zh) * | 2008-08-05 | 2008-12-31 | 浙江大学 | 基于故障注入的嵌入式系统测评方法 |
CN102375767A (zh) * | 2010-08-17 | 2012-03-14 | 鸿富锦精密工业(深圳)有限公司 | 计算机重启测试系统及方法 |
US20120271982A1 (en) * | 2011-04-25 | 2012-10-25 | Microsoft Corporation | Intelligent flash reprogramming |
CN103744764A (zh) * | 2013-12-26 | 2014-04-23 | 浪潮电子信息产业股份有限公司 | 一种基于Crontab的整机内存稳定性的测试方法 |
EP2749848A1 (en) * | 2012-12-27 | 2014-07-02 | General Electric Company | Firmware upgrade error detection and automatic rollback |
CN104536875A (zh) * | 2015-01-16 | 2015-04-22 | 浪潮电子信息产业股份有限公司 | 一种基于ipmi的对服务器进行自动化重启测试的方法 |
CN105302726A (zh) * | 2015-11-13 | 2016-02-03 | 浪潮电子信息产业股份有限公司 | 一种测试的方法及装置 |
CN105700997A (zh) * | 2016-01-05 | 2016-06-22 | 浪潮电子信息产业股份有限公司 | 一种dos下测试重启服务器并且记录重启次数的方法 |
CN106598796A (zh) * | 2016-12-16 | 2017-04-26 | 郑州云海信息技术有限公司 | 一种测试reboot时硬件信息稳定性的方法 |
-
2017
- 2017-09-26 CN CN201710882718.1A patent/CN107608829A/zh active Pending
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1484147A (zh) * | 2002-09-20 | 2004-03-24 | 联想(北京)有限公司 | 实现自动开关机测试的系统及方法 |
CN101334754A (zh) * | 2008-08-05 | 2008-12-31 | 浙江大学 | 基于故障注入的嵌入式系统测评方法 |
CN102375767A (zh) * | 2010-08-17 | 2012-03-14 | 鸿富锦精密工业(深圳)有限公司 | 计算机重启测试系统及方法 |
US20120271982A1 (en) * | 2011-04-25 | 2012-10-25 | Microsoft Corporation | Intelligent flash reprogramming |
EP2749848A1 (en) * | 2012-12-27 | 2014-07-02 | General Electric Company | Firmware upgrade error detection and automatic rollback |
CN103744764A (zh) * | 2013-12-26 | 2014-04-23 | 浪潮电子信息产业股份有限公司 | 一种基于Crontab的整机内存稳定性的测试方法 |
CN104536875A (zh) * | 2015-01-16 | 2015-04-22 | 浪潮电子信息产业股份有限公司 | 一种基于ipmi的对服务器进行自动化重启测试的方法 |
CN105302726A (zh) * | 2015-11-13 | 2016-02-03 | 浪潮电子信息产业股份有限公司 | 一种测试的方法及装置 |
CN105700997A (zh) * | 2016-01-05 | 2016-06-22 | 浪潮电子信息产业股份有限公司 | 一种dos下测试重启服务器并且记录重启次数的方法 |
CN106598796A (zh) * | 2016-12-16 | 2017-04-26 | 郑州云海信息技术有限公司 | 一种测试reboot时硬件信息稳定性的方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111679943A (zh) * | 2020-06-10 | 2020-09-18 | 浪潮商用机器有限公司 | 一种服务器测试系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7124328B2 (en) | Capturing system error messages | |
US6532552B1 (en) | Method and system for performing problem determination procedures in hierarchically organized computer systems | |
Vishwanath et al. | Characterizing cloud computing hardware reliability | |
US20180357146A1 (en) | Completing functional testing | |
Miranskyy et al. | Operational-log analysis for big data systems: Challenges and solutions | |
US7475387B2 (en) | Problem determination using system run-time behavior analysis | |
US9170873B2 (en) | Diagnosing distributed applications using application logs and request processing paths | |
US8661125B2 (en) | System comprising probe runner, monitor, and responder with associated databases for multi-level monitoring of a cloud service | |
Syer et al. | Leveraging performance counters and execution logs to diagnose memory-related performance issues | |
US8381036B2 (en) | Systems and methods for restoring machine state history related to detected faults in package update process | |
US9594670B2 (en) | Managing software dependencies during software testing and debugging | |
US7930600B2 (en) | Logical to physical connectivity verification in a predefined networking environment | |
US20030237035A1 (en) | Analyzing system error messages | |
US6550019B1 (en) | Method and apparatus for problem identification during initial program load in a multiprocessor system | |
US20120254662A1 (en) | Automated test system and automated test method | |
Doyle et al. | An empirical study of the evolution of PHP web application security | |
US10657028B2 (en) | Method for replicating production behaviours in a development environment | |
Nguyen et al. | Automated verification of load tests using control charts | |
CN110851352A (zh) | 一种模糊测试系统及终端设备 | |
CN108572895B (zh) | 一种Linux下自动检查软硬件配置的稳定性测试方法 | |
Syer et al. | Identifying performance deviations in thread pools | |
CN111858201A (zh) | 一种bmc综合测试方法、系统、终端及存储介质 | |
CN109067605B (zh) | 一种存储子系统故障诊断方法、装置、终端及存储介质 | |
CN107608829A (zh) | 一种验证服务器是否存在硬件丢失的方法 | |
Ding et al. | Automatic Software Fault Diagnosis by Exploiting Application Signatures. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180119 |