监控是有效管理基础设施和业务的关键工具。正确的监控应当与应用程序一同构建和部署,因为缺乏监控会导致对系统运行环境的不了解,阻碍故障诊断,以及无法及时获取关键的性能、成本和状态等信息。 然而,我们需要注意一些监控中的误区:
● 机械式监控:避免过于机械和生硬的监控方法,应当采用更灵活、智能的监控方式。 ● 不够准确的监控:监控系统应当具备高准确性,以确保获得真实、可信的监控数据,避免误导性信息的干扰。 ● 静态和监控:监控系统需要具备动态适应性,能够随着系统和业务的变化而调整监控策略,避免过于静态化的监控设置。 ● 不频繁的监控:监控应当是持续、频繁的活动,而非间歇性的检查。只有通过频繁监控,才能及时捕捉系统的变化和潜在问题。 ● 缺少自动化或自服务:引入自动化和自服务的监控工具是必要的,这有助于提高效率、减少人工干预,并能够更好地应对系统变化。 正确的监控方法是在保证准确性和实时性的基础上,采用灵活、动态、频繁、自动化的监控策略,从而更好地了解和管理系统的运行状态。
在黑盒监控中,应用程序或主机的观察是从外部进行的,因此该方法可能受到一定的限制。其检查旨在评估被观察系统是否按照已知的方式响应探测。 例子: ● 主机是否响应 PING 请求。 ● 特定 TCP 端口是否处于打开状态。 ● 应用程序是否在接收特定 HTTP 请求时使用正确的数据和状态代码进行响应。 ● 特定应用程序的进程是否在其主机中运行。
白盒监控使系统能够展示其内部状态和关键性能数据。这种自我观察可能非常强大,因为它揭示了内部操作,展示了不同内部组件的健康状况,这在没有此类监控的情况下可能难以确定。 数据处理方式: ● 日志导出: 通常通过日志记录来实现,例如处理 HTTP 服务器的访问日志以监视请求率、延迟和错误百分比。 ● 结构化事件输出: 类似于日志记录,但不将数据写入磁盘,而是直接发送到处理系统进行分析和聚合。 ● 聚合保存在内存中: 这种格式的数据可以驻留在端点中,也可以直接从命令行工具中读取。例如,使用 Prometheus metrics的 /metrics、HAProxy 的 stats 页面或 varnishstats 命令行工具。
在监控系统执行过程中,度量指标通常可以分为两种方式:push(监控系统主动拉取服务数据)和 pull (被监控的服务自动推送数据到监控系统)【站在客户的角度】。
Push VS Pull
测量什么
谷歌提出应该监控的四个指标: ● 延迟: 服务请求所需的时间。 ● 流量: 正在发出的请求的数量。 ● 错误: 请求失败的比率。 ● 饱和: 未处理的工作量,通常在队列中。
Brendan 的方法更关注于对于每个资源( CPU、磁盘、网络接口等)的监视,包括以下指标: ● 利用率: 以资源繁忙的百分比来衡量。 ● 饱和: 资源无法处理的工作量,通常会排队。 ● 错误: 发生的错误数量。
汤姆威尔基的红色方法更侧重于服务级别方法,而不是底层系统本身。这种方法对于了解服务很有用,对于预测外部客户的体验也很有价值。如果服务的错误率增加,就可以合理地假设这些错误将直接或间接地影响客户的体验。 ● 速率: 转换成每秒请求数。 ● 错误: 每秒失败请求的数量。 ● 持久性: 这些请求所花费的时间。
长亭百川云网站监测是一款专为有站点监测需求的用户打造的 SaaS 应用,致力于解决用户互联网风险监测难题的 SaaS 化订阅服务产品。可实现对网络质量、页面性能、入侵篡改、内容违规、挂马暗链、SSL 证书等场景进行周期性监控,支持多维度分析性能指标。利用可视化性能数据和告警通知,帮助用户及时对业务质量作出反应,保证业务稳定正常运行。 监控类型包括: ● 可用性监控 ● 稳定性监控 ● 内容合规监控:敏感内容+内容篡改 ● 安全监控:暗链监控、挂马监控、dns解析监控 ● 漏洞扫描
● 成熟的社区支撑,是CNCF的毕业项目,得到大厂支持。 ● 易于部署和运维,核心只有一个二进制文件,无其他依赖。 ● 采用Pull模型,通过HTTP的Pull方式从各监控目标拉取数据,避免了Push模型的运维难度和压力。 ● 强大的数据模型,支持自定义标签,有助于进行数据聚合和计算。 ● 强大的查询语言PromQL,支持数据查询、聚合、可视化和告警。 ● 完善的生态,提供丰富的接入方案和客户端SDK。 ● 高性能,单一实例可处理数以百计的监控指标。
当然还有更多其他好用的监控应用,也可以选择自己二开。你觉得有哪些好用的监控应用呢?在评论区推荐吧~~