我们在Azure中运行了很长时间的ASP.NET WebApp，没有公开任何实际的终结点-它具有一个功能目的，主要是读取和操作数据库数据，实际上是一个批处理的计划任务，由计时器每30秒触发一次。该应用在大多数情况下都能正常运行，但偶尔会遇到这样的问题：该应用的CPU负载立即（而不是逐渐）接近AppServicePlan的最大负载，并停止执行更多的计时器触发器，因此我们无法在执行代码来解决它（没有死锁的迹象等，并且所有代码路径都具有try / catch，因此不应有未处理的异常）。我们经常会看到与数据库建立连接的错误，但不清楚是由原因还是症状引起的。
注意，这是AppService计划中的唯一资源。 Azure SQL数据库位于同一区域，虽然它们被其他应用程序使用的程度很低，但是它们也不会出现问题应用程序看到的任何问题。
感觉这与基础架构有关，但是我们找不到任何能够解释正在发生的事情，因此，如果有人对我们应该去的地方有任何建议，我们将不胜感激。我们已经启用了基本的Application Insights（不是SDK），但是除了在无法充分利用Insight方面了解有限的知识外，除了在应用响应丢失之前看到CPU负载激增之外，其他有用的信息也很少。
[我们在Azure中运行了很长时间的ASP.NET WebApp，没有公开任何实际的终结点-它具有单一功能，主要用于读取和操作数据库数据，有效地是批处理，...
根据您的描述，我认为有两点可以解决您的问题。首先，您可以通过代码跟踪程序的运行状态，并在批处理计划任务的开始和结束处放置一个日志，以记录每次运行的状态。如果可能，记录请求和响应信息以及开始和结束信息。这样可以完全记录任务的时间和运行状态。
第二，您可以在程序开始数据库操作之前记录日志，以及数据库连接是否成功。最好的情况是能够记录哪些业务将在操作时触发CPU负载，并跟踪特定的操作条件，以便专门分析导致数据库连接失败的原因。