如果这听起来像是一个基本问题，请原谅，但我是网络开发的新手。
我们在多台服务器之间进行负载平衡。这些应用程序配置为使用 log4j 进行日志记录。他们各自写入各自服务器上的日志文件。这意味着研究问题意味着从所有这些服务器获取日志，这是乏味的，并且意味着要通过运维来控制负载平衡，并引入延迟。
这是网络应用程序日志记录的规范吗？或者是否有简单的解决方案可以将日志记录整合到一处？使开发人员可以轻松获取日志的标准做法是什么？
Excuse me if this sounds like a basic question, but I'm new to web development.
We load balance across several servers. The apps are configured to log using log4j. They each write to log files on their respective servers. That means that researching issues means getting logs from all of these servers, which is tedious, and means going thru Ops as they control the load balancing, and introduces delays.
Is this the norm for web app logging? Or are there easy solutions to consolidating logging in one place? What are standard practices for making logs easily available to developers?
发布评论
评论（5）
使用 JDBC 附加程序记录到 SQL （或替代版本）而不是文件。
Log to SQL using the JDBC appender (or an alternative version) instead of files.
您可以执行多种日志记录，并且这些日志记录是自动可用的。
一些类型是：
对于这些内容，请授予访问权限，以便您可以远程访问它们，并根据需要进行整理/检查。
获得对文件夹的访问权限，以便您可以自己分析这些文件夹。
我建议记录到数据库。 （尽管这些需要经常修剪/总结。）
如果记录到数据库失败，则会记录到机器日志。
注意：这可能会对性能产生影响，因此请注意您执行的日志记录量。
如果运营部门不愿意让您直接访问，请查看是否可以将这些文件例行转储到您可以访问的位置。
There is a wide variety of logging you can do, and which is available automatically.
Some types are:
For these, get access granted so you can access them remotely, and collate/examine as required.
Get access granted to the folders, so you can analyze these yourselves.
I recommend logging to a database. (Although these need to be pruned/summarized frequently.)
If the logging to the database fails, logging to machine logs occurs.
Note: This can have a performance impact, so be careful how much logging you do.
If operations is unwilling to give you direct access, see if a routinue dump of these files can be done to a location you can access.
Log4J 有一个 JMS 附加程序 （因此您可以将日志发送到消息队列 - 并不像听起来那么愚蠢，具体取决于您需要执行多少/何种处理！）和 syslog 附加程序（本地或远程）。其中任何一个都将帮助您在单个位置收集日志。 Syslog 附加程序可能是您将信息收集到一个地方的最佳选择，因为 Unix 系统已经使用 syslog 很长时间了，并且有很多稳定的功能可供您利用。
根据您的流量，记录到数据库可能很难扩展，除非您擅长批量插入。我建议您将这些内容保存在平面文件中（当然是合并的），这样您就可以灵活地将它们一次性导入到数据库中，或者尝试诸如 Hadoop（许多基于解析日志文件的示例）- 当然，前提是您有足够的数量来证明这种复杂性。
Log4J has both a JMS appender (so you can send logs to a message queue - not as dumb as it sounds depending on how much/what kind of processing you need to do!) and a syslog appender (local or remote). Either of these will help you collect logs at a single location. Syslog appender might be your best bet just to collect stuff in one place as Unix-ish systems have been doing syslog for a very long time and there are lot of stable features there of which you can advantage.
Logging to a database can be difficult to scale depending on your traffic unless you are smart about batching inserts. I would recommend you keep this stuff in flat files (merged, of course) somewhere so you have the flexibility to import them into the database later in one go, or experiment with stuff like Hadoop (lots of examples based around parsing log files) - provided you have the volume to justify this complexity of course.
我们有一个具有强大日志记录的网络农场，以下是它的实施方式。
每个 Web 应用程序都会生成日志事件消息。使用 MSMQ，这些消息被发送到托管在单独计算机上的专用队列。这台机器有一个应用程序，可以将消息出队并将其写入 Sqlite 数据库。
使用 MSMQ 将 Web 应用程序与日志服务器分离。如果服务器离线，则消息将保留在 Web 服务器上，直到重新建立连接为止。 MSMQ 负责将消息移动到目标服务器。这样，网站就可以不间断地继续执行其操作。
日志服务器有自己的 Web 界面来查询日志数据库，并且还可以接收来自其他应用程序的日志消息。
我们为每条消息分配一个分类。对于具有致命错误分类的消息，日志服务器会自动生成一封电子邮件发送给支持团队。其他非致命消息和跟踪消息仅记录到数据库中以进行汇总报告。
We have a web farm with robust logging and here is how it is implemented.
Each web application generates logging event messages. Using MSMQ these messages are sent to a private queue hosted on a separate machine. This machine has an application that dequeues the messages and writes them to a Sqlite database.
Using MSMQ decouples the web application from the logging server. If the server is offline the messages sit on the web server until the connection is re-established. MSMQ handles moving the messages to the destination server. This way the web site can continue to do its thing without interruption.
The logging server has its own web interface to query the logging database and can receive log messages from other applications as well.
We assign a classification to each message. For messages with a fatal error classification, the logging server generates an email automatically to the support team. Other non-fatal messages and trace messages are just recorded to the database for aggregate reporting.
使日志更容易访问的一种可能选择是将它们写入通过NFS共享的驱动器。您可以对每个服务器的单独目录进行一些处理，但要在要评估日志的服务器上显示这两个目录。
One possible option for making logs more easily accessible is to write them to a drive shared via NFS. You could do some juggling with separate directories per server, yet have both of those directories visible on the server on which you want to evaluate the logs.