PeerDAS metrics specifications by Ekaterina Riazantseva | Devcon SEA

[Music] all right hi everyone my name is scansa and my project is beust metrics specifications um so um U miss the slide uh I'm not going to dive into what is spear do uh it's been it's been mentioned already so it's scaling solution for data availability and um all of you know that uh etherum protocol is built with a um according to the consensus uh and execution specs um so uh but the metrics for different clients are different I mean uh we don't have uh the UniFi metrics for the clients um it's challenging for ceps to compare the different clients uh and for for the devops team it's challenging to um to monitor all the clients there are a lot of them um and it's also difficult for research to uh get the unified data to synchronize the data so the solution is One dashboard for all clients and uh the unified metric specs uh so how it worked before uh we had sorry we had uh different dashboards for every client uh different graphs uh so uh to compare different clients uh it was quite painful uh what do we have now for P D um we have a single dashboard with different clients um the metrics implemented for grandine for Lighthouse for um taco and um grandine Lighthouse Teo and prism a little bit so uh for this dashboard you can apply filters um you can choose if it's a full node or super node um you can uh choose one client two clients all clients and you can also choose an instance and compare or monitor or wherever you need let's look at some examples um uh this blue client implemented some feature this one is piras and um uh the filter is for full nodes and it is obvious that there are some issues with it because other clients um for full node they have less values and this one looks like super node this is the case for investigating uh so the next one is obviously uh there is some issue with one client uh which devops can catch V visually or can um can apply the alerts grafana alerts as well um for researchers the this uh dashboard is helpful because they can build benchmarks uh for example here you can see two clients and they have the same metrix uh so this means that probably the case The Benchmark with specific um numbers uh this dashboard is also added to curtois so uh whenever you want to run curosis and you need a beard dashboard it's already there so now need to build your own dashboard um the dashboard is already actively used by jimy by Sigma Prime um this is his notes about um no pust notes uh super notes and full notes bandwidth uh and you can see the graphs from from dashboard why hasn't it been done before because um especially before the merge there were not so many clients and it was manageable but why do we need it now because the ecosystem is growing and there's more and more clients not so fast but anyway the uh number of clients grows and as Perry told me plus one client is 10 time consuming mean for monitoring for testing Etc so the benefits of metric specs uh it's easier to catch errors um it's easier to save resources of teams so you just save some time or um for uh for building for testing Etc um it's easier to compare clients which sometimes really important and for researchers it's easy to create benchmarks um currently padas metrics uh specs cover um the main points of pias uh they computation inclusion proof uh kg verification reconstruction gossip verification and custody and uh they also um uh in the discussion gossips up and lipop metrics with labels for for p do uh this is the current state of project uh some of the metrics are already implemented uh some of them are open PRS um some they need a review or need an adjustment and I hope to cover all this um table but that's not the end the road map uh sorry the workflow for the implementing metric is kind of like this we discover it on um we discuss it on uh pus breakout rooms uh then uh put it into the GitHub specs and then develop test and if researchers need then um create a benchmarks uh then process of reviewing goes and if it's needed then the circle starts again and if it's not it's merged uh but this is not the end so puras metrics are only the beginning I would say um the next goal is to uh spread it to uh consensus clients and later to execution layer um I would like to wrap up with the words of a poet such an i client diversity for the win uh so um this project um presents uh ethereum values uh such like client diversity and collaboration and it wouldn't be possible without my mentors Perry and Barnabas from E PES and Dimitri from te and Jimmy from Lighthouse I also worked with different teams uh prism with Grine uh I had a feedback from megalops um they are researchers um so yeah I'm going to Pro proceed with it thank you for your attention if if you're interested in any details you can scan the code and thank you all right thank you kacha any questions for Kia thank you Josh and Mario that's what wonderful I may have missed it but how are the metrics being collected at the moment is it being produced by C CIS um if you run it on cortosis yeah they are collected uh uh using pereus matrix it's like standard stuff yeah but devop team also has their own databases on Victoria matrics they collected there so these um specifications are more for internal use uh for devops team for researchers but they also available for uh public usage uh you mentioned CL specs do you know if there's any work being done on that yet uh no no but we're we're in discussions about uh uh building specs for um lipop and gosip sub because yeah because they are already in production so it's difficult to kind kind of synchronize them but we're trying to find the solution uh how do you think would it be useful yeah you find it have lots of lots of lots of metrics um and the teams also have their lots and lots of metrics so find be the EAS a this is not a mass so um teams can also uh create their own metrics if they need like more or in different ways so but some of of some of the points uh would be great to be synchronized in any points yeah so um is it correct that uh you uh implemented these uh PRS in different client teams like different clients or did yeah okay so do you see this moving forward to add these metrics across all the parts of the clients do you see this as something that uh you or the devops team would do or is it that the client team themselves have to implement these um like going the way how I see it so we will start we will get used to it and when the new for example EIP or any other feature is delivered later which is not yet started the process is for example in research um with building the specs for the clients we can advance at least like the we can mark the point where should be the metric and the clients uh during the building the feature the IP uh they could bring bring it right into the right place so I I hope I won't do all the metrics for the clients so the idea is just uh to bring this process so it came natural and uh not that painful for teams all right thank you all right thank you Kata thank you