解决方案:HertzBeat赫兹跳动v1.0.beta.5发布，易用友好的监控告警系统

　　解决方案:HertzBeat赫兹跳动v1.0.beta.5发布，易用友好的监控告警系统

　　HertzBeat由Dromara孵化，开源支持探云、API、PING、端口、数据库、整站等监控类型的网站，支持阈值报警、报警通知（邮件、webhook、钉钉、微信、飞书机器人），一个开放的具有易于使用和友好的可视化操作界面的源监控和报警项目。

　　官网：|

　　本次升级版包括dashboard重新设计，阈值表达式支持多种指标，丰富数据库监控类型，新增mariaDB和postgreSQL数据库监控，控制台页面帮助文档等，欢迎使用。

　　特征：

　　功能支持 mariadb 监控类型 (#11)

　　功能仪表板重构（#13）

　　feature alarm 配置支持@pengliren 提出的多指标采集 感谢

　　功能支持 postgresql 数据库监控（#16）

　　添加了监控以默认启用检测。

　　新增mysql采集指标。

　　新增监控大类，支持自定义监控页面菜单自动渲染

　　操作页面新增帮助链接，完善自定义和门槛帮助文档

　　feat: 模拟浏览器设置成chrome浏览器 #Issues 14 贡献者 @学习码的小白 感谢

　　

" />

　　BUG修复

　　登录登录，傻傻的糊涂了。

　　新增文档常见问题，采集器http参数优化验证。

　　如果采集

器未能调度到第 0 优先级，则后续优化将被取消。

　　错误修正网站监控路径索引路径中的非法字符

　　bugfix 深色主题适配问题 (#10)

　　修复国际化异常释放层级接口认证保护

　　欢迎在线试用

　　新仪表板：

　　告警阈值配置支持多指标表达式：

　　新增mariaDB和postgreSQL数据库监控类型，欢迎体验！

　　HertzBeat是TanCloud支持的开源监控告警项目，支持网站、API、PING、端口、数据库等多种监控类型，具有简单易用、友好的可视化操作界面。

　　

" />

　　我们也提供相应的SAAS版本监控云。中小型团队和个人不再需要为了监控自己的网站资源而部署繁琐的监控系统，登录后即可免费上手。

　　HertzBeat 支持自定义*敏*感*词*。我们只需要配置yml文件就可以自定义需要的监控类型和指标，满足常见的个性化需求。

　　HertzBeat是模块化的，manager、collector、scheduler、warehouse、alerter各个模块解耦，方便理解和定制开发。

　　HertzBeat 支持更自由的报警配置（计算表达式），支持报警通知和报警模板

　　欢迎来到HertzBeat的云环境TanCloud试用了解更多。

　　我们正在快速迭代，欢迎加入我们共建项目的开源生态。

　　HertzBeat的多类型支持、易扩展、低耦合希望能够帮助开发者和中小团队快速搭建自己的*敏*感*词*系统。

　　老手们可以通过演示视频直观了解功能：

　　微信交流群

　　添加微信tan-cloud拉你进微信群。

　　QQ交流群

　　添加QQ群号718618151，验证信息：tancloud

　　仓库地址

　　看到这里还不如给个Star，万分感谢，鞠躬！！

　　解决方案:贵司的监控系统处于什么时代？

　　关于作者

　　Lu Hongli，来自硅谷的SRE，拥有多年*敏*感*词*大型互联网公司运维经验，专注于分布式系统设计、监控、容量规划、数据中心技术和生产环境最佳实践。我的订阅号：Cloudify，会发布一些关于高可用和分布式系统研究的文章。

　　文本

　　说到监控，开发同学可能会说就是在开发应用的时候多打几条日志，然后运维同学写脚本统计分析某个关键字的出现次数。如果超过设定的阈值，发送电子邮件或短信发出警告。

　　是的，这是基本逻辑。但是如果你公司的监控真的像这位开发者描述的那样，那我只能说你的监控如果拿人类社会的发展阶段来说，还是处于原创

社会。

　　根据系统的完善程度，我简单的把监控系统分为三个阶段：

　　如果你觉得公司的监控系统已经很好了，你可以换个地方；如果您认为公司的监控系统还需要改进，请继续阅读以确保值得。

　　1.准备知识

　　在介绍监控系统之前，有两个关键的概念需要先明确一下：第一个是时间序列，第二个是监控的类型。

　　第一：时间序列

　　简单的定义就是在数据格式中收录

时间字段的数据，一般与某个目标相关联，两个数据点之间有固定的时间间隔。时间序列用于不同的学科。在监控中，目标一般是监控的某个指标，比如系统负载的每分钟采样。绝大多数监控系统在采集数据后，将监控数据按时间序列进行存储。

　　1）监控型

　　有两种类型的监控：白盒或黑盒。

　　白盒监控擅长发现系统中个别组件的问题，但难以覆盖系统端到端的健康检查。

　　黑盒监控可以提供最接近真实用户的系统端到端检测。

　　准备知识介绍完了，下面进入正题。本文主要讲白盒监控。

　　说到监控，为什么我们一般会说“监控系统”呢？因为一个好的监控需要一个完整的生态系统来支撑。基础监控系统需要具备以下功能：数据采集、数据存储、数据显示、异常触发、告警发送。

　　2）数据采集

　　以被监控对象为主体，主要有两种数据采集方式，分为主动推送和被动拉取。这两种采集方式各有优缺点。

　　主动推送

　　优势

　　缺点

　　被动拉动

　　优势

　　

" />

　　缺点

　　以上两种采集方式的缺点能否得到改善，就看工程师愿意花在上面的时间了。

　　一般来说，被动拉动方式更能体现监控的完备性。它最大的缺点是对短活应用的监控，让这些应用主动推送到代理应用，然后被动拉取。目标发现可以与公司的内部命名系统一起实施。

　　3、数据存储

　　时间序列集合之后是如何存储的，主流的存储方式有以下三种：

　　RRD（循环数据库）

　　旧的 Nagios、collectd 和 Ganglia 使用这种存储方式；Graphite使用的Wisper也是基于RDD的基本思想设计的。它的特点是使用基于循环缓冲区的数据库。系统初始化后数据库大小不变，无需担心数据存储空间不足。缺点也是数据库的大小是恒定的，所以只能保存一定时间段的数据，数据库初始化后不能调整时间序列的区间。另一个致命的缺点是受单机磁盘的限制，当需要监控的规模较大时，数据存储和读取会出现瓶颈。

　　MySQL

　　Zabbix 使用 MySQL 来存储时间序列数据。MySQL 也受到单机磁盘大小和性能限制，但可以通过分区来缓解。

　　无SQL

　　使用No-SQL存储时间序列的应用有很多：Opentsdb、kairosdb、newts。使用No-SQL存储时间序列，没有单机磁盘限制，数据量大时也不存在扩容问题。

　　时间序列的存储一般不需要考虑数据存储的schema。客户端仅通过简单的 API 访问时间序列数据。具体的存储模式由底层存储系统（MySQL或No-SQL）决定，但不同的存储模式决定了数据。查询/显示性能。

　　RRD和MySQL都受限于单机磁盘的性能。SSD 可以显着提高数据读取性能。当数据量较大时，MySQL可以通过分区进行扩容，而RRD不能进行扩容。MySQL虽然可以进行分区，但是复杂度和维护成本也很高。No-SQL天生适合存储时间序列，可以提供较大的存储容量和读取性能，但也需要考虑维护成本。如果公司有No-SQL公共服务可以应用，那么No-SQL存储时序是最好的选择。

　　4、数据显示

　　数据展示需要具备以下绘图能力：

　　数据展示有两种应用场景：一种是供运维人员在定位问题时使用，需要能够快速编辑生成新的图表来验证猜想，因此需要灵活易用；但对于业务人员查看统计数据，需要一个强大的综合聚合来反映整体系统的健康状况。

　　数据展示有时会涉及短时间内读取大量时间序列，或者需要多人同时读取数据进行绘图查询。底层数据存储格式是影响查询性能的主要因素。底层数据存储的schema影响查询性能，合理的架构设计可以大大提高查询性能。

　　常见的优化点有：

　　5.异常触发

　　数据已经采集保存，图表显示没有问题，但谁也不愿意天天盯着图表找问题。根据历史经验，通过定义一些条件来触发某些动作的需求应运而生。这需要一个规则评估引擎，它可以是一个单独的过程，也可以与数据采集

集成。输入是时间序列和用户定义的规则。当时间序列符合规则中定义的状态时，执行指定的动作。常见的动作包括：执行命令（修复脚本）、将定义的内容发送到外部系统等。

　　对发动机系统的要求是：

　　6、报警发送

　　异常触发后，能自动修复的一定要自动解决。当出现无法通过自动化解决的异常时，需要报警让人介入。

　　报警发送最基本的就是发送邮件，更高级的可以支持短信和语音通话。现在手机普及了，一些公司可能会有手机软件接收报警信息。

　　发送的告警内容一般包括：

　　

" />

　　高级报警内容还可能包括：

　　七、监控系统的三个时代及特点

　　监控系统的基本功能在各个时代都大同小异。本质区别在于不同功能模块的实现是否可以高度扩展、高度可定制、面向服务，整体监控系统是否形成闭环系统。一般来说，时代主要是由它监控的集群规模和公司的技术水平来决定的。

　　原创

社会

　　当监控机器数量在1000台左右时，公司会专注于核心业务功能的开发，运维方面可能没有开发投入。这时候一般直接使用市面上成熟的监控软件，比如Nagios。此时的监控系统如下所示。

　　此时的监控系统具有以下特点：

　　工业时代

　　随着公司业务规模的快速发展，当机器数量达到10000台左右时，即使是对市场现有的解决方案进行简单的二次开发也难以满足监控的需求。随着机器规模的不断增长，企业一般有两种选择：继续对现有解决方案进行深度定制开发，或者开发符合企业架构的监控系统。现阶段的监控系统可以支持上万台机器规模的集群。

　　此时的监控系统如下所示：

　　与原创

社会相比，此时的监控系统具有以下特点：

　　信息时代

　　监控系统的演进和关注的焦点伴随着集群管理调度系统和软件开发框架的发展。当公司的集群规模超过10万台时，机器本身的监控会逐渐剥离出来，由集群来管理。团队负责，上层应用更关心分配的可用资源内的健康监控。上百个部门都在开发和部署应用，对监控系统的要求空前高涨。公司要发展到这个规模，必须成立所谓的运维开发部或者基础设施部，负责开发通用的监控平台、自动化平台等。这时候，监控的需求是尽可能用最简单的方式实现白盒监控。监控系统必须根据公司的集群管理系统和软件开发框架高度定制。目的是减轻开发过程中监控需求的负担。并且可以支持海量数据的采集、存储和展示。在这种要求下，监控系统必须能够提供灵活、强大的配置能力，以适应众多应用的不同监控需求。目的是减轻开发过程中监控需求的负担。并且可以支持海量数据的采集、存储和展示。在这种要求下，监控系统必须能够提供灵活、强大的配置能力，以适应众多应用的不同监控需求。目的是减轻开发过程中监控需求的负担。并且可以支持海量数据的采集、存储和展示。在这种要求下，监控系统必须能够提供灵活、强大的配置能力，以适应众多应用的不同监控需求。

　　信息时代的监控系统是从工业时代的监控系统发展而来的。除了对基本功能进行细分和强化外，还具有以下特点：

　　这个时代的监控系统足以支撑百万台机器规模、上亿个监控目标的集群，每天产生的监控数据以数百TB计算。信息时代之后，监控系统会如何发展还不好说，但是现在我们可以在市场上看到一个明显的趋势，那就是监控功能的产品化。

　　8.趋势

　　一站式服务

　　完整的软件系统

　　专业的服务

　　加入运维帮本地群

　　现在上海、广州、深圳城市群已经开通，先加微信yunweibang666，然后拉你进群，敲门密码：你的城市。

　　运维助力选型

　　欢迎加入运维求助QQ技术讨论群：542812110