本发明涉及故障分析定位技术，尤其涉及一种定位故障的方法及装置。
背景技术
随着计算机通信与计算机网络技术的发展与应用，计算机网络通信已渗透到人类活动的各个领域，通过构建与业务应用相关的计算机网络系统，可以实现海量数据的共享以及协作，从而有效提高工作效率、降低成本。但如何监测计算机网络系统中各设备和链路之间的网络故障，从而能在数量庞大的计算机网络系统中准确、快速地定位发生故障的设备或链路并报警以便及时进行修复，以保障计算机网络系统的运行效率，成为摆在业务人员面前亟需解决的技术问题。
目前，当发生故障报警时，相关业务人员一般通过查看所有布置在计算机网络系统中的代码服务器上收集的各类业务应用的日志来排查故障原因，通过日志分析故障原因进行故障定位，但该定位故障的方法，由于需要业务人员通过手工方式查看所有业务应用运行的日志，使得定位故障所需的时间长，无法高效快速的确定故障原因，故障定位效率较低。
技术实现要素：
有鉴于此，本发明实施例提供一种定位故障的方法及装置，能够提升故障定位效率，以解决现有的定位故障的方法中，定位故障所需的时间长，故障定位效率较低的问题。
第一方面，本发明实施例提供一种定位故障的方法，包括：
获取发生故障报警的日志中包含的业务应用第一属性信息；
查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志；
如果查询到异常日志，提取所述异常日志包含的业务应用第二属性信息；
依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位。
结合第一方面，在第一方面的第一种实施方式中，设置所述故障定位数据库包括：
按照预先设置的日志更新周期收集日志；
按照收集的日志包含的业务应用第一属性信息，对所述收集的日志进行分类存储，得到分类日志集；
分别提取分类日志集中每一日志的业务应用属性信息中的状态值，获取状态值为预定异常值的日志。
结合第一方面或第一方面的第一种实施方式，在第一方面的第二种实施方式中，所述依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
统计所述业务应用第二属性信息中包含的服务器ip数以及用户ip数，计算服务器ip数与用户ip数的和值；
如果服务器ip数与和值的比率超过预先设置的服务器故障比率阈值，确定为服务器故障，如果用户ip数与和值的比率超过预先设置的恶意访问比率阈值，确定为恶意访问。
结合第一方面或第一方面的第一种实施方式，在第一方面的第三种实施方式中，所述依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
提取所述业务应用第二属性信息中的状态码，依据所述状态码定位故障。
结合第一方面或第一方面的第一种实施方式，在第一方面的第四种实施方式中，所述依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
提取所述业务应用第二属性信息中的返回子码值，查询预先设置的返回子码值与故障的映射关系，定位提取的返回子码值映射的故障。
结合第一方面或第一方面的第一种实施方式，在第一方面的第五种实施方式中，所述依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，基于所述业务应用关联接口id查询故障定位库，定位关联故障。
结合第一方面的第五种实施方式，在第一方面的第六种实施方式中，所述基于所述业务应用关联接口id查询故障定位库，定位关联故障包括：
获取业务应用关联接口id映射的接入商，在所述接入商产生的日志中的预先固定位置设置固定字符串；
向所述接入商发送请求，获取接入商返回的请求响应对应的日志；
提取所述请求响应对应的日志中的预先固定位置的响应字符串，统计所述响应字符串与所述固定字符串不一致的请求数与总请求数的比率，如果超过预先设置的接入商故障比率阈值，确定为接入商故障。
结合第一方面的第五种实施方式，在第一方面的第七种实施方式中，所述基于所述业务应用关联接口id查询故障定位库，定位关联故障包括：
依据所述业务应用第二属性信息中的耗时字段，计算所述异常日志在当前日志更新周期内的日志耗时参数，如果同比，和/或，环比超过预先设置的波动阈值，确定为网络的耗时故障。
第二方面，本发明实施例提供一种定位故障的装置，包括：
第一属性信息获取模块，用于获取发生故障报警的日志中包含的业务应用第一属性信息；
异常日志查询模块，用于查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志；
第二属性信息提取模块，用于如果查询到异常日志，提取所述异常日志包含的业务应用第二属性信息；
故障定位模块，用于依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位。
结合第二方面，在第二方面的第一种实施方式中，所述异常日志查询模块包括：
故障定位数据库单元，用于按照预先设置的日志更新周期收集日志；按照收集的日志包含的业务应用第一属性信息，对所述收集的日志进行分类存储，得到分类日志集；分别提取分类日志集中每一日志的业务应用属性信息中的状态值，获取状态值为预定异常值的日志。
结合第二方面或第二方面的第一种实施方式，在第二方面的第二种实施方式中，所述故障定位模块包括：
ip数统计单元，用于统计所述业务应用第二属性信息中包含的服务器ip数以及用户ip数，计算服务器ip数与用户ip数的和值；
恶意访问判断单元，如果服务器ip数与和值的比率超过预先设置的服务器故障比率阈值，确定为服务器故障，如果用户ip数与和值的比率超过预先设置的恶意访问比率阈值，确定为恶意访问。
结合第二方面或第二方面的第一种实施方式，在第二方面的第三种实施方式中，所述故障定位模块包括：
状态码定位故障单元，用于提取所述业务应用第二属性信息中的状态码，依据所述状态码定位故障。
结合第二方面或第二方面的第一种实施方式，在第二方面的第四种实施方式中，所述故障定位模块包括：
返回子码定位故障单元，用于提取所述业务应用第二属性信息中的返回子码值，查询预先设置的返回子码值与故障的映射关系，定位提取的返回子码值映射的故障。
结合第二方面或第二方面的第一种实施方式，在第二方面的第五种实施方式中，所述故障定位模块包括：
关联故障定位单元，用于判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，基于所述业务应用关联接口id查询故障定位库，定位关联故障。
结合第二方面的第五种实施方式，在第二方面的第六种实施方式中，所述关联故障定位单元包括：
关联故障判断子单元，用于判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，通知接入商故障定位单元；
接入商故障定位子单元，用于获取业务应用关联接口id映射的接入商，在所述接入商产生的日志中的预先固定位置设置固定字符串；向所述接入商发送请求，获取接入商返回的请求响应对应的日志；提取所述请求响应对应的日志中的预先固定位置的响应字符串，统计所述响应字符串与所述固定字符串不一致的请求数与总请求数的比率，如果超过预先设置的接入商故障比率阈值，确定为接入商故障。
结合第二方面的第五种实施方式，在第二方面的第七种实施方式中，所述关联故障定位单元包括：
关联故障判断子单元，用于判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，通知接入商故障定位单元；
耗时故障定位子单元，用于依据所述业务应用第二属性信息中的耗时字段，计算所述异常日志在当前日志更新周期内的日志耗时参数，如果同比，和/或，环比超过预先设置的波动阈值，确定为网络的耗时故障。
结合第二方面、第二方面的第一种至第六种中任一种实施方式，在第二方面的第七种实施方式中，
本发明实施例提供的一种定位故障的方法及装置，通过获取发生故障报警的日志中包含的业务应用第一属性信息；查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志；如果查询到异常日志，提取所述异常日志包含的业务应用第二属性信息；依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位，能够提升故障定位效率，以解决现有的定位故障的方法中，定位故障所需的时间长，故障定位效率较低的问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为本发明的实施例一定位故障的方法流程示意图；
图2为本发明的实施例二定位故障的装置结构示意图。
具体实施方式
下面结合附图对本发明实施例进行详细描述。
应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
图1为本发明的实施例一定位故障的方法流程示意图，如图1所示，本实施例的方法可以包括：
步骤101，获取发生故障报警的日志中包含的业务应用第一属性信息；
本实施例中，作为一可选实施例，业务应用第一属性信息包括：业务应用名称或业务应用接口标识(id)，一业务应用名称或一业务应用接口标识可以唯一标识一业务应用。
步骤102，查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志；
本实施例中，作为一可选实施例，查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志包括：
以所述业务应用第一属性信息中的业务应用名称或业务应用接口标识查询预先设置的故障定位数据库，确定所述故障定位数据库中是否存储有与所述业务应用名称或业务应用接口标识相匹配的异常日志集。
本实施例中，故障定位数据库中，以业务应用名称或业务应用接口标识为标识存储异常日志集，即构建有业务应用名称和业务应用接口标识与异常日志集的映射关系。
本实施例中，作为一可选实施例，设置所述故障定位数据库包括：
a11，按照预先设置的日志更新周期收集日志；
本实施例中，作为一可选实施例，每间隔一预先设置的日志更新周期统计一次所有日志。
本实施例中，日志更新周期可以根据实际需要进行设置，例如，可以设置为5分钟，即每间隔5分钟由系统中的服务器进行一次日志收集。
本实施例中，收集的日志包含的业务应用属性信息包括但不限于：业务应用名称、业务应用接口标识、弹性搜索(es，elasticsearch)索引、状态值(ret值)、耗时字段、服务器ip、用户ip、返回子码(sub)、查询地址、查询语句、httpcode(状态码)等。其中，业务应用名称及业务应用接口标识为业务应用第一属性信息。
本实施例中，查询地址为url链接地址，作为一可选实施例，业务应用属性信息还包括采用json格式、用于请求过滤使用的黑名单和白名单，以便于对存储的日志进行过滤。
本实施例中，每一业务应用包含有一个或多个日志，同一业务应用对应的不同日志，其ret值可以相同，也可以不同。
a12，按照收集的日志包含的业务应用第一属性信息，对所述收集的日志进行分类存储，得到分类日志集；
本实施例中，作为一可选实施例，依据业务应用名称或业务应用接口id对日志进行分类。进一步地，还可以将依据业务应用名称或业务应用接口id分类的日志以分类日志集进行存储。
a13，分别提取分类日志集中每一日志的业务应用属性信息中的状态值，获取状态值为预定异常值的日志。
本实施例中，作为一可选实施例，依据ret值来判断收集的各日志是否为异常日志。例如，如果日志中包含的ret值为非0，则表明该日志为异常日志，获取的状态值为预定异常值的日志集组成故障定位数据库。
本实施例中，作为一可选实施例，故障定位数据库为mysql数据库，较佳地，为nosql数据库。
本实施例中，作为一可选实施例，故障定位数据库包括：应用耗时数据库表以及上线操作数据库表，其中，
应用耗时数据库表(app_runtime表)用于存储预先设置的日志更新周期内的日志及日志耗时参数。
本实施例中，作为一可选实施例，日志耗时参数包括但不限于：日志请求量、最大耗时、最小耗时以及平均耗时。其中，日志耗时参数依据业务应用属性信息中的耗时字段进行计算。
上线操作数据库表(event表)，用于同步记录运维上线回滚等操作过程。
本实施例中，作为一可选实施例，以所述业务应用第一属性信息中的业务应用名称或业务应用接口标识查询预先设置的故障定位数据库包括：
b11，获取发生故障报警的日志的业务应用属性信息，封装所述业务应用属性信息；
本实施例中，根据发生故障报警的异常日志，获取异常日志对应的业务应用属性信息，并将获取的异常日志对应的业务应用属性信息进行封装后发送给rabbitmq。
b12，依据封装的业务应用属性信息查询故障定位数据库。
本实施例中，作为一可选实施例，rabbitmq将消息推送给work，其中，work是指故障定位数据库中的用于存储异常日志的消息队列，work接收到推送消息后，根据查询地址以及查询语句，利用es(elasticsearch)索引，在预先设置的nosql数据库中进行滚动查询(scroll)，并将查询到的数据(根据ret值评判为异常的日志)存入预先设置的mongodb中。
本实施例中，作为一可选实施例，在查询时，php脚本调用curl函数，curl查询地址，参数为查询语句，返回对应的数据(异常日志或异常日志集)，其中，curl是利用url语法在命令行方式下工作的开源文件传输工具。
本实施例中，作为一可选实施例，可以由系统中的服务器按照预先设置的日志更新周期发送crontab命令触发执行预先设置的php脚本，php脚本从存储所有线上业务应用的日志的mysql数据库中查询发生故障报警的异常日志对应的业务应用，获取异常日志对应的业务应用下的日志。
步骤103，如果查询到异常日志，提取所述异常日志包含的业务应用第二属性信息；
本实施例中，作为一可选实施例，业务应用第二属性信息包括：状态值(ret值)、耗时字段、服务器ip、用户ip、httpcode(状态码)、ret值以及sub(返回子码)。
本实施例中，如果异常日志为多个，则依次提取每一异常日志中包含的业务应用第二属性信息。
步骤104，依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位。
本实施例中，作为一可选实施例，依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
c11，统计所述业务应用第二属性信息中包含的服务器ip数以及用户ip数，计算服务器ip数与用户ip数的和值；
本实施例中，服务器ip数与用户ip数的和值为异常日志的总条数。
c12，如果服务器ip数与和值的比率超过预先设置的服务器故障比率阈值，确定为服务器故障，如果用户ip数与和值的比率超过预先设置的恶意访问比率阈值，确定为恶意访问。
本实施例中，服务器在当前日志更新周期统计的1000条异常日志中(每一日志中包含一服务器ip或一用户ip)，如果1000条异常日志中，服务器ip数占比超过服务器故障比率阈值(例如，50％)，可定位是服务器故障；如果1000条异常日志中，用户ip数占比超过恶意访问比率阈值(例如，50％或其他)，可定位该异常是恶意访问引起的异常。
作为另一可选实施例，依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
提取所述业务应用第二属性信息中的状态码，依据所述状态码定位故障。
本实施例中，对于httpcode(状态码)，网页所在的服务器会返回一个包含http状态码的信息头(serverheader)，用以响应浏览器的请求，例如，如果状态码为200，表明服务器成功返回网页；如果状态码为404，表明请求的网页不存在。
作为再一可选实施例，依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
提取所述业务应用第二属性信息中的返回子码值，查询预先设置的返回子码值与故障的映射关系，定位提取的返回子码值映射的故障。
本实施例中，对于sub(返回子码)，根据程序员自定义的错误码匹配，可以判断具体发生的是哪些故障。例如，如果sub值为10001，表明为请求错误等。
作为再一可选实施例，依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位包括：
判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，基于所述业务应用关联接口id查询故障定位库，定位关联故障。
本实施例中，每一业务应用具备唯一的业务应用名称或一业务应用接口标识。作为一可选实施例，如果该业务应用还关联有一个或多个下游业务应用，则业务应用第二属性信息还可以包含一个或多个业务应用关联接口id，每一业务应用关联接口id关联该业务应用下的一下游业务应用，如果该业务应用未关联下游业务应用，则业务应用接口标识不具有业务应用关联接口id。
本实施例中，作为一可选实施例，关联故障包括：接入商故障、影院故障、耗时故障、上线发版故障等。
本实施例中，关联故障为接入商故障，基于所述业务应用关联接口id查询故障定位库，定位关联故障包括：
d11，获取业务应用关联接口id映射的接入商，在所述接入商产生的日志中的预先固定位置设置固定字符串；
d12，向所述接入商发送请求，获取接入商返回的请求响应对应的日志；
d13，提取所述请求响应对应的日志中的预先固定位置的响应字符串，统计所述响应字符串与所述固定字符串不一致的请求数与总请求数的比率，如果超过预先设置的接入商故障比率阈值，确定为接入商故障。
本实施例中，以业务应用关联接口id为接入商为例，如果关联了接入商，预先针对关联的接入商的日志，在日志中的预先固定位置设置固定字符串，针对每一次请求，去比对该请求得到的日志中的预先固定位置的响应字符串是否与该接入商的日志中预先固定位置设置好的固定字符串是否一致，计算不一致的请求数与总请求数的比率，如果超过预先设置的接入商故障比率阈值，确定为接入商故障。
本实施例中，定位影院故障的流程与定位接入商故障的流程相类似，在此略去详述。
作为再一可选实施例，基于所述业务应用关联接口id查询故障定位库，定位关联故障包括：
依据所述业务应用第二属性信息中的耗时字段，计算所述异常日志在当前日志更新周期内的日志耗时参数，如果同比，和/或，环比超过预先设置的波动阈值，确定为网络的耗时故障。
本实施例中，针对业务应用名称、业务应用接口标识耗时的判断，根据实时发生的故障报警对应的业务应用接口id的业务应用关联接口id，查询mysql库中app_runtime存储耗时表，以日志更新周期为单位，分析周期同比环比是否突增或突降，排查是否为网络原因。例如，日志更新周期为5分钟，每5分钟产生1000条日志，每条日志中包含一个耗时字段，则获取1000条日志中耗时字段的平均耗时，最大耗时和最小耗时，如果其中至少一项的同比，和/或，环比超过预先设置的波动阈值，确定为网络的耗时故障。
作为再一可选实施例，基于所述业务应用关联接口id查询故障定位库，定位关联故障包括：
依据发生故障报警的日志所属的业务应用关联的关联业务应用，查询故障定位数据库中上线操作数据库表，确定是否为上线发版故障。
本实施例中，功能上线(发版)程序开发提交新功能供用户使用时，监控发生报警时，通过运维判断是否需要代码回滚操作，如果需要，则可以利用上线操作数据库表判断故障是否由发版等操作引起。
本实施例中，在产生故障报警时，从故障报警所在时间的最相邻的已完成异常日志统计的故障定位库中，查找分析该故障报警所对应的具体的异常日志及故障原因。即当发生故障报警时，根据发生故障报警时的故障时间，获取故障报警对应的业务应用名称或业务应用接口id，依据获取的业务应用名称和业务应用接口id查询故障定位数据库，从而分析并定位出故障报警的具体原因。
本实施例中，上述的故障定位的多种技术方案，可择一或多种判断同时进行。
本实施例中，作为一可选实施例，该方法还包括：
如果在预先设置的故障定位数据库中未查询到异常日志，将所述发生故障报警的日志输出以进行人工故障定位分析。
本实施例定位故障的方法，通过获取发生故障报警的日志中包含的业务应用第一属性信息；查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志；如果查询到异常日志，提取所述异常日志包含的业务应用第二属性信息；依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位，这样，预先获取异常日志并存储，依据业务应用名称、业务应用接口id以及业务应用关联接口id，通过存储的异常日志去分析和查找故障及定位故障，无需业务人员通过手工方式查看所有业务应用运行的日志，使得定位故障所需的时间短，能够提升故障定位效率，以解决现有的定位故障的方法中，定位故障所需的时间长，故障定位效率较低的问题。
图2为本发明的实施例二定位故障的装置结构示意图，如图2所示，本实施例的装置可以包括：第一属性信息获取模块21、异常日志查询模块22、第二属性信息提取模块23以及故障定位模块24，其中，
第一属性信息获取模块21，用于获取发生故障报警的日志中包含的业务应用第一属性信息；
本实施例中，作为一可选实施例，业务应用第一属性信息包括：业务应用名称或业务应用接口标识。
异常日志查询模块22，用于查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志；
本实施例中，作为一可选实施例，查询预先设置的故障定位数据库是否存储有所述业务应用第一属性信息对应的异常日志包括：
以所述业务应用第一属性信息中的业务应用名称或业务应用接口标识查询预先设置的故障定位数据库，确定所述故障定位数据库中是否存储有与所述业务应用名称或业务应用接口标识相匹配的异常日志集。
本实施例中，作为一可选实施例，异常日志查询模块22包括：
故障定位数据库单元(图中未示出)，用于按照预先设置的日志更新周期收集日志；按照收集的日志包含的业务应用第一属性信息，对所述收集的日志进行分类存储，得到分类日志集；分别提取分类日志集中每一日志的业务应用属性信息中的状态值，获取状态值为预定异常值的日志。
本实施例中，收集的日志包含的业务应用属性信息包括但不限于：业务应用名称、业务应用接口标识、弹性搜索(es，elasticsearch)索引、状态值(ret值)、耗时字段、服务器ip、用户ip、返回子码(sub)、查询地址、查询语句、httpcode(状态码)等。其中，业务应用名称及业务应用接口标识为业务应用第一属性信息。
第二属性信息提取模块23，用于如果查询到异常日志，提取所述异常日志包含的业务应用第二属性信息；
本实施例中，作为一可选实施例，业务应用第二属性信息包括：状态值(ret值)、耗时字段、服务器ip、用户ip、httpcode(状态码)、ret值以及sub(返回子码)。
故障定位模块24，用于依据所述业务应用第二属性信息对所述发生故障报警的日志进行故障定位。
本实施例中，作为一可选实施例，故障定位模块24包括：ip数统计单元以及恶意访问判断单元(图中未示出)，其中，
ip数统计单元，用于统计所述业务应用第二属性信息中包含的服务器ip数以及用户ip数，计算服务器ip数与用户ip数的和值；
恶意访问判断单元，如果服务器ip数与和值的比率超过预先设置的服务器故障比率阈值，确定为服务器故障，如果用户ip数与和值的比率超过预先设置的恶意访问比率阈值，确定为恶意访问。
作为另一可选实施例，故障定位模块24包括：
状态码定位故障单元，用于提取所述业务应用第二属性信息中的状态码，依据所述状态码定位故障。
作为再一可选实施例，故障定位模块24包括：
返回子码定位故障单元，用于提取所述业务应用第二属性信息中的返回子码值，查询预先设置的返回子码值与故障的映射关系，定位提取的返回子码值映射的故障。
作为再一可选实施例，故障定位模块24包括：
关联故障定位单元，用于判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，基于所述业务应用关联接口id查询故障定位库，定位关联故障。
本实施例中，作为一可选实施例，如果该业务应用还关联有一个或多个下游业务应用，则业务应用第二属性信息还可以包含一个或多个业务应用关联接口id，每一业务应用关联接口id关联该业务应用下的一下游业务应用，如果该业务应用未关联下游业务应用，则业务应用接口标识不具有业务应用关联接口id。
本实施例中，作为一可选实施例，关联故障定位单元包括：关联故障判断子单元以及接入商故障定位子单元，其中，
关联故障判断子单元，用于判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，通知接入商故障定位单元；
接入商故障定位子单元，用于获取业务应用关联接口id映射的接入商，在所述接入商产生的日志中的预先固定位置设置固定字符串；向所述接入商发送请求，获取接入商返回的请求响应对应的日志；提取所述请求响应对应的日志中的预先固定位置的响应字符串，统计所述响应字符串与所述固定字符串不一致的请求数与总请求数的比率，如果超过预先设置的接入商故障比率阈值，确定为接入商故障。
本实施例中，以业务应用关联接口id为接入商为例，如果关联了接入商，预先针对关联的接入商的日志，在日志中的预先固定位置设置固定字符串，针对每一次请求，去比对该请求得到的日志中的预先固定位置的响应字符串是否与该接入商的日志中预先固定位置设置好的固定字符串是否一致，计算不一致的请求数与总请求数的比率，如果超过预先设置的接入商故障比率阈值，确定为接入商故障。
本实施例中，定位影院故障的流程与定位接入商故障的流程相类似，在此略去详述。
作为另一可选实施例，关联故障定位单元包括：关联故障判断子单元以及耗时故障定位子单元，其中，
关联故障判断子单元，用于判断发生故障报警的日志所属的业务应用是否有对应的业务应用关联接口id，如果有，通知接入商故障定位单元；
耗时故障定位子单元，用于依据所述业务应用第二属性信息中的耗时字段，计算所述异常日志在当前日志更新周期内的日志耗时参数，如果同比，和/或，环比超过预先设置的波动阈值，确定为网络的耗时故障。
作为再一可选实施例，关联故障定位单元包括：
上线发版故障定位子单元，用于依据发生故障报警的日志所属的业务应用关联的关联业务应用，查询故障定位数据库中上线操作数据库表，确定是否为上线发版故障。
本实施例中，作为一可选实施例，该装置还包括：
离线定位分析模块(图中未示出)，用于如果在预先设置的故障定位数据库中未查询到异常日志，将所述发生故障报警的日志输出以进行人工故障定位分析。
本实施例的装置，可以用于执行图1所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。
尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，″计算机可读介质″可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。
应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。
在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
为了描述的方便，描述以上装置是以功能分为各种单元/模块分别描述。当然，在实施本发明时可以把各单元/模块的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。