🎯 Problem to be solved
The metric that we push to prometheus core_validatorapi_vc_user_agent does not always send readable VC type/version. For Lighthouse it doesn't even send one.
i.e.:
okhttp/4.12.0 is for Teku. While we know okhttp is a Java HTTP library and we know only Teku uses Java from our stack, it's not intuitive for users.
Similar to Go-http-client/1.1 and Prysm.
🛠️ Proposed solution
Ask VCs to include the correct header.
🧪 Tests
Check for all VCs (including the newly supported - Vouch) if they are properly displayed in the Validator Client Version in Grafana. Easy to test using Kurtosis.
🎯 Problem to be solved
The metric that we push to prometheus
core_validatorapi_vc_user_agentdoes not always send readable VC type/version. For Lighthouse it doesn't even send one.i.e.:
okhttp/4.12.0is for Teku. While we knowokhttpis a Java HTTP library and we know only Teku uses Java from our stack, it's not intuitive for users.Similar to
Go-http-client/1.1and Prysm.🛠️ Proposed solution
Ask VCs to include the correct header.
Issue: Add
User-AgentHTTP header for validator client requests sigp/lighthouse#7963PR: add user-agent header to all http clients sigp/lighthouse#8786
Issue: Set User-Agent header for any outbound http requests Consensys/teku#9602
PR: Add User-Agent header with Teku version on VC requests Consensys/teku#9935
Issue: Add Nimbus version to all requests status-im/nimbus-eth2#7427
PR:
Issue: Set User-Agent header for any outbound http requests OffchainLabs/prysm#15435
PR: adding user agent validator beacon client OffchainLabs/prysm#15574
🧪 Tests
Check for all VCs (including the newly supported - Vouch) if they are properly displayed in the
Validator Client Versionin Grafana. Easy to test using Kurtosis.