亿级用户下的业务监控体系构建之路

TEABOUTME•微博技术保障部，业务监控平台攻城师•任职微博业务监控平台，负责业务监控平台的基础架构，各组件的优化，中间件的优化工作，主导业务监控平台各阶段的技术选型与架构调整。担任核心组件的代码开发。在构建高并发，海量数据，高可用的互联网在线技术领域有丰富的实践经验。graphite开源项目的研究者与维护者。•业界没有现成的解决方案，各部门不同的监控工具，人员对于业务监控不同认知，如何选型•如何形成标准，提升跨部门协作的效率•做为业务监控平台的构建方，面对失败的项目可能会困惑，如何摆脱•项目摸索的失败，基础体系的瓶颈，业务监控指标指数级增加，迁移过程中服务的不稳定，各方•业务监控架构演进过程•业务监控模型•业务监控系统分析•业务监控系统架构•关键技术环节介绍•业务监控实施经验总结控指标••监控bui据据务监控场景时发现问题：题点，避免故障的发生户体验问题发生的根本原因，为系统的调整优化提供决策依据量评估提供决策依据，避免资源的浪费••端原数据pxxoilogintcbyhostxxxxhttpxxxxxxgetuseridhitservalintervalintersdpoolssoilogintcbyhostxxxxhttpxxgetuseridmean据•单机数据oilogintcbyhostxxxxhttpxxxxxxgetuseridhits•全量数据tchttpxxxxxxgetuseridhits•聚合周期业务监控模型-业务监控场景一切基于K/V景模型-业务监控场景控场景•业务监控的技术难点•时间序列数据库的选取•数据流图•一切基于K/V•海量metric•启用单机指标监控后，随着接入机器的增多，metric呈指数级的增加，已经上升到千万级•开放API和易用的UI•不同维度的多个指标形成图表，多个图表组合成dashboard•图表与dashboard的定制必须灵活便捷，以方便多维度监控需求•方便的接口供使用方灵活调用•稳定性•解决了海量数据的伸缩性问题，随着系统复杂性的增加，稳定性成为了挑战•大数据计算•数据实时性•数据的写入与展示必须接近实时统分析-时间序列数据库的选取•文件存储：•GraphiteWhisper：graphite原生态的存储方式，一个metric会对应磁盘一个文件Tool•opentsdb(基于hbase)：不受容量的限制•blueflood：•kairosDB(基于cassandra)：•influxdb：•prometheus(基于leveldb)•Druid:•RDBMS:•mysql,postgresql储储数据聚合数据路由二次聚合数据缓冲r Key/value•…rrictreenagiosgraphite-webStatsdcountersettimer，后续加入了k/v类型，二次聚合数据并定时flushCrelay滤，数据转发mysqltoptop0，通过statsd编写的top插件来实现Redishost储业务监控的实时状态信息，数据由watchd写入webxmlkeykeynagios：负责告警处理Gearmandgearmanworkerkey数据获取性能(*)graphiteweb与http-api模式,前者主要负责界面与交互，后者主要负责数据的存储改造只需要满足前端finder与render两个http接口即可finderkeykey过程中这需要单boostloggraphitewebopentsdb此项应用•读写分离，读进程mount写进程的磁盘存储•把key的分层结构按照树形目录的方式进行存储•Crelay转发支持tsdb的格式•tsdb不稳定，会偶发http500错误•修改ids-used，Ids-used限制为1500万，metric-key达到1500万后将无法创建metric•高峰期关闭压缩，提升整点压缩时读取的卡顿问题•hbase关闭定期压缩，压缩期间会造成opentsdb不稳定•没必要启动过多的tsdb实例•metric不包含ip与api,ip与api加到tag里•openapi_profile.fanservice_web-tc-inner.byhost.__.HTTP.__.interval2(host=10_77_xxx_xxxapi=read_info_json)Ks存储大小：10T据•运营数据•metric量20万---->3000万+,存储500G->10TB，计算量300K/s提升到目前的2400K/sb•快速迭代：避免冗长的开发周期，以满足最小需求为前提条件下，不断升级优化技术细节•标准与非标准兼顾：面对复杂多变的需求，标准与非标准要兼顾•文档与代码兼顾：开源的文档大