我将要编写公司准则，以指导日志中绝不能出现的内容（应用程序的痕迹）。实际上，一些开发人员试图尽可能多地包含尽可能多的信息，这使得存储这些日志很冒险，并且提交它们非常危险，尤其是当客户不知道该信息是否存储时，因为她从不关心此信息。切勿阅读文档和/或警告消息。
例如，在处理文件时，一些开发人员很想跟踪文件名。例如，在将文件名附加到目录之前，如果我们跟踪所有错误内容，则很容易注意到例如附加名太长，并且代码中的错误是忘记检查代码的长度。串联字符串。这很有用，但这是敏感数据，绝不能出现在log中。
以相同的方式：
- 密码，
- IP地址和网络信息（MAC地址，主机名等）¹，
- 数据库访问
- 来自用户的直接输入和存储的业务数据
绝对不能出现。
那么，必须从日志中清除其他哪些类型的信息？有没有已经写好的指南可以使用？
¹显然，我不是在谈论IIS或Apache日志。我所说的是收集信息的唯一目的是调试应用程序本身，而不是跟踪不可信实体的活动。
编辑：谢谢您的回答和评论。由于我的问题不太精确，因此我将尝试回答评论中提出的问题：
- 我在处理日志吗？
应用程序的日志可能存储在内存中，这意味着可以将其存储在本地主机的硬盘中，数据库中，也可以存储在Windows事件中。在每种情况下，都担心这些来源可能不够安全。例如，当客户运行一个应用程序并且该应用程序将日志存储在temp目录的纯文本文件中时，任何对PC有物理访问权限的人都可以读取这些日志。
该应用程序的日志也可以通过互联网发送。例如，如果客户对应用程序有疑问，我们可以要求她以全跟踪模式运行该应用程序并向我们发送日志文件。此外，某些应用程序可能会自动将崩溃报告发送给我们（即使存在有关敏感数据的警告，在大多数情况下，客户也不会阅读这些警告）。
- 我是在谈论特定领域吗？
否。我仅在一般业务应用程序上工作，因此唯一敏感的数据是业务数据。没有任何与健康或特定法规涵盖的其他领域相关的内容。但是，谢谢您谈论这个问题，我可能应该看看这些领域，以获取一些有关我可以在指南中包括的内容的线索。
- 加密数据难道不是很容易吗？
不会。这会使每个应用程序变得更加困难，特别是如果我们要使用C＃诊断程序和TraceSource。它还需要管理授权，这不是最简单的想法。最后，如果我们谈论的是客户提交给我们的日志，则我们必须能够读取日志，但不能访问敏感数据。因此，从技术上讲，从不将敏感信息完全不包含在日志中，并且永远不在乎这些日志的存储方式和位置会更容易。
debug文件名可能没问题，但对info文件名却不行。