首页 > 互联网技术, 系统架构 > 运维架构的一些思考(3)

运维架构的一些思考(3)

2012年5月29日 3,239 views 发表评论 阅读评论

关于监控.

关于监控的查看, 许多时候,不只是运维人员需要查看,研发同学也需要查看,产品同学可能也想看看. 用户希望的是单点登录获取所有有用信息,他需要从一个点就可以获取到所有的信息,而不是存在多个信息孤岛,所以有必要整合各种监控产品.让用户尽可能方便获取他要关注的一些指标.
如果研发同学也能实时查看到整个服务的一个性能变化趋势, 会有助于他们改进程序.
许多故障发现问题的时候,往往已经晚了,如果监控并没有及时发现, 那么是否有更实时的方式, 是否可以对关键的访问进行实时统计,实时在线记录各种性能数据呢?这样会投入一定开发成本, 但对于用户体验的改善更有针对性.
生产环境, 数据库往往在最后一环, 如果应用服务不能及时预警,那么一个小小的升级,都可能导致突然数据库流量大增, 导致数据库宕掉.  互联网公司许多服务为了快速上线,压力测试往往并没有做. 部分原因是认为开发成本高,想赶进度,部分原因是产品和研发同学自己都不清楚具体的数据, 许多人希望进行快速上线,快速迭代, 在运营中不断调整架构和改善程序,  如果要适应这样的模式, 更加需要服务的监控预警功能,有必要细化到许多具体访问的指标. 细化到监控一些具体的用户行为. .
当然,各种软件,负载均衡软件本身也有很强大的日志,可以协助定位问题和性能瓶颈点. 但开发同学,产品同学关注的一些访问点会更直观,更直接.
其实影响数据库的性能主要还是系统架构,应用程序,数据库设计,撰写sql的质量, 而os的调优,硬件,数据库的调优所起的作用有限. 真正到了性能瓶颈的时候, 救火往往解决不了问题,这个时候已经是事后了.
数据库的慢查询分析工具很有效, 但往往也是事后分析,  所以如果可能,应用程序配合监控实时记录慢查询,实时分析正在运行的语句也是一个很好的办法. 用图表的方式展示一些数据库的查询性能,比直接给开发同学看慢查询报告友善多了. 一个高质量的服务,往往本身是一个自诊断的系统,即使没有图形化的方式,也有很完善的性能日志,可以快速定位到性能瓶颈的源头,不用运维人员,开发人员不断检查,debug,猜测来猜测去.
监控其实是一个非常高技术含量的活. 我所想到的只是缓解数据库压力的的一些关注点 . 如果监控,部署很自动化了,完善了,那么完全可以大大减少数据库运维的工作量,dba就可以集中精力在数据库的特别的应用上 而不用care一般的需求,也不要求有什么多高的故障诊断能力.其他运维工作我想也是类似的.
 » 转载保留版权:老陈 » 《运维架构的一些思考(3)》
 » 如果喜欢可以: 点此订阅本站
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.