基于搜索服务器的告警规则管理方法和设备

技术领域

本申请涉及计算机信息处理，尤其涉及一种基于搜索服务器的告警规则管理技术。

背景技术

在互联网急速发展的年代，人们对系统的业务数据以及日志的关注度越来越高，特别是在云计算行业，类似Elasticsearch这类开源搜索引擎与日志存储系统的使用率越来越高。人们习惯于将云平台上海量的日志与业务数据存放于此类系统中，并由此来进行必要的业务查询、监控告警，及大数据处理。

人们日常使用的操作系统Linux/windows/MacOS提供了大量的操作命令，来进行系统进程的快捷管理或复杂操作，随着越来越多的优秀的开源系统出现在市面上，人们能够在操作系统中能够使用及管理的方面越来越多。同时，随着系统发布更新日渐频繁，市面上也出现了很多优秀的发布平台，比如，Jenkins提供了优秀的持续集成能力，能够与代码仓库gitlab/github进行集成，通过其指定方式进行自动化发布。随着人们对云平台业务数据以及日志的关注度越来越高，在云计算平台和大数据的系统体量快速扩展的同时，包括Elasticsearch在内的开源搜索引擎与日志存储服务的使用率越来越高，这些搜索引擎提供的告警功能对云计算平台的业务监控尤为重要。

以Elasticsearch为例，其提供watcher监控日志的告警功能，允许用户通过HTTPPOST请求发送指定的json格式体给Elasticsearch集群创建告警，但是，当有大量用户(例如500-1000个甚至更多的系统)接入Elasticsearch时，系统管理员需要管理上千告警请求及对应用户规则，这将难以承受。

发明内容

本申请的一个目的是提供一种基于搜索服务器的告警规则管理方法和设备。

根据本申请的一个方面，本申请提供了一种基于搜索服务器的告警规则管理方法，该方法包括以下步骤：

获取由管理员设备发送的初始告警文件；

获取用户发送的关于待处理文件的文件提交请求；

响应于所述文件提交请求，获取所述待处理文件中的目标参数，并将所述目标参数渲染至所述初始告警文件以获得目标告警文件；以及，

基于所述目标告警文件生成对应的告警规则。

根据本申请的另一方面，本申请提供了一种基于搜索服务器的告警规则管理设备，其中，该设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以上方法所述的操作。

根据本申请的另一方面，本申请提供了一种存储指令的计算机可读介质，所述指令在被执行时使得系统执行以上方法所述的操作。

与现有技术相比，本申请所提供的基于搜索服务器的告警规则管理方法及设备使得相关用户可以自行调用命令创建规则，以及通过此命令工具与代码仓库进行持续集成，大大降低系统管理员的工作量，实现告警配置的自动化封装和快速集成。从而，本申请所提供的基于搜索服务器的告警规则管理方法及设备在云平台上业务快速迭代的过程中能够更快速更高效地进行业务监控告警配置，提升平台的运作效率，保证云平台的整体稳定性，并节省系统管理的人力成本。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出本申请一个实施例中基于搜索服务器的告警规则管理方法的流程；

图2示出本申请一个具体实施例中的告警规则管理流程；

图3示出一种可用于本申请各实施例的示例性系统的框图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(例如，中央处理器(Central Processing Unit,CPU))、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RandomAccess Memory,RAM)和/或非易失性内存等形式，如只读存储器(Read Only Memory,ROM)或闪存(Flash Memory)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(Phase-Change Memory,PCM)、可编程随机存取存储器(Programmable Random Access Memory,PRAM)、静态随机存取存储器(Static Random-Access Memory,SRAM)、动态随机存取存储器(Dynamic Random AccessMemory,DRAM)、其他类型的随机存取存储器(Random Access Memory,RAM)、只读存储器(Read-Only Memory,ROM)、电可擦除可编程只读存储器(Electrically-ErasableProgrammable Read-Only Memory,EEPROM)、快闪记忆体(Flash Memory)或其他内存技术、只读光盘只读存储器(Compact Disc Read-Only Memory,CD-ROM)、数字多功能光盘(Digital Versatile Disc,DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请所指设备包括但不限于用户设备、网络设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备包括但不限于任何一种可与用户进行人机交互(例如通过触摸板进行人机交互)的移动电子产品，例如智能手机、平板电脑等，所述移动电子产品可以采用任意操作系统，如Android操作系统、iOS操作系统等。其中，所述网络设备包括一种能够按照事先设定或存储的指令，自动进行数值计算和信息处理的电子设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific IntegratedCircuit,ASIC)、可编程逻辑器件(Programmable Logic Device,PLD)、现场可编程门阵列(Field Programmable Gate Array,FPGA)、数字信号处理器(Digital Signal Processor,DSP)、嵌入式设备等。所述网络设备包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云；在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟超级计算机。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(Ad Hoc Network)等。优选地，所述设备还可以是运行于所述用户设备、网络设备、或用户设备与网络设备、网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的程序。

当然，本领域技术人员应能理解上述设备仅为举例，其他现有的或今后可能出现的设备如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

在本申请的描述中，“多个”的含义是两个或者更多，除非另有明确具体的限定。

根据本申请的一个方面，本申请提供了一种基于搜索服务器的告警规则管理方法。参考图1，该方法包括步骤S100、步骤S200、步骤S300和步骤S400。下面以一种用于执行该方法的操作的管理设备为例，详细描述该方法的各个步骤。

其中，在步骤S100中，管理设备获取由管理员设备发送的初始告警文件。在此，管理员设备由系统管理员操作，初始告警文件(或者称之为规则模板)也由系统管理员提供。以下实施例非限制性地以Elasticsearch为例进行说明。首先由Elasticsearch系统管理员事先提供多种针对不同告警条件的规则模板，上传到代码仓库。后续所有需要接入告警的人员下载，并填写规则文件所需的参数，重新上传到代码仓库。随后，在步骤S200中，管理设备获取用户发送的关于待处理文件(例如用户填写参数后重新上传至代码仓库的规则文件)的文件提交请求，其中，该文件提交请求包含前述待处理文件，即用户填写参数后的规则文件(也就是用户更新后的初始告警文件)。

之后，在步骤S300中，管理设备响应于前述文件提交请求，获取所述待处理文件中的目标参数，并将所述目标参数渲染至所述初始告警文件以获得目标告警文件。其中，系统管理员通过开发命令行工具供Jenkins进行调用。

其中在一些实施例中，为提升用户的操作效率以及避免用户填写出错，前述初始告警文件包括保留符，例如系统管理员根据Elasticsearch的官方watcher语法，设计yaml格式的告警请求模板文件，并把关键的索引部分、查询部分、聚合部分、阈值部分等值，通过模板语言的方式置为保留符后续供用户使用，而其他请求体统一的部分，则系统管理员设计后直接编写入模板文件中。在执行指定命令时，命令行工具可以根据用户提交的规则文件中的参数，通过指定算法将告警规则必要的参数渲染至请求模板文件中的保留符。

而在步骤S400中，管理设备基于所述目标告警文件生成对应的告警规则(拟在系统中创建的告警规则)，例如，在告警规则生成后，根据请求文件生成的请求，通过命令，发送请求至Elasticsearch集群中创建真正的告警条件。

在一些实施例中，上述步骤S300包括子步骤S310、S320(均未示出)。其中在子步骤S310中，管理设备响应于所述文件提交请求，获取所述待处理文件中的目标参数；随后在子步骤S320中，管理设备对所述目标参数执行格式检查，若合法，则将所述目标参数渲染至所述初始告警文件以获得目标告警文件。例如如果通过go的yaml库渲染时发现用户的yaml格式非法，则直接报错，退出程序。从而避免后续正式创建告警规则时出错而影响系统正常运行甚至造成大面积出错。

进一步地，在一些实施例中，上述子步骤S320又包括子步骤S321、S322(均未示出)。其中，在子步骤S321中，管理设备对所述目标参数执行格式检查，若合法，由所述目标参数解析获得对应的告警规则名称；随后在子步骤S322中，管理设备将所述告警规则名称写入规则名称字典，其中所述规则名称字典线程安全，并将所述目标参数渲染至所述初始告警文件以获得目标告警文件。例如，在上一步格式检查合法后，再进行第二步检查。该步骤中检测用户是否提交同名文件，需要将用户提交的规则文件中alert_name，即告警规则的名称(逻辑上不允许同一用户创建两个名称相同的文件，否则会互相覆盖)，写入一个线程安全的字典中。后续对拟创建告警规则的管理即可基于该字典进行(例如通过对该字典中的规则名称进行增加或删减实现)。

特别地，在一些实施例中，首先在规则名称字典中查询所述告警规则名称；若返回为空，将所述告警规则名称写入规则名称字典，其中所述规则名称字典线程安全，并将所述目标参数渲染至所述初始告警文件以获得目标告警文件。具体而言，在在写入之前，先尝试从此字典获取此alert_name，如有，则说明发生了同名，报错并退出程序，以避免进一步操作使系统出错。

除了如上所述的新增拟创建的告警规则的操作之外，一些实施例还提供了对告警规则的移除操作，以提供更强大的管理功能，提升系统的灵活性。在一些实施例中，上述方法还包括步骤S400(未示出)。在该步骤S400中，管理设备执行告警规则移除操作，以移除对应的告警规则并更新所述规则名称字典。例如，执行清除命令clean，通过调用Elasticsearch的API，进行告警规则的删除。

其中，在一些实施例中，因为大量用户的调用，因此需要设计多线程进行递归，保证工具在大量请求的时候的执行性能，子线程以信号的方式，反馈给主线程；主线程也同样通过计数的方式，来统计子线程是否全部执行完毕。相应地，上述步骤S400包括子步骤S410、S420、S430(均未示出)。其中，在子步骤S410中，管理设备响应于接收到规则移除请求，解析所述规则移除请求以确定对应的待移除告警规则；在子步骤S420中，管理设备执行关于所述待移除告警规则的告警规则移除操作，并从所述规则名称字典中移除所述待移除告警规则对应的告警规则名称；而在子步骤S430中，管理设备当检测到待移除告警规则所对应的子线程执行完毕，移除所述待移除告警规则并更新所述规则名称字典，其中所述待移除告警规则对应于所述规则名称字典中未被移除的告警规则名称。例如，clean命令在递归读取文件夹中的文件时，需要读取出此文件的alert_name，即告警名称，接下来通过alert_name去删除watcherrules_map中与alert_name同名的键，当递归完毕后，全局字典中watcherrules_map中仍保存的键值，可以暂时理解为“用户在代码仓库已经将规则文件删除，但是Elasticsearch中，并未删除的规则”。随后，调用Elasticsearch的API，进行告警规则的删除。

在一些实施例中，上述方法还包括步骤S500(未示出)。在该步骤S500中，管理设备对生成的告警规则执行规则创建操作。例如，调用rulegen install–f./watcherrules正式创建相应的告警规则。可选地，在一些实施例中，上述方法还包括验证步骤，在该验证步骤中，系统验证Elasticsearch日志中出现对应错误时，watcher告警是否生效，以便于系统管理员尽早发现和排除错误。

在一些实施例中，为了进一步减少用户操作失误而造成系统出错，在上述步骤S400中，管理设备先执行对所述目标告警文件的校验；若校验通过，基于所述目标告警文件生成对应的告警规则。例如，将正确且不同名的告警规则yaml转换为json格式，并发送至Elasticsearch以供创建规则。此处添加-debug参数，在此，命令后加上的-debug参数表明只进行校验而跳过创建流程。如，rulegen install–f./watcherrules/alert.yaml–debug。而若校验失败，则向管理员设备发送校验失败提示，以通知系统管理员介入查看。

在上述基础上，在一些实施例中，为了避免某个或某些用户造成的错误导致其他用户无法成功创建规则，可选地将上述校验步骤设置为多线程执行。具体而言，在上述步骤S400中，对每个用户所对应线程所创建目标告警文件进行累加以获得文件创建计数，并获取初始告警文件的读取次数；若所述文件创建计数与所述读取次数相同(即所有用户整体操作有效)，则基于所述目标告警文件生成对应的告警规则。例如，设置全局变量success_count，即整体成功的个数。在读取到每一个文件时，基于线程安全的原子操作记录总共的全局变量：文件数file_count。设计为多线程是为防止因一个用户的错误，而导致其他用户无法进行创建。当每一个线程创建成功一个文件，则success_count加1，且只要有一个用户出现错误线程退出，即最终success_count不等于file_count，此命令结果就设计为失败，并通知系统管理员介入查看。

另一方面，亦可选地对用户的操作进行控制，以提升各用户整体的操作效率。具体来说，上述步骤S300包括子步骤S330、S340(未示出)。在子步骤S330中，管理设备将所述文件提交请求发送至审核用户，并获取对应的审核结果；在子步骤S340中，若审核结果为审核通过，管理设备响应于所述文件提交请求，获取所述待处理文件中的目标参数，并将所述目标参数渲染至所述初始告警文件以获得目标告警文件。通过审核用户(例如使用系统的高级或资深用户)，可以减少如上所述的某个或某些用户造成的错误导致其他用户无法成功创建规则的情况。特别地，在一些实施例中，管理设备记录用户发送文件提交请求的发送次数，以及当前用户每次发送文件提交请求所对应告警规则创建成功的创建次数；并且，管理设备基于发送次数与创建次数确定各用户的可信赖度信息(例如该可信赖度信息对应于发送次数与创建次数之比)；若可信赖度信息低于第一阈值(例如50％)，则判定当前用户的提交操作需要审核。而审核用户亦可通过该可信赖度信息而确定，例如，从可信赖度信息高于第二阈值(例如80％)的多个用户中选取前述审核用户。其中，一种选取方式可以是，在可信赖度信息高于第二阈值(例如80％)的多个用户中，确定活跃度最高的用户为审核用户，从而尽可能降低当前用户需要长时间等待审核的可能性，提升用户的操作效率。用户的活跃度可选地可以基于以下一点或几点确定：

-最近一次文件提交请求与当前时刻之间的间隔(间隔越短表明越活跃)；

-选定时间段内发送的文件提交请求的数量；

-选定时间段内成功创建告警规则的数量。

当然，本领域技术人员应能理解，上述用于确定活跃度的基础仅为举例而非对本申请具体实施方式的限定，其他现有的或者今后可能出现的确定方式如能适用，也包含在本申请的保护范围内，并以引用的方式包含于此。

为清楚起见，在此对照图2给出本申请的一个具体实施方式。

其中，用户希望在日志中监控，15分钟内，日志中“status Code:500”次数达到3次时进行告警。

首先，系统管理员根据Elasticsearch官方watcher语法，设计yaml格式的告警请求模板文件，并把关键的索引部分(indices)、查询部分(如query)、聚合部分(aggs)、阈值部分(threshold)等值，通过模板语言的方式置为保留符后续供用户使用，而其他请求体统一的部分，则系统管理员设计后直接编写入模板文件中。根据不同的告警规则，设计不同的告警请求模板，比如告警需求为一段时间内某内容超过某字段则进行告警，则告警请求模板文件的类型名称可以设计为one-period-threshold，这样后续用户填写自定义告警文件时，即可通过yaml文件中的alert_type字段内容进行匹配。

设计多种告警规则模板，如日志中“statusCode:500”某时间段占总百分比超过1％时的查询规则进行告警；比较日志在两个不同的时间间隔内的两个字段，字段一与字段二，的平均值是否超过阈值等进行告警。

接下来，创建代码仓库，供用户进行自定义规则文件的上传。用户规则文件中，只需要填写yaml格式的indices，query规则，aggs规则，及阈值threshold，即上述保留符的内容。

然后通过go命令行框架cobra。开始编写命令行工具rulegen，以及告警规则命令install。install命令首先需要设置参数f，后跟指定路径文件或文件夹，比如rulegeninstall–f./watcherrules/alert.yaml。-f参数后跟文件夹，则需要递归读取文件夹中的所有文件，直到所有文件夹读取完毕为止。

接着将用户文件中的参数，渲染至告警请求模板文件中，此时，第一步会进行格式检查，如果通过go的yaml库渲染时发现用户的yaml格式非法，则直接报错，退出程序。如该步骤成功，则进行第二部检查，检测用户是否提交同名文件。此部分需要将用户提交的规则文件中alert_name，即告警规则的名称(逻辑上，不允许同一用户创建两个名称相同的文件，否则会互相覆盖)，写入一个线程安全的字典中。在写入之前，先尝试从此字典获取此alert_name，如有，则说明同名，报错并退出程序。

将正确且不同名的告警规则yaml转换为json格式，并发送至Elasticsearch创建规则。此处添加-debug参数，如果在命令后加上-debug，则说明只进行校验，而跳过创建流程。如：

rulegen install–f./watcherrules/alert.yaml–debug

检验结果：将上一步设计为多线程操作，且设置全局变量success_count，即整体成功的个数。对于install命令，读取到每一个文件时，同样需要线程安全的原子操作，来记录总共的全局变量文件数file_count。设计为多线程的以防因一个用户的错误，而导致其他用户无法创建，当每一个线程创建成功一个文件，则success_count加1，且只要有一个用户出现错误线程退出，即最终success_count不等于file_count，此命令结果就设计为失败，并由系统管理员介入查看。

随后编写清除命令clean，命令首先需要设置参数同样需要设置-f，后跟指定路径文件或文件夹，比如rulegen clean–f/watcherrules/alert.yaml。参数-f后跟文件夹，则需要递归读取文件夹中的所有文件，直到所有文件夹读取完毕为止。

clean命令先会调用Elasticsearch的API，获取Elasticsearch目前已有全部watcher规则的名字，即全部告警名称，并将其存入一个线程安全的全局字典中watcherrules_map，以告警名称为键，值随意。

接下来clean命令在递归读取文件夹中的文件时，需要读取出此文件的alert_name，即告警名称，接下来通过alert_name去删除watcherrules_map中与alert_name同名的键，当递归完毕后，全局字典中watcherrules_map中仍保存的键值，可以暂时理解为“用户在代码仓库已经将规则文件删除，但是Elasticsearch中，并未删除的规则”。

上一步的设计中，因为大量用户的调用，因此也需要设计多线程进行递归，保证工具在大量请求的时候的执行性能，子线程以信号的方式，反馈给主线程，主线程也同样通过计数的方式，来统计子线程是否全部执行完毕。

告警规则的删除可通过调用Elasticsearch的API进行。

同理，封装Elasticsearch的watcher/_stop与watcher/_start，为wstart，wstop命令，通过执行rulegen wstart，rulegen stop启停watcher服务。

此外，设计Jenkins平台的流程代码，首先在Jenkins上创建一个任务，此任务能够执行上述rulegen命令。

在gitlab以及github上，配置此Jenkins任务的webhook，当用户进行代码commit，或者提交代码分支的merge request时，能够自动触发上述webhook，执行对应的Jenkins任务，而由Jenkins来执行rulegen。

接着通过Groovy语言，编写Jenkins流程代码脚本文件Jenkinsfile，实现逻辑如下：

当代码仓库(gitlab以及github)发送的webhook类型为commit类型时，Jenkins会从代码仓库拉取watcherrules，即全部用户提交自定义告警文件的文件夹，此文件夹同目录下，由系统管理员放置命令行工具rulegen；

执行命令rulegen install–f./watcherrules–debug，如检验失败，通过Groovy代码中gitlab或github插件的集成，回写失败结果，让用户看到提交的结果有误，但未显示错误原因；

当发送的webhook类型为merge request时，同样执行rulegen install–f./watcherrules–debug，如检验失败，通过Groovy代码中gitlab或github插件的集成，即可在merge request的备注中，回写上述步骤中，程序终止而报出的用户可读的错误，用户即可通过错误进行规则的检查；

将报错结果，通过Groovy代码同样打印至Jenkins任务的控制台；

如检验成功，则调用rulegen install–f./watcherrules进行真正的创建。

最后，验证Elasticsearch日志中出现对应错误时，watcher告警是否生效。

以上详述了本申请的一些实施方式。须知，这些实施方式仅为举例，而非对本申请具体实施方式的限定。

图3示出了可被用于实施本申请中所述的各个实施例的示例性系统。

如图3所示，在一些实施例中，系统1000能够作为各所述实施例中的任意一个用户终端设备。在一些实施例中，系统1000可包括具有指令的一个或多个计算机可读介质(例如，系统存储器或NVM/存储设备1020)以及与该一个或多个计算机可读介质耦合并被配置为执行指令以实现模块从而执行本申请中所述的动作的一个或多个处理器(例如，(一个或多个)处理器1005)。

对于一个实施例，系统控制模块1010可包括任意适当的接口控制器，以向(一个或多个)处理器1005中的至少一个和/或与系统控制模块1010通信的任意适当的设备或组件提供任意适当的接口。

系统控制模块1010可包括存储器控制器模块1030，以向系统存储器1015提供接口。存储器控制器模块1030可以是硬件模块、软件模块和/或固件模块。

系统存储器1015可被用于例如为系统1000加载和存储数据和/或指令。对于一个实施例，系统存储器1015可包括任意适当的易失性存储器，例如，适当的DRAM。在一些实施例中，系统存储器1015可包括双倍数据速率类型四同步动态随机存取存储器(DDR4SDRAM)。

对于一个实施例，系统控制模块1010可包括一个或多个输入/输出(I/O)控制器，以向NVM/存储设备1020及(一个或多个)通信接口1025提供接口。

例如，NVM/存储设备1020可被用于存储数据和/或指令。NVM/存储设备1020可包括任意适当的非易失性存储器(例如，闪存)和/或可包括任意适当的(一个或多个)非易失性存储设备(例如，一个或多个硬盘驱动器(Hard Disk,HDD)、一个或多个光盘(CD)驱动器和/或一个或多个数字通用光盘(DVD)驱动器)。

NVM/存储设备1020可包括在物理上作为系统1000被安装在其上的设备的一部分的存储资源，或者其可被该设备访问而不必作为该设备的一部分。例如，NVM/存储设备1020可通过网络经由(一个或多个)通信接口1025进行访问。

(一个或多个)通信接口1025可为系统1000提供接口以通过一个或多个网络和/或与任意其他适当的设备通信。系统1000可根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信。

对于一个实施例，(一个或多个)处理器1005中的至少一个可与系统控制模块1010的一个或多个控制器(例如，存储器控制器模块1030)的逻辑封装在一起。对于一个实施例，(一个或多个)处理器1005中的至少一个可与系统控制模块1010的一个或多个控制器的逻辑封装在一起以形成系统级封装(SiP)。对于一个实施例，(一个或多个)处理器1005中的至少一个可与系统控制模块1010的一个或多个控制器的逻辑集成在同一模具上。对于一个实施例，(一个或多个)处理器1005中的至少一个可与系统控制模块1010的一个或多个控制器的逻辑集成在同一模具上以形成片上系统(SoC)。

在各个实施例中，系统1000可以但不限于是：服务器、工作站、台式计算设备或移动计算设备(例如，膝上型计算设备、手持计算设备、平板电脑、上网本等)。在各个实施例中，系统1000可具有更多或更少的组件和/或不同的架构。例如，在一些实施例中，系统1000包括一个或多个摄像机、键盘、液晶显示器(LCD)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(ASIC)和扬声器。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。本领域技术人员应能理解，计算机程序指令在计算机可读介质中的存在形式包括但不限于源文件、可执行文件、安装包文件等，相应地，计算机程序指令被计算机执行的方式包括但不限于：该计算机直接执行该指令，或者该计算机编译该指令后再执行对应的编译后程序，或者该计算机读取并执行该指令，或者该计算机读取并安装该指令后再执行对应的安装后程序。在此，计算机可读介质可以是可供计算机访问的任意可用的计算机可读存储介质或通信介质。

通信介质包括藉此包含例如计算机可读指令、数据结构、程序模块或其他数据的通信信号被从一个系统传送到另一系统的介质。通信介质可包括有导的传输介质(诸如电缆和线(例如，光纤、同轴等))和能传播能量波的无线(未有导的传输)介质，诸如声音、电磁、RF、微波和红外。计算机可读指令、数据结构、程序模块或其他数据可被体现为例如无线介质(诸如载波或诸如被体现为扩展频谱技术的一部分的类似机制)中的已调制数据信号。术语“已调制数据信号”指的是其一个或多个特征以在信号中编码信息的方式被更改或设定的信号。调制可以是模拟的、数字的或混合调制技术。

作为示例而非限制，计算机可读存储介质可包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据的信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动的介质。例如，计算机可读存储介质包括，但不限于，易失性存储器，诸如随机存储器(RAM,DRAM,SRAM)；以及非易失性存储器，诸如闪存、各种只读存储器(ROM,PROM,EPROM,EEPROM)、磁性和铁磁/铁电存储器(MRAM,FeRAM)；以及磁性和光学存储设备(硬盘、磁带、CD、DVD)；或其它现在已知的介质或今后开发的能够存储供计算机系统使用的计算机可读信息/数据。

在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。