中国民生银行天眼日志平台架构演进的平凡之路
对于一个简单的日志应用场景，通常会准备 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