《2019年鹰眼日志监控报警系统.pdf》由会员分享,可在线阅读,更多相关《2019年鹰眼日志监控报警系统.pdf(37页珍藏版)》请在三个皮匠报告上搜索。
1、鹰眼日志监控报警系统目录CONTENT背景和痛点(why)选型和功能设计(what)架构演进及优化(how)一些思考(review)4321 背景 痛点背景和痛点(why)PART01日益增长的服务数量和不能妥协的SLA2014-2016研发70人服务数量150个服务器100+台手工上线一切找运维2017-2018研发100+人服务数量300+个服务器200+台自动化上线推广微服务架构2018以后研发200人服务数量500+个服务器上千节点微服务容器化会沟通grep/awk总是被投诉后才知道两小时了还没好?痛点总结 后知后觉 沟通成本高 能力要求高 排查问题慢选型和功能设计(what)自研还是
2、开源?我们究竟要什么?这才是我们想要的 小结PART02乱花渐欲迷人眼 Elastalert CAT ELK SkyWalking Pinpoint简单为先 依赖少 报警规则够用 基于ES技术栈 耦合低Elastalert实践检验选择不成功 配置文件维护不便 不稳定 不及时 es语法曲线陡峭我们究竟要什么?轻量模块划分清晰相互依赖少基于开源技术体系开源技术相对简单可视化配置简单勾选即可完成,用户不需了解全部细节,知道大概即可高频功能工具化专注问题分析场景,常用的分析手段工具化,不做炫但无用的功能持续维护改进不做一锤子项目,要持续迭代进化,权限、分析手段随时间推移要不断增加监控报警要灵活根据业务
3、实际需要,支持灵活的任务调度频率这才是我们想要的-事件日志程序日志明细查询,慢日志查询,日志统计分析APP日志明细查询,崩溃分析,HTTP分析站点评价站点评分Web日志实时/历史查询,性能分析,慢流量分析等前端日志明细查询关键业务在纷杂的日志中重点关注核心业务部分这才是我们想要的-时序指标快速总览文件打开数,CPU,load,GC,QPSJVM线程数、内存占用、GC情况、类加载Datasource最大/小连接数、活动连接数&其他自定义指标请求情况服务器、状态码、URL维度请求量及耗时Tomcat线程数、请求量、接收发送数据Hystrix熔断状态、线程数、延迟、错误数Grafana同环比插件:h
4、ttps:/ 架构演进过程 成果展示 做了哪些优化 小结PART03 采集 将日志从端采集并传输至日志服务端 分发 利用成熟的实时计算技术实现高可扩展 存储不但支持高并发写入,还要支持高性能读 应用 基于存储进行业务开发,一般分为日志分析和监控报警设计理念分析系统监控报警应用存储高并发写存储分发实时计算采集采集服务端采集客户端 采集 采集客户端nxlog 采集服务端logstash 分发 无专门分发,logstash直接写入es 存储es 应用 监控报警elastalert 分析kibana架构设计V1.0V2.0V3.0kibanaelastalert应用存储采集nxlognxlognxlo
5、gnxloglogstashlogstashlogstasheseseses 采集 采集客户端nxlog+sharkagent 采集服务端flume 分发 引入kafka logstash消费后写入es 存储es 应用 鹰眼监控报警系统 鹰眼数据分析系统架构设计V2.0V1.0V3.0鹰眼数据鹰眼监控应用存储采集nxlognxlogsharkagentsharkagentflumeflumeflumeeseseses分发kafkakafkalogstashlogstashkibanaesflume 采集 采集客户端nxlog+sharkagent 采集服务端flume 采集端集成简单分发逻辑
6、分发 引入kafka storm消费后写入es 存储es 应用 鹰眼监控报警系统 鹰眼数据分析系统架构设计V3.0V2.0V1.0鹰眼数据鹰眼监控应用存储采集nxlogsharkagentflumeflumeflumeeseses分发kafkakafkastormstormkibanaflumeesesnxlogsharkagent 采集 采集客户端micrometer 采集服务端statsrelay 采集服务端telegraf 分发 influx-proxy双写influxdb 存储influxdb 应用 鹰眼监控报警系统 grafana架构设计V3.0V2.0V1.0鹰眼监控应用存储采集s
7、tatsdclientstatsrelayinfluxdb分发telegraftelegrafinfluxproxyinfluxproxyinfluxdbstatsrelaygrafanainfluxclientmicrometertelegraftelegrafinfluxdbinfluxdb成果6亿条/天,360G/天程序日志22亿条/天,820G/天Web日志200W条/天慢日志经销商技术,用户产品中心等4个主要部门接入部门占部门总人数50%以上日均UV2000个,日均运行50w次以上监控任务错误日志秒级,info日志几十秒级,web日志分钟级时延成果是监控体系的重要组成部分监控体系基调
8、网络主机监控nagios监控业务监控趋势监控Web日志性能日志实时监控源站监控程序日志慢日志成果监控项p PVp 平均耗时p TP90p TP99p TP999p 超时p 响应码p 同比p 环比趋势预警的目的是为了发现“慢性病”成果实时报警示例成果监控预警反哺构建完整生态圈成果流量性能可靠性单测覆盖度圈复杂度代码质量站点排名促进业务系统良性改进成果 上线验证效率提升:全年线上发版9000次,平均每次上线后验证2分钟,共节省38人日(9000*2/60*8=37.5)解决问题效率提升:程序日志访问18000次,平均每次处理耗时30分钟,产生2次访问,共节省562人日,约2.25人年(18000/
9、2)*30/60*8/250=2.25)大幅提升上线验证及解决问题效率只保留最近N天数据同一索引只存同构文档去掉文档得分统计多集群有条件就上SSD优化索引存储es优化写入优化字段名说明datetime请求时间,统一使用utc时间,很重要s-ip服务器IPcs-method请求方法cs-uri-stemurl主干部分cs-uri-queryurl参数部分c-ip客户端IPcs-user-agentUserAgentcs-referer来源信息cs-host域名sc-status响应状态码time-taken耗时,单位msx-forwarded-forhttp协议头代理信息开启最高压缩(codec
10、=best_compression)减少索引20%-30%的大小固定mapping,明确每个字段的类型只存必需字段增大refresh间隔优化es优化索引存储写入优化一定要批量写入重要业务优先写入,保证写入低延迟micrometer关闭暂停补偿器或更新至1.0.10版本及以上优化写入优化索引存储es优化小结先后经历3次架构调整做了各种优化发现和解决问题效率大幅提升一些思考(review)标准先行 精益研发 技术运营 还可以做的更好PART04标准先行得益于功能设计理念,我们可以标准化日志格式APP日志时序日志慢日志程序日志项目名称、级别、类名、方法名、服务端IP、GET请求参数、FORM表单参数、行号、异常类型、异常信息等Web日志以IIS日志为基础,涵盖了日常使用绝大多数情况需要的字段项目名称、域名、服务器IP、慢方法所在类、慢方法、耗时、请求参数、请求主干等系统类型、设备ID、操作系统版本、硬件型号、CPU、app版本号、网络运营商、异常信息、经纬度、客户端IP等Influxdb兼容格式、statsd扩展格式精益研发更快的交付有价值的需求定好基调小步快跑持续迭代技术运营尊重上帝的需求,正视反馈做真正有用的东西,而不是一切为了KPI服务意识,正视用户反馈完善配套、形成合力、体系化建设还可以做的更好AIOps调用链应用视角的工具链建设