Envoy源码分析之Stats使用基础

简介: # Stats基本使用 在上一篇文章中我们介绍了`Metrics`,以及对应的三个具体的`Metrics`类型`CounterImpl`、`GaugeImpl`、`HistogramImpl`,而本文将会介绍下,如何去使用这个三个Metrics类型。在Envoy中要定义一组`stats`一般会按照下面的步骤来创建。 1. 定义一组`stats` ```cpp #define M

Stats基本使用

在上一篇文章中我们介绍了Metrics,以及对应的三个具体的Metrics类型CounterImplGaugeImplHistogramImpl,而本文将会介绍下,如何去使用这个三个Metrics类型。在Envoy中要定义一组stats一般会按照下面的步骤来创建。

  1. 定义一组stats
#define MY_COOL_STATS(COUNTER, GAUGE, HISTOGRAM)     \
COUNTER(counter1)                                    \
GAUGE(gauge1, mode)                                  \
HISTOGRAM(histogram1)
  1. 将定义好的stats放到一个struct
struct MyCoolStats {
  MY_COOL_STATS(GENERATE_COUNTER_STRUCT, GENERATE_GAUGE_STRUCT,GENERATE_HISTOGRAM_STRUCT)
};
  1. 初始化stats
MyCoolStats stats{MY_COOL_STATS(POOL_COUNTER_PREFIX(scope, prefix), POOL_GAUGE_PREFIX(scope, prefix), POOL_HISTOGRAM_PREFIX(scope, prefix))};
  1. 使用stats
stats.counter1_.inc();
stats.gauge1_.inc();
stats.histogram1.recordValue(xx)

到此为止一组stats就定义好了,在代码中创建一份实例,然后通过这个实例就可以引用对应的stats来进行统计了。整个stats的创建和使用还是比较简单的,这都要归功于Envoy预先定义好的一组stats macors。下面我们将进一步分析这些宏的背后到底做了哪些事情。

Stats macros分析

// Fully-qualified for use in external callsites.
#define GENERATE_COUNTER_STRUCT(NAME) Envoy::Stats::Counter& NAME##_;
#define GENERATE_GAUGE_STRUCT(NAME, MODE) Envoy::Stats::Gauge& NAME##_;
#define GENERATE_HISTOGRAM_STRUCT(NAME) Envoy::Stats::Histogram& NAME##_;

GENERATE_*_STRUCT开头的宏其实就是定义了对应的Metrics类型的基类引用,这个部分还是很好理解的,MyCoolStats展开后如下:

struct MyCoolStats {
  Envoy::Stats::Counter& counter1_;
  Envoy::Stats::Gauge& gauge1_;
  Envoy::Stats::Histogram& histogram1_;
};

接着构造MyCoolStats的时候,通过POOL_*_PREFIX开头的宏来创建对应的Metrics类型的实例,其实现如下:

#define FINISH_STAT_DECL_(X) + std::string(#X)),
#define FINISH_STAT_DECL_MODE_(X, MODE) + std::string(#X), Envoy::Stats::Gauge::ImportMode::MODE),

#define POOL_COUNTER_PREFIX(POOL, PREFIX) (POOL).counter(PREFIX FINISH_STAT_DECL_
#define POOL_GAUGE_PREFIX(POOL, PREFIX) (POOL).gauge(PREFIX FINISH_STAT_DECL_MODE_
#define POOL_HISTOGRAM_PREFIX(POOL, PREFIX) (POOL).histogram(PREFIX FINISH_STAT_DECL_

需要传入一个POOL,这个POOL在Envoy中指的就是Scope对象后面的文章会重点来介绍,用来创建不同类型的Metrics,展开后如下。

MyCoolStats stats{scope.counter(prefix + std::string("counter1")),
                  scope.gauge(prefix + std::string("gauge1")),
                  scope.histogram(prefix + std::string("histogram1"))}

如果不需要提供prefix的话,也可以使用POOL_*宏,创建不带prefix的Metrics。 其内部也是调用带有prefix的宏来实现的。

#define POOL_COUNTER(POOL) POOL_COUNTER_PREFIX(POOL, "")
#define POOL_GAUGE(POOL) POOL_GAUGE_PREFIX(POOL, "")
#define POOL_HISTOGRAM(POOL) POOL_HISTOGRAM_PREFIX(POOL, "")
目录
相关文章
|
6月前
|
负载均衡 监控 Cloud Native
|
3月前
|
微服务 Windows
【Azure微服务 Service Fabric 】在SF节点中开启Performance Monitor及设置抓取进程的方式
【Azure微服务 Service Fabric 】在SF节点中开启Performance Monitor及设置抓取进程的方式
|
6月前
|
负载均衡 监控 Cloud Native
Service Mesh的实现原理
【5月更文挑战第6天】Service Mesh是一种针对云原生应用的服务治理技术,通过轻量级网络代理(SideCar)实现服务间的通信和可靠性保证,无需代码集成。它解决了跨语言服务调用和云原生服务治理的问题。
|
6月前
|
负载均衡 监控 Cloud Native
Service Mesh 的实现原理
【2月更文挑战第20天】
|
缓存 Kubernetes 安全
kubernetes indexer源码解析
kubernetes indexer是实现了多索引的本地缓存,在实现思路,特别在代码可复用方面,值得我们学习借鉴
132 0
kubernetes indexer源码解析
BXA
|
存储 弹性计算 Kubernetes
解析Kubernetes的设计与实现原理
Kubernetes 是一种用于自动化部署、扩展和管理容器化应用程序的开源平台。它通过提供跨主机集群的容器协调和管理服务,实现了高可用性和弹性伸缩的容器集群管理。
BXA
189 0
istio 原理简介
Istio 的架构分为控制平面和数据平面 数据平面:由一组智能代理(Envoy)以 sidecar 模式部署,协调和控制所有服务之间的网络通信。 控制平面:负责管理和配置代理路由流量,以及在运行时执行的政策。
istio 原理简介
|
负载均衡 Kubernetes 网络协议
K8S原理剖析:Service原理剖析和实践
K8S原理剖析:Service原理剖析和实践
686 0
K8S原理剖析:Service原理剖析和实践
|
Kubernetes 负载均衡 监控
kube-proxy源码分析:深入浅出理解k8s的services工作原理
在进行k8s实践中, services 是经常碰到的资源对象,services 充当了 k8s 集群 pod 服务抽象的功能,为后端pod 提供了负载均衡和服务发现,那他到底是如何工作的呢,这里从 services 的具体实现 kube-proxy 出发解读 services 的工作机制。
2317 1
kube-proxy源码分析:深入浅出理解k8s的services工作原理
|
存储 网络协议 前端开发
Envoy源码分析之Stats基础
# 简介 Envoy官方文档中提到`One of the primary goals of Envoy is to make the network understandable`,让网络变的可理解,为了实现这个目标Envoy中内置了`stats`用于统计各类网络相关的指标,Envoy没有选择使用`Prometheus`SDK,而是选择自己实现了`stats`,[目的是为了适配Envoy的线
1615 0
Envoy源码分析之Stats基础