Introspection endpoints are used in collector as a way to inspect its internal state when working on developing/debugging code. Implementing something similar could be helpful long-term when teams running fact in clusters want to debug potential issues.
With the current code state, I would propose adding introspection endpoints for:
/config: return the currently applied configuration from config::reloaded::Reloaded/inodes: return the current map of inodes to paths from host_scanner./info: return general information about fact and the system it is currently running on.
For the implementation itself, I would suggest an approach similar to how the output component handles reconnections.
endpoints can hold the sender end of an mpsc channel for each component to inspect.- When receiving a query for a component, send a
oneshot::Sender<String> through the channel for the component to be inspected.
- The component gets the message, dumps its internal information as a JSON string and sends it back through the
oneshot::Sender.
- The endpoint side uses the JSON string as the body in the response for the query.
Introspection endpoints are used in collector as a way to inspect its internal state when working on developing/debugging code. Implementing something similar could be helpful long-term when teams running fact in clusters want to debug potential issues.
With the current code state, I would propose adding introspection endpoints for:
/config: return the currently applied configuration fromconfig::reloaded::Reloaded/inodes: return the current map of inodes to paths fromhost_scanner./info: return general information about fact and the system it is currently running on.For the implementation itself, I would suggest an approach similar to how the
outputcomponent handles reconnections.endpointscan hold the sender end of anmpscchannel for each component to inspect.oneshot::Sender<String>through the channel for the component to be inspected.oneshot::Sender.