排查性能问题往往比排查功能性的Bug更让人头疼,主要有以下几个原因
对于服务器端的性能问题,我们常用的方法是写日志文件,例如把每个请求的响应时间都记录下来,但对海量日志文件的存储,聚合与分析又成了另一个麻烦。常用的解决方案有ElasticSearch + Logstack + Kibana,或是StatsD/CollectD + Graphite等等。在Glow,对于性能监控这样的通用服务,我们更偏向于选择云服务,而不是自己去维护这些系统,这样我们的精力才能集中在产品研发上。 在对于性能监控类的云服务做了一些横向比较后,我们选择了Datadog,使用一年多,感觉很不错,所在在这里分享给大家。 Datadog简介Datadog的工作方式是在每一台需要监控的服务器上运行它的Agent。Agent不但会收集这台服务器的各类基础性能数据,如CPU使有率,剩余内存空间,剩余磁盘空间,网络流量等,也可以收集用户自定义的性能数据,灵活性很好。 Datadog另一个好用的地方在于它与众多的云服务和开源项目有整合,我们在实际用的整合有
下面图中是我们一台Redis服务器的监控面板,除了可以看内置的基本性能信息外(CPU,内存,网络等),也可以实时地看到Redis服务器的连接数,Key的总数,每秒接收到指令数等,相当实用。 Datadog也可以对各种监控的性能指标设定阈值,当指标超出阈值范围时,发出警报。我们可以利用它与Slack的整合,直接将警报推送到Slack上。 自定义指标 - Custom metrics虽说Datadog内置系统监控以及第三方整合都很好用,但它真正强大之处在于可以方便地自定义指标。这些自定义的指标可以是Web server对每个请求的响应时间,或是数据库中每张表的读写请求数,也可以是Job queue里pending的job数量。因为可以自定义想要收集的数据,所以不会受限于Datadog原生提供的功能,这也是当初我们选择这个云服务的主要原因。 Datadog的自定义指标有两种类型Count和Histogram。Count比较直观,就是用于记数,用来统计某个事件在一个时间区间内发生了多次次,例如我们可以定义一个 对发送到Datadog的每个数据点,我们都可以添加多个tag,这对于之后数据的查询与分类非常有帮助,比如我们可以根据数据来自哪个microservice,给它们打上不同的tag。在实际使用中,我们会以更细的粒度在数据点上添加tag。 下面是向Datadog发送自定义指标的Python代码示例,其中
第一个例子我们用
第二个例子我们记录的是Histogram类型的数据。这里假设在我们的Nurture应用下,有一个专用于读写用户数据的User service,某次访问该服务下
在Datadog上建立Dashboard当我们把想要监控的数据发送给Datadog后,下一步就是将统计数据可视化,这一步可以通过在Datadog上创建Dashboard来完成。虽然Datadog提供了很多种图表的类型,但最常用的是Time Series和Top List。前者用于显示某组指标在一段时间内的变化,比如查看服务响应时间在最近24小时内的变化曲线。后者用于显示在某段时间内某一指标的排名,比如查看最近24小时响应时间最长的10个API。 下面看一个简单的Time Series Graph的例子 这里用的自定义指标名为 下面再看一个的Top List的例子 上面这例子列出了在生产环境中( 图表中显示的数据也可以是若干个指标的数学运算组合。假设我们在代码中发送了应用层缓存的Cache hit与Cache miss的Count数据到Datadog,我们就可以创建一个图表来显示缓存的命中率,也就是 上图中 监控与报警我们不可能每时每刻都关注Datadog上的Dashboard,但当某些服务无法工作或是性能指标异常时,我们希望可以立即被通知到。Datadog的监控报警可以与Slack整合。在发生异常时,Datadog可以把消息推送到Slack的一个Group里,这样所有在这个Group里的人都能在手机上收到推送通知。 Datadog的监控与报警和配置界面很直观,基本不需要什么学习成本。比如在下图中,我们创建了一个监控web server响应时间的监控,当最近5分钟内的平均响应时间超过1.0秒时报警 为了保证生产环境的正常运作,我们可能需要创建非常多的监控,这里有许多的重复劳动(例如,每个app都要对响应时间做监控),纯手动操作既低效又容易出错。幸运的是,Datadog可以通过它的RESTful API来管理监控。这样配合一些系统配置工具可以更有效地管理这些监控。下面这段Ansible代码可以为我们所有的app创建了响应时间的监控,其中
小结生产系统的性能监控并不仅仅是为了保证系统的稳定性,也是为了可以持续地改进整体的系统架构。性能调优是任何一个对技术有热情的团队都愿意做的事情。但很多时候一些技术人员虽热衷于尝试新的技术与想法,但却缺少一种“一切以数据说话”的态度。我的观点是,没有明确的量化指标,性能优化就无从谈起。也不要轻易地去拿一些网上的benchmark来说话,因为真实的生产环境复杂地多。这篇文章虽然是对Datadog这个工具的介绍,但我想传达是一种对生产环境的真实性能做全方位量化的态度。从每个API call所用的时间,到各个层级缓存的使用频率与命中率,再到数据库每张的读写频率与响应时间,这些数据都需要收集,不但要收集,更需要有效地可视化,让技术团队方便实时地分析这些数据,并基于数据来决定未来架构的发展。 |
|
来自: 昵称54185769 > 《待分类》