关于应用程序日志

日志的内容

日志，在我们程序开发调试、生产环境运行异常追踪、应用程序性能监控，甚至是用户行为分析等多个场景都会用到的工具。如何设计、实现应用程序的日志机制，来让我们及时获得必要的信息、达成的目标，是很值得讨论的话题。

日志是对事件的记录，根据我们的使用场景，不同的类型事件会包含不同的信息，记录在不同的日志文件（Wiki: Log File）中。我们希望日志的内容充分而且有规则。一条日志，基本要包含这些信息：

什么时候发生的，When

在哪儿发生的，Where

谁触发的，Who

事件内容是什么，What

日志的目标与常见类型

根据日志的不同业务场景，上述信息（特别是详细描述）会具体化为不同的内容；常见的日志及其内容，有这么几种：

应用运行调试日志

通常是开发者用于追溯应用的运行状况，捕获程序异常、业务异常，从而改善应用健壮性。这类日志，通常包含这些内容：

访问日志

通常是对服务访问信息，及其响应信息的记录；对于异常的访问，可能会单独记录。比如 Nginx 的访问日志、错误日志。

这类日志，有这些信息：

应用性能日志

通常是是为了统计应用访问压力、处理能力、平均响应时间而保存的日志；这类信息通常有多种来源，比如上面访问日志的请求相应时间就是一个重要的来源。一条性能日志，通常会包含：

日志的格式

当我们整理好日志的内容应用程序日志，接下来就要考虑以那种格式保存下来，日志的格式的选择会受这些因素影响：

日志的格式有很多经验，也有很多现有的规则可以参考，比如：

日志的其他注意事项

在日志的内容整理、持久化保存的过程中，还有一些额外的事项需要考虑。

常见日志库

接下来，在我们具体的服务开发中，就要根据日志的内容、类型、存储形式、细节的注意事项来实现我们的日志了。一般，每个语言内建库，及其生态圈都有很多日志库的选择，一个可配置、功能全面的日志工具库可以极大的简化基础日志操作的工作，把工程时大部分精力放在恰当的描述事件内容上来。

这些库是我们经常遇到、使用的：

日志的集中存储与分析

现在的服务开发语境下，为了便于开发者获取和分析在众多服务节点上产生的日志，通常会对日志进行集中化处理、展示，进而考虑程序化分析。因此会有很多工具、服务做这一层面的工作。

服务的集中化，使得日志的“阅读”过程演变为先机器、后人工、再机器，这也反过来影响了日志格式的选择。

日志的集中存储，通常会考虑采集 -> 解析/转换 -> 存储 -> 可视化的过程，常见有这些套路：

Windows/Linux 应用日志

这个过程体现了Elastic Stack对日志处理的典型过程，其他日志流也有很大的相似性。

Docker 容器日志

鉴于近几年容器化、Docker 的应用，这也是一个常见的场景；我们会把上面的工具栈稍微改造一下，用更轻量的工具替换几个组件。

由于容器生态的火热，其实，上面每一层都有很多选择；而逐渐演变到 Service Mesh，日志流的也有一些变化。

性能日志接入监控系统

讨论到应用的性能监控，通常我们会从 APM 领域展开讨论，常见到StatsD、graphite、prometheus等工具。这里，我们重点讨论，从日志（比如 Web 访问日志）挖掘性能数据的过程是怎样的。

参考文章后记

整理这篇综述原因，是《左耳听风》学习小组的“命题作文”；这是挺好的一个机会，让自己完整地总结一下“日志”这个工作中经常遇到的话题，在讨论时都应该包含哪些内容。

我想，现在大概只写了 1/3，得空还要不断补充。

除了话题本身的内容，当探索一个新概念，或者去补充一个已知概念（比如这次）完整度时，该怎么做？也是一个有趣的实践过程，值的反复去训练。我一般会从这样的搜索开始。

一个新概念，拿“区块链”举个例子，转换成英文去 Google 里搜索。

另外，从上面的探索中，我们会遇到很多大公司技术团队的讨论文章，也是补充我们知识的重要来源。

（编辑：武汉站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!