infrastructure

A collection of 2 posts
devops

生产环境下的性能监控 - Datadog

排查性能问题往往比排查功能性的Bug更让人头疼,主要有以下几个原因 * 很多性能问题只会在高负载的生产环境下出现,在开发过程中很难发现。 * 功能性出错时我们通常会抛出异常,我们可以通过Tracestack很快定位到问题所在代码的位置。但对于性能问题,我们很难做这样的快速定位。 * 虽然我们有各式各样的Profiling工具,但适用于对生产环境的并不多。当然这因编程语言而异,Glow服务器端的技术栈是Python + Gevent,目前为止我们都没有找到合适的Profiling工具。 对于服务器端的性能问题,我们常用的方法是写日志文件,例如把每个请求的响应时间都记录下来,但对海量日志文件的存储,聚合与分析又成了另一个麻烦。常用的解决方案有ElasticSearch + Logstack + Kibana,或是StatsD/CollectD + Graphite等等。在Glow,对于性能监控这样的通用服务,我们更偏向于选择云服务,而不是自己去维护这些系统,这样我们的精力才能集中在产品研发上。 在对于性能监控类的云服务做了一些横向比较后,我们选择了Datadog,使用一年
infrastructure

用户事件的存储与分析

许多时候我们说一款产品的设计是数据驱动的,是指许多产品方面的决策都是把用户行为量化后得出的。一个典例的例子就是注册流程的设计,如果用户需要填写的注册信息较多,一般就会分成多个页面,而产品设计师最关心的就是每个页面的流失率,从而不断的对这个流程作调整以达到信息量与流失率之间的平衡。 为了能够量化用户的行为,前提是要将各种用户事件都保存下来。其中最典型的事件包括user creation, page view和button click,但实际上还有许多其他事件,比如用户更改了状态或是录入了某些数据等等。目前有许多第三方的服务可以帮助你做这方面的统计,国内有友盟,国外有Google Analytics和Mixpanel。但如果你记录的事件数量非常庞大,或是对之后的数据分析有非常定制化的要求,那就要考虑自己构建事件分析的平台,而这个过程中最关键的一步就是如何存储用户事件。 首先我们来分析一下用户事件存储有哪些特性 * 数据量巨大 用户在应用中产生的事件数量远远大于他们产生的数据。非常简单的一个例子,就是用户在浏览各个页面时,他们并不产生任何数据,但却产生了大量的page view