我们正在使用HyperLeDger Fabric 2.2.3，每个组织有2个同行，共有6个认可的同行，3个订购者，并使用Prometheus工具进行监视。
使用认可式的指标来计算认可同行时的交易到达率，当将10件交易发送给网络时，我们观察到以下值。
peer0-org1 : 2 transactions
peer1-org1 : 1 transaction
peer0-org2 : 3 transactions
peer1-org2 : 5 transactions
peer0-org3 : 6 transactions
peer1-org3 : 3 transactions
bardcast_processed_count和ledger_transaction_count指标在所有同行提供了所有10笔交易，并且使用多数认可策略，所有交易都是成功的。
我们想了解sardorser_proposals_recress指标如何给出值。
我们正在使用速率（认可_proposals_recredise [1M]）来计算认可者的到达率
We are using Hyperledger fabric 2.2.3 with 3 organizations 2 peers each, a total 6 endorsing peers,3 orderers, and using the Prometheus tool for monitoring.
using the endorser_proposals_recieved metric for calculating the transactions arrival rate at endorsing peer, when 10 transactions are issued to the network we observed the following values.
peer0-org1 : 2 transactions
peer1-org1 : 1 transaction
peer0-org2 : 3 transactions
peer1-org2 : 5 transactions
peer0-org3 : 6 transactions
peer1-org3 : 3 transactions
where broadcast_processed_count and ledger_transaction_count metrics are giving all 10 transactions at all peers and all transactions are successful, using majority endorsement policy.
we would like to understand how the endorser_proposals_recieved metric is giving values.
we are using rate(endorser_proposals_recieved[1m]) for calculating arrival rate at endorser
发布评论
评论（1）
值得了解面料交易流，此处记录：
您的多数认可策略是指成功更新分类帐的交易，客户必须从至少两个（三个）中获得认可组织。客户可以免费向任何（或全部）可用同行发送建议，以接收（至少）足够的匹配认可的建议响应以符合此认可政策。根据客户的实施，它可能是根据其块高度，随机选择或其他策略来选择同行（和组织）。
关键的外卖是，您可以合理地期望有关不同组织和这些组织中不同同行的不同交易的建议。即使在可用的组织或同行中，提案的分布也不一定是。
请注意，“ nofollow noreferrer”>认可策略关键水平可以进一步影响组织和同行之间的提案分布。
It is worth understanding the Fabric transaction flow, documented here:
https://hyperledger-fabric.readthedocs.io/en/release-2.4/txflow.html
Your majority endorsement policy means that, for a transaction to successfully update the ledger, the client must obtain endorsements from at least two (of three) organisations. The client is free to send proposals to any (or all) available peers in order to receive (at least) enough matching endorsed proposal responses to meet this endorsement policy. Depending on the client implementation, it might be picking peers (and organisations) based on their block height, random selection, or some other strategy.
The key take-away is that you can reasonably expect proposals for different transactions to be spread across different organisations and different peers within those organisations. The distribution of proposals is not necessarily even across available organisations or peers.
Note that endorsement policies specified at the chaincode, collection and key level can further impact the distribution of proposals across organisations and peers.