question ask, why meta protocol proxy not support metric like istio_request_total?

[huanghuangzym]

istio_request_total metric name is set regular, and label provices source and destination workload ,port ,request path and so on
but when i use aeraki metaprotocol ,it provides like

it is difficult to use the metric to statistics ,analyze , and Alarm notification
can meta protocol proxy support feature like this ?
provide stats filter ?

[huanghuangzym]

i think like duboo, source envoy can set some metadata inthe annotation?

[zhaohuabing]

@huanghuangzym it's a great suggestion, I'd like to put this on the backlog.

Before we have the stats filter, please try to make the most of the current metrics generated by the MetaProtocol Proxy. They still can provide some very useful information about the services at the request level, such as Pxx latency, error rate, etc. https://www.aeraki.net/zh/docs/v1.0/tutorials/metrics/

[zhaohuabing]

i think like duboo, source envoy can set some metadata in the annotation?

Could you please elaborate on your use case? What labels do we need to add to the metrics?

Istio adds the following labels to a metric:

纬度	含义	示例	备注
source_cluster	集群-请求源端		请求跨集群时才会有该label
source_app	应用名称-请求源端	reviews	来源于deployment的 app label，如没有则是 unknown
source_canonical_service	标准服务名称-请求源端	reviews	来源于label service.istio.io/canonical-name
source_workload_namespace	namespace-请求源端	default
source_workload	deployment-请求源端	reviews-v3
source_principal	服务身份-请求源端	spiffe://cluster.local/ns/default/sa/bookinfo-reviews
source_canonical_revision	标准版本号-请求源端	v3	来源于label service.istio.io/canonical-version
source_version	版本号-请求源端	v3	来源于label version，可能和source_canonical_revision
destination_cluster	集群-请求目的端		请求跨集群时才会有该label
destination_app	应用名称-请求目的端	ratings	来源于deployment的 app label，如没有则是 unknown
destination_service_namespace	服务所在namespace-请求目的端	default	如果采用 VS 进行路由，service和实际的workload的namespace可以不同
destination_workload_namespace	deployment所在namespace-请求目的端	default
destination_canonical_service	标准服务名-请求目的端	ratings	来源于label service.istio.io/canonical-name
destination_service_name	实际服务名-请求目的端	ratings	目的端实际服务名，可能和destination_canonical_service不同
destination_service	服务全限定名称-请求目的端	ratings.default.svc.cluster.local
destination_principal	服务身份-请求目的端	spiffe://cluster.local/ns/default/sa/bookinfo-ratings
destination_workload	deployment-请求目的端	ratings-v1
destination_canonical_revision	标准版本号-请求目的端	v1	来源于label service.istio.io/canonical-version
destination_version	版本号-请求目的端	v1	来源于label version，可能和destination_canonical_revision
response_code	http/grpc 返回码	200
response_status	调用是否成功	0	0 成功，非 0表示失败。该取值根据协议类型是 http 还是 grpc 分别进行判断，remote writer向云监控中台上报时添加
connection_security_policy	链接安全策略	mutual_tls
instance	服务实例	172.16.0.7:15090
response_flags	返回标准（出错时的具体信息）	UR
request_protocol	应用层协议	http
reporter	本metrics的上报端	destination

[huanghuangzym]

usally we use source and destination app,workload,namespace,cluster; destination svc ,response code, status in alauda.

[zhaohuabing]

That's something we can do. Do you also need metrics on both sides (reporter=source/destination)?

…

On Fri, May 6, 2022 at 11:11 AM lihuang ***@***.***> wrote: usally we use source and destination app,workload,namespace,cluster; destination svc ,response code, status in alauda. — Reply to this email directly, view it on GitHub <#196 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCWITDMPUB5WLZANEM2WTVISEW5ANCNFSM5VETMMHQ> . You are receiving this because you commented.Message ID: ***@***.***>

[huanghuangzym]

That's something we can do. Do you also need metrics on both sides (reporter=source/destination)?
…
On Fri, May 6, 2022 at 11:11 AM lihuang @.> wrote: usally we use source and destination app,workload,namespace,cluster; destination svc ,response code, status in alauda. — Reply to this email directly, view it on GitHub <#196 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKCWITDMPUB5WLZANEM2WTVISEW5ANCNFSM5VETMMHQ . You are receiving this because you commented.Message ID: @.>

usally we use source, because there are many self protocol server have not injected sidecar
in future, it is better to provicde both

[zhaohuabing]

We can do it in two steps:

1. First, try to add needed labels to the metrics generated by MetaProtocol proxy framework. It would meet your current requirements.
2. The long term goal is to create a dedicated stats filter to generate metrics at the service level on both sides.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[huanghuangzym]

it seems only destination metric has all value ,but in source metric ,the destination lable value are all unknown

[huanghuangzym]

@zhaohuabing can help me?

[huanghuangzym]

it seems in the document,the metric is also has many unknown @zhaohuabing

[zhaohuabing]

@huanghuangzym Currently only mutation in the dubbo request is handled, we need alose to encode the mutated header here :https://github.com/aeraki-mesh/meta-protocol-proxy/blob/8cd2ac4a7b43e165ba9d70d78c054fdf525d1523/src/application_protocols/dubbo/dubbo_codec.cc#L70

[huanghuangzym]

@huanghuangzym Currently only mutation in the dubbo request is handled, we need alose to encode the mutated header here :https://github.com/aeraki-mesh/meta-protocol-proxy/blob/8cd2ac4a7b43e165ba9d70d78c054fdf525d1523/src/application_protocols/dubbo/dubbo_codec.cc#L70

ok let me try

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.