作者:许涛
上篇说到ELK日志整合系统的搭建:如何使用ELK Stack分析Oracle DB日志,这篇接着说说分析系统的设计和开发,还是举个例子吧。
Oracle12c有一个Application Continuity的特性,它可以在中断后恢复受影响的数据库会话,从而让终端用户和应用程序感觉不到中断的发生。过程如下:
当发生可恢复错误的时候,数据库会发送恢复请求,收到请求后,Application Continuity会replay会话请求。在replay成功之后,应用从数据库会话中断的时候继续执行,终端用户不会被挂起,可以继续执行操作。管理员也不用介入。如图所示:
我们的任务就是测试这个功能,如果有问题,就定位导致bug的原因。大致的测试就是向Oracle发送请求,同时破坏会话、instance,或者网络链路,然后看请求是否可以如常处理。如果请求没有如期恢复,那该功能就有bug存在,就通过日志分析来定位是什么导致了bug。这类trace日志巨大,即便是简单场景下,每分钟就有近1G的日志量,再加上测试场景众多,日志数量也较为庞大,快速分析日志定位bug就较为重要。
从这个功能的目标和过往的分析中积累了一些分析模式,举例如下:
这些分析模式便成了AC日志分析系统的设计基础。
使用Spring Boot实现一个MVC架构的日志分析展示系统很方便,View和Controller依据使用场景建立即可,这里主要考虑Model的实现,包括建立Elastic索引,和确定如何访问Elastic索引并从中依据分门别类的条件提取相关文档。
索引名称需要和测试场景关联且具有唯一标示性,文档构成字段需要考虑方便搜索,AC日志格式如下:
2019-01-13T09:37:27.721 PM -0800 UCP FINEST seq-408008,thread-70 oracle.jdbc.replay.driver.TxnReplayableBase.doPostWhenRecording 333BB13F Enter: public abstract boolean java.sql.ResultSet.next() throws java.sql.SQLException, true, null |
---|
显见的字段有:时间、级别、线程号、sequence号、类-方法名和日志消息,为了便于分析,线程号和sequence号应该设置成数值类型(便于排序、聚合等),还应该添加Oracleerror字段,这个需要从日志消息中提取。还要注意一个消息可能跨越很多行,根据这些要求配置Logstash,由它将AC日志分析装载进Elastic中。
Elastic·的发展很快,也就导致了其访问方式的快速变化,在开始开发前一定要确定合适的访问方式。经过一些使用场景的POC测试,AC日志分析展示最终选择了bboss,下面做一些简单比较。
目前常用的Java客户端有两大类,一个是TransportClient,但官方会逐渐弃用,在未来的Elastic8中将被淘汰。另一个是RestClient·,它又分为low levelrest client和high level rest client,high level基于low level,提供了请求和响应的串行化,但low level还有些high level所不具备的功能。直接使用这些Client的主要问题是过于复杂,程序需要自己处理Elastic请求和响应的JSON串,而Java对JSON的支持不太好,还需要借助第三方JSON处理库,比如fastjson、json-path或Gson等。这种方式可以作为备胎,当第三方库无法满足需求时启用。
一些第三方库和Elastic交互更为方便,比如Jest、spring-data-elastic和bboss。
Jest基于HttpClient,比Elastic自身更早地提供REST风格的支持。Jest不提供Elastic Query的生成,需要自己编写JSON串,还需要自己分析响应所对应的Gson对象。
spring-data-elastic主要提供两种方式用于和Elastic交互,ElasticsearchTemplate和ElasticsearchRepository,它们都是基于TransportClient和/或RestClient。ElasticsearchRepository类似于spring为领域对象提供的repository,只需要扩展该接口,框架便会自动提供一些默认的功能,程序就可以调用这些功能对领域对象进行CRUD操作。ElasticsearchTemplate与领域对象无关,可以用它进行一些repository无法完成的操作,如索引的创建和删除,文档的Aggregation等。对于日志分析类应用而言,索引的建立、文档的分析装载已经由Filebeat或Logstash完成,展示平台主要需要Query和Aggregation,而这方面spring-data-elastic所提供的API多而杂,开发人员除了要熟悉Elastic的DSL语句外,还需要把DSL转为相应的API,支持不够好。
bboss和spring-data-elastic类似,也是一款Elastic ORM开发库,采用xml文件管理Elastic的DSL脚本,在DSL脚本中可以使用变量、循环、逻辑判断和注释等,开发和调试非常方便。在AC日志分析应用中,用到多个DSL语句进行Query和Aggregation,bboss要比spring-data-elastic支持的更好一些。
从AC日志展示的主要场景可以归纳出基本的DSL语句,这里仅举几例说明:
bboss表达式会根据OERR_EXCLUSIONS列表动态生成要排除的Oracle error。
这里的bboss表达式使用了一个类似于Map<String,List<String>>的变量,该变量的Key指定字段,Value指定Key字段应该匹配的字符串。
其中include_conditions 和exclude_conditions 都是Map<String, List>结构,其中的Key是要匹配的字段,Value是一个包含有多个要匹配的关键字的列表。
有了这些DSL语句,程序使用bboss的API就可以进行Query和Aggregation操作了。
最后,几个使用场景如下:
本文分享自 云服务与SRE架构师社区 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!