文章作者：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本身还是很有意义的，相信后面也会有不错的发展。