Channelz简介

Channelz简介
Channelz是⼀个⼯具，可提供有关gRPC中不同级别的连接的全⾯运⾏时信息。

它旨在帮助调试可能受到⽹络，性能，配置问题等实时程序提供有关channelz设计的详细说明，并且是跨语⾔的所有channelz实现的规范参考。

本博客的⽬的是使读者熟悉channelz服务以及如何使⽤它解决调试问题。

这篇⽂章的上下⽂是在，但总体思路应适⽤于多种语⾔。

在撰写本⽂时，channelz可⽤于和。

⽀持包装语⾔即将推出。

让我们通过⼀个简单的⽰例来学习channelz，该⽰例使⽤channelz来帮助调试问题。

的我们的仓库中的⽰例进⾏了稍微修改以设置越野车场景。

您可以在此处找到完整的源代码：，。

客户端设置：客户端将使100个SayHello RPC到达指定的⽬标，并使⽤循环策略负载均衡⼯作负载。

每个呼叫都有150毫秒的超时时间。

记录RPC响应和错误是为了进⾏调试。

运⾏该程序，我们在⽇志中注意到存在间歇性错误，错误代码为DeadlineExceeded，如图1所⽰。

但是，没有什么原因导致超出期限的错误，并且存在很多可能性：
⽹络问题，例如：连接丢失
代理问题，例如：中间的请求/响应被丢弃
服务器问题，例如：请求丢失或响应缓慢
图1.程序⽇志屏幕截图
让我们打开grpc INFO⽇志以获取更多调试信息，看看是否可以找到有⽤的信息。

图2. gRPC INFO⽇志
如图2所⽰，信息⽇志指⽰到服务器的所有三个连接均已连接，并准备传输RPC。

⽇志中未显⽰可疑事件。

从信息⽇志中可以推断出的⼀件事是所有连接⼀直都处于打开状态，因此可以排除丢失的连接假设。

为了进⼀步缩⼩问题的根本原因，我们将向channelz寻求帮助。

Channelz通过gRPC服务提供gRPC内部联⽹机制统计信息。

要启⽤channelz，⽤户只需在其程序中将channelz服务注册到gRPC服务器并启动服务器即可。

下⾯的代码段显⽰了将channelz服务注册到的API 。

请注意，我们的⽰例客户端已经完成了此操作。

import "/grpc/channelz/service"
// s is a *grpc.Server
service.RegisterChannelzServiceToServer(s)
// call s.Serve() to serve channelz service
⼀个名为⽹络⼯具已开发出可通过⽹页⽅便地提供channelz数据的⼯具。

⾸先，将Web应⽤程序配置为连接到为channelz服务提供服务的gRPC端⼝（请参阅上⼀个链接中的说明）。

然后，在浏览器中打开channelz⽹页。

您应该看到⼀个如图3所⽰的⽹页。

现在我们可以开始查询channelz！
图3. Channelz主页
由于错误是在客户端，因此我们⾸先单击。

TopChannels是没有⽗母的根频道的集合。

在gRPC-Go中，主要渠道是由⽤户通过创建或，⽤于进⾏RPC调⽤。

顶部通道的在channelz中键⼊，这是可以发布RPC的连接的抽象。

图4. TopChannels结果
因此，我们单击TopChannels，然后会出现⼀个如图4所⽰的页⾯，其中列出了所有实时直播频道以及相关信息。

如图5所⽰，只有⼀个顶部通道的id = 2（请注意，⽅括号中的⽂本是内存通道对象的参考名称，可能会因语⾔⽽异）。

查看“数据”部分，我们可以看到在此通道中有15个呼叫失败（总共100个）。

图5.顶部通道（id = 2）
在右侧，它显⽰该通道没有⼦Channel，3个 Subchannel（如图6中突出显⽰）和0 Sockets。

图6.通道拥有的⼦通道（id = 2）
⼀个是对连接的抽象，⽤于负载平衡。

例如，您要将请求发送到“ ”。

解析器将“ ”解析为多个为“ ”服务的后端地址。

在此⽰例中，为客户端设置了循环负载均衡器，因此向所有活动后端发送了相等的流量。

然后，到每个后端的（逻辑）连接表⽰为⼦通道。

在gRPC-Go中，可以看作是⼦渠道
⽗通道拥有的三个⼦通道意味着与三个不同的后端有三个连接，⽤于将RPC发送到该后端。

让我们查看它们的内部以了解更多信息。

因此，我们单击列出的第⼀个⼦通道ID（即“ 4 []”），然后显⽰如图7所⽰的页⾯。

我们可以看到该⼦通道上的所有调⽤均已成功执⾏，因此该⼦通道不太可能与我们遇到的问题有关有。

图7.⼦通道（id = 4）
因此，我们返回并单击⼦频道5（即“ 5 []”），该⽹页再次表明，⼦频道5也从未发⽣过任何失败的呼叫。

图8.⼦通道（id = 6）
最后，我们单击Subchannel6。

这⼀次有所不同。

如图8所⽰，此⼦通道上的34个RPC调⽤中有15个失败。

请记住，⽗通道也有15个失败的呼叫。

因此，⼦渠道6是问题所在。

⼦通道的状态为READY，这意味着它已连接并准备传输RPC。

那排除了⽹络连接问题。

要了解更多信息，我们来看⼀下此⼦通道拥有的Socket。

⼀个⼤致相当于⽂件描述符，通常可以视为两个端点之间的TCP连接。

在grpc-go中，和对应于Socket。

请注意，⽹络侦听器也被认为是套接字，并将显⽰在channelz服务器信息中。

图9.⼦通道（id = 6）拥有套接字（id = 8）
我们单击页⾯底部的Socket 8（请参见图9）。

现在，我们看到如图10所⽰的页⾯。

该页⾯提供有关套接字的全⾯信息，例如正在使⽤的安全性机制，流计数，消息数，keepalive，流控制编号等。

套接字选项信息未显⽰在屏幕快照中，因为其中有很多套接字选项且不相关我们正在调查的问题。

“远程地址”字段表明我们遇到问题的后端是“ 127.0.0.1:10003”。

这⾥的流计数与⽗⼦信道的呼叫计数完全对应。

由此，我们可以知道服务器没有主动发送DeadlineExceeded错误。

这是因为如果服务器返回DeadlineExceeded错误，则流将全部成功。

客户端流的成功与调⽤是否成功⽆关。

根据是否已收到设置了EOS位的帧来确定（请参阅有关更多信息）。

此外，我们可以看到发送的消息数为34，等于呼叫数，它排除了客户端以某种⽅式卡住并导致超过期限的可能性。

总之，我们可以将问题缩⼩到服务器上127.0.0.1:10003上。

服务器可能响应缓慢，或者服务器前⾯的某些代理正在丢弃请求。

图10.套接字（id = 8）
如您所见，channelz只需单击⼏下就可以帮助我们查明问题的潜在根本原因。

现在，您可以集中精⼒使⽤精确服务器。

同样，channelz也可以帮助加快服务器端的调试速度。

我们将在这⾥停⽌，让读者探索⽐客户端更简单的服务器端channelz。

在channelz中，⼀台还是类似于Channel的RPC⼊⼝点，传⼊的RPC到达并得到处理。

在grpc-go中，⼀个对应于channelz服务器。

与Channel不同，Server仅将套接字（侦听套接字和正常连接的套接字）作为其⼦代。

以下是给读者的⼀些提⽰：
查找地址为（127.0.0.1:10003）的服务器。

查看通话次数。

转到服务器拥有的套接字。

查看Socket流计数和消息计数。

您应该注意到，服务器套接字接收到的消息数量与客户端套接字（套接字8）发送的消息数量相同，这排除了中间出现代理⾏为异常（丢弃请求）的情况。

并且服务器套接字发送的消息数等于客户端接收到的消息数，这意味着服务器⽆法在截⽌⽇期之前发回响应。

您现在可以看⼀下代码以验证是否确实是原因。

服务器设置：服务器端程序启动三台GreeterServer，其中两台使⽤实现（）响应客户端时没有延迟，并且使⽤了⼀种实现（）会在发送响应之前注⼊100ms-200ms的可变延迟。

正如您在本演⽰中所看到的，channelz帮助我们快速缩⼩了问题的可能原因，并且易于使⽤。

有关更多资源，请参见详细的channelz 。

在GitHub上找到我们，为。