azure api 管理

The Azure Portal offers the free tool Cost Management that we can use for managing Azure costs. As we’ll see, we can use this tool to organize how we manage our spending along with setting limits for thresholds to alert the appropriate members. While this tool can be useful for our organization, it has the potential to cause noise or disruptions, so we still want to review how we use it within our organization for managing the spending of our teams.

Azure门户提供了免费工具“成本管理”，我们可以使用它来管理Azure成本。 正如我们将看到的，我们可以使用此工具来组织我们如何管理支出，以及设置阈值限制以提醒适当的成员。 尽管此工具对我们的组织有用，但它有可能引起噪音或干扰，因此我们仍然想回顾一下我们在组织内部如何使用它来管理团队的支出。

Azure门户中的成本管理 (Cost Management in the Azure Portal)

From the home page of the Azure Portal, we’ll see the Cost Management tool and when we click on this tool, we’ll see a blade that pops up that shows Create budget (see below image) with options that we can select. For now, I’ve avoided setting up an action group so that we can set this up for this example. If you already have an action group, you can skip the next three steps. On this screen, we’ll select the option, Manage action groups.

在Azure门户的主页上，我们将看到“成本管理”工具，当我们单击该工具时，将看到一个弹出的刀片，显示创建预算 （见下图）以及可供选择的选项。 现在，我避免设置操作组，以便我们可以在此示例中进行设置。 如果您已经有一个操作组，则可以跳过接下来的三个步骤。 在此屏幕上，我们将选择选项管理操作组 。

If you have an action group already, you will see them listed. For this example, we have none, so we’ll set up our first action group by selecting the option Add action group.

如果您已经有一个行动小组，您将看到他们被列出。 在此示例中，我们没有任何操作，因此我们将通过选择添加操作组选项来设置第一个操作组 。

How we organize our Azure resources will matter here, as we’ll be setting our action group on the basis of our resource group – but if we don’t manage our teams by resource groups, this will not be an option for us (we can scale and organize our resources by subscription instead). Also, keep in mind that we want to keep our resource groups named in a way that allows scale. For example, what if we need more resource groups for a team and we’ve named them in a manner that doesn’t allow logic in our code and prevents us from scaling easily, which adds to our Azure costs? I suggest using naming conventions that make scale easy – such as a name like ReportReaderApp00, ReportReaderApp01, ReportReaderApp02, etc. or TeamLavender000, TeamLavender001, TeamLavender002, etc. These easily scale through automation in their naming conventions, whereas coming up with a unique for each resource group for one team or application invites complexity.

我们将如何组织Azure资源在这里很重要，因为我们将根据资源组来设置操作组–但是，如果我们不按资源组来管理团队，那么这对我们来说不是一个选择（我们可以通过订阅来扩展和组织我们的资源）。 另外，请记住，我们要以允许扩展的方式来命名资源组。 例如，如果我们需要一个团队更多的资源组，并且以一种不允许在代码中添加逻辑并阻止我们轻松扩展的方式来命名它们，那会增加Azure成本吗？ 我建议使用易于缩放的命名约定，例如ReportReaderApp00，ReportReaderApp01，ReportReaderApp02等名称或TeamLavender000，TeamLavender001，TeamLavender002等。这些命名约定可以通过自动化轻松地进行缩放，而每个命名约定都具有唯一性一个团队或应用程序的资源组会带来复杂性。

In the below image, we add the details for our action group – the action group name, short name, subscription (not shown), and resource group. Our naming convention for the names follows the pattern of our resource group and for good reason – this helps us quickly identify what resources these actions track.

在下图中，我们添加了操作组的详细信息- 操作组名称 ， 简称 ， 订阅 （未显示）和资源组 。 我们的名称命名约定遵循我们资源组的模式，并且有充分的理由–这有助于我们快速确定这些操作跟踪哪些资源。

Once we create our action group, we return to our budget page for Azure costs and input the options that we want for this action group. We’ll see that we have many options here such as name, budget, time period, and the percent of our budget. It’s possible that we want this resource to be a percent of our budget. For our example, we’ll set this resource to use the full budget (100%). We also see that we’re setting the limit to $2 for the purpose of generating significant use and getting an alert in a short period of time for testing this feature. While we do this quickly in this example, this budget page is where we want to spend time in large organizations thinking about how much Azure costs we want to allow for each team. We also set a short expiration date for this budget and this will generally be further into the future, if we’re satisfied with our limits and results. In the end, we’ll specify an email address that we’ll send an alert to and we’ll add that (not shown).

创建操作组后，我们将返回Azure成本的预算页面，并输入该操作组所需的选项。 我们将看到这里有许多选项，例如名称，预算，时间段和预算百分比。 我们可能希望此资源占预算的百分比。 对于我们的示例，我们将设置此资源以使用全部预算（100％）。 我们还看到，我们将限制设置为$ 2，目的是产生大量使用并在短时间内收到警报以测试此功能。 尽管在此示例中我们快速执行此操作，但此预算页面是我们想要在大型组织中花费时间的地方，我们在考虑我们希望为每个团队允许多少Azure成本。 我们还为此预算设置了一个较短的到期日期，如果我们对我们的限制和结果感到满意的话，这通常会更远。 最后，我们将指定要发送警报的电子邮件地址，并将其添加（未显示）。

Now, we’ll create and use a bunch of resources to generate an alert. Soon after we create a resource or two (in my example, I create a MongoDB and add a bunch of large documents in a database), we’ll return to our budget page for our Azure Costs in the Azure Portal and we’ll notice how we’ve progressed toward our budget – your actual result will differ depending on the resources you’ve created. This still hasn’t crossed our threshold, but we’ll notice how far we’ve progressed toward it.

现在，我们将创建并使用大量资源来生成警报。 在创建一两个资源（在我的示例中，我创建一个MongoDB并在数据库中添加一堆大文档）后不久，我们将返回到Azure门户中Azure成本的预算页面，并且我们会注意到我们如何朝预算方向发展–根据您创建的资源，您的实际结果会有所不同。 这仍然没有超过我们的门槛，但是我们会注意到我们朝着它迈进了多远。

As we see in the Azure portal, we can drill into this budget further to remove or update the details if we need by clicking on the budget (in this case RG1):

正如我们在Azure门户中所看到的，如果需要，我们可以通过单击预算（在本例中为RG1 ）进一步深入该预算，以删除或更新详细信息：

We can continue using our resources that we’ve created to surpass our budget and generate an alert, or we can wait a period of time if the resource we created will cross the use threshold in a day or two. When we update the budget page, we’ll see that we’ve crossed it:

我们可以继续使用我们创建的资源超过预算并生成警报，或者如果我们创建的资源将在一两天内超过使用阈值，则可以等待一段时间。 更新预算页面时，我们会看到它已经越过了：

In the Azure Portal, we also see that our resource group called OurResourceGroup is only a fraction of the spending, but it exceeded its budget.

在Azure门户中，我们还看到名为OurResourceGroup的资源组只是支出的一小部分，但超出了预算。

避免电子邮件警报垃圾邮件陷阱 (Avoiding the Email Alerting Spam Trap)

When we consider alerting on Azure costs by setting budgets, we still want to follow the best practices on alerting. I’ve witnessed alerts being ignored in environments where developers receive thousands of alerts per day – a load that the average developer cannot handle. Alerts should follow the below rules, or else they should be disabled

当我们考虑通过设置预算来警报Azure成本时，我们仍然希望遵循警报的最佳实践。 我目睹了在开发人员每天收到成千上万个警报的环境中忽略警报的情况，这是普通开发人员无法处理的负载。 警报应遵循以下规则，否则应将其禁用

• If there are one or two steps to solve the problem, automate the solution and don’t alert. In this case, we need an alert on our Azure spending, but with a new alert added to our development teams or management teams, we need to ensure that other alerts are needed (we’re adding to the alerting load) 如果有一两个步骤可以解决问题，请自动执行解决方案，并且不要发出警报。 在这种情况下，我们需要有关Azure支出的警报，但是在开发团队或管理团队中添加了新警报之后，我们需要确保需要其他警报（我们正在增加警报负载）
• Our alerts should be actionable and in this case with Azure costs, we should have clear action steps that teams will do if they receive an alert about a resource overspending, such as disable the resources, prioritize performance improvements for the resources, etc. This also means that we’ve allowed these teams to have a “time-cushion” each month for possible work injection 我们的警报应该是可操作的，并且在这种情况下需要支付Azure费用，如果团队收到有关资源超支的警报（例如禁用资源，优先改善资源的性能等），我们应该有明确的操作步骤，团队应该采取的措施。意味着我们允许这些团队每个月都有一个“时间缓冲”来进行可能的工作注入
• Set lower thresholds than the maximum so there is time to prevent issues and this relates to the above point. If we set the maximum threshold – we cannot spend more than $1000 for an action group – what happens if we cross it? Do we disable the resource? A better step would be to set our threshold at a lower bound value, such as $750 to provide time for our developers to optimize a performance solution 将阈值设置为低于最大值，以便有时间防止出现问题，这与上述几点有关。 如果我们设定最高阈值–我们为一个行动小组花费的资金不能超过1000美元–如果我们超过该阈值会怎样？ 我们是否禁用资源？ 更好的步骤是将我们的阈值设置为较低的界限值，例如750美元，以便我们的开发人员有时间优化性能解决方案
• Delineate who receives the alerts for large teams that may already be seeing many alerts. For development or administrative teams where we have every team member receiving the same alerting, it may be more appropriate with large teams to organize the alerts by groups within the team. For the case of Azure costs, we may want only the manager of the team to receive these alerts 为可能已经看到许多警报的大型团队描述谁接收警报。 对于我们每个团队成员都收到相同警报的开发或管理团队，大型团队可能更适合按团队中的组来组织警报。 对于Azure成本，我们可能只希望团队经理接收这些警报
• Because increasing revenue and decreasing costs are the basis of business, with any cost alert, I suggest setting aside some time to review these costs as a team 由于增加收入和降低成本是业务的基础，因此在有任何成本预警的情况下，建议您花一些时间以团队方式审查这些成本

Alerts can provide us with a useful tool that helps us prevent problems provided that we design them appropriately and we consider other alerts we already have running. We should always err on the side of fewer alerts to prevent overwhelming employees or creating the “boy who cried wolf” problem that often accompanies alerting.

警报可以为我们提供一个有用的工具，可以帮助我们预防问题，前提是我们进行了适当的设计并且考虑了我们已经在运行的其他警报。 我们应该总是减少警报的数量，以防止员工不堪重负或造成警报经常伴随的“哭狼来了”的问题。

结论 (Conclusion)

As we’ve seen, we can use the Cost Management tool in the Azure Portal to create and manage action groups and set budgets for these groups. Once these are in place, we can also alert the appropriate teams or team members about these thresholds being crossed – and we’ve reviewed how we may want to set our thresholds at a lower level than the maximum we want to allow. This is one of many tools that allows us to manage our Azure costs by helping us prevent overspending or helping us see resources that must be optimized for performance.

如我们所见，我们可以使用Azure门户中的成本管理工具来创建和管理操作组并为这些组设置预算。 一旦设置好这些阈值，我们还可以提醒适当的团队或团队成员这些阈值已被突破-我们已经审查了如何将阈值设置为低于我们希望的最大值。 这是许多工具之一，可通过帮助我们防止超支或帮助我们查看必须针对性能进行优化的资源来管理Azure成本。

目录 (Table of contents)

翻译自: https://www.sqlshack.com/tracking-azure-costs-with-cost-management/

azure api 管理