迅雷 故意限速

您的日志讲述了一个故事-或至少应该如此。 可以安全地假设所有软件应用程序都具有某种类型的日志记录。

在这种情况下进行日志记录是指响应从应用程序部署到取消部署而在应用程序中发生的事件而生成的消息。 这些消息通常会传输到其他系统以供使用。 它们的目的是告知应用程序中正在发生的事情，而不是应用程序功能的一部分。

在许多应用程序中，日志记录是事后才执行的。 我们做了一些事情，但我们没有考虑太多。 此外，对于过多的日志记录以及它们对代码库造成的“混乱”可能引起的危险，存在很多（有效）担忧。 本文将不解决这些问题。 我对如何执行故意的日志记录很感兴趣，因为我相信日志记录只要正确完成，就可以将我们的应用程序提升到一个新的水平。 那么，为什么我们要登录？

我们记录日志以将有用的（通常是可行的）信息传达给感兴趣的一方。 尝试调试应用程序为何无法按预期运行时，可能是我们自己。 也许我们记录用户的行为是为了更好地了解他们并帮助我们为他们建立更好的体验。 否则我们可能会记录日志，因为根据法规它是强制性的。

我将尝试进行分类，并将日志分组到以下位置：

• 用户行为：与用户在使用我们的应用程序时的旅程有关的数据。 我们使用它们可以改善他们的体验
• 调试：当应用程序中的事物无法按预期运行时，在遇到麻烦时可以帮助我们的信息
• 性能：可帮助我们了解应用程序组件在各种负载下的性能并揭示我们需要改进的方面的指标
• 法规合规性：某些应用程序需要保留某些日志以进行审核，协助进行不可抵赖性控制等。
• 安全性：可帮助我们建立基准，实时识别攻击并做出响应的日志
• 业务：关注由于用户活动和应用程序使用而导致的数据状态和流程。 此类数据是最符合我们应用程序目的的数据
• 系统：我在这里进行了概括，包括与操作系统，数据库，应用程序生命周期，其维护者等相关的所有日志。它提供有关应用程序运行环境的信息

上面的分类旨在传达并非所有日志都是相同的。 我们处理它们的方式也不应该相同。 我们可以基于以下属性评估和表征日志：

• 严重程度：消息有多重要？ 删除与用户行为相关的一些日志并不是什么大问题，但是我们不能删除审核所需的日志
• 频率和大小：多久生成一次消息？ 大小是多少？ 某些事件比其他事件发生得更多，并且日志有效负载的大小可能有所不同。 我们必须以适当的方式处理每个问题，例如防止瓶颈

一幅图片值一千个单词，因此根据上述属性（我在这里不够精确）评估日志类别可能看起来像这样：

我认为，其性质的差异可以证明在日志记录生命周期中对每个日志类别进行不同处理的理由。

日志记录生命周期非常简单。 记录的日志正在传输中，以便进行持久化，索引化，分析和可能的（自动）React。 日志的类型（关键程度，频率）将成为我们设计运输阶段的因素，因此我们允许日志记录增强我们的应用程序而不会影响其主要功能。 记录日志的方式将对分析和React的有效性和效率发挥作用。 那么我们应该如何写日志？ 在其中提供上下文和讲故事应该是什么？

该方法很简单。 我们希望人类和机器都易于理解日志，并且我们拥有一种完美的格式JSON。 所有数据都应以清晰的键值对形式输入。 接下来，我们应该记录什么？ 正如我们提到的， 我们需要讲一个故事，给出一个背景并从中删除所有的“胖子” 。 为了讲故事，每个日志应提供：

• 谁：服务参考ID，应用程序名称和版本
• 做什么：日志/事件类型（例如，安全性）和子类型（例如，未授权的请求）
• 代表谁：某种形式的用户或系统标识
• 出于什么原因：系统可以使用特定的业务功能（请求）
• 何时以及持续多长时间：时间戳记
• 来源：来源编号
• 关于：目标ID
• 作为对以下内容的响应：父流程或请求

这样，记录的事件将在上下文中与所有必要信息一起以人和机器都可以轻松分析的格式进行描述。

为了完整起见，我必须提到什么不记录。 为此，我仅提及OWASP，因为他们可以比我做得更好[1]。 因此，您的日志不得包含：

• 应用程序源代码
• 会话标识值（如果需要跟踪特定于会话的事件，请考虑将其替换为哈希值）
• 访问令牌
• 敏感的个人数据和某些形式的个人身份信息（PII），例如健康状况，政府身份，易受伤害的人
• 验证密码
• 数据库连接字符串
• 加密密钥和其他主密钥
• 银行帐户或支付卡持有人数据
• 允许存储比日志记录系统安全级别更高的数据
• 商业敏感信息
• 在相关司法管辖区非法收集的信息
• 用户选择退出收集或不同意（例如使用“不追踪”）或收集同意已过期的信息

关于不记录的最后一件事。 仅记录某人感兴趣的信息。 去除脂肪。 例如，您的团队中是否有人对过程发生在哪个线程感兴趣？ 如果是，那就很好–记录下来。 如果不是，则不应记录。

听起来像桃花似的，但在实践中存在挑战 。 我相信，在大多数应用程序中，日志记录的执行不是最理想的。 即使公司中有关于如何记录的明确指南，约定和策略，我希望每个人都不会遵循它们。 开发人员来来往往。 一般而言，日志并没有得到“尊重”。 因此，现实情况是，每个开发人员都以自己的语言（即成语）到处乱扔一些日志，达到他们认为合适的日志级别。 有关事件的重要信息可能会丢失，而不必要的信息可能会使日志混乱，这取决于每个开发人员的技能。 记录所有类型（异构短语）的日志并将其保存在某个位置。 后来，人们付出了巨大的努力来解析，索引，分析和使用这些日志。 但是我们可以而且应该做得更好。

一个有趣的想法和相对较低的投资是在您喜欢的日志库之上创建一个小的框架，该框架为开发人员提供了“日志外观”。 本文将讨论与您应该（或不应该）记录什么日志，格式以及对不同类别的日志的不同处理有关的所有这些项目，该框架将对其进行抽象和处理。 开发人员可以使用一个直观易用的界面。 会采用谨慎的日志记录做法，您的应用程序和操作会更好。 怎么做？ 对于另一篇文章，这绝对是一个不错的话题。

参考资料和启示：

[1] https://www.owasp.org/index.php/Logging_Cheat_Sheet

[2] https://www.codeproject.com/Articles/42354/The-Art-of-Logging

[3] https://www.symantec.com/connect/articles/building-secure-applications-consistent-logging

[4] http://jasonwilder.com/blog/2013/07/16/centralized-logging-architecture/

[5] https://www.loggly.com/blog/measuring-the-impact-of-logging-on-your-application/

[6] https://logmatic.io/blog/beyond-application-monitoring-discover-logging-best-practices/

[7] http://dev.splunk.com/view/logging/SP-CAAAFCK

翻译自: https://www.javacodegeeks.com/2018/07/deliberate-logging.html

迅雷 故意限速