统一日志管理

背景

随着技术的成熟，应用开发方式也在不断变化。开发各类功能的专用程序段已经成为主要趋势。

在微服务架构中，每个服务运行在独立的进程中，服务与服务间通过轻量级的通信机制（一般是基于HTTP协议的API）互相协作。API主要依赖于ESB、基于文件系统的资源、云解决方案及保留系统的集成。

客户端一般通过JavaScript框架搭建展示层，处理与API的交互。

根据“XX即代码”设计思路，大量底层服务能够通过git仓库和生成机制将源码转换为功能系统。

这便是应用设计机制。经过合理的设计，各个组件便能够正常运转，提供各项功能。但应用一旦发生故障，却很难定位到问题根源。

不同组件在提供应用服务的过程中都能产生日志，但日志格式和结构各不相同，因此需要建立统一日志管理机制。

下方的统一日志管理方案可处理各个组件的日志，实现了日志的统一查看与分析。

出现故障后，开发人员可根据统一格式的日志文件查找问题，不需要在不同系统之间来回切换。

哪些人员需要用到统一日志管理功能？

运维开发人员

如果应用突然出现故障，各组件的日志按照不同格式存储在文件系统中。即便收集到所有日志，按照时间顺序一一查询所有日志也耗时耗力。有了统一日志管理系统，日志不仅能够集中存储，还能保证格式统一，极大地方便了运维开发人员排查故障，而上下文信息也有助于找到问题的根源。

安全人员

统一日志管理系统能够帮助安全团队发现未授权的访问：从统一日志管理系统导出相关报告，比对日志，可发现可疑活动。例如，通过统一日志管理系统可发现如下错误：

通过统一日志管理系统导出报告后，可设置仅展示36209错误，显示日期/时间信息等相关消息。

IT运维人员

采用统一日志管理系统后，能够减少监控等任务对IT基础设施的侵入。IT运维人员可通过统一日志管理系统理解系统之间的交互关系，从而更加合理地安排日常巡检任务。

基本流程

统一日志管理系统的基本流程如下：

• 采集：连接源系统，采集系统原生日志，可设置日志采集级别。

• 解析：将源日志转换为统一日志管理系统的标准格式。这一点很重要，因为通过API生产的日志一般都是Apache格式的扩展版本，与数据库服务器的日志格式不同。

在解析正确的前提下，上方日志可以升级为如下格式：

升级后的日志采用了标准格式，提高了日志分析效率。

• 优化：进一步定义日志事件。通过优化日志格式，执行逻辑，分析日志中的IP地址，从而更好地理解系统或服务。也可以针对应用或服务设置自定义常数，减少交叉检索。

上方日志可优化如下：

经过优化，将时间戳转换成标准时间格式；在IP地址中添加主机系统；锁定错误码，查看更多信息。

• 存储：采集、解析、优化后的日志存储在统一日志关系系统的数据库中。此时可以通过索引和检索条件进一步了解源系统的原生日志。

• 预警：存储日志数据后，可配置事件预警，向其他系统发送预警，及时发现潜在问题。

• 分析：通过统一日志管理系统界面检索、过滤、查看与故障相关的所有事件，不需要直接从源系统查询日志。

日志中需要记录哪些信息

日志信息的时效性很强，因此采集过程中必须做好取舍。在文章开头的例子中，发生故障后，运维开发人员需要查看应用的全部日志，包括微服务、数据块、客户端和安全层的日志。如果日志中的部分数据与故障无关，就需要另外花时间剔除这类信息。

下图为授权服务日志：

虽然日志中的所有信息都很重要，但最好还是只保留下列信息：

这样，发生故障时，需要查看的日志量就会大大减少。

敏感信息

统一日志管理系统不能存储访问密钥、数据库连接串、加密密钥、账户信息、用户信息等敏感信息。上述案例中的tokenGoesHere消息就不应该保存在统一日志管理系统中。如确有需要，可采集下列信息：

达成约定

要基于统一日志管理系统所有用户的需求达成约定，即明确日志事件数量的上限和下限。

统一日志管理系统选择标准

要根据功能需求选择统一日志管理系统。以下为参考建议：

• 查询数据的便捷性：用户查询定位数据是否方便？很多用户并不擅长数据分析，因此内置报告或过滤条件能够极大地改善用户体验。

• 分析效率：创建复杂的检索过滤条件是，系统响应速度怎么样？返回结果的可读性和可用性怎么样？如前文所说，从统一日志管理系统检索信息时，响应时间和速度很重要。而过滤条件和报告则能有效改善用户体验。

• 可扩展性：公司所有的系统都能接入统一日志管理系统吗？需要多个用例吗？五年以后呢？未来会有更多系统需要接入，因此需要考虑统一日志管理系统的可扩展性。可根据响应时间对比不同解决方案的性能。

• 存储：对存储有什么要求？存储在哪里？采用统一日志管理系统的存储成本有多高？要了解与系统性能相关的存储边界。可部署二级存储，用于存储历史数据。

• 日志完整性：日志信息是否全面？是否需要从其他系统获取数据？如果还需要从其他系统另行获取数据，则说明该统一日志管理方案不符合需求。

• 数据优化功能：是否具备数据优化功能？功能是否简单易用？应用发生故障时，查看当前日志来源能够了解更多信息。而数据优化则能提升

• 是否开源：解决方案是否开源？如何接入公司现有系统？

• 日志采集工具：日志采集器具备哪些功能？是自研产品还是第三方开发产品？日志采集器由解决方案统一管理还是由日志源单独管理？一般来说，自研产品往往滞后于第三方开发的产品。如果日志采集器由解决方案统一管理，则能大大减少维护不同日志源的成本。

• 配置即代码。解决方案是否采用了“XX即代码”的设计思路？统一日志管理方案的配置能否保存在代码库？如果公司产品也采用这种设计思路，则采用“配置即代码”设计思路的统一日志管理方案便能够以编程的方式创建配置用例。

• 分类功能：分类用户（运维开发、安全、合规、IT运维）能否通过解决方案获得所需数据？能否通过解决方案定位不合规行为？如果具备这类功能，用户便能迅速了解异常情况，同时也能认识到统一日志管理解决方案的价值。

• API功能：解决方案是否具备开放API？熟悉统一日志管理解决方案底层API有助于进一步发挥解决方案的价值。

• 预期成本：可以根据成本比较不同产品的长期效益和可扩展性。

• 选择统一日志管理解决方案还是安全信息事件管理产品？

结论

开发运维人员、IT运维人员以及安全/合规人员都会用到统一日志管理解决方案。合理使用统一日志解决方案不仅有助于定位故障根源，还能在故障发生之前及时发送预警。部署统一日志解决方案时，需合理配置记录权限，按照监管规定避开敏感信息。优秀的统一日志管理解决方案应该能够快速提供分析所需信息，通过内置报告和相关功能帮助各类用户迅速响应常规请求。