某业务招致NameNode RPC通讯频繁,后来察看监控发现,是由于该业务获取HDFS列表文件的频率过于频繁。检查代码后,优化由20s获取一次目录列表改为5分钟获取一次,获取列表的RPC操作次数降落了约1.5倍,均匀每秒减少了2~3w次的RPC操作。
还有很多业务场景,经过剖析察看RPC画像,都发现了其不合理性,这里就不逐个罗列了。本文主要记载如何经过ELK快速剖析NameNode RPC操作并对接Grafana展现。
经过ELK快速剖析NameNode RPC操作
ELK是当前比拟主流的散布式日志搜集处置工具。这里采用Filebeat→Kafka集群→Logstash→ES→Kibana。
采用缘由:
1)Filebeat是基于原先logstash-forwarder的源码改造出来的。换句话说:Filebeat就是新版的logstash-forwarder,也会是Elastic Stack在shipper端的第一选择。
2)小贴士:固然LogStash::Inputs::TCP用Ruby的Socket和OpenSSL库完成了高级的SSL功用,但Logstash自身只能在SizedQueue中缓存20个事情。这就是我们倡议在消费环境中换用其他音讯队列的缘由。
而Redis效劳器是Logstash官方引荐的Broker选择,Broker角色也就意味着会同时存在输入和输出两个插件。
Kafka是一个高吞吐量的散布式发布订阅日志效劳,具有高可用、高性能、散布式、高扩展、耐久性等特性。目前曾经在各大公司中普遍运用。和之前采用Redis做轻量级音讯队列不同,Kafka应用磁盘作队列,所以也就无所谓音讯缓冲时的磁盘诘题。此外,假如公司内部已有Kafka效劳在运转,Logstash也能够快速接入,免去反复建立的费事。
3)目前Logstash1.5版本已自带支持Kafka插件,所以只需求学会如何书写Logstash规则,并且Kafka消费运用high-level消费。
4)Filebeat部署在应用效劳器上(只担任Logstash的读取和转发,降低CPU负载耗费,确保不会抢占应用资源),Logstash、ES、Kibana在一台效劳器上(此处的Logstash担任日志的过滤,会耗费一定的CPU负载,能够思索如何优化过滤的语法步骤来到达降低负载)。
详细搭建步骤:Filebeat装置运用(考虑后决议Filebeat运用Zip装置或者tar.gz便当修正配置打包分发。)→Logstash插件配置。
以下是架构图:
1、Filebeat采集hdfs-audit.log日志传输给Kafka或者Logstash
[hadoop@lf319-m3-002 filebeat]$ vi dynamically.config/audit-logstash.yml
filebeat.prospectors:
- input_type: log
paths:
- "/var/log/hadoop-hdfs/hdfs-audit.log"
harvester_buffer_size: 32768
scan_frequency: 1s
backoff: 10ms
#backoff <= max_backoff <= scan_frequency
processors:
- drop_fields:
fields: ["beat", "beat.name", "beat.hostname","beat.version","input_type","offset","@timestamp","type","source"]
output.logstash:
hosts: ["logstash-host:5044"," logstash-host:5045"]
loadbalance: true
worker: 4
bulk_max_size: 4096
#output.console:
# pretty: true
xpack.monitoring:
enabled: true
elasticsearch:
hosts: ["https://es-host1:9200", "https:// es-host2:9200"]
username: beats_system
password: beat@123
2、Logstash进一步合成日志,格式化日志数据
这里需求我们先查看下日志的格式,然后选择便当的日志格式化方式来解析日志。
日志格式案例:
2019-08-25 13:11:58,630 INFO FSNamesystem.audit: allowed=trueugi=lf_zh_pro (auth:SIMPLE)ip=/dn-ipcmd=getfileinfosrc=/user/lf_zh_pro/test/CommonFilter/sync/biz_id=B43/day_id=20190825/prov_id=089/part-00019-1566675749932.gzdst=perm=proto=rpc
2019-08-25 13:11:58,630 INFO FSNamesystem.audit: allowed=trueugi=lf_xl_bp (auth:SIMPLE)ip=/dn-ipcmd=createsrc=/user/lf_xl_bp/lf_xl_src.db/src_d_trip_all/date_id=20190825/hour_id=13/minute_id=00/.hive-staging_hive_2019-08-25_13-10-18_301_9180087219965934496-1/_task_tmp.-ext-10002/prov_id=031/_tmp.000238_0dst=perm=lf_xl_bp:lf_xl_bp:rw-rw-r--proto=rpc
2019-08-25 13:11:58,630 INFO FSNamesystem.audit: allowed=trueugi=ubd_obx_test (auth:SIMPLE)ip=/ dn-ipcmd=rename
经过察看能够发现上面的每条日志格式都是分歧的,都由时间戳、日志级别、能否开启审计、用户、来源IP、命令类型这几个字段组成。那么相较于grok来说dissect愈加简明。
Dissect的运用规则:https://www.elastic.co/guide/en/logstash/current/plugins-filters-dissect.html
Logstash配置如下:
input {
beats {
port => "5045"
}
}
filter {
if "/user/if_ia_pro/output/test" in [message] {
dissect {
mapping => { "message" => "%{logd} %{drop} %{level} %{log-type}: %{?allowed}=%{&allowed}%{?ugi}=%{&ugi} (%{?authtype})%{?ip}=/%{&ip}%{?cmd}=%{&cmd}%{}=/user/if_ia_pro/output/test/%{src2}/%{src3}/%{}%{?dst}=%{&dst}%{?perm}=%{&perm}%{?proto}=%{&proto}" }
add_field => {
"srctable" => "/user/if_ia_pro/output/test/%{src2}/%{src3}"
"logdate" => "%{logd} %{drop}"
}
remove_field => ['message','src2','src3','logd','drop']
}
}
else if "/user/lf_zh_pro/lf_safedata_pro/output/" in [message] {
dissect {
mapping => { "message" => "%{logd} %{drop} %{level} %{log-type}: %{?allowed}=%{&allowed}%{?ugi}=%{&ugi} (%{?authtype})%{?ip}=/%{&ip}%{?cmd}=%{&cmd}%{}=/user/lf_zh_pro/lf_safedata_pro/output/%{src2}/%{}%{?dst}=%{&dst}%{?perm}=%{&perm}%{?proto}=%{&proto}" }
add_field => {
"srctable" => "/user/lf_zh_pro/lf_safedata_pro/output/%{src2}"
"logdate" => "%{logd} %{drop}"
}
remove_field => ['message','src2','drop']
}
}
else if "/files/" in [message] {
dissect {
mapping => { "message" => "%{logd} %{drop} %{level} %{log-type}: %{?allowed}=%{&allowed}%{?ugi}=%{&ugi} (%{?authtype})%{?ip}=/%{&ip}%{?cmd}=%{&cmd}%{}=/files/%{src2}/%{}%{?dst}=%{&dst}%{?perm}=%{&perm}%{?proto}=%{&proto}" }
add_field => {
"srctable" => "/files/%{src2}"
"logdate" => "%{logd} %{drop}"
}
remove_field => ['message','src2','drop']
}
}
else {
dissect {
mapping => { "message" => "%{logd} %{drop} %{level} %{log-type}: %{?allowed}=%{&allowed}%{?ugi}=%{&ugi} (%{?authtype})%{?ip}=/%{&ip}%{?cmd}=%{&cmd}%{}=/%{src}/%{src1}/%{src2}/%{src3}/%{}%{?dst}=%{&dst}%{?perm}=%{&perm}%{?proto}=%{&proto}" }
add_field => {
"srctable" => "/%{src}/%{src1}/%{src2}/%{src3}"
"logdate" => "%{logd} %{drop}"
}
remove_field => ['message','src','src1','src2','src3','logd','drop']
}
}
date {
match => [ "logdate","ISO8601" ]
target => "@times"
remove_field => ['logdate']
}
}
output {
elasticsearch {
hosts => ["es-host:9200"]
index => "logstash-hdfs-auit-%{+YYYY.MM.dd}"
user => "elastic"
password => "password"
}
stdout { }
}
3、ES上察看数据
Filebeat和Logstash配置好采集剖析hdfs-audit.log之后启动进程,到ES上察看会发现创立有logstash-hdfs-auit- YYYY.MM.dd的index。
详细查看数据,能够看到曾经具备多个需求运用到的字段。
Grafana配置NameNode RPC操作
最后一步就需求在Grafana上配置衔接ES数据库。
然后创立Dashboard依次配置以下几种查询展现:
1)集群整体RPC每分钟衔接次数
2)HDFS途径All下All类型每分钟操作计数
3)All类型操作计数最多的hdfs途径
4)途径All下操作计数排行前五的类型 和All操作类型下操作计数前五的途径
总结:
那么如今关于企业来说,不论是在物理机上还是云上,玩本人的大数据平台跑消费任务,就不可防止会有不够合理不够优化的任务,比方最简单的集群对拷任务呈现异常中缀时,我们通常会挂定时任务并对hadoop distcp添加-update参数,停止比照更新掩盖,这时当定时吊起的过于频繁,就会发现当对拷目录下文件数越来越多,NameNode对该目录的listStatus类型的RPC衔接会激增,这时我们就需求优化对拷任务。
RPC的监控只是监控大数据平台的一个指标,这里经过这篇文章,带大家理解下如何快速地采集剖析平台日志,并停止展现监控。