关于通过web api记录日志的问题讨论
0
悬赏园豆：100
[已解决问题]
解决于 2018-09-19 18:03
一般接入日志框架需要添加各种配置信息，也免不了引入相关类库。
如果写个Web Api，提供接口记日志，然后针对不同平台封装相应的类库，这样就不用在每个记录日志的项目加配置信息了。
打个比方：
1.有个Web Api 利用NLog.Mongo将日志记录到数据库，向外提供不同业务日志或者日志等级的接口，这都是业务实现，先不讨论。
2.根据web api提供的接口封装相应的方法提供给客户端,可以理解成工具类，针对web api的，比如日志等级，发邮件等等。异步post
3.项目引用封装类库，就可以调用相应方法记日志了
4.提供界面查看日志
之所以这么干就是想避免项目里配置节点或者添加日志配置文件，还是我这种处理方式把问题想复杂了？但我真的很讨厌配置，虽然有的并不麻烦，web api也可以进行分布式部署
问题是这么干有什么缺点吗，如果高并发采用异步post会有什么隐患吗。像mongodb的数据写入性能我觉得可以忽略。
欢迎讨论
最佳答案
0
我认为你的想法是对的，当项目变多时，日志在每个项目中各自配置使得总体成本增加的较快，
于是便想着将这些重复的逻辑挪到一个地方，比如你说的api，这是符合srp的原则。
但是我认为 异步post到MongoDB ，这个地方异步的创建（或使用）可能会造成性能瓶颈。
因为我看过一篇文，在写日志的时候使用了同步语句，而且解释为什么没有使用异步，
他认为写日志的实现消耗应该小于异步创建的消耗。
总体我认为这是一个相对平衡的问题，就是 写日志消耗的时间代价要大于集中管理日志收获的价值。
我感觉这个问题结果还是要靠实践。
如果说的不对，欢迎指出。
收获园豆：100
确实是，异步开启线程会有消耗，这一块得考虑值不值当。可以考虑用线程池来减少创建和销毁线程的开销。
先按这思路试试看吧。
性能问题感觉还是异步post上。接口并发大的话可以有其他解决方案。真正写web api的话内部可以随便整其他日志框架，写文件 数据库 es都可以
总之还是希望尽量减少各种依赖和配置吧。
其实不用异步也行，完全可以理解成秒杀接口，秒杀后台那一套逻辑可以搬到记日志的api里面。。。
@去海边生活:
1 async 默认是从线程池中取线程，
2 调用api写日志，应该是走网络的，走网络就若干问题，即便是内网，由于写日志的成功与否不影响业务的执行，这是它可以异步的出发点。
我感觉并发实在要求的话，先扔到 MQ 中，接着再持久化（同你说的秒杀应该是相同的原理，这个地方我不确认）。处理高要求的一般思路CPU-内存-存储器。
其他回答(1)
0
如果你用 asp.net core ，就没这个烦恼了
能多指点一下吗，没有深入了解.net core,虽然现在web项目和服务用.net core写的
@去海边生活: 可以使用 asp.net core 内置的日志功能 + Serilog ，参考 Asp.Net Core中利用Seq组件展示结构化日志功能 。Serilog 提供了各种 Sinks，可以将日志写入你所使用的日志服务中。
@dudu: 好的 谢谢 我了解一下
