AmbariLogSearch
⽂章作者：luxianghao
免责声明：⽂章内容仅代表个⼈观点，如有不当，欢迎指正。
---
⼀简介
Ambari Log Search是Ambari社区从2.4版本推出的⼀个新组件，主要功能包括⽇志监控、收集、分析，并为收集的⽇志建⽴索引从⽽进⾏故障排查，⽇志搜索、⽇志审计等，官⽅介绍参考
⼆架构
Log Search拥有两个组件：Log Search Portal（server + web UI）和Log Feeder。log4j2自定义日志文件名
Log Feeder分布在所监控服务的多个主机上，负责监控特定的⽇志⽂件并把解析过的⽇志发送到Solr，⽤户使⽤Log Search Portal的web UI来查询⽇志，web UI发送请求给Log Search Portal的后端server，后端server再发送query请求给Solr服务，最终实现⽇志查询。
Log Search Portal后端server集成了，并利⽤作为Solr的client和Solr交互。
其中，是Apache的⼀个开源搜索平台， Log Search依赖Ambari Infra服务，Ambari Infra服务中含有组件。
具体架构图如下
三功能预览
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中的fig.files属性中到。
如果你添加了⼀个⾃定义的服务（添加⾃定义服务参考），为了在Log Search中也⽀持这个服务，你需要在定义这个服务的configuration⽬录中添加*-l的配置⽂件，*可以是⾃定义的名字，Ambari会根据*在 /etc/ambari-logsearch-logfeeder/conf/产⽣⼀个fig-*.json的⽂件，*-l中应该包含如下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 Log Search是为⼤数据相关服务定制，⼤数据集⼀般集规模会⽐较⼤，组件也很多，对应的相关⽇志也很多，可能考虑到负载、健壮性等问题，官⽅⽬前也只
是在⼩规模（例如在只有100多个节点的⾮⽣产环境的⼩集上使⽤）的在使⽤。不过Ambari Log Search本⾝还是很有意义的，相信后⾯也会有不错的发展。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。