作为一名深耕云端运维多年的工程师，我们常常在思考：在基础设施代码化早已普及的今天，监控系统的部署是否也应该跟上“自动化优先”的步伐？当我们面对成百上千台 Linux 虚拟机时，手动点击门户的操作方式不仅效率低下，更是人为错误的温床。在这篇文章中，我们将深入探讨如何通过 PowerShell 自动化地在 Azure Linux 虚拟机上部署 OMS Agent（即 Log Analytics Agent），并结合 2026 年的先进开发理念，探索从传统运维向智能运维进阶的路径。
目录
为什么这仍然是 2026 年的核心话题？
你可能会问，OMS Agent 的部署教程在网上随处可见，为什么还需要重写？答案在于“上下文的变化”。随着 Agentic AI（自主 AI 代理）的兴起，我们的监控数据不再仅仅是给人看的，更是给 AI看的。通过 PowerShell 标准化地接入监控数据，是我们构建“AI 原生”可观测性平台的第一步。我们需要收集的不仅仅是 CPU 和内存，更是能够反映业务健康状态的全面信号。让我们从基础开始，一步步构建这套现代化的监控体系。
核心实战：Cloud Shell 与 PowerShell 的深度结合
在 2026 年，我们更倾向于使用 Cloud Shell 这种托管的云端开发环境，因为它天然集成了 Azure 权限管理，避免了本地环境配置的繁琐。让我们来看一个实际的例子。
步骤 1：环境初始化与脚本编写
请打开 Azure Portal 顶部的 Cloud Shell（建议选择 PowerShell 模式）。为了确保我们的操作符合“基础设施即代码”的原则，我们将逻辑封装在脚本中，而不是在命令行中逐行敲击。
# 创建脚本文件
touch installOMSAgent.ps1
# 打开内置编辑器
code installOMSAgent.ps1
步骤 2：编写生产级部署代码
以下是经过我们实战优化的核心逻辑。请注意代码中的注释，它们解释了每一行背后的运维考量。
# --- 环境配置 ---
# 设定目标订阅。在大型企业环境中，明确订阅上下文至关重要
$subName = "Production-Subscription"
Select-AzSubscription -Subscription $subName
# --- 获取工作区信息 ---
# 这种动态获取方式比硬编码更安全，也更符合现代化实践
$workspaceRG = "Monitor-RG"
$workspace = Get-AzOperationalInsightsWorkspace -ResourceGroupName $workspaceRG
$workspaceId = $workspace.CustomerId.Guid
# 获取密钥。注意：在生产环境中，我们强烈建议使用 Azure Key Vault 来存储此密钥
# 这里为了演示方便直接获取，但在实际脚本中请使用 Get-AzKeyVaultSecret
$workspaceKey = (Get-AzOperationalInsightsWorkspaceSharedKeys -ResourceGroupName $workspaceRG -Name $workspace.Name).PrimarySharedKey
# --- 构建配置对象 ---
# 将配置封装为 Hashtable，便于后续维护和扩展
$publicSettings = @{
"workspaceId" = $workspaceId
}
$protectedSettings = @{
"workspaceKey" = $workspaceKey
}
# --- 执行扩展安装 ---
# 这是一个幂等性操作，即重复执行不会产生副作用，这是自动化脚本的重要特征
Set-AzVMExtension `
-ResourceGroupName "Linux-Servers-RG" `
-VMName "app-server-01" `
-Name "OmsAgentForLinux" `
-Publisher "Microsoft.EnterpriseCloud.Monitoring" `
-ExtensionType "OmsAgentForLinux" `
-TypeHandlerVersion "latestVersion" `
-Settings $publicSettings `
-ProtectedSettings $protectedSettings `
-Location "East US" `
-EnableAutomaticUpgrade $true # 关键：允许微软自动修复 Bug 和更新功能
步骤 3：批量化与自动化思维
单台服务器的部署只是测试，真正的效率体现在批量处理上。让我们思考一个场景：我们需要为某个资源组下所有新增的 Linux VM 自动安装 Agent。这不仅仅是节省时间，更是为了确保“零配置”的服务器接入体验。
# 定义目标资源组
$TargetRG = "MyWebApp-RG"
# 获取该资源组下所有 Linux 状态为“Running”的 VM
# 我们添加了 Status 过滤，避免对已关机的 VM 进行无效操作
$linuxVMs = Get-AzVM -ResourceGroupName $TargetRG | Where-Object { $_.StorageProfile.OSDisk.OSType -eq ‘Linux‘ -and $_.Statuses[1].Code -eq ‘PowerState/running‘ }
# 循环部署
foreach ($vm in $linuxVMs) {
Write-Host "[Info] 正在部署至: $($vm.Name)" -ForegroundColor Cyan
try {
Set-AzVMExtension `
-ResourceGroupName $TargetRG `
-VMName $vm.Name `
-Name "OmsAgentForLinux" `
-Publisher "Microsoft.EnterpriseCloud.Monitoring" `
-ExtensionType "OmsAgentForLinux" `
-TypeHandlerVersion "latestVersion" `
-Settings @{ "workspaceId" = $workspaceId } `
-ProtectedSettings @{ "workspaceKey" = $workspaceKey } `
-Location $vm.Location `
-EnableAutomaticUpgrade $true `
-ErrorAction Stop # 遇到错误立即停止，便于排查
Write-Host "[Success] $($vm.Name) 部署完成" -ForegroundColor Green
}
catch {
Write-Host "[Error] $($vm.Name) 部署失败: $_" -ForegroundColor Red
}
}
深入解析：现代化监控的技术选型（2026 视角）
当我们谈论 OMS Agent 时，我们必须正视 2026 年的技术栈演变。虽然 OMS Agent 依然是连接传统环境与 Azure Monitor 的桥梁，但我们必须了解其在新时代的角色转变。
为什么不直接使用 Azure Monitor Agent (AMA)？
这是一个非常好的问题。在 2026 年，Azure Monitor Agent (AMA) 已经成为了推荐选项，它支持更好的数据源管理和更少的系统开销。然而，OMS Agent 依然在以下场景中不可替代：
- 旧版本系统的兼容性：许多 CentOS 7 或更早版本的遗留系统无法运行 AMA，必须依赖 OMS Agent。
- 特定的依赖关系：某些复杂的诊断配置（如旧版 SCOM 集成）仍依赖 OMS Agent 的架构。
我们在技术选型时的经验是：对于新项目，优先评估 AMA；但对于需要“无痛接入”且不想更换内核模块的传统 Linux 环境，OMS Agent 依然是最高效的“氛围编程”式解决方案。
融合 AI 辅助开发：如何让 AI 帮你写脚本
作为开发者，我们现在是“AI 辅导”的程序员。在编写上述 PowerShell 脚本时，我们是如何利用 Cursor 或 GitHub Copilot 等工具提高效率的呢？
场景：我们需要处理复杂的 JSON 序列化问题，或者需要记住特定的 Azure PowerShell 参数。
实践：我们会直接在编辑器中输入：“使用 PowerShell 为 Azure Linux VM 批量安装 Log Analytics Agent，要求包含异常处理和自动升级”。AI 会根据上下文生成脚手架。我们的工作重心从“记忆 API”转移到了“审核代码逻辑”和“安全审查”上。这种 Vibe Coding（氛围编程） 的方式，让我们能更专注于业务逻辑——即“我们要监控什么”，而不是“怎么写 foreach 循环”。
深入故障排查与最佳实践
在我们最近的一个大型项目中，我们发现仅仅让脚本运行起来是远远不够的。以下是几个我们踩过的坑以及对应的解决方案。
1. 密钥管理的安全陷阱
问题：直接在脚本中硬编码 Workspace Key 是严重的安全违规行为。
2026 解决方案：我们利用 Azure Key Vault 将敏感信息从代码中剥离。脚本在运行时动态获取密钥。这不仅仅是安全需求，更是为了应对密钥轮转时的自动化需求。当管理员在 Key Vault 中更新密钥时，我们的自动化脚本无需修改即可使用新密钥。
2. 网络限制导致的“心跳丢失”
问题：在高度安全的网络环境中，VM 无法访问 Azure Monitor 服务端点，导致 Agent 显示“已连接”但无数据。
排查：我们可以使用 PowerShell 的一行命令直接在 VM 内部执行网络诊断：
Invoke-AzVMRunCommand -ResourceGroupName $rg -VMName $vm -CommandId ‘RunShellScript‘ -Scripts ‘curl -v https://ods.ops.azure.com‘
这比手动 SSH 登录要快得多，完全符合“远程优先”的开发理念。
3. 数据采样与成本优化
经验：默认配置可能会收集过多的性能计数器，导致 Log Analytics 账单激增。我们在脚本中应明确指定只收集必要的计数器（如仅收集 Error 级别的 Syslog，而不是 Info 级别）。这体现了我们在资源管理上的精细化考量。
总结：迈向 AI 原生的运维未来
通过这篇文章，我们不仅掌握了如何使用 PowerShell 安装 OMS Agent，更重要的是，我们学习了如何在 2026 年的技术背景下思考运维问题。我们利用 AI 辅助编写代码，使用脚本实现批量自动化，并时刻关注安全性和成本优化。
从手动点击到脚本化部署，再到基于 AI 的监控洞察，这正是技术演进的缩影。希望这篇文章能帮助你在实际工作中构建出更加稳定、智能的云端监控体系。现在，让我们尝试运行上面的脚本，看看效果如何吧！