Expose all the graph statistics via network not only in the diag window

[rubu]

Description

Due to leaks and sync issues it would be very interesting to obtain the statistics show in the diagnostics window for aggregation and inspection. Currently AMCP has some stats on the GPU usage, OSC exposes rates for channels, but stuff like dropped frames and consume times are not exposed.

Solution suggestion

I could implement this, but since I don't want to live off a fork all the time, my question is what would be the preferred way, so that this stuff can be accepted via a Pull Request? I see the following options:

1. Add an AMCP command that returns the values from the last tick. Kind of bad that this would mean polling, but it would live off an existing mechanism
2. Add support for this in OSC. I noticed that current OSC implementation does not use proper NTP timestamps but some kind of ticks, which I would need to fix then. And UDP being unrealiable, but again an already existing mechanism
3. A new transport, I guess TCP based, maybe compatible with Prometheus or any other popular monitoring software?

---

Additional information

If you have some additional information or attachments.

[hreinnbeck]

Note: If done via OSC it should be configured in the config file and disabled by default.

[Julusian]

I do not like 1. I don't think it would be able to give a good set of data if only returning the last tick due to command queueing. 3 adds quite a bit of complexity, and another library. While the idea of prometheus metrics does appeal to me, but I don't think the pull model is best suited here and not everyone wants to run prometheus.

2 is the most appealing, and is basically what we used to have in 2.1. I don't remember why that went away. UDP being unreliable is probably not something worth worrying about. Just make sure that casparcg and the receiver are close together on a reliable network and all will be fine. Many people and hardware devices use osc over wifi for sending commands without issue.

With osc being such a common protocol, it will be easy to write a standalone process in any language to convert the osc data into a more useful format such as prometheus

As hreinnbeck says, it should be an opt in thing. Probably opt-in per osc target, as most will not care for the information.

[rubu]

@jamesdwise thanks, yeah 2. also did sound as as the best choice to me, so will spare some time and start working.