I am designing a error logging feature so our servers (each donig different things) can have a central data store for logging errors.
我正在设计一个错误记录功能,所以我们的服务器(每个不同的东西)可以有一个*数据存储来记录错误。
Would it be a good idea to have the various applications writing to the error log file using a WCF service, or is that a bad idea?
让各种应用程序使用WCF服务写入错误日志文件是不是一个好主意,或者这是一个坏主意?
they can do it just by ADO.NET to the database, which I think is the simpler route.
他们只能通过ADO.NET到数据库,我认为这是更简单的路径。
3 个解决方案
#1
1
How about having a look at syslog? It was made for exactly that purpose.
看看syslog怎么样?它是为了这个目的而制作的。
#2
1
I'd say just log to your local data store. The advantages are :
我只想登录到您的本地数据存储。优点是:
- Speed - it's pretty rapid to just dump your chosen error report to an existing data connection.
- Tracability - What happens if you have an error in your service? You lose all ability to chase down errors on all servers.
- Simplicity - If you change the endpoint for your errors service, you have to update every other application that uses the error service.
- Reporting - Do you really want to trawl through error reports from tens / hundreds of applications in one place when you could easily find them in the data store local to the app?
速度 - 将您选择的错误报告转储到现有数据连接非常快速。
可追溯性 - 如果您的服务出错,会发生什么?您将失去在所有服务器上追踪错误的所有能力。
简单性 - 如果更改错误服务的端点,则必须更新使用错误服务的每个其他应用程序。
报告 - 当您可以在应用程序本地的数据存储中轻松找到它们时,您是否真的想在一个地方搜索来自数十/数百个应用程序的错误报告?
Of course, any of these points could be viewed from the other side, these are just my opinions.
当然,任何一点都可以从另一方面看,这些只是我的意见。
#3
0
We're looking at a similar approach, except for audit logging as well as error handling.
我们正在研究类似的方法,除了审计日志记录和错误处理。
Looking at using WCF over netTcp, also looking at using the event log, but that seems to require high trust settings, and maybe performance issues.
看着在netTcp上使用WCF,也看着使用事件日志,但这似乎需要高信任度设置,也许还有性能问题。
Not convinced by ZombieSheep's objections:
不相信ZombieSheep的反对意见:
-
It's pretty rapid to dump your chosen error report over an existing WCF connection. Seriously. Plus, you can do it async/queued. Not a key factor for me.
将您选择的错误报告转储到现有的WCF连接上非常快速。认真。另外,您可以执行异步/排队。对我来说不是一个关键因素。
-
You log to the central service and the local service. When the erroer service comes back on line, you poll your machines for events since the last timestamp. Problem solved.
您登录到*服务和本地服务。当erroer服务恢复联机时,您可以在机器上轮询自上一个时间戳以来的事件。问题解决了。
-
Use a dns alias, and don't change the path - the way you should do internal addressing anyway IMO.
使用dns别名,并且不要改变路径 - 无论如何应该进行内部寻址的方式IMO。
-
What if you have multiple apps on a single machine? What if you want to see the timing of errors across multiple apps?
如果您在一台计算机上有多个应用程序怎么办?如果您想查看多个应用程序的错误时间,该怎么办?
#1
1
How about having a look at syslog? It was made for exactly that purpose.
看看syslog怎么样?它是为了这个目的而制作的。
#2
1
I'd say just log to your local data store. The advantages are :
我只想登录到您的本地数据存储。优点是:
- Speed - it's pretty rapid to just dump your chosen error report to an existing data connection.
- Tracability - What happens if you have an error in your service? You lose all ability to chase down errors on all servers.
- Simplicity - If you change the endpoint for your errors service, you have to update every other application that uses the error service.
- Reporting - Do you really want to trawl through error reports from tens / hundreds of applications in one place when you could easily find them in the data store local to the app?
速度 - 将您选择的错误报告转储到现有数据连接非常快速。
可追溯性 - 如果您的服务出错,会发生什么?您将失去在所有服务器上追踪错误的所有能力。
简单性 - 如果更改错误服务的端点,则必须更新使用错误服务的每个其他应用程序。
报告 - 当您可以在应用程序本地的数据存储中轻松找到它们时,您是否真的想在一个地方搜索来自数十/数百个应用程序的错误报告?
Of course, any of these points could be viewed from the other side, these are just my opinions.
当然,任何一点都可以从另一方面看,这些只是我的意见。
#3
0
We're looking at a similar approach, except for audit logging as well as error handling.
我们正在研究类似的方法,除了审计日志记录和错误处理。
Looking at using WCF over netTcp, also looking at using the event log, but that seems to require high trust settings, and maybe performance issues.
看着在netTcp上使用WCF,也看着使用事件日志,但这似乎需要高信任度设置,也许还有性能问题。
Not convinced by ZombieSheep's objections:
不相信ZombieSheep的反对意见:
-
It's pretty rapid to dump your chosen error report over an existing WCF connection. Seriously. Plus, you can do it async/queued. Not a key factor for me.
将您选择的错误报告转储到现有的WCF连接上非常快速。认真。另外,您可以执行异步/排队。对我来说不是一个关键因素。
-
You log to the central service and the local service. When the erroer service comes back on line, you poll your machines for events since the last timestamp. Problem solved.
您登录到*服务和本地服务。当erroer服务恢复联机时,您可以在机器上轮询自上一个时间戳以来的事件。问题解决了。
-
Use a dns alias, and don't change the path - the way you should do internal addressing anyway IMO.
使用dns别名,并且不要改变路径 - 无论如何应该进行内部寻址的方式IMO。
-
What if you have multiple apps on a single machine? What if you want to see the timing of errors across multiple apps?
如果您在一台计算机上有多个应用程序怎么办?如果您想查看多个应用程序的错误时间,该怎么办?