剑客
关注科技互联网

再谈系统 Monitoring 和 Alerting

再谈系统 Monitoring 和 Alerting 题图:Tru by Emilia Dziubak

上一篇提到我之前做搜索,后来转而做了支付。有读者留言问:为什么选择支付而不是搜索?其实当时的选择并不是觉得一个领域比另一个领域更有意思,而是当时的机遇 恰恰给了我一个在支付方向发展的更好的机会。

无论哪个领域,做到一定程度,都会有很多很有意思的问题。逐年的积累也会带给你看待问题 的思路 和解决问题的经验。这样,在系统设计时,你能有个更好的全局感;解决问题时,能有更清晰的思路;遇到异常时,会有更高的敏感度;实现时,也能有更有效的执行力。

现在的方向很多,不同的方向锻炼出来的思维方式和技能集也不尽相同。比如我有很多朋友做增长(Growth),这在很多时候就需要快速迭代、采集和分析有效数据,还需要有比较好的产品的 Sense。很多朋友做 Search、做 Risk,很多时候就需要建模、调参,机器学习使用的也会比较多。有一些做底层 Infrastructure(比如 Storage,Data 或 Event Pipeline)就会比较注重 Scalability 和 Reliability 等。

而支付呢?做到一定规模后需要考虑 Scale 的问题,而最基本最关键的还是保证事务的一致性、正确性、和可审计性。打个简单的比方。 房客 A 想在 Airbnb 上预订房东 B 的房子。这样我们需要从房客 A 收钱,经过一段时间再转账给房东 B。说起来简单,不过是两笔交易,但这中间可能和需要发生的东西就太多了:A 和 B 可能是不同货币,需要进行汇率换算;A 可能使用两种或以上支付方式,比如一半用 Credit 付、一半用信用卡付,而这两笔可能失败,或者一笔成功一笔失败;可能某一步的第三方支付延时过长,实际交易成功却丢失了回执;可能需要保留一部分租赁税上交政府;可能房客下完订单后又希望改变预定的天数,这样需要追加一部分付费或者 Refund 交易的一部分…… 而每个公司的支付都要做结算,怎样保证每一笔现金流和转账都按一定的方式有记录,能够重现整个交易发生的场景。怎样保证任何的交易错误都能及时被发现等等。

所以支付说白了,就是各种各样奇葩的场景,怎样能做到系统的处理不会导致任何错误,并且能记录下足够的信息任何时候都能还原实际发生的事件。除了一些比较 Domain Specific 的支付知识,支付一个很重要的需求,就是系统对任何想得到的想不到的、有可能发生的情况都能正确的处理。

每年到了最后几个月,支付的一个重头戏就是为审计做准备,说白了,就是各种对账。前一段时间,大家都是做开发,最近,按照组里的小朋友们的说法,就是每天都像侦探一样在 “破案”。系统里的帐一批批、一笔笔地对,确保每一笔订单的收、支、现金流都是 “有案可查”,都是正确的。

而受益于我们整个 Monitoring 和 Alerting 系统已经做的相当完善,每一笔账的追踪就成为可能。有一些是放之四海而皆准的方案,不妨拿来说说。

Syslog 或 Kibana Log:也就是系统的日志,之前《 白话 IT 之浅谈 ELK 日志系统 》略有提及。这样,哪笔订单执行过哪些函数,留下的 Food Print 就可以搜索。缺点有二:一是 Kibana Log 在 ELK 系统中通常只能查到最近几十天或一个月的,定期 Archive,不能方便地查询历史所有的信息。而是没有办法很好的做 Analysis。

Hive 或者 DB Persisted Event:可以做比较详尽的 Event Tracking。这个根据不同的使用场景可以做的特别 Powerful。但是需要搭建比较完善的 Event Pipeline 和 Processing System。量大以后 Scalability 的处理也很重要。对工程师的要求比较高,尤其是在 Infrastructure 方面。

Datadog:可以记录一些系统的 Statistic。打个比方。对一个 Charge 函数。可以入口的时候设一个计数器,出口的时候为成功的 Charge 和失败的 Charge 各设一个计数器。这样就可以用图表追踪 Charge 成功的 Rate。并且可以进一步设置一个 Alert,当这个 Rate 低于 99.9% 的时候就 Fire Alarm。Datadog 还可以做一些很细致的统计、画图和警报。很多公司都有大屏幕用 Datadog 实时 Monitor 系统的核心 Metrics。

Sentry 和 NewRelic:主要是实时 Track 系统的 Error 和异常。对一些 API 或者 Client、Server Error 进行 Aggregation。很多公司 Oncall 必不可少的监测手段。

基于机器学习或者数学模型建立的 Alert 系统:比如之前《 公司里的 Data Scientist(数据科学家) 》一文中提过的我们建立的一个异常监测系统就属于这一类。

基于 DB Trigger 的 Auditing Trail:记录所有的 DB 改动,可以还原所有数据库写操作的历史。

有了以上这些工具和系统,几乎任何一种情况都能让工程师的 “侦察” 工作变得更轻松简单。

很多公司一开始的时候没有 Setup 好这样一些基本框架,就会丢失很多有价值的数据和记录。这样后面真的需要信息的时候就没有办法再找回来了。因此,设立一套完善的 Monitoring 系统,虽然对产品没有直接的好处,但从长远来看,是极为重要的。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址