设备SYSLOG日志采集 ****************** 收集交换机推送的日志。 采集侧 =========== 采集原理 ~~~~~~~~~ 交换机厂商的日志，会推送至syslog服务器上。syslog再将接收的日志发送至采集平台。日志采集需要将日志解析出来， 根据RFC3164协议来解析。得到日志的的类别，优先级，发送的设备IP，日志时间，日志内容。 .. attention:: *设备日志不需要主动采集，会被动推送* .. attention:: *部分设备不能解析出IP地址，只能解析出设备名，需要做一次从CMDB的查找* 任务处理流程 ~~~~~~~~~~~~~~ a. 接收日志信息； #. 对接收的日志去重，在1分钟内收到的日志条目，接收的syslog信息的时间戳和message部分hash值一样的，只保留一条。 #. 对日志做解析，按RFC3164协议来解析。提取出时间戳、优先级、HOSTNAME、message等信息。 #. 如果HOSTNAME部分为IP地址，则通过IP地址查询CMDB（优先带内，再带外）；如果是非IP地址，则按设备名字查询CMDB，如果CMDB有多条返回值，优先选择设备流程状态为在线，且有IP地址的条目。如果依旧有多条，选择第一条即可。 #. 做数据染色 数据染色 ~~~~~~~~~~~~~~~~ a. 时间戳（接收时间） #. 业务线 #. 区域(地域) #. 机房 #. POD #. 房间 #. 机柜 #. 业务属性（服务角色） #. 设备角色 #. 带内管理IP #. 带外管理IP #. 设备名 #. 厂商 #. 设备品牌 #. 设备型号 #. 设备流程状态 #. syslog时间戳 #. syslog优先级 #. syslogMessage 设备推送日志示例 ~~~~~~~~~~~~~~~~~~~~~~~~ 如下是一台H3C系列交换机的推送的一条端口状态变化的日志。 .. code-block:: shell 2019 Feb 21 00:20:41 <172.22.129.125> [err] -DevIP=172.22.129.125; GigabitEthernet1/0/18 link status is UP. 数据分析和报警 ================== SYSLOG信息包含较多内容，需要比较高的自助灵活配置实现对异常的检测。分三个步骤来实现数据分析和报警。 #. 定义异常，定义异常的一个名字，只用于识别。诸如“端口UP/DOWN”，“板卡异常”等等。 #. 定义异常的匹配规则，即如何通过日志message信息匹配出符合异常的信息。 #. 定义报警策略，即报警规则和阈值等设置。 定义异常 ~~~~~~~~~~~~~~~~ .. list-table:: :widths: auto :stub-columns: 1 :align: left * - **异常名称** - 故障的名字 * - **是否过滤下联端口** - 因为有些特殊情况，我们会过滤掉一些T0的下联服务器的端口。这个目前只用于端口up/down。仅仅用于T0。何谓下联端口需要一定规则指出。 定义异常匹配规则 ~~~~~~~~~~~~~~~~ 同一类异常，不同厂商的关键字信息，筛选信息都不太一样。需要针对不同厂商的做不同的定制。 .. list-table:: :widths: auto :stub-columns: 1 :align: left * - **品牌名称** - 交换机的品牌。需要根据日志条目里渲染的设备产生信息去针对性匹配。 * - **异常** - 选择异常名，仅限在异常信息维护信息里维护的部分 * - **关键在** - 从日志原文中匹配出异常的关键字。**必须大写** * - **告警匹配规则** - 分为两种，关键字和正则。关键字的话只要匹配上了上述的关键字，即视为匹配成功。正则则需要关键字+后面配置正则信息一块匹配上才算匹配成功。 * - **正则** - #. 告警匹配规则是正则的时候，必选。其他可选。支持从正则中扣选出一个字段，作为 ``部件信息``。也可以不扣选，则 ``部件信息`` 为空。 #. 告警匹配规则是关键字的时候，可选。支持从正则中扣选出一个字段，作为 ``部件信息``。也可以不扣选，则 ``部件信息`` 为空。 策略配置 ~~~~~~~~~~~~~~~~~ .. warning:: 对于端口在专线或者出口列表里的端口，不能进入此分析过程，他们单独应用于专线和出口。 .. list-table:: :widths: auto :stub-columns: 1 :align: left * - **策略名** - #. 报警策略名字 * - **异常类型** - 定义异常里的异常 * - **策略筛选条件** - #. 业务线 #. 区域(地域) #. 机房 #. POD #. 业务属性（服务角色） #. 设备角色 #. 设备IP、IP地址段 * - **策略生效时间** - 支持到小时级别（0-23） * - **触发阈值** - M分钟内出现S次（M,S为整数）。 * - **恢复阈值** - # 是否支持恢复。对于部分异常，是没法支持恢复。需要增加此选项做识别 # 对于支持恢复的，X分钟内出现Z次（X,Z为整数）。默认X=M，Z=0 # 部分异常还需要额外的数据来满足恢复条件。需要个性化的定制。（比如端口状态的恢复检查，需要依赖其他的数据） * - **策略生效状态** - 默认为策略生效状态，开启时源数据进入告警分析模块进行计算和比对，禁用时源数据不进行告警分析 * - **策略告警等级** - 用于标识该策略的告警重要性程度，分5个等级：A1严重，A3主要，A5次要，A7一般，A9通知 * - **告警组和通知方式** - #. 告警组，将不同人员分成不同的组，按组的方式发送告警； #. 通知方式：邮件、咚咚、微信、短信、电话；针对每个组可多选或者不选； 策略筛选条件的互斥关系 ~~~~~~~~~~~~~~~~~~~~~~~~ a. 机房--POD--设备IP--端口名，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；当且仅当机房、POD同时处于单选状态下方可继续选择设备IP； #. 区域--机房，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择； #. 设备IP地址仅仅可以在没有任何其他项勾选的情况下，才可以支持手工输入多个IP地址，或者多个地址段； 报警信息格式 ~~~~~~~~~~~~~~~~~~~~ 报警信息分为两种，一种是触发阈值告警，一种是满足恢复阈值告警。我们把它称之为告警状态，分为 ``告警`` ``恢复`` 。因为告警通道的的不通，为了便于阅读。需要针对不同渠道的报警设置信息格式。 .. warning:: 只有有恢复类型的告警才有恢复时间，持续时间。 .. code:: shell 邮件： ----------------------- 标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【机房，POD，角色，设备IP，``部件信息`` 】 邮件内容： 故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）， 业务线，区域，机房，POD，业务属性，设备角色, 设备IP，设备名称 ``部件信息`` syslogMessage 短信，咚咚，电话，微信： ------------------------ 【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警状态（告警/恢复）】【告警等级】【告警策略名】 【机房，POD，角色，设备IP，设备名称】【 ``部件信息`` 】 【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】 报警的默认收敛规则 ~~~~~~~~~~~~~~~~~~~~ 对重复的报警信息，实行收敛。 a. 即一条策略被触发后，发送报警通知。同时更新一些计数器。 #. 如果在未满足恢复阈值前提条件下，再次触发了阈值，则该次触发的报警被抑制，不对外发送报警信息。但会涉及一些计数器的更新。 #. 当满足恢复阈值时候，发送告警恢复信息。同时更新一些计数器。对于没有恢复类型的告警，在30分钟内再次受到新的报警，则不对外发送。重新开始计时。直到30min之内没有新报警到来之后。 #. 之后，如报警阈值被再次满足，则对外发送新的报警通知。 关于报警时间的规则 ~~~~~~~~~~~~~~~~~~~~~~ 整个策略匹配过程及报警过程中，分别涉及多个时间，做如下说明。 1.故障开始时间：第一次触发阈值（满足告警阈值的第一个点的时间） 2.故障触发告警时间：满足告警频次达到告警条件 3.告警通知时间：告警平台对外发送告警通知的时间 4.聚合告警通知时间：故障触发告警时间满足告警聚合周期，多条告警聚合后的由告警平台发出的告警通知时间（仅仅在有聚合报警策略的情况下），有4没有3。 --以下仅针对有恢复的策略-- 5.故障持续时间：未恢复的告警，从故障开始时间计算到当前时间点的时间段，在告警实时看板中展示；恢复的告警，故障持续时长=故障恢复时间-故障开 始时间； 6.故障恢复时间：第一个满足恢复条件的时间，通常只有在触发了第7个“故障触发恢复条件时间”时才会被记录 7.故障触发恢复条件时间：满足恢复阈值和频次达到恢复条件 8.恢复通知时间：告警平台发送恢复通知的时间 9.聚合恢复通知时间：故障触发恢复时间满足恢复聚合周期，告警平台发出的恢复通知时间（仅仅在有聚合报警策略的情况下），有9没有8 和NOC工单系统的联动 ~~~~~~~~~~~~~~~~~~~~~~~ 对于产生的故障告警，需要推送给NOC工单进入工单管理。需要根据工单返回结果对该告警做一个标记，表示目前关于此告警的工单的处理情况。 处理规则： #. 对于产生的告警（而非进行聚合后的告警，即聚合前的单条告警。），需要推送给NOC工单平台，根据noc平台的返回信息对该条告警设置一个 ``工单状态标记`` 。 #. 当NOC工单对该单条告警改变了状态，需要同步的跟新报警系统中该条报警的 ``工单状态标记`` ； #. 当NOC工单标记为“已完成”，则触发告警恢复，忽略掉恢复阈值的检测，对外发送告警恢复信息；同时这条告警彻底清除，即便真实情况下告警并未恢复。 #. 如果告警恢复阈值检测到满足，则触发告警恢复信息，同时通知NOC工单平台修改该工单状态为"已完成", 关闭工单。 #. 对于没有告警恢复的告警，30min内没有新告警到达。则清除条目。有新告警到达，则更新24H累计告警数。然后重新开始计时。 告警池字段要求如下： #. 故障开始时间 #. 故障持续时间 #. 异常名 #. 设备IP #. 部件名 #. 告警关键字 #. 设备角色 #. 业务线 #. 机房 #. 历史告警数（24H） #. NOC工单状态 NOC工单状态说明 ~~~~~~~~~~~~~~~~~~ +---------------+----------+----------------------------------+ | NOC返回状态值 | 状态 | 说明 | +---------------+----------+----------------------------------+ | 1 | 新工单 | 告警事件生成工单的初始状态 | +---------------+----------+----------------------------------+ | 10 | 待处理 | NOC人员接单后触发这个状态 | +---------------+----------+----------------------------------+ | 20 | 处理中 | NOC人员进行处理操作 | +---------------+----------+----------------------------------+ | 21 | 已转派 | NOC人员处理不了转派给网络运维 | +---------------+----------+----------------------------------+ | 99 | 已取消 | NOC人员进行取消操作 | +---------------+----------+----------------------------------+ | 100 | 已完成 | NOC人员进行跟进确认后触发该状态 | +---------------+----------+----------------------------------+ | 101 | 自动恢复 | 这个是根据告警这边的恢复通知生成 | +---------------+----------+----------------------------------+ 可视化 ================== 以单台设备维度，展示SYSLOG日志信息 #. 以表格形式，展示解析后的日志信息。 #. 支持关键字搜索日志message 以全网设备维度，统计一天内syslog日志量（条目数）的TOP N。设备信息。 #. 表格形式展示。包括 机房、POD、设备IP、设备名、设备角色、设备IP 未完成的部分 ================== #. 自助任务下发； #. 策略的分级，即按类似ACL的方式匹配策略；需求未提 #. 实现业务线的支持，或者所是多用户的支持； #. 重复告警抑制 #. 基于LLDP抑制邻居端口UP/DOWN告警