Questions tagged «logging»

计算机数据记录是在计算机程序中记录事件的过程,通常在一定范围内记录事件,以便提供可用于了解系统活动和诊断问题的审核跟踪。

6
尝试/捕获/记录/重新抛出-是反模式吗?
我可以看到几篇文章,其中强调了在中心位置或过程边界处处理异常的重要性,这是一种好的做法,而不是乱丢try / catch周围的每个代码块。我坚信我们大多数人都了解它的重要性,但是我仍然看到人们仍然使用catch-log-threrow反模式,主要是因为在任何异常情况下,为了简化故障排除工作,他们想记录更多特定于上下文的信息(例如:方法参数)通过),方法是将方法包装在try / catch / log / rethrow周围。 public static bool DoOperation(int num1, int num2) { try { /* do some work with num1 and num2 */ } catch (Exception ex) { logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); throw; } } 在保持异常处理良好实践的同时,有没有正确的方法来实现这一目标?我听说过类似PostSharp的AOP框架,但是想知道这些AOP框架是否有任何不利或主要的性能成本。 谢谢!

5
数据库表何时应使用时间戳记?
首先要注意的是,我认为这个问题可能属于数据库交换,但我认为它总体上与编程解决方案有关,而不是与数据库有关。如果人们认为那是最好的,它将转向数据库交换。 我想知道何时在数据库表中添加创建和更新的时间戳? 第一个明显的答案是,如果任何业务逻辑需要知道什么时候进行了更新(例如事务完成日期等),则必须将其输入。 但是非业务逻辑案例呢?例如,我可以想到这样的场景:了解行更改的日期时间以帮助进行故障查找是非常有用的,例如某些业务逻辑发生故障并查看相关的数据库行,从而有可能在更新之前确定一行正在更新导致错误的另一行。 在这种用例下,给每个表一个更新并创建时间戳是有意义的(也许最琐碎的枚举表可能不会被应用程序的任何部分更新)。 为每个表提供时间戳肯定是快速停顿数据库的好方法(尽管可能是错误的)。 那么什么时候数据库表应该使用创建和更新时间戳?

8
我应该在抛出异常的构造函数上记录错误吗?
我花了几个月的时间来构建应用程序,然后才发现出现了一种模式: logger.error(ERROR_MSG); throw new Exception(ERROR_MSG); 或者,在捕捉时: try { // ...block that can throw something } catch (Exception e) { logger.error(ERROR_MSG, e); throw new MyException(ERROR_MSG, e); } 因此,无论何时我抛出或捕获异常,都将其记录下来。实际上,这几乎是我在应用程序上所做的所有日志记录(除了一些用于应用程序初始化的操作)。 因此,作为一名程序员,我避免重复。因此,我决定将logger调用移至异常构造,因此,每当构建异常时,都会记录事件。当然,我也可以创建一个ExceptionHelper来为我抛出异常,但是这会使我的代码更难以解释,更糟糕的是,编译器无法很好地处理它,而没有意识到对该成员的调用会立即扔。 那么,这是一种反模式吗?如果是这样,为什么?

2
在全部捕获或基本异常类中记录异常是否更明智?
我正在重构一个相当大的Web应用程序。主要问题之一是不一致的错误处理,我正在尝试提出一个明智的策略。我已经通过set_error_handler创建了一个自定义错误处理程序,该处理程序从本质上转变了ErrorExceptions中的 PHP错误以及一个直接从Exception继承的自定义基本异常类。 在生产环境中,我正在通过set_exception_handler使用通用异常捕获功能,并且将要添加异常记录*的功能。我的难题是在基本异常类或全部捕获中执行实际日志记录的位置。 我想到了将其记录在全部功能中的几个原因: 代码中有很多异常需要转换为基本异常类的适当子代。在此之前,并非所有异常都会被记录。 总括而言,以某种方式感到更自然,基本异常类不应该仅仅这样做。(这可能是一个单一的责任原则,但可能只是一种误导) 以及登录基本异常类的原因之一: 目前,全部收集仅用于生产。将其引入我们的其他环境(开发,测试)很容易,但是这需要进行一些调整,因为错误在每个环境中的处理方式不同,在生产中将其转换为404/503错误页面。 在哪里记录异常有可接受的做法吗? *日志记录将首先涉及写入文本文件,并且可能会演变成发送某些类型异常的邮件。 @unholysampler的回答提示了一些说明: 我面对的是2 * 10 ^ 6 sloc代码库,其中包含许多我无法控制的第三方内容,而我确实有一些代码可以控制PHP中的preddates异常。而且还有一些糟糕的最新代码,我们正从长期的沉重压力中恢复过来,在这些压力下,我们实际上不得不停止思考并被黑了。 我们正在积极进行重构以解决所有不一致问题,并引入明智的错误处理方法,但这将需要一些时间。在达到正确处理错误的程度之前,我对该怎么办更感兴趣。在某个时候,我可能会问另一个关于明智的例外策略的问题。 记录背后的主要动机是,每当生产中发生任何问题时,都会在我的手机上收到一封电子邮件。我不在乎数据转储是否会很大,如果确实如此,我将有一份cron作业,不时地删除旧的。

3
为什么要创建一个Logger对象,而不是在整个应用程序中使用静态日志记录方法?
以一个简单的Ruby on Rails应用程序为例。它Logger在应用程序加载过程中创建一个对象: # in environment.rb config.logger = Logger.new(<STDOUT | file | whatever>) # and in our application we use this object logger.warn "This process is taking too long to process. Optimization needed." 我的问题是,为什么我们不使用类方法(或静态方法)进行日志记录?会不会Logger.warn比Logger.new.warn?或至少Logger.warn看似直观Logger.new.warn。 即使Logger.new是单例对象,它提供什么好处?

6
管理异常的错误日志记录的最佳方法是什么?
介绍 如果网站或系统上发生错误,则将其记录下来并向用户显示带有错误代码的礼貌消息当然是有用的。 而且,如果您有许多系统,则不希望散布这些信息-最好有一个集中的位置。 在最简单的级别上,所需要做的就是增加ID和错误详细信息的序列化转储。(可能的“集中位置”是电子邮件收件箱。) 另一方面,也许是一个完全规范化的数据库,该数据库还允许您按下按钮并查看每天的错误图,或者确定系统X上最常见的错误类型是服务器A是否拥有更多的数据库。服务器B的连接错误,等等。 我在这里指的是通过远程系统记录代码级错误/异常- 而不是 “基于人的”问题跟踪,例如使用Jira,Trac等进行的跟踪。 问题 我正在寻找使用过这种系统的开发人员的想法,特别是关于以下方面的想法: 您不能没有哪些基本功能? 真正节省您时间的功能有什么好处? 哪些功能似乎是个好主意,但实际上没有用吗? 例如,我想说一个“显示重复项”功能很重要,它可以识别多次出现的错误(而不必担心可能会有所不同的“不重要”细节)。 用于“在[Jira / etc]中为此错误创建问题”的按钮听起来像是节省了时间。 再次重申一下,我所追求的是使用过此类系统的人们的实践经验,最好是对功能令人敬畏/可怕的原因进行备份。 (无论如何,如果要进行理论化,至少要这样标出答案。)

5
何时开始编写异常处理,日志记录
您何时开始编写异常处理代码?您何时开始编写日志记录语句。 出于阐述这个问题的目的,让我们假设我们使用Log4net日志记录在.NET平台上,但是可以以一般方式随意回答。 解决方案:Windows窗体项目。项目:UI,BusinessRules,DataHandlers 因此,您是否打算编写DataHandlers来进行数据处理,例如首先创建,读取,更新,删除。 然后遵循您的业务规则 然后是您的用户界面或以上的任何其他排列。 测试您的应用程序的功能。 而再开始写你的异常处理代码和最后日志记录代码? 在什么时候开始编写您的异常处理代码? PS:在书Clean Code中,他们说首先写您try-catch-finally块。那促使我提出这个问题。

6
记录规则和建议?
在我的组织中,我们整理了一些有关日志记录的规则/准则,我想知道您是否可以添加或评论。 我们使用Java,但您可能会对Loggin进行一般性评论-规则和建议 使用正确的日志记录级别 错误:出了点问题,需要立即修复 警告:此过程可以继续进行而不进行修复。应用程序应容忍此级别,但警告应始终得到调查。 INFO:重要过程完成的信息 调试。仅在开发期间使用 确保您知道要记录的内容。 避免日志记录影响应用程序的行为 日志记录的功能应该是在日志中写入消息。 日志消息应具有描述性,清晰,简短和简洁。 故障排除时,废话消息的使用很少。 将正确的属性放入log4j 输入正确的方法和类是自动编写的。 例: 日期文件-web log4j.rootLogger=ERROR, DATEDFILE log4j.logger.org.springframework=INFO log4j.logger.waffle=ERROR log4j.logger.se.prv=INFO log4j.logger.se.prv.common.mvc=INFO log4j.logger.se.prv.omklassning=DEBUG log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender log4j.appender.DATEDFILE.layout=org.apache.log4j.PatternLayout log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n log4j.appender.DATEDFILE.Prefix=omklassning. log4j.appender.DATEDFILE.Suffix=.log log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/ 日志值。 请记录应用程序中的值。 日志前缀。 声明日志记录是从应用程序的哪一部分写入的,最好带有项目约定前缀的内容,例如 PANDORA_DB 文字量。 注意不要有太多的日志文本。它会影响应用程序的性能。 登录格式: -有几种与log4j一起使用的变体和方法,但是当我们记录异常时,我们希望统一使用以下格式: logger.error("PANDORA_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", …
13 java  logging 

2
Logger.getLogger(MyClass.class)是初始化log4j记录器的最佳方法吗?
此Mkyong教程建议以这种方式初始化记录器: @Controller public class WelcomeController { private static final Logger logger = Logger.getLogger(WelcomeController.class); // etc } 现在,假设您使用的所有其他类都具有记录器,它们将以相同的方式初始化其记录器。 我的问题是-这是最好的方法吗?似乎...重复。
13 java  logging 

1
登录到文件还是数据库表?
我正在开发一个使用MS SQL来处理各种数据的Web应用程序:包括用户,用户帐户,用户许可证,许可证价格,发票。 我需要记录用户对系统的实时使用情况,并将其用于每月计费:例如,每当用户获得特定页面/ URL时就记录一次,并在月底根据所获取的页面数向用户计费。 是否应该将这些日志事件写入MS SQL数据库的表中? 是否应将这些日志事件写入非SQL的仅追加日志文件? 我应该为每个用户将这些日志事件写入不同的日志文件吗? 这不是一个特别庞大的网站:例如,最多10,000个用户,每个用户平均每天进行5个可记录事件=> 50,000个事件/天= 30个事件/分钟= 18,000,000个事件/年。 我问是因为这两种选择似乎都是可行的,而且我看不出是否有明显的优势。 与计费事件相关的数据很简单,例如: 用户ID(SQL中与Users表的外键关系) 日期和时间 计费页面的URL 我对这个问题的回答如下: 将日志写入数据库表的一些好处: 关系完整性:例如,记录的事件与有效的用户ID相关联(通过将用户ID定义为表之间的外键) 易于阅读的账单:例如SELECT COUNT GROUP BY,获得每个用户的日志事件数的计数 写入日志文件的一些好处: 性能更容易:SQL较少使用,例如仅用于用户登录事件,而大多数仅用于读取 易于管理:通过移动旧日志文件而不是通过从数据库中删除/存档,例如在年底时更易于归档旧数据 如果我的答案有误,请告诉我;或夸大某事的重要性;或忘记了一些重要的考虑。 和/或,如果与我的答案不同,请告诉我您的答案是什么。

2
我应该如何处理记录器故障?
在公司的一些应用程序中,我们使用自定义记录器。它相当健壮,尽管将来我们可能会用NLog之类的东西来代替它。记录器的任务之一是记录应用程序中遇到的任何异常。 我一直担心的一个问题是,记录器中的异常处理允许出现静默故障。也就是说,如果未针对给定的异常编写日志(由于记录器中的错误),那么我应该如何处理该异常并(以某种方式)将异常记录到记录器本身中? 假设WriteLog函数引发异常。我应该尝试多次调用该函数还是直到不引发异常之前?我是否应该尝试使用记录器编写引发的异常(这很可能会导致异常完全消失……)?除了第一次实现自定义记录器时,我很幸运没有遇到这种情况。另一方面,我目前无法知道记录器是否未能记录应用程序异常(由于其自身的异常)。 我已经尝试过在线和在一些SE网站上进行搜索,但是到目前为止,由于所有帖子都处理记录器中的错误(但不记录潜在的异常以及如何记录它们)或记录器外部的异常,到目前为止,这种方法是徒劳的。

8
是否可以将代码完全记录在业务逻辑之外?
借助AOP,我可以从业务逻辑中删除日志记录代码。但是我认为它只能用于记录简单的事物(即记录方法的进入/退出和参数值)。 但是,如果我需要在业务逻辑中记录一些内容,该怎么办?例如 public void SomeDomainMethod(string id) { //Get user by Id User user = Users.Get(id); if (user == null) { Log.Warn("user is not existed"); //<----------------- Log A throw new InvalidOperationException("user is not existed"); } //Step 1 while(true) { //do something } Log.Info("Step 1 is completed"); //<----------------- Log B //Step 2 …

6
需要使我的代码对团队中的其他程序员更具可读性
我正在delphi中工作一个项目,并且正在为该应用程序创建安装程序,主要包括三个部分。 PostgreSQL安装/卸载 myapplication(使用nsi创建myapplication的安装程序)安装/卸载。 通过脚本(批处理文件)在Postgres中创建表。 一切正常运行,但是如果出现故障,我创建了一个LogToFileger,它将在过程的每个步骤中记录LogToFile, 如下所示 LogToFileToFile.LogToFile('[DatabaseInstallation] : [ACTION]:Postgres installation started'); 函数LogToFileToFile.LogToFile()This将内容写入文件。这工作得很好,但是问题是这使代码混乱了,因为它变得很难读取代码,因为一个ca只能LogToFileToFile.LogToFile()在代码中到处看到函数调用。 一个例子 if Not FileExists(SystemDrive+'\FileName.txt') then begin if CopyFile(PChar(FilePathBase+'FileName.txt'), PChar(SystemDrive+'\FileName.txt'), False) then LogToFileToFile.LogToFile('[DatabaseInstallation] : copying FileName.txt to '+SystemDrive+'\ done') else LogToFileToFile.LogToFile('[DatabaseInstallation] : copying FileName.txt to '+SystemDrive+'\ Failed'); end; if Not FileExists(SystemDrive+'\SecondFileName.txt') then begin if CopyFile(PChar(FilePathBase+'SecondFileName.txt'), PChar('c:\SecondFileName.txt'), False) then LogToFileToFile.LogToFile('[DatabaseInstallation] …

7
从设计的角度来看,记录的最佳实践是什么?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 我想将日志记录添加到当前正在处理的应用程序中。我之前添加了日志记录,这不是这里的问题。 但是从面向对象语言的设计角度来看,遵循OOP和模式的最佳记录实践是什么? 注意:我目前正在C#中执行此操作,因此显然欢迎使用C#中的示例。我也想看看Java和Ruby中的示例。 编辑:我正在使用log4net。我只是不知道插入它的最佳方法是什么。

4
异步记录-应该怎么做?
在我从事的许多服务中,已经完成了许多日志记录。这些服务是(大多数)使用.NET EventLogger类的WCF服务。 我正在改善这些服务的性能,并且我认为异步记录将有益于性能。 我不知道当多个线程要求登录时会发生什么,是否会造成瓶颈,但是即使不是这样,我仍然认为它不应该干扰正在执行的实际进程。 我的想法是,我应该调用现在调用的同一日志方法,但是在继续实际过程的同时,使用新线程来执行此操作。 关于此的一些问题: 可以吗 有没有缺点? 是否应该以其他方式完成? 也许它是如此之快,甚至不值得付出努力?
11 logging 

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.