余姚做轴承网站,wordpress国内优化,网站设计要先做图么,东莞百度搜索优化1、功能概述 通常所说的监控#xff0c;会模糊地包含以上下个细分领域的内容#xff1a; 应用性能监控#xff08;Application Performance Monitoring#xff09;业务交易监控#xff08;Business Transaction Monitoring#xff09;网络性能监控#xff08;Network …1、功能概述 通常所说的监控会模糊地包含以上下个细分领域的内容 应用性能监控Application Performance Monitoring业务交易监控Business Transaction Monitoring网络性能监控Network Monitoring操作系统监控System Monitoring网络站点监控Website Monitoring 在任何一个 IT 业务环境中都会存在各种各样的硬件设备、软件应用等。按照逻辑层次划分我们可以将其划分 为了及时掌控基础环境和业务应用系统的可用性需要获取各个组件的运行状态如 CPU 的利用率、系统的负载、服务的运行、端口的连通、带宽流量、网站访问状态码等信息而这一切都离不开监控系统的支撑。 2、实现原理 模块组成 一个监控系统的组成大体可以分为两部分数据采集部分客户端Agent和数据存储分析告警展示部分服务器端Server 采集协议 按照支持的协议方式监控系统数据采集可以分为两种专用客户端采集和公用协议采集SNMP、IPMI、SSH、Telnet等。 采集模式 监控系统数据采集的工作模式可以分为被动模式从服务器端到客户端采集数据pull和主动模式客户端主动上报数据到服务器端push两种。通常大多数监控系统都应该能同时支持这两种工作模式但不同的监控系统由于采集技术不同仅有部分能够同时支持这两种工作模式。 一般来说被动模式对监控控制端服务器的开销较大适合小规模的监控环境主动模式对监控控制端服务器的开销较小适合大规模的监控环境。 监控指标 监控系统通常都支持一些常见的监控采集指标如操作系统监控、应用程序监控等。部分常见的监控指标如下 代理架构 对于大规模的监控环境被监控节点多且监控类型多监控产生的数据和网络连接开销非常大数据采集方式除了使用主动采集模式还需要使用代理架构通过代理架构分摊服务器端的性能开销。另外代理架构还支持跨地域、跨网络的分布式监控。常见的代理架构即C/P/SClient/Proxy/Server客户端/代理端/服务器端此处的 Client和 Agent意思等同都表示客户端下同架构。采用中间代理将大大提高监控服务器端的处理速度从而支撑构建大型分布式监控环境从架构上支持异地多机房的需求。 对于小型的监控环境被监控节点不多且处于同一地域或网络环境下监控系统所需采集的监控数据量较少采用 C/SClient/Server客户端/服务器端架构即可满足监控业务需求。 数据存储 在监控客户端采集数据之后会将数据上传给监控服务器端监控服务器端程序将接收到的数据进行存储。通常监控系统会选用以下几种数据存储方式。 1本地存储。使用本地磁盘基于文件的方式存储。 2使用时序数据库进行数据存储如古老的环状数据库Round Robin Database, RRD等。近年来随着时序数据技术的不断发展出现了比较成熟的时序数据库如 OpenTSDB 底层存储基于HBase、Graphite、InfluxDB、Prometheus 等与直接使用文件的存储方式相比这些时序数据库更加高效。目前时序数据库领域相关技术的发展速度较快应用的生态也逐步完善基于时序数据库的监控系统会逐渐增多。从长远角度来看使用时序数据库存储监控数据是必然的发展趋势。 3使用数据库管理系统Database Management System, DBMS进行数据存储如常见的MySQL、Oracle、SQL Server 等。使用这种数据库来存储监控数据当数据量达到一定规模时其读/写效率均会显著下降数据库的压力比较大通常优化方案思路有3种一是减少数据的存储量二是优化数据库本身调整配置参数优化运行环境三是使用分布式数据库和数据库集群技术方案。故使用 DBMS 作为数据存储的监控系统对数据库本身的掌握程度决定了监控系统能否在大规模环境下良好工作。 4使用 NoSQL数据库进行数据存储。NoSQL相对于 DBMS这种传统的数据库有着一些天然的优势单机的QPS通常较高。但NoSQL本身并不是为监控系统设计的在数据结构存储方面存在一些缺陷故直接采用NoSQL作为监控数据存储的监控系统产品较少。 5使用列存储数据库进行数据存储。列存储数据库由于其设计之初专为大数据而有所考虑故无须担心其存储容量底层均有良好的解决方案。但由于其部署、运维均较为复杂故一般监控系统也不会常采用这种技术作为数据库存储。这方面的数据库代表为HBase。 6使用全文搜索引擎数据库进行监控数据存储。这方面的代表是Elasticsearch其作为监控数据库存储监控数据具有天然的优势支持集群、分布式部署、容灾并且集群能够提供较高的性能。目前采用全文搜索引擎数据库进行监控数据存储典型的代表是 ELK 套件而Zabbix监控系统也在这方面进行了尝试在Zabbix 4.0中可以选用Elasticsearch作为数据库存储。 以上我们看到在不同的场合下监控系统对数据的存储要求会不同因此有些监控系统产品直接将数据库存储的选项交给了使用者来决定会同时支持多种方式的数据库存储。 告警功能 监控系统的重要功能是根据设定的阈值进行告警同时也要求在发生故障时有一定的故障自动化处理功能对于特殊的告警还需要具备告警的升级功能将不同级别的告警分成不同的梯度发送给不同的告警接收人。 虽然监控系统的重要功能是告警但过多地发送告警对于监控系统的使用效果来说反而会不理想。因为人的精力是有限的不可能随时随地等待着故障发生而立即处理故障当告警过多时我们需要优化监控系统。 在触发和发送告警时告警模块需要支持故障的有效汇报和集中汇报尽量避免出现“告警风暴”防止同一时间大量发送重复、类似的告警即告警功能支持对告警内容进行分析和自动处理防止误报、漏报及抖动。对于大多数监控系统来说这一点都是一个值得挑战和研究的课题。举一个实际的例子当机房网络发生故障时按照常规用户会收到无数条告警信息内容是每台设备的故障。但如果将告警聚合我们希望收到的信息是“某机房存在网络故障受影响的设备IP地址是X.X.X.X受影响的业务是XXX”。 事后还需要对告警信息进行统计分析以方便对系统的运行情况进行分析统计从而衡量系统的稳定性、可用性。通常使用SLA服务质量指标来衡量。 可扩展性 可扩展性是指监控系统本身具备良好的扩展能力包括监控方式的扩展、监控能力的扩展、监控数据存储的扩展、分布式的支持等。要求监控系统能够随着不同环境而做出改变和调整大多数监控系统都具备一定的扩展能力。 对于告警要求支持多种方式如短信、邮件、即时通信和其他接口且具备可定制化能力可以对第三方告警介质提供可编程接口。这一点在很多场合都非常重要例如将告警结果发送到专用的告警分析系统。 监控系统需要根据实际应用的需求实时/非实时地采集和展示数据。另外还包括历史趋势数据的展示和分析以及容量报表、可用性报告的生成。 在一个监控系统中构成要素为监控服务器端程序、数据存储、被采集节点等相关模块其告警分析和自动故障处理功能由服务器端执行。在数据采集完成之后需要对采集到的数据进行分析和处理判断是否有异常、是否符合告警条件。那么如何配置告警条件呢通常是根据实际的经验值、业务需求来设置告警阈值的。当达到告警条件时则发送告警信息给管理人员。然而对于有些故障我们希望程序能自动处理减少人工干预让程序自动修复只在出现严重故障、程序无法判断时才发送告警通知管理人员处理。 一个监控系统往往需要集成资产管理系统资产管理功能可以从逻辑上展示业务用途的信息通过对其进行数据分析做到对投资与回报的反馈展示为资产的合理规划与使用提供依据。 从工作模式来看监控系统的数据采集可以分为两种主动监控和被动监控。一个理想的监控系统采集端支持的采集方式越多其扩展能力越强大适用的环境场合越多。 监控系统需要具有对外提供API的能力方便第三方应用系统对监控数据进行操作管理。通常能对外提供 API 功能的软件意味着其扩展能力更强大因而会更加受到用户的喜爱。API的方式一般可以分为 RESTful、SOAP等在 API中使用的数据类型可以为 JSON、XML等。从目前的趋势来看RESTful已经成为绝大多数API首选的方式。 监控系统需要对故障数据进行分析汇总从故障数据中分析出现的概率进而可以积累数据经验避免以后出现类似的问题。例如通过分析统计机器硬件导致故障的概率有多大、哪些部件最容易出问题、出问题的影响概率有多大、立即解决问题的概率有多大等问题在此基础上进行分析汇总就可以整理出有效的相应故障对策和技术应急方案。 3、开源产品 在监控软件中开源的解决方案有 流量监控MRTG、Cacti、SmokePing 等、性能告警Nagios、Zabbix、Zenoss Core、Ganglia、Netdata 等、基于时序数据库存储数据的监控Graphite、OpenTSDB、InfluxDB、Prometheus、OpenFalcon 等、基于全文搜索引擎数据库存储数据的监控如 ELK 套件可供选择。 上述各监控产品都有自己的特点和功能其侧重点和目标不完全相同在设计理念和实现方法上也各有差异但都具有一些共同特征例如采集数据、分析展示、告警以及简单的故障自动处理等最终都能达到对 IT 系统服务可用性的完全展示。需要说明的是当前的时序数据库侧重于监控数据的存储其采集需要借助其他工具来实现。时序监控产品的设计理念较为先进具有很多创新功能随着其不断发展将会极大地促进监控领域技术的发展。 Cacti Cacti官方网站地址https://www.cacti.net/。 Cacti仙人掌是一套基于 PHP、MySQL、SNMP和 RRDtool开发的网络流量监测图形分析工具。其数据采集仅支持SNMP方式通过snmpget命令来获取监控数据使用RRDtool命令工具存储历史数据和绘图并提供数据和用户管理功能可以根据用户权限查看不同的树状结构、主机设备以及指定的监控数据图支持与LDAP结合进行用户认证同时也能自定义模板。对于网络设备的监控其展示效果非常不错在10年前它是广受网络管理员喜欢的监控产品。 Nagios Nagios官方网站地址Nagios Open Source | Nagios Open Source。 Nagios是一个插件式的监控系统可以监控服务的运行状态和网络信息等并能监视所指定的本地或远程主机参数以及服务同时提供异常告警通知功能等。 Nagios对开源监控系统的影响非常深远曾经风靡一时占据开源监控市场的大部分份额并基于Nagios 产生了很多新的监控产品。近年来随着其他开源监控软件的崛起Nagios 逐渐淡出了历史舞台使用的人群相对减少但目前仍有一些公司在使用。 Nagios支持客户端的数据采集通过编写客户端插件可以获取各种监控数据并提供了Web管理界面进行数据查询。其产品的主要功能侧重于监控服务的可用性根据设置的阈值进行告警但大部分告警逻辑都是通过监控插件实现的。 InfluxDB套件 InfluxDB官方网站地址InfluxDB Times Series Data Platform | InfluxData。 InfluxDB 并不是一个监控产品而是一个开源的分布式时序、时间和指标数据库使用Go 语言开发。其功能是数据指标的存储不提供告警分析功能和数据采集功能仅仅是一个数据库支持 SQL语言查询其语法和 MySQL类似。随着 InfluxDB时序数据库的功能不断完善官方也推出了作为监控系统使用的相关套件分别是 Telegraf采集数据的客户端、InfluxDB存储监控数据、Kapacitor告警分析、Chronograf监控数据可视化。 Prometheus Prometheus官方网站地址Prometheus - Monitoring system time series database。 Prometheus 是一套开源的系统监控报警框架。Prometheus最初的设计理念受 Google的 Borgmon监控系统所启发由工作在 SoundCloud的 Google前员工于2012年创建作为社区开源项目进行开发2015年正式发布。2016年Prometheus正式加入Cloud Native ComputingFoundationCNCF组织2018年其成为继Kubernetes从CNCF毕业的第二个项目其受欢迎程度仅次于Kubernetes。 Prometheus产品得到迅速发展离不开天时、地利、人和在2015年前后微服务概念开始流行软件架构从单体应用转换为微服务此时能够原生支持对容器 Docker、Kubernetes监控的产品会被使用微服务的公司首先接受而同期的其他监控产品均不直接提供对微服务的监控故其在微服务领域取得先机。另外该产品本身的设计较为合理提供了灵活而强大的查询语句PromQL、灵活的告警策略易于管理方便扩展其数据采集使用私有客户端传输协议使用 HTTP数据存储使用私有数据库。 OpenFalcon OpenFalcon官方网站地址https://book.open-falcon.org/。 OpenFalcon 是一个企业级、高可用、可扩展的开源监控解决方案。OpenFalcon由多个组件构成重要的组件有数据采集、数据传输、数据存储、告警分析、图形展示等数据采集使用专用客户端传输协议为私有的数据存储支持 OpenTSDB 和RRD两种方式。 Netdata Netdata官方网站地址GitHub - netdata/netdata: Monitor your servers, containers, and applications, in high-resolution and in real-time!。 Netdata是 Linux系统实时性能监测工具以 Web可视化方式展示系统及应用程序的实时运行状态包括CPU、内存、硬盘输入/输出、网络等Linux性能数据。 Netdata 数据采集为私有客户端数据存储为私有格式也支持多种时间序列后端服务比如Graphite、OpenTSDB、Prometheus、JSON document DBs并支持告警功能在单机监控系统中具有其他监控系统所不具备的优势。其监控界面较为美观。 ELK家族 ELK官方网站地址Elasticsearch Platform — Find real-time answers at scale | Elastic。 ELK是Elasticsearch、Logstash、Kibana的简称这三者是核心套件但并非全部。 Elasticsearch 是实时全文搜索和分析引擎提供搜集、分析、存储数据三大功能是一套开放 REST 和Java API 等结构提供高效搜索功能并可扩展的分布式系统。它构建在Apache Lucene搜索引擎库上。 Logstash 是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志这些来源包括 syslog、消息传递如RabbitMQ和 JMX。它能够以多种方式输出数据包括电子邮件、WebSocket和Elasticsearch。 Kibana 是一个基于 Web 的图形界面用于搜索、分析和可视化存储 Elasticsearch 指标中的日志数据。它利用 Elasticsearch的 REST接口来检索数据不仅允许用户创建自己数据的定制仪表板视图还允许他们以特殊的方式查询和过滤数据。 实际上随着ELK家族的不断发展其针对日志采集开发了专用的客户端Beats系列产品包括Filebeat日志文件、Metricbeat指标、Packetbeat网络数据、WinlogbeatWindows事件日志、Auditbeat审计数据、Heartbeat运行时间监控。 Zabbix Zabbix是企业级分布式监控系统是一个开箱即用的成熟解决方案具备完备的功能。综合其他监控产品来说它是一个大而全、功能丰富且定制非常灵活的产品具备其他监控产品的功能同时提供了其他监控产品所不具备的功能扩展非常灵活是企业级监控系统比较合理的选择之一。 从功能上说Zabbix 支持多种采集方式和采集客户端有专用的 Agent代理也支持SNMP、IPMI、JMX、Telnet、SSH 等多种协议它将采集到的数据存放到数据库中可以支持 MySQL、Oracle、PostgreSQL、SQLite、Elasticsearch 等数据库然后对其进行分析整理达到条件触发告警并支持对告警数据的分析统计。Zabbix 具有良好的管理界面。 从以上各种监控系统产品的对比来看Zabbix都是具有优势的其具有丰富的基本功能、可扩展的能力、二次开发的能力和简单易用的特点读者只要稍加学习即可构建自己的监控系统。