Even now some of the information (not necessarily monitoring) is presented using the procfs or fairly recently added sysfs filesystem (see 28350928d2465fcf5466f42984d86948d913adc2 and 2847b2a0449d01b129627e6a96b2005094b5461a). But a lot of such information is provided by the httpserver-api module and its read-only "cousin" - httpserver-monitoring-api which expose many HTTP endpoints returning information in JSON. There are some downsides to this approach:
the httpserver-api is pretty tightly integrated with the internals of the OSv kernel and relies on many C++ symbols that need to be exported (see the related issue #1186); we have recently made strides to at least convert some of those to the C symbols (see 182499cb6fee68c2ac6fb6d37f84773f79b26f4c and fa3b38e72d633fd179dd03f9665f6d84f742cf0f) but many remain especially in the networking related libtools module
thehttpserver-api is implemented in C++ so implicitly any image that wants to include this monitoring module AND wants to use the version of the kernel with most symbols and all C++ ones hidden, needs to add a fairly large libstdc++.so; it is even worse if the app is in C++ and needs a different version of libstdc++.so (see #821)
Where am I going with this? It would be nice to expose the information which currently httpserver-api retrieves by directly invoking C or still C++ symbols in form of the pseudo-files under /proc or /sys. The advantage of this approach is that any app even in Java would be able to read relevant pseudo-file and utilize it for monitoring. And httpserver-api does not need new endpoints to present new information - one could use the existing /file? endpoint to read the relevant pseudo file. In the future, we could implement an even smaller and "dummer" http module that would only know how to return the content of the files from /proc and /sys and allow for monitoring that way.
Obviously, we would want to use the standard Linux paths for at least some of this information, but if it is OSv specific enough, we would put those under /sys/osv/.
Even now some of the information (not necessarily monitoring) is presented using the
procfsor fairly recently addedsysfsfilesystem (see 28350928d2465fcf5466f42984d86948d913adc2 and 2847b2a0449d01b129627e6a96b2005094b5461a). But a lot of such information is provided by thehttpserver-apimodule and its read-only "cousin" -httpserver-monitoring-apiwhich expose many HTTP endpoints returning information in JSON. There are some downsides to this approach:httpserver-apiis pretty tightly integrated with the internals of the OSv kernel and relies on many C++ symbols that need to be exported (see the related issue #1186); we have recently made strides to at least convert some of those to the C symbols (see 182499cb6fee68c2ac6fb6d37f84773f79b26f4c and fa3b38e72d633fd179dd03f9665f6d84f742cf0f) but many remain especially in the networking relatedlibtoolsmodulehttpserver-apiis implemented in C++ so implicitly any image that wants to include this monitoring module AND wants to use the version of the kernel with most symbols and all C++ ones hidden, needs to add a fairly largelibstdc++.so; it is even worse if the app is in C++ and needs a different version oflibstdc++.so(see #821)Where am I going with this? It would be nice to expose the information which currently
httpserver-apiretrieves by directly invoking C or still C++ symbols in form of the pseudo-files under/procor/sys. The advantage of this approach is that any app even in Java would be able to read relevant pseudo-file and utilize it for monitoring. Andhttpserver-apidoes not need new endpoints to present new information - one could use the existing/file?endpoint to read the relevant pseudo file. In the future, we could implement an even smaller and "dummer" http module that would only know how to return the content of the files from/procand/sysand allow for monitoring that way.Obviously, we would want to use the standard Linux paths for at least some of this information, but if it is OSv specific enough, we would put those under
/sys/osv/.