云计算的广泛运用让运维人员从底层基础架构硬件的部署、配置、管理、维护等繁琐工作中解放出来。对于已经上云的企业，有效的云端监控依然必不可少。本次《云监控实战》将基于微软云端解决方案Azure Monitor，通过系列实战教程，全面介绍如何打造云端计算资源监控平台，并结合安全工具有效防范外部攻击，构建体系化的企业安全日志监控系统。

在上一期内容中，我们简要介绍了如何配置Azure Log Analytics以便完成日志采集的准备工作，错过的童鞋可以点击这里回看之前的内容。

本篇，我们将重点介绍如何利用Log Analytics获取虚拟机指标信息，以及Windows和Linux的系统日志。请注意，下列内容均以AZURE CLI 2.x为例，操作环境为Windows10，所有操作由世纪互联运营的Microsoft Azure上完成。

 

使用Log   Analytics获取虚拟机指标信息

按照上期的介绍，我们已经在LA Workspace上连接了第一台Windows 10虚拟机，并获得了心跳信息。这是否意味着我们已经获得了该Windows虚拟机的所有指标（Metric）和日志（Event）？

并没有！这种情况下，LA workspace只拿到了心跳信息而已。由于注入LA workspace的信息会按照数据量收取费用，因此这种默认设置还是很好理解的。

接下来我们将依次给LA workspace管理下的OMS Agent发布搜集信息的指令，并用于搜集：

1. Windows、Linux的CPU、内存、磁盘等指标

2. Windows系统日志（Event）

3. Linux Syslog

4. Windows安全日志

1.  环境准备

资源准备请参考上一期的介绍，并在设置开始前保持LA workspace中的虚拟机处于连接（Connected）状态。

2.  设置LA   Workspace的数据源

点击Workspace里的Advanced settings：

点击Data->Windows   Performance Counters，默认会有图示的指标，选择加入，之后点Save：

至此，该Workspace所连接的Windows OMS   Agent就会开始向LA   workspace发送与CPU、内存、逻辑磁盘相关的日志了。

想要看到这些指标，可以点下图的Logs菜单开启Kusto   Query工作台：

随后输入下列命令：

Perf| take 100| sort by TimeGenerated desc

这样就可以得到这台Windows虚拟机最新的指标日志。其中“Perf”是存放所有Windows、Linux指标的Kusto表，“Take 100”表示获取最新的100条记录，“Sort by   TimeGenerated desc”表示这些日志把最新的日志放在最前面。

注意：这个日志在第一次注入时通常需要5~10分钟的时间。之后的日志时延在1到2分钟左右。具体为什么时延不能再缩小，主要涉及效率问题，把日志Buffer一段时间，Agent批量发送是一个原因，Kusto写索引需要时间也是一个原因。

更具体的技术细节可以参阅微软的相关说明：

典型延迟：延迟是指在受监视系统上创建数据的时间以及可在Azure Monitor中使用该数据进行分析的时间。引入日志数据时的典型延迟时间为2到5分钟。任何特定数据的特定延迟将根据下面介绍的各种因素而变化。

影响延迟的因素

特定数据集的总引入时间可以细分为以下几个高级别区域。

• 代理时间：发现事件、收集事件，然后将其作为日志记录发送到Azure Monitor引入点的时间。大多数情况下，此过程由代理处理。

• 管道时间：引入管道处理日志记录的时间。包括解析事件属性，并且可能会添加计算信息。

• 索引时间：将日志记录引入到Azure   Monitor大数据存储所花费的时间。

下面将详细介绍该过程中引入的不同延迟。

代理收集延迟：代理和管理解决方案使用不同的策略从虚拟机收集数据，这可能会影响延迟。一些具体示例包括：

• 立即收集Windows事件、syslog事件和性能指标。Linux性能计数器每隔30秒轮询一次。

• IIS日志和自定义日志在其时间戳更改后收集。对于IIS日志，这会受IIS上配置的滚动更新计划影响。

• Active Directory复制解决方案每五天执行一次评估，而Active   Directory评估解决方案每周对Active Directory基础结构进行一次评估。只有在评估完成后，代理才会收集这些日志。

代理上传频率：为确保Log Analytics代理保持轻型，代理会缓冲日志并定期将其上传到Azure Monitor。上传频率在30秒到2分钟之间变化，具体取决于数据类型。大多数数据可在1分钟内上传。网络状况可能会对数据抵达Azure Monitor引入点的延迟产生负面影响。

Azure活动日志、资源日志和指标。Azure数据增加了额外的时间，以便在Log   Analytics引入点处可用于处理：

• 资源日志中的数据需要2到15分钟，具体取决于Azure服务。请参阅下面的查询，以便在你的环境中检查此延迟

• 将Azure平台指标发送到Log   Analytics引入点需要3分钟。

• 将活动日志数据发送到Log Analytics引入点大约需要10到15分钟。

• 数据在引入点处可用后，还需要2到5分钟才能进行查询。

注意：我们曾有用户遇到过了2~3个小时才收到日志的情况。最后查下来发现日志是由Linux Diag Agent搜集的日志。这个Agent如何工作以后再叙述。我们在这里要了解的是，如果LA workspace注入的日志时延超过了20分钟，基本上就应该是有问题需要诊断了。

 

获取Windows系统日志

在获取了Windows虚拟机的指标信息后，又该如何获得Windows系统日志？

类似的操作，请点击Workspace里的Advanced settings：

随后点击Data->Windows   Event logs，这时输入System，选择加入，之后选择Save：

至此，所有连接到SecSpace这个Workspace的Agent都会开始为LA workspace搜集System、Application、Setup等Windows日志了。

注意：这里并没有Security日志。Windows Security日志必须要开启Security Center的Workspace级别Standard Tier定价层，才能由LA workspace搜集、索引和按字段搜索。

要想找到搜集到的Event   log，可以在LA Workspace的查询Event中查找。

注意：通常新日志搜集进来需要有5~10分钟的延时。

随后只需输入下列Kusto查询语句：

Event| sort by TimeGenerated desc| take 100

就可以看到System、Application和Operation Manager的日志。

至于Windows的System、Application和Setup日志都分别是什么，请打开Windows虚拟机中的事件查看器，可以看到它们属于Windows   logs的主要日志。Windows有故障时会在本地搜索这个日志。微软的Windows技术支持部门每天不少用这个工具。有了LA的Kusto，我们就可以不再使用过滤功能不够强大的事件查看器工具了。

至于System、Application、Setup日志分别搜集什么，可以参考：

• Application应用程序–由本地计算机上托管的应用程序记录的信息。

• Setup设置–安装和升级Windows操作系统时生成的消息。如果Windows系统是域控制器，则这些消息也会记录在这里。

• System系统– Windows操作系统生成的消息。

• Forwarded Events转发的事件–当本地计算机充当中央订户时，其他计算机转发的事件。

• Applications and Services   Logs应用程序和服务日志 - 包括硬件事件，Internet   Explorer和Windows   PowerShell事件的类别。

• Security安全性–与登录尝试（成功和失败），提升的特权以及其他审核事件有关的信息。     

 

获取Linux   Syslog

之前的内容中，我们以一台Windows 10虚拟机为例，通过OMS Agent（MMA）搜集了虚拟机指标和日志信息，并用Kusto语句构建自己的查询表和图表。

接下来，我们试试看使用LA管理Linux虚拟机。

1.  环境准备

请准备好下列资源：

• 资源组：AzMRGe2（位置在China East2东二区） - [之前已创建]

• LA workspace：SecSpace，实现日志中心功能，用于存储需要实时查看分析的日志 - [之前已创建]

• 资源组：AzMRGn（位置在China North北一区） - [之前已创建]

• 虚拟机：cent-BA0-vm01

• 存储账户：stgn，log存储账户，NSG日志需要存储到存储账户 - [之前已创建]

注意：实验中虚拟机和LA workspace不在同一区，可以让大家了解LA workspace可以服务跨区域资源。

2.  创建资源组、LA   Workspace和存储账户

使用Azure CLI进行创建：​​​​​​​

az cloud set --name AzureChinaCloudaz login//[之前已创建] 创建 LA workspace, 只能在东二区创建，所以需要在东二区创建一个资源组az group create -l chinaeast2 -n AzMRGe2//[之前已创建] 创建 LA workspace, 日志保留 30 天 (保留时间以后还可以改动)az monitor log-analytics workspace create --resource-group AzMRGe2 --workspace-name SecSpace --retention-time 30//[之前已创建] 创建虚机使用的资源组az group create -l chinanorth -n AzMRGn// 创建 CentOS Linux 虚拟机az vm create --name cent-BA0-vm01 --resource-group AzMRGn --image OpenLogic:CentOS:7.6:7.6.201909120 --size Basic_A0 --admin-username azureuser --admin-password REPLACEYOURPASS//[之前已创建] 创建存储账户az storage account create -n stgn -g AzMRGn --sku Standard_LRS

3.  连接 LA   Workspace

点击cent-BA0-vm01这个主机名，然后点连接：

连接过程中可以通过tail -f /var/log/messages了解安装进度：

连接前，默认状态可以看到该虚拟机只有LinuxDiagnostic这一种Agent：
下图没有因为Linux LinuxDiagnostic因为被手工删除了。
连接后的多出了OmsAgentForLinux,并且状态改为Provisioning 成功的状态：

注意：如果OMS   Agent连不上，可以尝试先删除Linux Diag Agent。如果依然连接不上，可以按这里列出的步骤删除再Connect一下。

接下来，可以查查Linux虚拟机的心跳信号收集上来了没有：

确认无误后，添加要监视的Linux指标：

随后在LA workspace里搜到的指标如下图：

接下来需要搜集Linux日志。此处请注意，默认支持的Syslog文件有十几种，详见这里：

• kern

• user

• mail

• daemon

• auth

• syslog

• lpr

• news

• uucp

• cron

• authpriv

• ftp

• local0-local7

试着添加几个指标：

如果没看到Log，可以检查omsagent.conf文件，并确认其中是否包含下列内容：

cat /etc/rsyslog.d/95-omsagent.conf​​​​​​​

----------------------------------------------------------------------------------
# OMS Syslog collection for workspace 02ccb4e7-3777-4001-9d60-dfea75dd96b5
auth.=alert;auth.=crit;auth.=debug;auth.=emerg;auth.=err;auth.=info;auth.=notice;auth.=warning @127.0.0.1:25224
authpriv.=alert;authpriv.=crit;authpriv.=debug;authpriv.=emerg;authpriv.=err;authpriv.=info;authpriv.=notice;authpriv.=warning @127.0.0.1:25224
daemon.=alert;daemon.=crit;daemon.=debug;daemon.=emerg;daemon.=err;daemon.=info;daemon.=notice;daemon.=warning @127.0.0.1:25224
kern.=alert;kern.=crit;kern.=debug;kern.=emerg;kern.=err;kern.=info;kern.=notice;kern.=warning @127.0.0.1:25224
syslog.=alert;syslog.=crit;syslog.=debug;syslog.=emerg;syslog.=err;syslog.=info;syslog.=notice;syslog.=warning @127.0.0.1:25224
user.=alert;user.=crit;user.=debug;user.=emerg;user.=err;user.=info;user.=notice;user.=warning @127.0.0.1:25224----------------------------------------------------------------------------------

确认无误后，应该就可以看到Linux日志并进行搜索了。

Linux的日志都在Syslog这个表里，因此请使用如下命令：

Syslog| sort by TimeGenerated desc| take 100

随后可以看到：

尝试着用如下命令过滤出SSH login的记录：

Syslog| where Facility contains "auth"| where ProcessName == "sshd"| where SeverityLevel == "info"| where SyslogMessage contains "user"| where SyslogMessage contains "Failed password"| extend SyslogMessage=replace(' ',' ', SyslogMessage)| extend SyslogMessage=replace(' ',' ', SyslogMessage)| extend SyslogMessage=replace(' ',' ', SyslogMessage)| extend SyslogMessage=replace(' ',' ', SyslogMessage)| extend text1=split(SyslogMessage, " ")[0]| extend text2=split(SyslogMessage, " ")[1]| extend text3=split(SyslogMessage, " ")[2]| extend text4=split(SyslogMessage, " ")[3]| extend text5=split(SyslogMessage, " ")[4]| extend username=split(SyslogMessage, " ")[5]| extend text6=split(SyslogMessage, " ")[6]| extend ip_add =split(SyslogMessage, " ")[7]| extend text7=split(SyslogMessage, " ")[8]| extend src_port =split(SyslogMessage, " ")[9]| sort by TimeGenerated desc| take 100

可以看到如下图所示的结果：

有经验的运维人员应该可以知道，这意味着由于SSH端口对Internet开放，引来了无数的字典攻击。

关于这套云端监控系统的前期准备工作大致就是这些内容了，对Azure Log Analytics感兴趣的同学可以参阅官方文档，进一步了解该服务的详细使用方法。

本系列文章的后续内容，我们将以采集到的日志为基础，介绍如何对所有信息进行分析和可视化展示，并在此基础上进一步打造我们自己的安全监控系统。敬请期待！