我有一个 Web 应用程序，我想审核该应用程序上的大多数用户操作，例如登录、插入数据库、更新数据库、引发异常等。
我的一位高级人员建议使用队列来提高性能，因此，您只需将一个事件放入队列，然后它就会自动处理，而无需等待它被处理。
您有什么建议？我应该如何处理它们？将它们排队没有问题，但我不确定在没有主体调用方法的情况下将如何处理它们。
我正在使用 C# 和 .NET 4.0
I have a web application, and I would like to audit most of the users actions on the application, for example login, insertion to db, update to db, fired exceptions, etc.
One of my senios suggested using a queue for faster performance, so you just enqeue an event and it is then processed automatically without having to wait for it to be processed.
What are your suggestions? How should I process them? Enqueueing them is no problem, but I'm not sure how they will be processed then without no body calling a method.
I am using C# with .NET 4.0
发布评论
评论（5）
我一直在开发一个可能有帮助的库。
Audit.NET 及其用于审核不同系统的扩展 (WCF，MVC，WebApi, EF）并将日志存储在不同的数据存储中（< a href="https://github.com/thepirat000/Audit.NET/tree/master/src/Audit.NET.SqlServer#auditnetsqlserver" rel="noreferrer">SQL，MongoDB, DocumentDB、文件、EventLog）将为您提供灵活配置您想要审核的内容以及您想要存储审核日志的位置。
I've been working on a library that can probably help.
Audit.NET and its extensions to audit different systems (WCF, MVC, WebApi, EF) and store logs in different data storages (SQL, MongoDB, DocumentDB, File, EventLog) will give you the flexibility to configure what do you want to audit and where do you want to store the audit logs.
我只是推荐一个稳定且受支持的现成日志框架。您是否考虑过使用日志框架，例如 log4net？
如果您愿意，您可以编写一个自定义附加程序来登录 MSMQ。
I would simply recommend an off the shelf logging framework that is stable and supported. Have you considered a logging framework, like log4net?
You could write a custom appender for logging into MSMQ if you'd like.
另一种记录器称为 TracerX。它是用 C# 编写的，快速且灵活。由于源代码可用，这意味着您可以根据需要对其进行修改。它配备了一个允许过滤输出的查看器。
https://github.com/MarkLTX/TracerX 以及一篇有关如何使用它的文章：
http://www.codeproject.com/KB/dotnet/TracerX.aspx
An alternative logger is called TracerX. It is written in C# and fast and flexible. Because the source code is available it means you can modify it as you wish to suit your needs. It comes with a viewer that allows for filtering the output.
https://github.com/MarkLTX/TracerX and an article on how to use it:
http://www.codeproject.com/KB/dotnet/TracerX.aspx
实际上有两个有趣的主题：
异步日志记录可以将繁重的处理速度加快 100 倍。使用写入器线程，每隔 100 毫秒将队列转储到日志接收器中，但是日志引擎必须确定性地启动和停止，以便它可以在应用程序停止时刷新接收器。
面向方面的编程解决了您的横切问题 - 应在所需的操作序言/结尾中调用审核/日志调用 - 请参阅 PostSharp< /a> 项目。
Two topics of interest actually:
Asynchronous logging may speed-up heavy processing 100-fold. Use a writer thread that dumps the queue into log sink every,say 100ms however that Logging engine must be deterministically started and stopped so it can flush the sinks on application stop.
Aspect Oriented Programming addressed your cross-cutting concern - audit/log calls shall be invoked in desired operation prologues/epilogues - look at PostSharp project.
（答案有点晚了，这篇文章在谷歌中的排名很高，所以我认为可能值得看看其中的一些选项）
如果您想进行实际审计。 （我的意思是记录发生的操作、谁执行的以及何时执行的，并且该可审计日志能够用作外部审计员的证据）
（调试日志记录与审核日志记录）
如果是这样，您可以考虑一些选项，例如：
1. 使用审计库
两者都非常酷，因为它们允许您携带自己的数据存储
2. 事件采购
这里的设计（这可能会影响您的架构以拥抱事件）是事件是不可变的，如果您存储它们，那么您就拥有系统中发生的事情的可审计存储
注意 这确实不是为了解决上面的问题，但它确实解决了如何审计，所以我提到了
3.日志库
你必须确认日志库如果未能添加审核日志，就会抛出异常。
如果不这样做，那么您将丢失可审计日志，这样您就无法与审计员建立信任
旁注 1 - 使用选项 1 和 3，您可能需要确保日志与您的主日志写入在同一事务中数据存储。确保所有信息都是 ACID 的。 （这类似于人们在发布数据库事务之外的事件时遇到的问题）
旁注 2 - 审核日志应该能够识别谁做了什么，因此您可能/应该需要加密它们最终结束的数据存储上来。
(Little late on the answer, this post shows up high in google, so I thought it may be worth looking at some of the options)
If you are looking to actually audit. (By this I mean to record that an action took place, who did it and when, and for that auditable log to be able to be used as evidence to an external auditor)
(Debug Logging vs Auditing logging)
If so, you can consider some options, such as:
1. using an audit library
both are pretty cool, as they allow you to bring your own datastore
2. Eventsourcing
The design here (which can impact your architecture to embrace Events) is that Events are immutable, and if you store them then you have an auditable store of things that happened in your system
note this does not look to solve the question above, but it does solve how to audit, so I have mentioned it
3. Logging library
you have to confirm that the logging library if it fails to add an Audit Log, it will throw an exception.
if it does not do that then you will be missing auditable logs, which then you cannot build trust with your Auditors
Side note 1 - with options 1 and 3, you may need to ensure that the log is written in the same transaction as your primary data store. to ensure that all of the information is ACID. (this is similar to the issue people have with publishing an event which is outside of the database transaction)
Side note 2 - that audit logs should be able to identify who did what, so you may/should need to encrypt the datastore they eventually end up in.