seo百度站长工具,网站功能建设描述书,市场调研的重要性,阿里云备案网站备案本文选自 《交易技术前沿》总第三十六期文章(2019年9月)陈靖宇深圳证券交易所 系统运行部Email: jingyuchenszse.cn摘要#xff1a;为了应对基础设施规模不断上升#xff0c;数据中心两地三中心带来的运维挑战#xff0c;深交所结合现有基础设施现状#xff0c;以通用性、灵…本文选自 《交易技术前沿》总第三十六期文章(2019年9月)陈靖宇深圳证券交易所 系统运行部Email: jingyuchenszse.cn摘要为了应对基础设施规模不断上升数据中心两地三中心带来的运维挑战深交所结合现有基础设施现状以通用性、灵活性为目标实现对基础设施的自动化监控和运维。本文从基础设施运行的实际情况出发借助IPMISNMPwalk日志等多种方式采集数据实现了基础设施的运维监控以及可视化。目前系统已经初步上线运行稳定为后续以数据为基础的智能化基础设施运维打下坚实的基础关键词基础设施、硬件监控、数据可视化一、背景随着云计算大数据的大量运用基础设施的规模不断扩大硬件故障的发生频率逐渐上升故障的响应的时效性准确性以及故障的复杂性给基础设施运维提出了更高的要求。为了更好的运维基础设施高效的硬件监控必不可少相比于应用、中间件、操作系统的监控硬件监控存在信息量少采集途径有限数据不标准的特点。因此搭建统一的硬件监控平台显得尤为重要。 目前基础设施硬件监控有以下三个方面问题1、 基础设施尤其是服务器的品牌众多难以有标准统一的监控指标。由于业务系统的不断更新和上线服务器的采购需求变更等原因现有服务器的品牌不统一同品牌服务器型号不相同BMC管理系统版本不一致导致运维的成本上升复杂性提高。2、 指标的种类繁多却难以准确的反映基础设施的状态。由于基础设施的品牌、型号不同设备的传感器数量指标的名称、类型多样同时后续新增的设备同样会有不同的指标对于监控告警的设计要求兼顾数据完备性和灵活性的要求。3、 基础设施的关键部件故障需要提前预警。比如服务器的硬盘虽然可以通过RAID实现高可用但是在服务器数量上升到一定数量级后硬盘的频繁不定期更换会使得运维人员疲于应对。理想的情况是提前预测故障在特定的操作窗口下预先更换备件以达到有备无患的目的。二、IAAS基础设施监控方案选型物理服务器交换机F5防火墙是最常见的4类基础设施数据的采集方式有日志、SNMPwalk、IPMISNMPTrap等方式。具体的监控方式需要针对不同的设备类型和管理端的功能以及运维的需求进行选择。日志是相对通用的采集数据源基础设施都有相应的日志系统提供各个维度的日志由于日志属于相对滞后的数据信息在系统发生事件后才会在日志中写入因此往往作为排查故障的用途而且交换机F5防火墙的日志生产数据多容量大难以做到实时采集分析告警有效的故障信息密度很低不利于搭建基于日志的故障监控告警系统。SNMPwalk通过主动发送设备定制的OID来获取数据可以实现高频次的数据采集时效性较好但数据的可读性较差需要进行数据的处理整合并丰富基本信息来作为监控的指标。IPMI是物理服务器BMC管理端实现的基础协议通过该方式可以实现对服务器状态的完整监控取得包括传感器状态日志固件信息网络配置用户管理等内容并且不受服务器类型种类固件版本的限制适配性较好。虽然不同的服务器传感器数量有差异但总体上的关键指标都有采集。传统的监控方式是通过在基础设施的管理端配置SNMPTrap发包的告警对接到告警平台实现硬件的故障感知和响应。这种方式存在以下缺点SNMPTrap包的内容难以解析可读性差而且发包的机制难以准确判断发送无效告警的几率高。比如HP服务器存在当固件版本与ILO版本不适配时SNMP将会频繁发包但是不影响业务使用只能通过屏蔽OID的手段忽略告警。采集的数据量较少被动依靠SNMP发包难以实现灵活主动的监控管理。SNMPTrap的机制是通过BMC管理系统判断系统是否存在异常之后发送SNMPTrap包实现告警功能对于运维人员来说该机制实际上是个黑盒很多包的OID的含义难以查询不利于快速响应故障。通过分析上述数据采集的方式我们针对不同的基础设施设计了相应的数据采集方案:1、物理服务器的BMC日志数据量小且准确有着比较完备的BMC管理端故障信息密度高适合基于IPMI的方式进行硬件监控IPMI采集传感器和BMC日志来进行硬件监控。2、交换机F5防火墙日志数据量大难以提取有效信息往往作为故障发生后的定位、自查的作用因此选择SNMPwalk 的方式采集指标并进行数据的整合来实现监控告警而日志采集后作为故障定位的备查数据源利用日志数据可读性强的优点借助告警时间准确查询小范围时间内的日志来丰富告警信息。3、针对基础设施没有提供接口的数据采集通过expect脚本登陆采集的方式获取数据。比如交换机vlan划分端口映射等数据。三、IAAS基础设施监控方案实现3.1 总体架构设计图1 基础设施监控架构图整体的监控框架分为IAAS层采集层存储层和应用层。如图1所示IAAS层包含服务器、交换机、F5、防火墙四类基础设施采集层实现IPMI、 SNMPwalk、日志ssh登陆采集等数据收集端。IPMI、SNMPwalk、日志等方式有其先天缺点由于其采集效率依赖基础设施管理端的性能使得在基础设施规模日益增长的场景下顺序采集信息的效率过低因此我们设计通过线程池并发的方式来实现分钟级的硬件监控。我们在存储层针对不同的数据类型进行分类保存指标类型数据经过标准化后存入时序数据库ClickHouse日志类文本型数据存入ElasticSearch数据库基础设施标准静态配置数据存入mysql数据库。最后在应用层实现标准数据的展示、指标数据及基线计算、日志数据分析等功能。指标的采集和数据标准化和数据可视化是本文的重点后续将就指标类型数据处理日志数据处理以及数据可视化三方面介绍基础设施监控设计方案。3.2 指标数据采集服务器方面主要包含HP、H3C、Inspur、Dell等品牌基于IPMI协议通过lanplus接口获取服务器的传感器和日志信息。虽然不同品牌的服务器的传感器数量差异导致采集的数据粒度不同但是采集的IPMI指令是通用的我们将数据进行分类整合为功耗数据风扇转速数据服务器状态温度数据从而实现对不同品牌服务器的指标进行标准化输出。首先由于不同服务器的传感器指标各不相同我们采用借助输出数据的单位字段进行分类过滤。比如watts这类单位属于功耗数据RPM这类单位属于风扇转速数据degree这类单位属于温度数据服务器状态等数据统一指标名然后将各种指标名打上类型标签存入ClickHouse。其次在应用层我们借助Grafana按类型查询各类型指标进行聚合查询实现对各类指标的展示分析。比如各类服务器的有1U2U4U的所包含的的风扇数量不同通过聚合查询取均值实现对数据的整合。交换机F5防火墙指标通过SNMP协议获取该类设备厂商能够提供完整的OID列表来收集数据。针对系统状态数据性能数据固件数据分类存入ClickHouse和Mysql数据库。交换机等网络设备日志通过syslog发送到汇聚节点。需要关注的是SNMPwalk对交换机进行数据采集的频率过于频繁的采集指标会影响交换机的性能要在效率和数据之间做出平衡.上述方式能够采集大部分的指标类型数据而部分设备的标准信息无法实现OID或其他的获取方式我们通过脚本ssh到目标设备实现登陆采集。图2 服务器指标日志采集流程3.3. 基础设施日志数据采集日志数据分为网络设备日志和服务器带外日志。 我们通过IPMI指令采集服务器BMC带外日志到汇聚节点后进行日志数据的处理与丰富为日志信息丰富主机IP等信息统一写入文件由flume采集通过kafka保存到ElasticSearch。因为BMC带外日志有其特殊性正常的服务器设备是不会产生BMC带外日志的且日志内容十分标准所以我们在BMC日志入库时即对其进行告警。网络设备日志通过配置syslog服务将设备日志转发到flume汇聚节点指定端口后sink到ElasticSearch。期间对日志进行简单的解析比如采集时间入库时间日志内容等字段进行分类。3.4 数据应用场景我们在本节主要介绍两个在基础设施运维中数据的应用场景交换机到服务器端口映射关系图服务器硬盘配置管理与故障预测。交换机内部系统使用的是阉割版本的定制化Linux系统如图3所示我们借助expect脚本建立从交换机获取到交换机物理端口描述→物理端口→逻辑端口→mac地址的映射关系通过CMDB 获取到服务器对应网卡与mac地址的映射关系。如果交换机有做ae这类端口绑定需要再采集ae与逻辑端口的映射管理。图3 服务器交换机拓扑关系采集流程服务器的硬盘是日常运维过程中出现问题概率较高的设备配件目前普遍采用SAS接口的硬盘使得以往通过采集S.M.A.R.T信息来进行故障预测的方案不可行。我们选择通过RAID卡厂商提供的命令行工具采集服务器RAID信息以及RAID与Slot的映射管理建立服务器操作系统逻辑磁盘与硬盘的对应关系为硬盘故障定位提供数据支持。并采集各个slot的硬盘错误计数建立监控指标监测磁盘运行状态。然而仅仅依靠硬盘的错误计数来判断硬盘的状态是不准确的。因此我们借助定期对系统内的数据盘进行性能测试来建立性能指标基线。综合硬盘性能和介质错误计数来判断硬盘故障。3.5 数据可视化数据可视化是基础设施硬件监控的重要组成部分通过对指标数据的可视化可以直观的看到基础设施在不同周期不同维度的运行状态借此运维人员可以更好的响应故障事件。在本方案中我们采用Grafana来实现数据可视化如图4所示在界面中集中展示服务器的运行状态、风扇温度功耗以及硬盘等设备的指标。图4 服务器硬件监控视图其中服务器状态传感器数量以及硬盘的介质错误这类指标是我们比较关注的。通过服务器状态指标可以反映服务器的通电状态传感器指标可以反应服务器自监控是否正常而硬盘的介质错误可以看出硬盘的状态过多的介质错误将导致硬盘的读写效率降低影响业务运行。四、总结基础设施的运维监控在上线以来填补了运维监控的漏洞解决了基础设施运维的问题提高了运维的效率。尤其是探索了基础设施的数据应用场景进一步提升了运维的稳定性和效率。未来随着业务的不断拓展需要会有更多的不同类型的基础设施需要加入到监控中来采集的数据规模也会越来越大需要加强数据的治理拓展数据的应用场景为全链路监控告警丰富故障预测等场景提供数据支持。在后续的工作中我们将着重提高数据的利用效率对业务、系统、基础设施等多层次多维度的数据进行整合向智能运维告警故障根因分析等方面努力进一步提升自己在运维开发安全运行的能力。