0
点赞
收藏
分享

微信扫一扫

Terraform Azure diagnostic setting升级

这两篇来分享一个实际工作中遇到过的问题,也是在使用terraform部署环境的时候碰到的,terraform虽然是好东西,不过很多时候在一些场景下其实真不一定比手动操作好用,尤其是遇到各种问题的时候,今年之前其实也分享过很多篇terraform相关的文章,有兴趣可以看看

  1. 使用terraform迁移logic apps
  2. 解决Terraform StatusCode=429问题
  3. 使用Terraform来部署performance counter
  4. 解决Logic Apps terraform部署时大小写问题

这次来讲的主要是在升级azurerm_monitor_diagnostic_setting这个资源的时候遇到的问题,先把代码贴出来


resource "azurerm_monitor_diagnostic_setting" "recovery_vault" {
  for_each = local.recovery_services_vault_diagnostics_settings

  name                           = each.value.name
  target_resource_id             = each.value.target_resource_id
  log_analytics_workspace_id     = try(each.value.log_analytics_workspace_id, null)
  log_analytics_destination_type = try(each.value.log_analytics_destination_type, null)
  storage_account_id             = try(each.value.storage_account_id, null)


  dynamic "log" {
    for_each = each.value.logs

    content {
      category = log.value
      enabled  = each.value.enabled

      #retention policy applies when output type is storage account
      retention_policy {
        enabled = each.value.retention_policy.enabled
        days    = each.value.retention_policy.days
      }
    }
  }

  dynamic "metric" {
    for_each = each.value.metrics

    content {
      category = metric.value
      enabled  = each.value.enabled

      #retention policy applies when output type is storage account
      retention_policy {
        enabled = each.value.retention_policy.enabled
        days    = each.value.retention_policy.days
      }
    }
  }
}

这个资源的作用是部署diagnostic settings,光这么说估计也不太容易理解到底是部署什么,参考下图其实就知道了,部署的实际就是把Azure资源的诊断日志,发送到诸如LA, Eventhub等资源的配置,这属于是个比较场景的需求,上边的代码就是用来做这个的

Terraform Azure diagnostic setting升级_删除文件

而这段代码有什么问题呢,主要包括两个方面

1.log这个资源已经deprecated,这个资源对应的其实就是上图里categories里可以选的那些选项,按照官方说法在4.0版本之后就会被remove了,需要用enabled_log替代,这个相对简单

Terraform Azure diagnostic setting升级_Cloud_02

2.第二个就比较复杂了,可以看到retention policy这个资源也在提示已经deprecated,而如果要替代这个资源的话,需要另外部署一个azurerm_storage_management_policy

Terraform Azure diagnostic setting升级_PowerShell_03

首先解释下这个retention policy是做什么的,这个主要用在把日志存储在storage account里的场景,你可以通过这个参数指定日志在storage account里存储的时间,比如放30天,之后就删除掉,而这个操作背后用到的其实就是storage account里的生命周期管理,后台会自动帮你创建一条rule出来

Terraform Azure diagnostic setting升级_删除文件_04

这条rule里会指定好之前提到的保存周期,最重要的是还会包含需要删除文件的prefix,下图中的是NSG的flowlog,所以prefix很少,但是像其他服务会有很多种类型的log,这种情况下就需要很多prefix,来确保删除时不要删错文件

Terraform Azure diagnostic setting升级_Terraform_05

以前这都是后台自动执行的,我们只需要配置个参数,指定好保存多少天就行了,但是以后这需要我们自己来管理了,不得不说这是个坏消息。

具体的退役时间线如下:

  • 2023 年 3 月 31 日 - 诊断设置存储保留功能将不再可用于为日志数据配置新的保留规则。 这包括使用门户、CLI PowerShell 以及 ARM 和 Bicep 模板。 即使已配置保留设置,也仍然可以在门户中查看和更改它们。
  • 2024 年 3 月 31 日 - 无法再使用 API(CLI、Powershell 或模板)或 Azure 门户来配置保留设置,除非将其更改为 0。 仍需遵守现有的保留规则。
  • 2025 年 9 月 30 日 - 将在所有环境中禁用诊断设置存储保留功能的所有保留功能。


接下来看下改完之后的代码,log直接替换成enabled_log即可,里边的配置基本也大同小异,区别是多了个category group,不过我这里没用这个,因为牵扯到一些逻辑上的东西。而retention policy上边说过了需要用azurerm_storage_management_policy替代,所以之前的这部分直接删掉就好了


resource "azurerm_monitor_diagnostic_setting" "recovery_vault" {
  for_each = local.recovery_services_vault_diagnostics_settings

  name                           = each.value.name
  target_resource_id             = each.value.target_resource_id
  log_analytics_workspace_id     = try(each.value.log_analytics_workspace_id, null)
  log_analytics_destination_type = try(each.value.log_analytics_destination_type, null)
  storage_account_id             = try(each.value.storage_account_id, null)


  dynamic "enabled_log" {
    for_each = each.value.logs

    content {
      category = enabled_log.value
      # category_group = try(enabled_log.value, null)
      #retention policy applies when output type is storage account

    }
  }

  dynamic "metric" {
    for_each = each.value.metrics

    content {
      category = metric.value
      enabled  = each.value.enabled

      #retention policy applies when output type is storage account

    }
  }
}

这部分其实是非常简单的,比较麻烦的是剩下的azurerm_storage_management_policy要部署出来,这部分准备放到另外一篇来说,因为会遇到一些意想不到的坑

举报

相关推荐

0 条评论