云时代架构之中国民生银行天眼日志平台架构演进的平凡之路

中国民生银行天眼日志平台架构演进的平凡之路

　　对于一个简单的日志应用场景，一般会准备 master/slave 两个应用。咱们只需运行一个 Shell 脚本，即可查看是否存在错误信息。随着业务复杂度的增长，应用场景也会变得复杂。虽然监控系统可以显示某台机器或者某个应用的错误。然而在实际的生产环境中，因为实施了隔离，一旦在上图下侧的红框内某个应用出现了 Bug，则没法访问到其对应的日志，也就谈不上将日志取出了。另外，有些深度依赖日志平台的应用，也可能在日志产生的时候就直接采集走，进而删除掉原始的日志文件。这些场景给咱们日志系统的维护都带来了难度。

　　咱们能够从实时性和错误分析两个维度来区分不一样的日志数据场景：

　　实时，通常适用于咱们常说的一级应用，如：直接面向用户的应用。咱们能够自定义各种关键字，以方便在出现各类 error 或 exception 时，相关业务人员可以在第一时间被通知到。准实时，通常适用于一些项目管理的平台，如：在须要填写工时的时候出现了宕机，但这并不影响工资的发放。平台在几分钟后完成重启，咱们能够再登陆填写，该状况并不形成原则性的影响。所以，咱们能够将其列为准实时的级别。除了直接采集错误与异常，咱们还须要进行分析。例如：仅知道某人的体重是没什么意义的，可是若是增长了性别和身高两个指标，那么咱们就能够判断出此人的体重是否为标准体重。也就是说：若是能给出多个指标，就能够对庞大的数据进行去噪，而后经过回归分析，让采集到的数据更有意义。此外，咱们还要不断地去还原数字的真实性。特别是对于实时的一级应用，咱们要能快速地让用户明白他们所碰到现象的真实含义。例如：商家在上架时错把商品的价格标签 100 元标成了 10 元。这会致使商品立刻被抢购一空。可是这种现象并不是是业务的问题，很难被发现，所以咱们只能经过日志数据进行逻辑分析，及时反馈以保证在几十秒以后将库存修改成零，从而有效地解决此问题。可见，在此应用场景中，实时分析就显得很是有用。最后是追溯，咱们须要在获取历史信息的同时，实现跨时间维度的对比与总结，那么追溯就可以在各类应用中发挥其关联性做用了。

　　最后是我考虑到一个实际状况，咱们尽量少的占有服务器，而后传输须要过滤转换，日志能够比较简单，符合这种 Key value（KV）格式。咱们能够按照取了一个 Rsyslog、取了一个 Fluentd、取了一个 Hbase，取了一个 echars 等这么一个方式作一个方案就能够了。我以为 Rsyslog、Fluentd、heka 这些均可以作采集。而后传输这块有 Fluentd 传输，由于 Fluentd 和 Kafka 到插件很是灵活能够直接对接咱们不少存储设备，也能够对应不少的文件、连 ES 均可以。

文章来源：

https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247487107&idx=1&sn=59ae4e09c6418cfac534f45e8572a577&chksm=fbe9b74ccc9e3e5aa3894166619833aab6ba4eec9c8099e4b1ea1c3ca54aa4901fed70f2642f&scene=21#wechat_redirect