ASP.NET 中的带宽监控
您好,我们正在 Asp.Net 中开发一个多租户应用程序,为每个租户提供单独的数据库,其中要求之一是监视每个租户的带宽使用情况,
我尝试搜索但没有找到有关该主题的太多帮助,我们希望准确监控每个租户使用了多少带宽,同时每个租户可以拥有自己的顶级域或子域或两者的组合。
那么有哪些可用的选项,我能想到的可以是
- IIS 日志监控,这意味着一个单独的应用程序将计算每个租户的带宽。
- 记录应用程序内租户的每个请求和响应,然后据此计算总带宽使用量。
- 如果可用,请使用一些第三方组件
那么您认为最好的方法是什么,以及是否有其他方法可以做到这一点。
Hi, We are developing a multi-tenant application in Asp.Net with separate Database for each tenant, in which one of the requirement is to monitor the bandwidth usage for each tenant,
i have tried to search but not found much help on the topic,we want to monitor exactly how much bandwidth is being used for each tenant while each tenant can have its own top level domain or a sub domain or a combination of both.
so what are the available options, the ones which i can think of can be
- IIS Log Monitoring means a separate application which will calculate the bandwidth for each tenant.
- Log Each Request and Response for a tenant from within the application and then calculate the total bandwidth usage based on that.
- Use some third part components if available
So what do you think will be the best approach, also if there is any other way to do this.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
想法(我没有测试过,留给你)
好的,这是一个关于 global.asax 的
使用此函数之一(找到具有有效最终大小的函数)
并获取您发送的大小,
获取调用的文件名
无需提及,您可以使用每个请求调用的此函数 ,因此您可以得到你的尺寸,剩下的由你来做。
这里必须注意,您需要首先测试这个想法,看看它是否有效,也许还可以改进它,并且在我看来,如果您压缩了服务器上的页面,则长度不正确,也许您需要将其压缩Global.asax 具有实际长度。
希望这有帮助。
Ok, here is an idea (that I have not test, leave that to you)
On global.asax
use one of this function (find the one that have a valid final size)
and get the size that you have send with
No need to metion, that you get the filename of the call using the
This functions called with every single request, so you can get your size and you do the rest.
Here must note, that you need first to test this idea to see if its work, and maybe improve it, and have in mine that if you have compress the pages on server the length is not the correct and maybe you need to compress it on Global.asax to have the actually lenght.
Hope this help.
好吧,由于 IIS 日志已经包含请求大小和响应大小,因此开发一个小工具来解析它们并计算每天/每周/每月/其他的总数似乎并不太麻烦。
Well, since the IIS logs already contain the request size and response size, it doesn't seem like too much trouble to develop a small tool to parse them and calculate the total per day/week/month/whatever.
根据我的经验,尝试根据主机对流量进行分段是很困难的。相反,如果您为每个租户提供自己的应用程序 IP,您应该能够找到基于 IP 监控带宽的程序。
附加 IIS 的结构是否是您拥有一个网站来为所有租户管理所有内容,并在登录时系统分叉到正确的数据库?如果是这样,这可能会产生版本控制方面的问题,因为所有租户的站点都必须具有完全相同的架构,并且在您更新应用程序时都需要同时更新,从而需要更改架构。
另一种结构(听起来像您可能拥有的结构)是每个租户都有自己的网站,如下所示:
其中
appvirtualdir
指向所有租户站点的相同物理路径。当所有客户端都具有相同的应用程序版本时,它们实际上都使用相同的代码。如果您有这种场景和某种身份验证,那么由于 SSL,您无论如何都需要每个租户一个 IP。 SSL 仅绑定到 IP 和端口,而不像非 SSL 绑定到 IP、端口和主机。如果是这样的话,那么基于 IP 的流量监控仍然会更简单、更准确,因为它可以在路由器或通过网络监视器完成。Trying to segment traffic based on host is difficult in my experience. Instead, if you give each tenant their own IP(s) for the applications you should be able to find programs that will monitor bandwidth based on IP.
ADDITION Is the structure of IIS that you have one website to rule them all for all tenants and on login the system forks to the proper database? If so, this may create problems with respect to versioning in that all tenant's sites will all have to have exactly the same schema and would all need to be updated simultaneously when you update the application such that a schema change is required.
Another structure, which sounds like what you may have, is that each tenant has their own website like so:
Where the
appvirtualdir
points to the same physical path for all tenant's sites. When all clients have the same application version, they are all using literally the same code. If you have this scenario and some sort of authentication, then you will need one IP per tenant anyway because of SSL. SSL will only bind to IP and port unlike non-SSL which will bind to IP, port and host. If that were the case, then monitoring traffic based on IP will still be simpler and more accurate as it could be done at the router or via a network monitor.