问题标签 [azure-app-service-plans]

在哪里可以找到与应用服务关联的文件共享？

我可以从 Kudo 控制台查看文件，但我没有使用门户或存储资源管理器在我的存储帐户上看到共享。

我在 Web 应用上添加了私有 Nuget 存储库，该存储库托管在应用服务计划上。

nuget.exe sources add -name {name} -source {feed} -username {username} -password {PAT}

但是，如果重新分配应用服务计划实例（扩展/扩展、Azure 维护...），则不会保留上面的 nuget.config。

我不想在存储库的 nuget.config 中添加此配置，因为它包含密码。如何在 Azure 应用服务计划主机上保留 nuget.config？

Why there is a difference between the IP address reported by Azure Application Insights and standard Google Search (What is my IP)?

• IP returned by Azure App Insights: xx.xx.xx.0
• IP returned by Google Search: xx.xx.xx.242

我使用新的应用服务计划创建了一个新的功能应用，以便对我拥有的一些功能进行新的发布。

在我的旧应用服务计划（非消费）中，我一直使用的证书停止运行，因为我的代码不再能够从证书存储中检索它，而且我从未确定根本原因。

设置新应用服务的一部分是允许我纠正这个问题，但我惊讶地发现旧应用服务计划中的 SSL 证书已经存在于这个新应用服务计划中，并且它似乎可以按预期工作（即我现在可以读取函数代码中的证书）。

这是预期的行为吗？相同的订阅和区域，但不同的应用服务计划。我不会期望之前从另一个应用服务计划/功能应用上传的 SSL 证书可用于新的、不相关的应用。

UPDATE: I've figured it out. See the end of this question.

I have an Azure App Service running four sites. One of the sites has two deployment slots in addition to the primary one. Recently I've been seeing really high CPU utilization for the App Service plan as a whole.

The dark orange line shows the CPU percentage. This is just after restarting all my sites, which brought it down to this level.

However, when I look at the CPU use reported by each site, it's really low.

The darker blue line shows the CPU time, which is basically nothing. I did this for all of my sites, and all the graphs look the same. Basically, it seems that none of my sites are causing the issue.

A couple of the sites have web jobs, so I took a look at the logs but everything is running fine there. The jobs run for a few seconds every few hours.

So my question is: how can I determine the source of this CPU utilization? Any pointers would be greatly appreciated.

UPDATE: Thanks to the replies below, I was able to get more detail into what was happening. I ended up getting what I needed from SCM / Kudu tools. You can get here by going to your web app in Azure and choosing Advanced Tools from the side nav. From the Kudu dashboard, choose Process Explorer. The value in the Total CPU Time column is not directly useful, because it's the time in seconds that the process has run since it started, which might have been minutes or days ago.

However, if you make a record of the value at intervals, you can look at the change over time, and one process might jump out at you. In my case, it was my WebJobs process. Every 60 seconds, this one process was consuming about 10 seconds of processor time, just within one environment.

The great thing about this Kudu dashboard is, if you can catch the problem while it is actually happening, you can hit the Start Profiling button and capture a diagnostic session. You can then open this up in Visual Studio and get some nice details about where the CPU time is being spent.

Just in case anyone else is seeing similar issues, I'll provide more details about my particular case. As I mentioned, my WebJobs exe was the culprit, and I found that all the CPU time was being spent in StackExchange.Redis.SocketManager, which manages connections to Azure Redis Cache. In my main web app, I create only one connection, as recommended. But Since my web jobs only run every once in a while, I was creating a new connection to Azure Redis Cache each time one ran, which apparently can lead to issues. I changed my code to create the Redis Cache connection once when the WebJob process starts up and use the existing connection when any individual WebJob runs.

Time will tell if this really fixes the issue, but I think it will. When the problem occurred, it always fit the same pattern: After a few days of running fine, my CPU would slowly ramp up over the course of about 12 hours. My thinking is that each time a WebJob ran, it created a connection object, which at first didn't produce trouble, but gradually as WebJobs ran every hour or two, cruft was building up until finally some critical threshold was met and the CPU usage would take off.

Hope this helps someone out there. Best wishes!

有没有办法显示应用服务对 Azure 应用服务计划中所有应用服务的内存/cpu 消耗？

或者，有没有办法为多个选定的应用服务生成资源消耗报告？

更新：每个实例的指标（应用程序服务）报告未显示计划中的每个应用程序。仅限您正在查看的应用的资源组中的应用。

我有一个 .NET 4.6 Web 应用程序在 64 位的 Azure 应用程序服务中运行。当我点击一个调用 LibGit2Sharp 的控制器时，我得到以下异常：

这是堆栈跟踪：

这段代码在本地运行良好，所以我不知道出了什么问题。

关于这篇 MSDN 文章；https://msdn.microsoft.com/en-us/magazine/mt793270

Per-App Scaling部分有以下段落。

使用前面的 50 个应用示例，为应用服务计划启用每应用缩放，所有 50 个应用都可以分配到同一个应用服务计划。然后，可以修改单个应用程序的缩放特性：

• 40 个低容量应用程序设置为在每个服务器上最多运行。
• 五个中低容量应用程序设置为在最多两台服务器上运行。
• 其余五个大容量应用程序设置为在最多 10 台服务器上运行。

基础应用服务计划可以从至少五台服务器开始。然后可以根据内存压力与 CPU 的需要设置自动扩展规则以进行扩展。

我不明白为什么上述三种配置至少提供五台服务器作为起始计数。

它是否说 40 个低容量应用程序到 1 个服务器，5 个中等容量应用程序到 1 个服务器，以及 5 个高容量应用程序到（未描述的）3 个服务器？

我在门户网站上找不到我最初创建此 FTP 访问帐户的位置。我想删除它。这可以在哪里完成？

关于这篇 MSDN 文章；https://msdn.microsoft.com/en-us/magazine/mt793270

Scale Unit Network Configuration部分有以下句子；

在基于 IP 的 SSL 的情况下，为给定的应用程序分配了一个专用 IP 地址，仅用于与云服务部署相关的入站流量。请注意：前端会终止所有应用程序和任何类型证书的所有 HTTPS 请求的 SSL 连接。然后前端将请求转发给给定应用程序的指定工作人员。

但是，什么时候Please note: Front ends terminate SSL connection for all HTTPS requests for all applications and any type of certificate发生？

• 这是在我们配置基于 IP 的 SSL 之后发生的吗？
• 或者，这是否总是在基于 IP 的 SSL 下发生在所有流量上？
• 要不然？