我想解析来自网络中不同用户机器的日志文件。在任何一天,要读取的机器数量可以在 10K 到 40K 之间。同样在解析日志文件之后,我想将每个解析的结果(行或 2)存储在一个公共位置(数据库表或平面文件)。他们自己的日志文件并没有那么大。
什么是最优雅和最有效的方法?
编写控制台应用程序,使用线程池并分配任务?或者 c# 中是否有更复杂的解决方案/类?
或者
我不熟悉编写 Windows 服务,但是是否可以编写一个服务并将其
部署到多台机器上?
或
任何其他方法?
我想解析来自网络中不同用户机器的日志文件。在任何一天,要读取的机器数量可以在 10K 到 40K 之间。同样在解析日志文件之后,我想将每个解析的结果(行或 2)存储在一个公共位置(数据库表或平面文件)。他们自己的日志文件并没有那么大。
什么是最优雅和最有效的方法?
编写控制台应用程序,使用线程池并分配任务?或者 c# 中是否有更复杂的解决方案/类?
或者
我不熟悉编写 Windows 服务,但是是否可以编写一个服务并将其
部署到多台机器上?
或
任何其他方法?
最有效的方法是什么?
这是有待商榷的——我敢说这个帖子的部分原因。就个人而言,我会在一台机器上对日志的读取进行线程池化,并将这些操作的结果存储在 SQL Server 后端。但是,这是重型生产环境方法,可能不适用,具体取决于您要投入多少精力。
理想情况下,这将被编写为专用的 Windows 服务,并且在 Visual Studio 的最新版本中构建/调试这些服务变得更加容易。另一种可行的方法是创建一个控制台应用程序,您可以轻松运行并查看其输出。部署时,您可以使用所有 NSSM 工具来允许控制台应用程序作为 Windows 服务运行。这可能是最不痛苦但稍微笨拙的方法 - 其他海报可能有更简洁的解决方案。
让一个应用程序或程序在单个服务器上运行是最简单的方法,但这假设服务器可以访问日志文件所在的每台机器上的相关共享。
如果您想将服务部署到有问题的每台机器上并让它在本地运行(绕过整个多线程方法,因为您有一个线程按定义的时间表检查一组日志文件),那么拥有一个 SQL Server 后端是更简单的方法是配置 SQL Server 帐户并允许远程连接比在一组机器上配置文件夹共享更容易(因为我不是域管理员,所以我会在此更正)。这样做的缺点是,如果您需要更新应用程序,那么在每台机器上进行更新会很痛苦。
归结为哪种方法最适合您的情况?需要机器共享的单一部署还是使用单个 SQL Server(或其他数据存储)实例的多重部署?