从 PHP 生产站点获取错误的最佳方法是什么?

发布于 2024-07-09 14:45:37 字数 1219 浏览 11 评论 0原文

对于大多数生产站点,您希望尽快知道何时出现错误。 我的问题是如何最好地获取这些信息。

通常,最好通过电子邮件获取错误,因为我不会每天都坐着观察错误日志,直到出现错误为止——这是不可能的,因为我在不同的服务器上有 20 个或更多生产站点。 这些错误可能是任何错误,包括未设置的变量、收到的无效数据或查询错误。

目前,我已按照 PHP 网站上的示例进行操作,可在此处找到 。 因此,它会创建一个文本字符串以及一个 XML 文件,然后通过电子邮件发送该文件。 我对此进行了稍微修改,以保留所有错误,直到脚本结束,然后发送附有 XML 文件的电子邮件。 (由于循环中的错误,我已经使几个发送超过 500 000 封电子邮件的邮件服务器崩溃了。)大多数情况下,这都可以正常工作。 (我还创建了一个对象来执行所有错误处理。)

当 wddx_serialize_value() 需要处理大量数据时,就会出现问题。 然后,如果存在多个错误,那么,它实际上最终会使用大量内存,大多数时候超过了脚本允许使用的内存。

因此,在将其存储在变量中之前,我在 XML 文件中添加了一个附加的 gzcompress() 。 这很有帮助,但如果数据量非常大,它仍然会耗尽内存。 (在最近的一个案例中,它想要使用大约 2GB。)

我想知道还有哪些其他解决方案,或者您如何修改它以使其工作?

一些要求:

  • 它必须能够向我发送的不仅仅是错误消息,并且不应该让我登录到服务器来弄清楚发生了什么(这样我可以检查移动时间并确定这是否是紧急事项)
  • 所以有 需要限制发送的电子邮件数量。 最好的仍然是 1.
  • 它需要按照正常方式记录到文件

编辑: 我需要与错误相关的其他信息,而不仅仅是错误字符串。 我经常发现几乎不可能重现该错误,因为它是由用户输入引起的,除非获得更多信息,否则我不知道这一点。 我已尽力添加信息性错误,但您永远不知道用户将如何使用系统或他们将添加哪些垃圾数据。因此,我需要的不仅仅是错误文本/字符串。

编辑2:无法将错误记录到数据库,因为据我所知,数据库可能不存在。 需要一些几乎可以保证运行的东西。 另外,这些网站并不都在一台服务器上,而且我经常无法访问该服务器上的 cron(愚蠢的托管公司)。

For most production sites, you want to know when there has been an error as soon as possible. My question is how best to get this information.

Usually, it's probably best to get the errors in an email as I'm not going to sit every day and watch error logs until there is an error--this would be impossible since I have 20 or more production sites on different servers. These errors could be anything including, unset variables, invalid data received, or query errors.

At the moment I have followed the example on PHPs websites, found here. As a result, it creates a text string along with an XML file that is then sent by email. I have modified this slightly to keep all of the errors until the script ends and then send an email with the XML files attached. (I have crashed a couple mail servers sending over >500 000 emails because of an error in a loop.) Most of the time this works perfectly. (I have also created an object to do all of the error handling.)

The problem arises when there is a large amount of data for wddx_serialize_value() to processs. And then if there are multiple errors, then, it really ends up using a lot of memory, most of the time more than the script is allowed to use.

Because of this, I have added an addition gzcompress() to the XML file before storing it within the variable. This helps, but if the amount of data is very large, it still runs out of memory. (In a recent case it wanted to use around 2GB.)

I'm wondering what other solutions there are to this or how you have modified this to make it work?

So a few requirements:

  • it must be able to send more than just the error message to me and shouldn't make me login to the server to figure out what happened (so I can check when mobile and determine if it's an urgent matter)
  • there needs to be a limit on the number of emails sent. The best is still 1.
  • it needs to log to a file as per normal

Edit: I need other information related to the error, not just the error string. Often I find it's near to impossible to reproduce the error because it's caused by user input, which I don't know unless I get more information. I have tried my best to put in informative errors, but you never know how a user is going to use the system or what crap data they are going to put in. Therefore, I need more than just the error text/string.

Edit 2: Can't log errors to the database because for all I know the database may not be there. Need something that is pretty much guaranteed to run. Also, the websites are not all on 1 server and I often don't have access to cron on the server (stupid hosting companies).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

始于初秋 2024-07-16 14:45:37

我没有设置自定义错误处理程序,而是像往常一样让错误进入错误日志。 我设置了一个定期运行的 cron 并监视错误日志中的更改 - 如果发生更改,它会向我发送一封仅包含更改的电子邮件。 您可以改进此过程并解析更改以更好地满足您的需求 - 例如,仅向您发送高于特定级别的错误(例如 E_WARNING 及以上)。

Instead of setting a custom error handler, I let the errors go to the error log as usual. I set up a cron that runs periodically and monitors changes in the error log - if it changed, it sends me an email with the changes only. You can improve this process and parse the changes to better suit your needs - for example send you only errors above a certain level (such as E_WARNING and above).

挽手叙旧 2024-07-16 14:45:37

一种方法可能是在应用程序中进行适当的异常管理,即控制记录哪些错误。

每个引发的异常都会将错误详细信息记录在数据库中。

然后,您可以编写一个小应用程序来搜索错误数据库,也许只是一个适用于您所有网站的数据库。

这样您就可以避免出现大型不可读的日志文件,因为所有内容都已编入索引并且可以快速搜索。
当数据库变得太大时,您可以通过 cron 作业截断日志表。

One approach could be proper exception management in your application, i.e. to have control over which errors get logged.

Each raised exception would log the error details in a database.

Then, you could code a little application in order to search the error database, maybe just one for all your websites.

That way you avoid large unreadable log files, because everything is indexed and quickly searchable.
When your database gets too large, you can truncate your log tables via cron jobs.

你在看孤独的风景 2024-07-16 14:45:37

Anacron,一个通过电子邮件将更改发送到错误日志* 的 cron 作业,并且一个错误日志文件就足够了。
cron 作业可以在发送电子邮件之前完成所需的所有处理。

Anacron, a cron job that emails changes to the error log* and an error log file should suffice.
The cron job can do all the processing required before sending the email.

巴黎盛开的樱花 2024-07-16 14:45:37

我过去使用过的一件事是 epylog,它是一个用 python 编写的非常灵活的日志监控应用程序。 您可以将其设置为监视错误日志,并将错误(或部分错误)包含在通过电子邮件发送给您的日志摘要中。

我倾向于将更详细的错误数据存储在服务器上的平面文件中,并向您发送电子邮件告诉您检查日志。 监视错误目录或文件的更改并设置速率限制的 cron 作业将是最大程度地减少对正在运行的应用程序的影响的好方法。

One thing I have used in the past is epylog, it is a very flexible log monitoring app written in python. You can set it up to monitor your error logs and include the errors (or parts of them) in a log summary that is emailed to you.

I'd lean towards storing the more detailed error data in a flat file on the server and sending you an email to tell you to check the log. A cron job that watches the error directory or files for changes and has a rate limit set would be a good way to minimize impact on your running application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文