Ambari Log Search

   文章作者：luxianghao

   文章来源：http://www.cnblogs.com/luxianghao/p/8630195.html  转载请注明，谢谢合作。

   免责声明：文章内容仅代表个人观点，如有不当，欢迎指正。

   --- 

 

一 简介

Ambari Log Search是Ambari社区从2.4版本推出的一个新组件，主要功能包括日志监控、收集、分析，并为收集的日志建立索引从而进行故障排查，日志搜索、日志审计等，官方介绍参考这里

 

二 架构

Log Search拥有两个组件：Log Search Portal（server + web UI）和Log Feeder。

Log Feeder分布在所监控服务的多个主机上，负责监控特定的日志文件并把解析过的日志发送到Solr，用户使用Log Search Portal的web UI来查询日志，web UI发送请求给Log Search Portal的后端server，后端server再发送query请求给Solr服务，最终实现日志查询。

Log Search Portal后端server集成了spring-data-solr，并利用spring-data-solr作为Solr的client和Solr交互。

其中，Solr是Apache的一个开源搜索平台， Log Search依赖Ambari Infra服务，Ambari Infra服务中含有Solr组件。

具体架构图如下

 

 

三 功能预览

1 历史操作日志存储

Ambari所管理的组件在Ambari Server上的历史操作日志将被保存，这对故障排查，历史回故，场景再现会比较有帮助。

 

2 主机相关组件日志快速查看

Ambari Server所管理的主机的的日志在的web端也将很容易查看，并且可以通过超链接直接跳转到Log Search UI。 

 

3 Log Search UI

1）故障排查

选择Log Search UI的Troubleshoting标签，如果HDFS有故障，正常情况下ERROR，FATAL日志的数量将会显著增加，那么你可以选择HDFS服务和相应的时间段，并点击GO to Logs，Log Search会自动查询所有HDFS相关的组件的日志，然后你就可以方便的查看日志，并高效的debug了。

Tips：有故障排查经验的同学肯定知道，一般情况下服务出现问题时，你都要先搜寻目标主机，然后到对应的机器上的对应目录打开对应的日志文件，查找ERROR或者FATAL日志，分析日志进行故障排查，有了Log Search我们会省去很多中间环节，为我们的故障排查赢得宝贵的时间，从而快人一步，保证我们服务的稳定性。

 

2)查询服务日志

选择Log Search UI的Service Logs标签，用户能够在一个页面快速的查看和搜索相关服务日志，用户可以通过时间、主机、日志级别、组件类型、日志存放路径、关键词等做快速查询，同时页面上也会统计不同时间、不同级别的日志情况 

 

3）查询审计日志

选择Log Search UI的Access Logs标签，用户能方便的查看审计日志，例如HDFS，你可以方便的看到是哪个用户、哪个目录、哪段时间的访问频率比较高，然后可以做相关的资源控制，冷热数据分离，这些都是和成本等息息相关的，相信这个功能也是很有必要的。

 

四 添加自定义组件

本节主要介绍下怎样在Log Search中添加一个自定义组件，并监控新的日志文件。

为了定义应该监控哪一个文件，怎样解析这些文件，你需要定义一些相关的输入日志数据的配置，服务部署好后，这些配置可以在/etc/ambari-logsearch-logfeeder/conf/logfeeder.properties中的logfeeder.config.files属性中找到。

如果你添加了一个自定义的服务（添加自定义服务参考这里），为了在Log Search中也支持这个服务，你需要在定义这个服务的configuration目录中添加*-logsearch-conf.xml的配置文件，*可以是自定义的名字，Ambari会根据*在 /etc/ambari-logsearch-logfeeder/conf/产生一个input.config-*.json的文件，*-logsearch-conf.xml中应该包含如下3个属性，

- service_name

- component_mappings

- content


第一个属性是service_name，这是自定义服务在Log Search中的标签，它也将在Log Search UI的troubleshooting的web页面上显示。
第二个是component_mapings, 这很重要，原因如下：
1 ）你在Log Search portal上点击自定义服务标签的时候，它会选择合适的组件去过滤；
2） 需要把Ambari组件和制定的logIds做个映射，你也会看到Ambari的组件名和Log Search的名字是不一样的
例如ZOOKEEPER_SERVER <-> zookeeper_server

对一个Ambari组件来说，它可能有多个Logids，因为一个组件可能有多个日志文件需要监控。

第三个属性是content，他是一个在logfeeder启动的时候会生成的一个配置文件模板，如果你在集群中新添加了一个带有*-logsearch-conf 配置的服务，你需要重启下Log Feeder。其中，

input描述了被Log Feeder监控的日志文件；

"rowtype"为service；

"type"为logid；

"path"为日志位置的表达式，支持正则，在例子中你可以看到path对应的是python代码，这个可以用来从Ambari配置里获取zookeeper的日志目录，如果日志目录会被更改这个功能就比较重要了；

filter模块里你应该选择"grok", 也支持"json"，不过这个只有在你的classpath里有logsearch-log4j-appender才能正常工作，在Grok里你可以定义每行日志应该怎么去解析，每一个field需要映射成为solr的field；

multiline_pattern 如果这个模式匹配上，意味着在日志中的行会被追加到上一行；

message_pattern定义了怎样解析指定的field并映射成为Solr field, 这里边"logtime"和"log_message"是必须的，"level"是可选的，但是推荐使用。

 

解析完成后，你可以在"post_map_values"里修改映射，例子里你可以看到，我们用指定的形式对日期重新做了映射，以便在solr里以指定的格式存储

更多关于input配置的可以参考这里，

为了找出针对你自己的日志文件的更合适的表达式，你可以使用这个，

在Log Search里也有一些内建的grok表达式，你可以在这里找到。

配置例子

<configuration supports_final="false" supports_adding_forbidden="true">  
  <property>    
    <name>service_name</name>
    <display-name>Service name</display-name>    
    <description>Service name for Logsearch Portal (label)</description>
    <value>Zookeeper</value>
    <on-ambari-upgrade add="true"/>  
  </property>  
  <property>
    <name>component_mappings</name>
    <display-name>Component mapping</display-name>
    <description>Logsearch component logid mapping list (e.g.: COMPONENT1:logid1,logid2;COMPONENT2:logid3)</description>
   <value>ZOOKEEPER_SERVER:zookeeper</value>
   <on-ambari-upgrade add="true"/>
 </property>
 <property>
   <name>content</name>
   <display-name>Logfeeder Config</display-name>
   <description>Metadata jinja template for Logfeeder which contains grok patterns for reading service specific logs.</description>
  <value>{  "input":[    
           {     "type":"zookeeper",     
                 "rowtype":"service",
                 "path":"{{default('/configurations/zookeeper-env/zk_log_dir', '/var/log/zookeeper')}}/zookeeper*.log"}  ],
            "filter":[   {
               "filter":"grok",
               "conditions":{
                 "fields":{"type":["zookeeper"]}
               }, 
               "log4j_format":"%d{ISO8601} - %-5p [%t:%C{1}@%L] - %m%n",     "multiline_pattern":"^(%{TIMESTAMP_ISO8601:logtime})", 
               "message_pattern":"(?m)^%{TIMESTAMP_ISO8601:logtime}%{SPACE}-%{SPACE}%{LOGLEVEL:level}%{SPACE}\\[%{DATA:thread_name}\\@%{INT:line_number}\\]%{SPACE}-%{SPACE}%{GREEDYDATA:log_message}",
              "post_map_values": { 
                 "logtime": {
                    "map_date":{
                       "target_date_pattern":"yyyy-MM-dd HH:mm:ss,SSS"         
                    }       
                  }     
               }    
          }   
      ]}    
    </value>
    <value-attributes>
      <type>content</type>
      <show-property-name>false</show-property-name>
    </value-attributes>
    <on-ambari-upgrade add="true"/>
  </property>
</configuration>

 

五 程序调试

在ambari-logserarch-portal组件部署的主机上的/etc/ambari-logsearch-portal/conf/logsearch-env.sh文件中会有相关的配置文件

#export LOGSEARCH_DEBUG=false
export LOGSEARCH_DEBUG=true

export LOGSEARCH_DEBUG_PORT=5005

默认DEBUG模式是关闭的，打开后ambari-logserarch-portal就会监听5005端口了，然后你就可以用idea或者其他工具愉快的进行远程调试了。

 

六 相关问题

实际使用过程中发现，查询的时候会有正则匹配相关的问题，refer to AMBARI-23333

 

七 后记

由于Ambari Log Search是为大数据相关服务定制，大数据集群一般集群规模会比较大，组件也很多，对应的相关日志也很多，可能考虑到负载、健壮性等问题，官方目前也只是在小规模（例如在只有100多个节点的非生产环境的小集群上使用）的在使用。不过Ambari Log Search本身还是很有意义的，相信后面也会有不错的发展。

posted on 2018-03-23 18:19  luxianghao  阅读(5528)  评论(0)  编辑  收藏  举报

导航