Some thoughts on Orchestrator's collating metrics

[payton]

My original post seems to be caught by the spam bot. Woops.

Anyways…

I think there are two discussions here:

1. How can Orchestrators better make sense of their own data? (new metric sources, new aggregates, alternative queries of existing livepeer metrics, etc)
2. What would a community data analytics environment look like?

@Strykar

If this is to serve as a community driven effort, we ought to collect metrics from sources other than the livepeer binary, like the kernel / NIC driver etc. and ensure that some metric types, common to all of them, do indeed converge as expected.

While there is absolutely value in collecting these additional metrics, the intent should not be to verify what livepeer reports. We are 100% capable of validating what the code reports in a much simpler and less error-prone way. It’s open source, so let’s take advantage of that.

@papa_bear

While I understand this is being proposed as a community driven effort, I’m concerned about the value of the data if this is done on an opt-in basis.

I agree with Stryker on this one that we can still extract a lot of value based on inference. We have the tools available to identify the location of nearly every single Orchestrator along with their stake. Using that, we can make some solid guesses on sessions.

@NightNode

However, as livepeer is the one who is pushing client changes and developing the application that we use for orchestrating. I do not think that it is an unreasonable assumption that they could integrate annonymous data reporting into the application.

IMO anonymizing data should be on us and we should keep the livepeer client as simple as possible. Our community efforts should be decoupled from livepeer. It’s worth noting that the livepeer client will not be the only client in the future. As the community grows, other client implementations will pop up.

@hthillman

I mentioned this to strykar in DM, but I would eventually be interested in rolling this into the explorer (accessible only to Os)

Does this mean that Livepeer would host the infra for ingestion?

@hthillman

(2) concerned about opt-in and would rather have the node software collect and anonymize data, why not submit a PR to update the node software in go-livepee

Just reemphasizing that I’m not a huge fan of this option. This is because I feel the livepeer client should be as simple as possible and stick to its core purpose (b/o/t operations… and i guess r [redemption] too)