代理安装是连接工作区的基础
要把服务器或虚拟机的日志送到 OMS Log Analytics 工作区，最直接的方式就是安装 Microsoft Monitoring Agent（MMA）。这个代理同时负责收集性能计数器和 Syslog 事件，并且把数据推送到你指定的工作区。安装之前需要先在工作区里拿到两个关键值：工作区 ID 和主密钥。这两个值在 Azure 门户中 Log Analytics 工作区的“代理管理”页面可以找到，密钥分为主密钥和辅助密钥，日常配置用主密钥即可。
Windows 服务器上可以下载 MMA 的安装包手动执行，也可以通过命令行静默安装。例如在 PowerShell 里运行以下命令完成静默安装并指定工作区：
$workspaceId = "你的工作区ID" $workspaceKey = "你的主密钥" $installerPath = "C:\Temp\MMASetup-AMD64.exe" Start-Process -FilePath $installerPath -ArgumentList "/C:`"setup.exe /qn ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID=$workspaceId OPINSIGHTS_WORKSPACE_KEY=$workspaceKey AcceptEndUserLicenseAgreement=1`"" -Wait
Linux 系统则需要使用 OMS Agent for Linux。下载安装脚本后执行，安装过程中会交互式询问工作区 ID 和密钥，也可以把这两个值作为参数传给安装脚本，避免交互过程。安装完成后，运行 sudo /opt/microsoft/omsagent/bin/service_control restart 可以重启代理，用 sudo /opt/microsoft/omsagent/bin/omsadmin.sh -l 可以查看当前连接的工作区信息。
手动安装适合小规模场景，服务器数量一旦超过十几台，逐个登录安装就会变得低效，而且容易遗漏。不过手动安装的优点是灵活，不受 Azure 订阅限制，无论是本地物理机、其他云平台的虚拟机还是公司内网的服务器都可以用同样的方式接入。需要注意的是，代理本身不会自动更新，需要定期检查新版本并制定升级计划。
Azure VM 扩展方式自动完成接入
如果你的虚拟机运行在 Azure 上，最省事的做法是启用 Log Analytics 虚拟机扩展。这个扩展本质上是把 MMA 代理的安装和配置打包成一个 Azure 资源扩展，部署时平台会自动在 VM 内部完成代理安装并且关联到指定的 Log Analytics 工作区。扩展只在虚拟机运行 Windows 或 Linux 时可用，Windows 对应的是 MicrosoftMonitoringAgent 扩展，Linux 对应的是 OmsAgentForLinux 扩展。
通过 Azure CLI 可以快速给一台现有 VM 添加扩展。下面的命令演示了为 Linux VM 添加 OmsAgentForLinux 扩展：
az vm extension set \
--resource-group MyResourceGroup \
--vm-name MyLinuxVM \
--name OmsAgentForLinux \
--publisher Microsoft.EnterpriseCloud.Monitoring \
--version 1.13 \
--settings '{"workspaceId": "你的工作区ID"}' \
--protected-settings '{"workspaceKey": "你的主密钥"}'
Windows VM 的命令类似，把扩展名称改成 MicrosoftMonitoringAgent，出版商仍然是 Microsoft.EnterpriseCloud.Monitoring。扩展方式的优势在于重复部署成本低，不管是新创建的 VM 还是已有的 VM，都可以用同样的模板或命令接入。如果配合 Azure Policy 使用，甚至可以做到新 VM 创建后自动连接工作区，避免手动遗漏。不过扩展方式要求 VM 能访问 Azure 的公共端点，如果 VM 位于隔离的虚拟网络中，需要确保网络安全组或路由表允许到 Log Analytics 服务端点的出站流量。
和手动安装相比，扩展方式的一个隐性好处是代理版本由扩展版本决定。当你升级扩展版本时，VM 内部的代理也会跟着更新，省去手动升级代理的工作。但这种自动更新也可能带来风险，比如新版本代理与现有采集配置不兼容，所以在生产环境升级扩展之前最好先在测试环境验证。
容器与 Kubernetes 场景的连接方案
容器化环境下不能直接在容器内部安装 MMA 代理，因为容器生命周期短暂，配置文件会随容器删除而丢失。对于 Kubernetes 集群，Azure 提供了 Container Insights 方案，通过部署一个 DaemonSet 在每个节点上放置一个 OMS 代理容器，这个代理会收集节点和容器的日志以及性能指标，然后把数据发送到 Log Analytics 工作区。启用 Container Insights 时可以选择创建新的工作区，也可以直接关联已存在的工作区。
如果已经有一个 Log Analytics 工作区，可以用下面的 Azure CLI 命令为 AKS 集群启用 Container Insights 并关联到指定工作区：
az aks enable-addons \ --resource-group MyResourceGroup \ --name MyAKSCluster \ --addons monitoring \ --workspace-resource-id /subscriptions/你的订阅ID/resourceGroups/MyWorkspaceRG/providers/Microsoft.OperationalInsights/workspaces/你的工作区名称
这个命令会自动在集群里创建 omsagent DaemonSet，并且每个节点上运行一个代理容器。代理收集的数据包括容器标准输出、Kubernetes 事件、节点性能指标等，这些数据会出现在 Log Analytics 工作区的 ContainerInsights 表中。对于非 Kubernetes 的独立容器，如果使用 Docker 或 containerd，可以考虑在宿主机上安装标准 MMA 代理，通过配置采集 Docker 日志目录或者使用 Fluentd 转发到 Log Analytics。但这种方式维护成本较高，更好的做法是直接使用 Container Insights 的托管方案。
容器连接还有一个容易忽略的问题：日志量突然增大时，工作区的数据保留和成本会明显上升。建议在启用 Container Insights 之前先估算日志生成速率，并且在工作区里设置每日数据上限，避免账单失控。另外要确保集群的出站流量没有被防火墙全部阻断，至少需要放行到 Log Analytics 数据收集端点的 HTTPS 端口 443。
连接失败时的常见排查路径
代理已经安装，但工作区里看不到任何数据，这是最典型的连接问题。第一步应该检查代理服务是否正常运行。Windows 上打开服务管理器查看 Microsoft Monitoring Agent 服务状态，Linux 上运行 sudo systemctl status omsagent 或 sudo /opt/microsoft/omsagent/bin/service_control status。如果服务在运行，接着查看代理日志，Windows 日志路径在 C:\Program Files\Microsoft Monitoring Agent\Agent\ 下的日志文件，Linux 日志在 /var/opt/microsoft/omsagent/log/ 目录里。
日志中常见的一种错误是证书验证失败，这通常意味着 TLS 版本过低。Log Analytics 服务已经要求 TLS 1.2，如果服务器操作系统是旧版 Windows Server 2008 R2 或旧版 Linux 发行版，默认可能只启用 TLS 1.0 或 1.1，需要在系统层面强制开启 TLS 1.2。另一个高频错误是工作区 ID 或密钥配置错误，尤其是在使用静默安装命令时参数传递不完整。可以对比一下工作区门户显示的 ID 和代理配置里的 ID 是否完全一致，注意不要复制进多余的空格。
网络连接问题也占很大比例。数据中心防火墙或代理服务器可能拦截了到 Log Analytics 端点的流量。对于 Azure 公共云，数据收集端点通常是 *.ods.opinsights.azure.com，管理端点通常是 *.oms.opinsights.azure.com。如果服务器需要通过代理出网，需要在代理配置里为这些域名设置例外，或者在 MMA 代理配置中指定代理服务器地址和端口。用 Test-NetConnection 或 nc -zv 命令测试到端点的 TCP 443 连通性，可以快速判断是否为网络问题。
排查的最后一步是确认工作区本身没有达到数据接收限制或处于暂停状态。如果工作区设置了每日上限并且已经达到，新数据会被丢弃。在 Azure 门户的工作区概览页可以查看数据接收量，也可以检查工作区的配额状态。这些排查步骤按顺序执行，大多数连接失败都能定位到具体原因。
OMS Log AnalyticsAzure 监控工作区连接修改时间：2026-09-24 11:33:54