基于应用程序的错误记录/处理？
我们有一个 Web 服务器，我们将在其上启动许多应用程序。在服务器级别，我们在 Hyperic 的帮助下设法解决了错误处理问题，以便在数据库/memcached 服务器出现故障时通知负责人。
但是，我们仍然需要在客户注意到之前处理应用程序级别上发生的最终错误和日志事件，以改进客户的应用程序。
那么，什么是一个好的解决方案呢？
如果我们同时运行大量应用程序，使用 PHP 自己的错误日志很快就会变得堵塞。如果您喜欢结构，这可能不是最好的选择。
一种想法是构建一个场外轻量级错误处理应用程序，该应用程序具有 REST/JSON API，用于接收加密和序列化的错误消息数组并将其存储到数据库中。也许它也可以根据错误的严重程度直接输入到我们的错误跟踪器中。
可能会花费几个小时，但这似乎是一个非常脆弱的解决方案，我确信已经有更好、更可靠的替代方案了。
谢谢，
We have a web server that we're about to launch a number of applications on. On the server-level we have managed to work out the error handling with the help of Hyperic to notify the person who is in charge in the event of a database/memcached server is going down.
However, we are still in the need of handling those eventual error and log events that happen on application level to improve the applications for our customers, before the customers notices.
So, what's then a good solution to do this?
Utilizing PHP:s own error log would quickly become cloggered if we would run a big number of applications at the same time. It's probably isn't the best option if you like structure.
One idea is to build a off-site lightweight error-handling application that has a REST/JSON API that receives encrypted and serialized arrays of error messages and stores them into a database. Maybe it could, depending on the severity of the error also be directly inputted into our bug tracker.
Could be a few well spent hours, but it seems like a quite fragile solution and I am sure that there's better more-reliable alternatives out there already.
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为什么使用 PHP 自己的 error_log 很快就会变得“堵塞”？如果一切顺利，你不会看到很多错误，对吗？
如果您问我的话，构建一个单独的应用程序，尤其是使用 API 的应用程序，仅用于错误报告会增加错误日志记录的许多可能的故障点。您也许可以构建一个应用程序来检查各种服务器/不同应用程序上现有的错误日志，以便能够在某种错误仪表板中显示它们，这样您就可以看到什么时候真正出了问题。
但我也很想看看其他人可能会提出什么建议，我自己还没有考虑太多。
Why would using PHP's own error_log quickly become 'cloggered'? If all goes well you won't see many errors, correct?
Building a separate application, especially one using an API, just for error reporting adds a lot of possible points of failure for error logging if you ask me. You could perhaps build an application that checks the existing error logs on various servers / for different applications to be able to display them in a sort of error dashboard, so you can see when things are REALLY going wrong.
But I'm interested to see what others might suggest as well, I haven't thought about it thát much yet for myself.
我们实际上
tail -f服务器的 php 错误日志来获取各种输出，但也捕获了很多我们自己抛出的异常。通过抛出自定义异常，您可以让它（当然基于优先级）写入您的数据库、日志流、错误跟踪器和/或邮寄那些负责该模块的人。当然，您应该记录引发异常的原因（例如，您所使用的方法的var_export()/serialize()的func_get_args()抛出一个异常。将异常消息设置为巨大，因为它会拯救你除此之外，我们在异常有点过大的情况下使用
Zend_Log（例如，如果给该方法的参数应该被弃用，我们可能会记录一些debug_backtrace()来查看该调用来自何处。这可以扩展到制作昂贵调用图等的程序，但这是一个旁注:)我最好的提示：知道您的应用程序可以在哪里。失败并且不能失败时，搜索该错误要容易得多，确保基于外部服务引发的错误被解释为这样……
说实话，我认为这种想法。 （Error-API/-Service on app.level）有点奇怪：如果你确切地知道如何处理错误，你怎么能防止错误呢？你不会避免/自动化它吗？
We actually
tail -fthe server's php error log for various outputs, but also catch a lot of exceptions we throw ourselves. By throwing a custom exception, you could have it (based on priority of course) write to your database, a log stream, your bug tracker and/or mail those-responsible-for-that-module. Of course you should log why the exception was raised (for example,var_export()/serialize()thefunc_get_args()of the method you threw an exception in. Make the exception message huge, since it will save you.In addition to this, we use
Zend_Logwhere exceptions are a bit overkill (for example if the argument given to the method should be deprecated, we might log a bit ofdebug_backtrace()to see where that call came from. This could be extended to programs making graphs of expensive calls etc, but that's a sidenote :)My best tip: know where your application could fail and where it can not, it's so much easier to search for that error. Make sure errors that are raised based on external services are interpreted as such.
... and to be honest, I think this kind of thinking (Error-API/-Service on app. level) is a bit weird: how could you prevent an error if you knew exactly how to handle it? Wouldn't you avoid/automatize it?
您可以使用
set_exception_handler和set_error_handler来收集更具体的信息并以减轻“堵塞”的方式进行报告。您可以为每个客户端或应用程序创建不同的文件，引入您自己的代码，以便通过错误解析脚本轻松处理，等等。我会小心地在错误处理过程中引入额外的代码或基础设施。它必须非常可靠，这样您才能相信所获得的信息。直接向数据库报告错误？数据库连接错误怎么办？ （等等）
You could use
set_exception_handlerandset_error_handlerto gather more specific info and report it in a way that will alleviate the 'cloggering'. You could do different files for each client or application, introduce your own codes that allow for easy processing by an error parsing script, etc.I'd be careful about introducing extra code or infrastructure to the error-handling process. It needs to be super solid so you can trust the info you get. Reporting errors directly to the database? What about database connection errors? (and on and on)
您要搜索的是 PHP 错误处理函数：http://de. php.net/manual/en/ref.errorfunc.php
特别有趣的是 set_error_handler()，它允许您完全覆盖 PHP 的内部错误处理程序。
这样，您可以为每个应用程序创建自己的日志/向管理员发送电子邮件/将错误信息保存到数据库/告诉用户管理员已收到通知或其他什么。
通过返回 true 或 false，您还可以控制 PHP 内部错误处理程序是否应该在您的函数之后运行。
What you're searching for are PHPs error handling functions: http://de.php.net/manual/en/ref.errorfunc.php
Especially interesting would be set_error_handler() that allows you to completely override PHPs internal error handler.
With that you can make your own logs per application / send emails to admins / save error info to a db / tell users that an admin has been notified or whatever.
By either returning true or false you can also control wether PHPs internal error handler should run after your function or not.