【运维】简介
目录
一、监控误区和挑战
监控是管理基础设施和业务的核心工具。也是大多数公司必须的,应该和应有程序一起构建和部署。没有监控,将无法了解你的系统运行环境,进行故障诊断,也无法向组织提供系统性的性能、成本和状态等信息。
- 机械式的监控
- 不够准确的监控
- 静态和监控
- 不频繁的监控
- 缺少自动化或自服务
二、墨盒和白盒监控
监视方法主要分为两大类,即黑盒监视和自盒监视。有很多人也叫做是探针(黑盒监控)和内省(自盒监控)
1. 黑盒监控
应用程序或主机是从外部观察的,因此,这种方法可能相当有限。检查是为了评估被观察的系统是否以已知的方式响应探测:
- 主机是否响应PING的请求
- 特定的TCP端口是否打开
- 应用程序在接收到特定的HTTP请求时,是否使用正确的数据和状态代码进行响应200?
- 特定应用程序的进程是否在其主机中运行?
2. 自盒监控
系统在被测对象表面显示其内部状态和临界段的性能数据。这种类型的自省可能非常强大,因为它暴露了内部操作,因此不同内部组件的健康状况,否则很难甚至不可能确定。这种数据处理通常以以下方式处理
- 通过目志导出:到目前为止,这是也是在广泛引入库之前,应用程序是如何暴露其内部工作的最常见的情况。例如,可以处理HTTP服务器的访问目志来监视请求率、延迟和错误百分比。
- 以结构化的事件输出:这种方法类似于日志记录,但不是将数据写入磁盘,而是直接将数据发送到处理系统进行分析和聚合.
- 以聚合的方式保存在内存中:这种格式的数据可以驻留在端点中,也可以直接从命令行工具中读取。这种方法的例子有/metrics with Prometheus metrics、HAProxy的stats页面或varnishstats命令行工具。
三、 度量值的收集
1. 两种收集方法概述
- PUSH >> client主动推送到---sever端
- PULL >> 监控sever端---向client端发送拉取数据请求----client端向sever端发送日志
2. PUSH VS PULL (客户端角度)
PUSH | PULL | |
响应时间 | 及 时 | |
sever和client中间有防火墙 | 方便一些 | |
服务器压力 | 相对大一些 | 自我调节 |
3. 测量什么
在计划度量时,必然会出现一个问题,即定义要观察哪些度量。为了回答这个问题,我们应该求助于当前的最佳实践和方法。在下面的主题中,我们将概述一些最具影响力和最受关注的方法,这些方法可以降低噪声,提高性能和一般可靠性方面的可视性。
1. 谷歌提出应该监控如下的四个指标:
- 延迟:服务请求所需的时间
- 流量:正在发出的请求的数量
- 错误:求失败比率
- 饱和:未处理的工作量,通常在队列中
2. Brendan的方法
更关注于机器,它声明对于每一个资源(CPU、磁盘、网络接口等等),应该监视以下指标:
- 利用率:以资源繁忙的百分比来衡量
- 饱和:资源无法处理的工作,通常会排队
- 错误:发生的错误数量
3.汤姆.威尔基的红色方法
RED方法更侧重于服务级别方法,而不是底层系统本身。显然,这种策略对于监视服务很有用,对于预测外部客户的体验也很有价值。如果服务的错误率增加,那么就可以合理的驾车这些错误将直接或简介的影响客户的体验。这些是需要注意的度量标准:
- 速率:转换成没秒请求书
- 错误:每秒失败请求的数量
- 持久性:这些请求所花费的时间
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?