无法诊断应用程序服务计划的SocketException问题，文档已过期 [英] Cannot Diagnose SocketException problems with App Service Plan, documentation out of date
问题描述
我正在研究生产环境中的间歇性SocketException。经过一些谷歌搜索后，我发现了这篇文章：
https://azure.microsoft.com/en-us/updates/tcp-connections-added-to-app-service-diagnostics/
<它链接到的深潜文章已被破坏。我最终用Google搜索了标题并在github上找到了另一个托管实例，这里：
文章中显示的用户界面已过时，现在完全不同了。如果您知道要搜索它，可以检查TCP连接问题（它没有像登录页面那样链接在登录页面上，它已被隐藏）。它给出的报告也是不同的
。如博客文章中所述，报告仅显示TCP连接，每个实例的连接和连接拒绝，而不是TCP连接，连接拒绝和打开套接字句柄。关于套接字句柄没有任何内容。
因此，您可以发现应用服务计划的实例正在泄漏出站连接，您可以查看出站端口以推断出哪种类型的出站连接连接它是（80意味着Web服务，1433是sql，27017是mongo等），但你不能
告诉哪个应用服务正在这样做。
对于我如果这个服务计划中有40个应用程序正在运行，其中任何一个都可能导致泄漏，并且显然没有办法在生产中缩小范围。我联系了Azure支持Twitter（ https://twitter.com/dusda/status/1130932854018400256 ），
他们让我在这里发帖。
我还通过Kudu在服务计划上运行的一些应用程序上尝试了CMD和Powershell终端。不幸的是，netstat需要提升，所以我也无法获得任何网络指标。所以...我想下一步就是在本地协调整个
基础设施并在时间点击它们，直到找到泄漏。
你好dusda，谢谢你的联系。对于您在文档中遇到的麻烦，我深表歉意。我已经与Azure App Services Doc主管分享了您的使用经验。
对出站连接进行故障排除可能会非常棘手，因为在处理此类型的外部连接时可能存在外部暴露的平台限制数据。因此，最好的选择是打开一个支持，让支持工程师钻进日志
并查看可能泄漏的应用程序。如果您没有支持计划，请通过azcommunity@microsoft.com与我联系，并附上您的订阅ID和此论坛帖子的URL。
我们期待您的回复。
I'm looking into an intermittent SocketException in a production environment. After some googling, I found this article:
https://azure.microsoft.com/en-us/updates/tcp-connections-added-to-app-service-diagnostics/
The deep dive article it links to is broken. I eventually googled the title and found another instance of it hosted on github, here:
The user interface shown in the article is out of date, it is completely different now. You can check for TCP Connection issues if you know to search for it (it's not linked on the landing page like the blog, it's buried). The report it gives back is different as well. Instead of TCP Connections, Connection Rejections, and Open Socket Handles as mentioned in the blog article, the report only shows TCP Connections, Connections per Instance, and Connection Rejections. Nothing about socket handles.
Because of this, you can figure out that an instance of an app service plan is leaking outbound connections, and you can look at the outbound ports to infer what kind of connection it is (80 means web service, 1433 is sql, 27017 is mongo, etc), but you can't tell which app service is doing it.
For my case there are like 40 apps running on this service plan, any one of them could be causing the leaks, and there is apparently no way to narrow it down in production. I reached out to the Azure Support twitter (https://twitter.com/dusda/status/1130932854018400256), they asked me to post about it here.
I also tried CMD and Powershell terminals through Kudu on some of the apps running on the service plan. Unfortunately netstat requires elevation, so I can't get any network metrics that way either. So...I guess the next step would be to orchestrate the whole infrastructure locally and hit them one at at time until I find the leak.
Hello dusda, thank you for reaching out. I apologize for the trouble you had with the documentation. I have shared your experience with the Azure App Services Doc lead for awareness.
Troubleshooting outbound connections can be tricky as there are platform limitations as to what can be exposed externally when dealing with this type of data. As a result, the best option is to open a support to have a support engineer drill into the logs and see what app might be leaking. If you do not have a support plan, please reach out to me at azcommunity@microsoft.com with your subscription ID and the URL of this forum post.
We look forward to your reply.
这篇关于无法诊断应用程序服务计划的SocketException问题，文档已过期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
