• 文章搜索:
  • 唯快不破

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    流量监控-唯我独尊排错篇

    作者:  |  上传时间:2014-11-25  |  关键字:流量监控-唯我独尊排错篇

    配置篇中我们已经介绍了各种日志结合NTA/UBA做流量监控与行为审计的配置,如果按照指导配置完成后却不能正常看到流量统计情况,可按如下步骤来进行排查。

    一. Netstream方式

    1. 查看iMC服务器上NTA/UBA进程都运行正常,如果处于停止状态请右键“启动”,如下图1:

    图1

    2. 查看设备上是否正确配置了netstream功能并运行正常,可执行命令display ip netstream cache ,如下图2:

    图2

    可以看到配置的netstream已经正常运行,active老化时间为30m,inactive老化时间为30s,最大数据流实体数为10000,目前cache中有IP流173条等信息。

    3. 查看设备是否正确发出了netstream日志报文,可执行命令display ip netstream export,如下图3:

    图3

    可以看到设备已经向172.16.0.20:9020发送netstream日志了,source interface没有内容代表发送源即为上连服务器的接口,截止目前一共以V5格式统计了382条数据流,发送出了36个netstream V5报文了,V9格式的没有输出。

    4. 确认服务器上收到了日志报文

    最直接的方法就是在NTA/UBA所在的服务器上抓包,过滤UDP端口为9020的报文,应该可以看到有报文发送过来,如下图4:

    图4

    如果没有收到报文则可能是由于网络中有防火墙把日志报文过滤了,或者设备上配置的NTA/UBA服务器IP地址不对,请排查确认。

    5. 查看NTA/UBA服务器receiver进程是否正确收到了日志数据,正常情况下应该会在iMC\data\recieverData目录下不断有.csv格式的文件生成更新,如下图5:

    图5

    如果没有文件生成则可能是由于服务器本身开启了防火墙功能,导致虽然网卡收到了日志报文但报文却没有正确地被receiver进程接收;如果不断有文件积压,则可能是由于processor进程启动异常导致接收到的数据没有被及时处理,重新启动processor进程即可。

    6. 确认统计数据是否成功地存入了数据库,正常情况下10分钟左右应该可以在数据库中看到有*tbl_nets_*的表生成,此表中记录的是接收到的原始日志数据,如下图6:

    图6

    注:如果部署了UBA则在此处可以看到,如果没有部署UBA的话默认是看不到的,需要在“配置管理-服务器管理”页面,开启服务器的“捕获原始日志”功能。

    7. 如果以上步骤都没有问题,但在iMC界面还是看不到流量统计信息时则可能是由于设备时间与NTA/UBA服务器时间设置不一致,导致NTA/UBA已经正确收到了数据但是由于时间上有差异而无法正常显示;或设备时区与NTA/UBA服务器时区不一致,导致数据处理异常。请确认设备所处时区及当前时间与服务器一致。

    8. 也有可能是设备接口索引和NTA/UBA服务器识别的索引不一致造成的,可在iMC平台中查看识别到的接口索引信息,进入“设备详细信息-接口列表”如下图7:

    图7

    同时在建立流量分析任务时查看NTA/UBA识别到的设备接口和平台识别到的是否一致,如下图8:

    图8

    9. 确认以上步骤都正常后如果还是没有数据显示则可能是服务器磁盘空间达到了配置的阈值,导致停止接收和处理日志了,具体的阈值和超过阈值的处理策略可以在“服务器管理”中看到,同时也可在“数据库空间使用”中查看目前NTA/UBA所在磁盘的空间利用情况,这时可以通过手工清理磁盘空间、删除旧日志等来解决,也可在磁盘空间达到阈值之前配置告警监控磁盘空间,日志转储等来避免此问题。

    10. 如果以上步骤排查完后还是不能解决问题请收集以下信息联系H3C客户服务热线4008100504处理。

    配置信息:将配置过程中的所有内容截图、设备日志方面的配置内容反馈,将NTA/UBA服务器上的\imc\unba\conf目录下的所有文件打包反馈;

    DEBUG日志信息:以cmd的方式进入\imc\unba\bin文件夹,分别修改接收器和处理器的日志级别为DEBUG,执行命令

    receiver.exe loglevel debug

    processor.exe loglevel debug

    然后等待10分钟左右将\imc\unba\log目录下的日志打包反馈,同时反馈在此过程中NTA/UBA服务器上的抓包信息。

    完成后将日志级别从DEBUG改回WARNING,执行命令

    receiver.exe loglevel warning

    processor.exe loglevel warning

    二. SFLOW方式

    1. 查看iMC服务器上NTA/UBA进程都运行正常,如果处于停止状态请右键“启动”,如下图9:

    图9

    2. 查看设备上是否正确配置了sflow功能并且运行正常,执行命令display sflow,如下图10:

    图10

    可以看到当前sflow版本为V5,Agent地址为172.16.0.1,source地址为空则代表日志发送的源地址即为Agent地址,接收器collector地址为172.16.0.20:9020,设备的接口G0/1下开启了sflow功能并且目前处于active状态(正常)。

    3. 查看NTA/UBA服务器上是否收到了设备发送过来的日志报文,正常情况下应该可以抓到UDP端口为9020的报文,如下图11:

    图11

    如果没有收到报文则可能是由于网络中有防火墙把日志报文过滤了,或者设备上配置的NTA/UBA服务器IP地址不对,请排查确认。

    4. 查看NTA/UBA服务器receiver进程是否正确收到了日志数据,正常情况下应该会在C:\Program Files\iMC\data\recieverData目录下不断有.csv格式的文件生成更新,如下图12:

    图12

    如果没有文件生成则可能是由于服务器本身开启了防火墙功能,导致虽然网卡收到了日志报文但报文却没有正确地被receiver进程接收;如果不断有文件积压,则可能是由于processor进程启动异常导致接收到的数据没有被及时处理,重新启动processor进程即可。

    5. 确认统计数据是否成功地存入了数据库,正常情况下10分钟左右应该可以在数据库中看到有*tbl_nets_*的表生成,此表中记录的是接收到的原始日志数据,如下图13:

    图13

    注:如果部署了UBA则在此处可以看到,如果没有部署UBA的话默认是看不到的,需要在“配置管理-服务器管理”页面,开启服务器的“捕获原始日志”功能。

    6. 如果以上步骤都没有问题,但在iMC界面还是看不到流量统计信息时则可能是由于设备时间与NTA/UBA服务器时间设置不一致,导致NTA/UBA已经正确收到了数据但是由于时间上有差异而无法正常显示;或设备时区与NTA/UBA服务器时区不一致,导致数据处理异常。请确认设备所处时区及当前时间与服务器一致。

    7. 另一个可能原因是设备接口索引和NTA/UBA服务器识别的索引不一致造成的,可在iMC平台中查看识别到的接口索引信息,进入“设备详细信息-接口列表”如下图14:

    图14

    同时在建立流量分析任务时查看NTA/UBA识别到的设备接口和平台识别的是否一致,如下图15:

    图15

    8. 确认以上步骤都正常后如果还是没有数据显示则可能是服务器磁盘空间达到了配置的阈值,导致停止接收和处理日志了,具体的配置内容可以在服务器管理中看到,如下图所示:

    这时可以通过手工清理磁盘空间、删除旧日志等来解决,也可在磁盘空间达到阈值之前配置告警监控磁盘空间,日志转储等来避免此问题。

    9. 如果以上步骤排查完后还是不能解决问题请收集以下信息联系H3C客户服务热线4008100504处理

    配置信息:将配置过程中的所有内容截图、设备日志方面的配置内容反馈,将NTA/UBA服务器上的\imc\unba\conf目录下的所有文件打包反馈;

    DEBUG日志信息:以cmd的方式进入\imc\unba\bin文件夹,分别修改接收器和处理器的日志级别为DEBUG,执行命令

    receiver.exe loglevel debug

    processor.exe loglevel debug

    然后等待10分钟左右将\imc\unba\log目录下的日志打包反馈,同时反馈在此过程中NTA/UBA服务器上的抓包信息。

    完成后将日志级别从DEBUG改回WARNING,执行命令

    receiver.exe loglevel warning

    processor.exe loglevel warning

    三. DIG格式

    1. 查看probe进程是否运行,方法是通过命令:ps –ef | grep probe;没有运行的话可进入探针安装目录下的unba\bin目录,执行./monitor来手工启动探针进程。如果手工还是不能启动则可能原因是安装探针不对,即单核系统安装了多核探针,或者多核系统安装了单核探针,也可能是安装探针后没有重新启动服务器;

    2. 如果探针进程运行正常,那么看/data/目录下是否时刻有日志生成,如果没有可能原因是在iMC UBA服务配置中没有进行配置下发,请进行配置下发; 或者服务器下发配置超时,导致探针没有正常工作,这有可能是探针服务器开启了防火墙功能,查看方法是通过命令iptables -L看是否有出入过滤规则;

    3. 查看NTA/UBA服务器上配置的ftp目录下是否实时有日志从探针服务器传过来;如果没有日志传过来,请检查ftp server是否启动,如果启动请检查ftp给探针服务器分配的用户是否具有写权限,中间是否有防火墙将日志给阻断了,简单方法是从探针服务器以ftp登录到NTA/UBA服务器并上传文件检查。

    4. 确认统计数据是否成功地存入了数据库,正常情况下10分钟左右应该可以在数据库中看到有*tbl_nets_*的表生成,此表中记录的是接收到的原始日志数据,如下图16:

    图16

    注:如果部署了UBA则在此处可以看到,如果没有部署UBA的话默认是看不到的,需要在“配置管理-服务器管理”页面,开启服务器的“捕获原始日志”功能。

    5. 如果数据库里已经可以正常存入数据了,但是页面上还是没有流量显示,则可能是探针服务器的时间与NTA/UBA服务器的时间不一致,或者探针的版本和NTA/UBA服务器的版本不一致造成,请检查确认修改。

    6. 如果以上步骤排查完后还是不能解决问题请收集以下信息联系H3C客户服务热线4008100504处理

    配置信息:将配置过程中的所有内容截图、设备和探针服务器的配置内容反馈,将NTA/UBA服务器上的\imc\unba\conf目录下的所有文件打包反馈;

    DEBUG日志信息:以cmd的方式进入\imc\unba\bin文件夹,分别修改接收器和处理器的日志级别为DEBUG,执行命令

    receiver.exe loglevel debug

    processor.exe loglevel debug

    然后等待10分钟左右将\imc\unba\log目录下的日志打包反馈,同时反馈在此过程中NTA/UBA服务器上的抓包信息。

    完成后将日志级别从DEBUG改回WARNING,执行命令

    receiver.exe loglevel warning

    processor.exe loglevel warning