做棋牌辅助网站,wordpress 多个分类,wordpress点赞按钮,广告公司网页页面设计模板在指标监控的世界里#xff0c;应用和业务层面的监控有两种典型手段#xff0c;一种是在应用程序里埋点#xff0c;另一种是分析日志#xff0c;从日志中提取指标。埋点的方式性能更好#xff0c;也更灵活#xff0c;只是对应用程序有一定侵入性#xff0c;而分析日志的…在指标监控的世界里应用和业务层面的监控有两种典型手段一种是在应用程序里埋点另一种是分析日志从日志中提取指标。埋点的方式性能更好也更灵活只是对应用程序有一定侵入性而分析日志的话对应用程序侵入性较小但由于链路较长、需要做文本分析处理性能较差需要更多算力支持。
所谓的埋点就是指应用程序内嵌了埋点的 SDK一个 lib 库然后在一些关键代码流程里调用 SDK 提供的方法记录下各种关键指标。比如某个 HTTP 服务提供了 10 个接口每个接口的处理花费了多少毫秒就可以作为指标记录下来。
核心原因是 SDK 可以帮我们封装一些通用的计算逻辑。比如有个指标是 Summary 类型可以提供某个接口 99 分位的延迟数据。如果没有 SDK我们需要怎么做呢每当这个接口响应一次请求就记录一个延迟时间然后存入一个内存数据结构等到一个时间间隔比如 10 秒钟就把这段时间内所有的延迟数据排个序然后取 99 分位的值最后调用 Pushgateway 的接口推过去。很麻烦是不是
而 SDK 就是做这些通用逻辑的应用程序要做的就是拿到延迟数据之后调用 SDK 的方法告知 SDK说又有一次新的接口调用延迟数据是多少SDK 就能完成剩余所有的事情。
界比较知名的跨语言埋点工具是 StatsD 和 Prometheus。当然有些语言有自己生态的常用工具比如 Java 生态的 Micrometer不过一般公司都会使用多种语言这些跨语言的埋点方案通常使用频率会更高。
StatsD 有个很大的特点是使用 UDP 传输协议大部分计算逻辑都挪到了 StatsD 的 ServerSDK 层面的工作非常轻量。 StatsD SDK 与 StatsD Server 之间通信使用的是 UDP 协议UDP 协议是 fire-and-forget无需建立连接即使 StatsD Server 挂了也不影响应用程序而对于延迟分布区间这样的计算逻辑是在 StatsD Server 里计算的也不会影响应用程序所以整个 StatsD 的设计是非常轻量的对应用程序基本没有影响。
由于 StatsD 相当知名所以很多采集器都实现了 StatsD 的协议比如 Telegraf、Datadog-agent也就是说图上的 StatsD Server 是可以换成 Telegraf 或 Datadog-agent 的。这样就不用部署太多进程一个采集器包打天下就拿 Telegraf 来说吧替换后架构就变成了这样。
Prometheus 的埋点方式跟 StatsD 很像对于请求数量和延迟这样的监控指标也是在请求处理完成之后调用 SDK 的方法进行记录的。不过如果每个方法都要加这么几行代码就显得太冗余了最好还是通过 AOP 的方式做一些切面逻辑Nightingale 的 Webapi 模块就是这么干的。
Webapi 的职能是提供一系列 HTTP 接口给 JavaScript 调用我们需要监控这些接口的调用量、成功率、延迟数据。埋点之前我们先规划一下标签我们给每个 HTTP 接口规划 4 个标签。
service服务名称要求全局唯一可以和其他服务区分开。codeHTTP 返回状态码可以根据这个信息得知 4xx 的比例是多少5xx 的比例是多少计算成功率。path接口路径比如 /api/v1/users 有时候我们会在接口路径中放置 URL 参数比如 /api/v1/user/23、/api/v1/user/12 是请求 id 为 23 和 12 的用户信息。这个时候不能直接把这个 URL 作为接口路径的标签值否则这个指标颗粒度就太细了应该把接口路径的标签值设置成 /api/v1/user/:id。methodHTTP 方法GET、POST、DELETE、PUT 等。
使用 StatsD 的埋点方式数据通过 UDP 推给 TelegrafTelegraf 推给后端监控系统。如果是通过 Prometheus 的方式来埋点就是暴露 /metrics 接口等待监控系统来拉。如果应用是部署在物理机或虚拟机上直接通过本地的监控 agent 来拉取即可。如果应用是部署在 Kubernetes 的 Pod 里则有两种办法来拉取数据一个是 Sidecar 模式一个是中心端服务发现的模式。下面这个示意图展示的是 Sidecar 模式。 左侧 Pod1 里有两个容器App 通过 StatsD 埋点然后通过 UDP 推给 TelegrafTelegraf 接收到数据之后做二次计算把结果推给监控服务端右侧 Pod2 里也有两个容器App 通过 Prometheus SDK 埋点暴露 /metrics 接口Categraf 通过这个接口拉取数据然后推给监控服务端。
这种方式的优点是比较灵活Pod 内怎么做应用自己说了算。即使给 /metrics 接口增加一些认证鉴权、指标过滤、扩展标签的逻辑都不影响其他的 Pod。数据是推给监控服务端的监控服务端接收数据的组件可以做成无状态集群前面架设负载均衡整个架构非常简单、扩展性也很好。当然缺点也很明显每个 Pod 里都伴生 Sidecar agent浪费资源。 此文章为8月Day12学习笔记内容来源于极客时间《运维监控系统实战笔记》推荐该课程。
