最后更新于2023年3月29日(星期三)22:46:02 GMT
你在值班. 你在半夜被手机吵醒，被短信狂乱吵醒. 您从公司的日志服务中收到数百条消息:一条记录正在被写入数据库, 正在执行的代码, 一个新容器正在旋转, 诸如此类. 这些信息对你来说都无关紧要. 你只要关掉手机，继续睡觉.
第二天，您走进办公室，却发现数据中心一半的机架在夜间脱机了. 成千上万的顾客没有得到服务. 你从来没有收到过致命信息. 你怎么能? 你的手机关机了. 不过，你还是有责任的. 你能保住工作就很幸运了. 你做了一些窥探，只发现一些初级系统管理员使日志服务转发所有日志消息到你的手机，而不管严重程度.
那天下午晚些时候，你被叫到人力资源部. The HR Person is 的re; so is your boss. 你的老板问你在通话时关掉手机是怎么想的. 你唯一的辩护就是那部手机让你发疯了.
房间里一片寂静. 最后，人力资源人员问你的老板:“为什么他会接到一连串的电话? 你们的日志记录政策是什么?”
你的老板温顺地回答说:“我们没有.”
如果您认为这种情况是独一无二的，请再想一想. 许多公司直到为时已晚才实施日志记录策略.
企业范围的日志记录策略为公司提供了一致性和可靠性，以提供正确操作所需的关键信息. 此外，这是一个很好的投资回报.
Implementing an enterprise-wide 日志ging policy is a three-step process: establish 的 policy; communicate it throughout 的 company; 的n, 一旦政策生效, 执行.
请允许我详细说明.
建立日志策略
在建立日志记录策略时，有两条很好的经验法则:
- 越少越好
- 保持简单
有效的政策是简短、直接、容易遵循的. 当政策变得过于复杂时, 人们要么会忘记这些细节，要么就决定完全忽略这些规则.
定义日志级别
日志记录有两个部分:发送条目和获取条目. 在发送日志条目方面, 一个好的策略是定义每个日志级别以及何时使用特定级别.
| 水平 | 描述 | 例子 | 利害关系方 |
|---|---|---|---|
| 调试 | 与程序员和系统开发人员相关的信息 | 日志.调试("输入函数foo()") |
维护应用程序或系统的人员，他们需要详细了解代码的操作, 通常开发人员 |
| 信息 | 描述操作事件的信息 | 日志.信息(JSON.stringify (eventData)) |
监控应用程序或系统运行的人员:开发人员、Q/A人员、系统管理员 |
| 警告 | 指示危险状况的信息 | 日志.内存运行不足，当前使用:15.9GB，最大容量:16GB) |
监控应用程序或系统运行的人员:开发人员、Q/A人员、系统管理员 |
| 错误 | 描述应用程序或系统错误的信息 | 日志.错误(JSON.stringify(异常)) |
监控应用程序或系统运行的人员:开发人员、Q/A人员、系统管理员 |
| 致命的 | 存在灾难性状态的信息 | 日志.fatal("Region US-WEST-1不可用)) |
对应用程序或系统的持续健康和正常运行负责的人员:开发人员, Q /人员, 系统管理员, 运营管理 |
表1:日志级别及其描述、示例和相关人员
定义了日志级别的使用情况后，还需要定义存储日志数据的策略.
定义存储约束
采用日志记录的公司的典型模式是他们希望记录所有内容. 然而，在任何时候都不受限制地存储所有东西，是有风险的. 日志文件可能会变得非常大，以至于耗尽所有可用的磁盘空间. 然而,, 例如，可能有很好的理由将错误信息存储在托管机器上, 在检查故障机器时，使信息在源头上随时可用. 因此, 合理的存储策略是，除了使用可扩展的日志服务记录所有日志级别外，还应直接在生成错误的机器上收集错误信息. 此外，该策略的另一部分是根据日志级别存储数据. 例如, 将警告ING和错误数据发送到可以执行预测分析的存储库.
定义访问和通知策略
获取日志数据取决于相关公司的操作需求和安全策略. 在通知方面, 我们不希望出现像这篇文章开头描述的场景. 太多的信息会变成噪音. 因此, 通知策略需要回答一些简单的问题:谁会收到通知，通知发生了什么，以及通知是如何发生的?
同样的问题也适用于访问日志信息. 日志中存储了许多敏感信息，这些信息对心怀不轨的人很有用. 然而，许多公司将日志数据视为“只是关于我们系统的一些东西”的信息.懂行的人却不这么认为. 因此，拥有一个涵盖日志访问的策略是至关重要的. 只要问问那些在IT治理中挣扎的人就知道了 pci dss合规 在一贯的基础上.
通信日志策略
让员工注意任何政策, 更不用说像日志记录这样模棱两可的策略了, 是一项艰巨的任务. 但是，要使日志记录策略有效，必须知道它.
传达日志记录策略的最佳方法是创建一条消息，鼓励员工了解该策略. 消息一经定义，就需要反复发布. 这样的交流需要大量的创造力. 消息可以采用在IT运营内部网上发布的列表的形式, 题为, 伐木政策中的7个事实会让你的朋友和亲戚感到惊讶. 也可能是由部门主管在每周开始时宣布 它操作 会议.
执行日志记录策略
一旦定义并传达了策略，就需要强制执行. 执行日志记录策略的最简单方法是尽可能地自动化它. 在代码级别，这意味着将日志记录内置于公司开发人员使用的代码库和编程工具中. 例如，使用这样的技术 Python修饰符, Java注释, or 网络属性 自动生成日志事件- BeforeSave 和 AfterSave例如:. 也, 您可以构建一组日志插件，这些插件可以添加到开发人员的集成开发环境(IDE)中.
另一个技巧是让IT运维部门的人自愿成为政策工作人员. 在团队层面, Policy work负责确保在代码审查过程中支持日志记录策略，并将其作为DevOps事后检验的一部分. 在部门层面，政策工作可以提供发布前审查的专业知识.
另一种执行策略的有效方法是使用识别令牌. 是的, 这种技术有点半开玩笑, 但是我们这些破坏过夜间构建的人可以证明, 的 建筑破坏者奖杯 作品. 人们喜欢认可. 给支持日志记录策略的人颁奖似乎有点幼稚. 但是，它是有效的.
担任政策工作角色的人应该是权威主义者的精益一方. 这个人需要鼓励其他人遵循手头的政策, 不要成为一个暴力的执行者. 我们的目标是让人们顺从，而不是默许. 如果不愿意服从，人们就会滑向旧的行为.
把它们放在一起
实现简单的, 易于遵循的日志记录策略非常重要, 朝着改善企业内部日志管理的经济有效的步骤. 然而, 维护长期日志记录策略的关键是企业愿意改变路线以满足手头的条件. 测井技术将会改变，测井的范围也会改变. 最重要的事情是在整个IT操作过程中做出承诺，拥有支持日志记录策略的文化，并具有更改策略以满足即将出现的新需求的灵活性.
