Sametime Meetings dashboard and error reporting

Currently the Sametime/Meetings server can be installed using Docker or Kubernetes. Smaller servers are usually put on Docker.

For Kubernetes there is a playbook on how to build a dashboard, for Docker ther is not. But smaller servers are usually in smaller organizations, with lower resources, and in those smaller organizations an easy way to keep tabs on the Sametime an Meetings server is of great value.

So I would ask if HCL would consider making available a dashboarding playbook for the Docker install. And a reporting feature for admins.

The reason for asking about dashboarding is that I am experiencing problems during meetings. Video meetings are complex beasts.  Lots of individual cogs may snag, and the end result is users complaining about ST and wanting to switch to Teams or another competitor to fix the problem.

Only if the problem is a meeting member with a bad Wifi connection or a crappy driver, this will obviously not solve the problem.  But with the current state of affairs, that is only found out after the new software is installed and used, and by that time the damage is done.

So providing insight to which part of the huge web of things is causing the meeting to drop video or other problems would be really beneficial. The nature of the problem, that there is a huge web of services and connections connecting all the users and the servers involved, make diagnosing any problems also a potentially huge undertaking. I think HCL could create a significant advantage if the admin knew which parts of this web to prioritize when diagnosing. That will lower time spent by the admin, thus loweringTCO. And increase user satisfaction, since problems are resolved faster.

To this end I envision a problem report sent if the server notices any problems. A simple statement, but due to the already observed complexity will probably be not that trivial to solve.

For optimal usability of this report, any problem in the web of things should be able to be reported on. Some examples: UDP/TCP connectivity (is UDP fallback to TCP enabled? How does it affect performance) Video encoding problems, DNS problems (no addres or wrong address), connectivity to STUN servers, timeout of connection tothe MongoDB server, dropped packets, disk errors, etc, etc,. As stated, an online meeting has a lot of moving parts, and any small part not working correctly is seen by all users.

I imagine that a lot of server parts already have some form of logging or fault reporting built in. Ideally, the Sametime clients would also report back problems to the server. I realize that in the case of a droppped connection of a Sametime client, this information would only become available to the server when the client has reconnected to the server. But this could also be in the report: This client was disconnected, and details were either not available at the time the report was sent, or made available at exampleDatetime.

I think that only problems over a certain threshold should be reported, to keep the volume of items down. These thresholds need research, and I think it would be beneficial if they could be set. Perhaps even in the form of profiles, a profile defing the thresholds to be used in making the report. So an admin can assign a certain meeting a more sensitive set of thresholds via a profile if a meeting with a known problematic user is taking place. Another idea is to store a lot of problem data in a database, and producing different reports based on different profiles. Perhaps even automatically selecting a profile based on the size of the report produced as a product of the data and the profile, with the first report sent only reporting a limited set of general statistics and a couple of problems, so as to give an admin a quick initial overview, but also the posibility of drilling down on available data when needed.

All in all a big idea, but I think one with great potential value.