这篇其实是承接之前Azure VDI中session host的监控以及Azure China 中 VDI session host的监控，我们之前谈到因为Azure China中WVDAgentHealthStatus这个query查不到数据，所以没办法直接在Log Analytics中设置告警，之前谈过一个办法就是用Azure Automation来发邮件，将邮件账号的信息存储在credential里，类似的办法其实还可以将信息存储在key vault中，本质上都是类似的
今天再来分享一个办法，就是可以结合logic apps来发邮件，通过automation里的runbook来触发logic apps，logic apps本身就是可以用来发邮件的，只是缺少一个触发器来触发这个发邮件的操作，这时候就可以通过Automation来充当这个触发器，automation可以把邮件的内容，标题，收件人等等信息包含在请求里，然后logic apps读取这些信息来发送邮件，这样就可以实现在runbook里监控VDI session host的状态，然后trigger logic apps发送告警
大概的架构就是这样，logic apps本身就是个很友好的serverless服务，不需要太多coding的工作也可以上手，通常来说，logic apps可以结合log analytics，Sentinel之类的实现告警的自动响应，这部分之后也希望能再发掘一些可以分享的案例出来，今天先拿一个简单一些的logic apps + Azure Automation出来
首先测试环境的话需要准备如下东西
- Azure Automation Account
- Azure VDI
- Azure Logic Apps
Automation account 和 VDI的部署就不多说了，主要看下logic apps的部署
创建logic apps的时候会有一些选项提供出来，主要看下这些选项代表的含义
这里可以看到publish会有两种选项，一个是workflow，还有docker container，一般来说绝大部分都是用的workflow
这里的定价模型可以看到会分为consumption和standard两大类，具体的区别可以参考下边的表格
资源类型 | 好处 | 资源共享和使用 | 定价和计费模型 | 限制管理 |
逻辑应用（消耗）
主机环境：多租户 Azure 逻辑应用 | - 最容易入门
- 仅为你使用的部分付费
- 完全托管 | 单个逻辑应用只单个能有一个工作流。
跨 Azure Active Directory 租户的逻辑应用共享相同的处理（计算）、存储和网络等。
出于冗余目的，将在配对区域中复制数据。 为实现高可用性，已启用异地冗余存储 (GRS)。 | 消耗（按执行付费） | Azure 逻辑应用管理这些限制的默认值，但如果特定限制存在更改值的选项，则可以更改其中某些值。 |
逻辑应用（消耗）
主机环境： 集成服务环境 (ISE) | - 适用于大型工作负载的企业规模
- 20 多个特定于 ISE 的连接器，可直接连接到虚拟网络
- 包含使用情况和客户控制缩放的可预测定价 | 单个逻辑应用只单个能有一个工作流。
同一环境中的逻辑应用共享相同的处理（计算）、存储和网络等。
数据所在区域与部署 ISE 的区域相同。 | ISE（固定） | Azure 逻辑应用管理这些限制的默认值，但如果特定限制存在更改值的选项，则可以更改其中某些值。 |
逻辑应用（标准版）
主机环境： 单租户 Azure 逻辑应用
注意：如果你的方案需要容器，请使用已启用 Azure Arc 的逻辑应用创建基于单租户的逻辑应用。 有关详细信息，请参阅什么是已启用 Azure Arc 的逻辑应用？ | - 通过单租户 Azure 逻辑应用运行时运行。 当前不支持部署槽位。
- 更多的内置连接器，可大规模实现更高吞吐量和更低成本
- 围绕运行时和性能设置的更多控制和微调功能
- 集成了对虚拟网络和专用终结点的支持。
- 创建自己的内置连接器。 | 单个逻辑应用可以有多个有状态和无状态工作流。
单个逻辑应用和租户中的工作流共享相同的处理（计算）、存储和网络等。
数据所在区域与部署逻辑应用的区域相同。 | 标准，基于处于所选定价层的托管计划。
如果运行有状态工作流（这些工作流使用外部存储，Azure 逻辑应用运行时将执行遵循 Azure 存储定价的存储事务。 | 你可以根据方案的需求更改多个限制的默认值。
重要说明：某些限制的具有固定的上限。 在 Visual Studio Code 中，你对逻辑应用项目配置文件中的默认限制值的更改不会反应在设计器体验中。 有关详细信息，请参阅在单租户 Azure 逻辑应用中编辑中逻辑应用的应用和环境设置。 |
逻辑应用（标准版）
主机环境： 应用服务环境 v3 (ASEv3) - 仅限 Windows 计划 | 与单租户相同的功能，加上以下优势：
- 完全隔离逻辑应用。
- 创建和运行比在单租户 Azure 逻辑应用中更多的逻辑应用。
- 无论创建和运行多少逻辑应用，都只需为 ASE 应用服务计划付费。
- 可以使用更多虚拟机实例或其他应用服务计划启用自动缩放或手动缩放。
- 从选定的 ASEv3 继承网络设置。 例如，部署到内部 ASE 时，工作流可以访问与 ASE 关联的虚拟网络中的资源，并拥有内部访问点。
注意：如果从内部 ASE 的外部访问，运行该 ASE 中的工作流的历史记录是无法访问操作输入和输出的。 | 单个逻辑应用可以有多个有状态和无状态工作流。
单个逻辑应用和租户中的工作流共享相同的处理（计算）、存储和网络等。
数据所在区域与部署逻辑应用的区域相同。 | 应用服务计划 | 你可以根据方案的需求更改多个限制的默认值。
重要说明：某些限制的具有固定的上限。 在 Visual Studio Code 中，你对逻辑应用项目配置文件中的默认限制值的更改不会反应在设计器体验中。 有关详细信息，请参阅在单租户 Azure 逻辑应用中编辑中逻辑应用的应用和环境设置。 |
或者通过这个图也可以看出来一些区别，基于consumption的logic apps不能做到网络隔离，也就是没办法部署到VNET里，这对于内网的一些使用场景是有限制的，另外基于consumption的logic apps是和其他客户共享资源的，不是独享，所以对于性能要求高的场景要慎重选择。对于enterprise级别的客户来说，还是用standard比较好一点，不过价格确实还是有不小差别的
可以看到如果是Standard的模型，在网络这部分是有不少选项的，包括是否配置VNET Injection之类的，这就是可以允许logic apps连接到内网资源了，但是如果是基于consumption的，这些都没办法配置
这些就是在创建logic apps时会遇到的一些选项了，因为logic apps这个应用介绍的不是很多，所以这里单独拿出来把创建的过程介绍下，之后就回到主题，看下logic apps和automation的结合
