我正在使用Django开发一个类似于项目经理的应用程序。因此，系统应该能够存储有关所有内容的信息。当我说出所有内容时，我指的是用户执行的操作，执行操作时发生的错误等。 我有一个类Log，它的一个属性叫做action_type，这个属性指定刚刚发生了什么样的动作。我应该有5种类型：
INFO： 此日志存储与用户操作相关的信息，例如创建项目，创建其他用户等。
DEBUG： 应存储开发人员发表的评论，以便他们检测错误。
错误： 显示系统中发生的错误，但不会影响系统的功能。
警告： 这是针对潜在的破坏性行为。
致命： 意外错误，异常和安全漏洞。
我只能为INFO提供逻辑日志。
你能否告诉我一些合理的日志，我应该包含在这个和其他类别中？
答案 0 :(得分：1)
答案将在很大程度上取决于您的应用程序的确切功能，但我的基本方法是：
每当您准备好记录事件时，只需考虑事件，它就会清楚它属于哪里。它会杀了你的申请吗？这是致命的。它能阻止某些东西正常工作吗？这是一个错误。 可以它可以阻止某些工作，这次我们真的很幸运吗？这是一个警告。有人关心吗？信息。否则，如果您仍需要记录它，则必须进行调试。
在您的特定环境中，听起来您可能只是尝试记录用户操作。如果是这种情况，唯一可能致命的行为就是你没有提供撤销选项的行为（或者，我想，如果用户能够通过你的订购钢琴长凳和一段长绳子应用）。我也无法想象任何来自用户操作的调试级日志。因此，我假设除了用户操作之外，您还将记录代码级事件。
致命： 这应该仅在您的应用程序实际崩溃时显示在日志中，并且可能与500个响应一起出现。你可以在你的wsgi应用程序中以一个全能的方式生成这些，只有当这个过程本来就已经死了。
错误： 可能与http错误响应相关联。这通常是由应用程序外部的错误引起的。代码中发生的事情可能是预期的并且＆lt; =警告级别，或意外和致命的。错误可能是来自用户在网址中输入拼写错误的404，表单提交上的验证错误或身份验证错误。从另一个方向，您可能会从您联系的远程Web服务或来自操作系统的IO错误返回错误。
警告： 对于那些没有破坏任何东西的东西，但如果你坚持下去，这可能会让你感到厌烦。示例使用不推荐使用的api以及由于默认值（时区，字符编码等）而无法使用的任何地方。也许某些输入值也会产生警告，比如过去设置截止日期。
信息： 一般，健康的运营。有人创建了数据库行（新项目或任务？），创建了帐户，登录或注销，套接字成功打开等等。
DEBUG： 正如它所说的那样。代码工作正常后通常会关闭的输出。方法入口/出口，对象实例化，代码中各个点的字段值，计数器。无论你需要弄清楚为什么你的程序正在崩溃，当你正在处理它时。