Just an interface and simple implementation dumping points to file on disk.
And I add also few monitoring records to some places of osquery code as an example.
Brief
Just an interface and simple implementation dumping points to file on disk.
And I add also few monitoring records to some places of osquery code as an example.
Motivation
osquery can monitor system health. But at some point we need to monitor the condition of osquery itself. Vast majority of interesting parameters can be represented by
numbers. How many queries it runs, how long does each query takes, what is the performance hit of each query, how long was last downtime and so on and so far. For obviou
s reason it hard to measure most of this parameters by external instrument. And it is almost impossible to evaluate it on production. But we can do it from inside of osquery.
What this PR is for
The systems like graphite or RRDtool can store and plot time-series data for us. We just have to
be able to feed data to it. We can create different plugins to be able to send data to different instruments. And we need some proper internal interface to all potential plugins. This PR is attempt to create generic interface.
Interface description
The most systems accept data as sequences of 2-dimensional points. One of the dimensions is value, the other is time. Each particular sequence has unique key, to be distinguished from the others.
Data descriptions for carbon. I have used this three parameters as an attributes of one monitoring point.
To send one point from some particular place in the code you just need to call the function record from namespace monitoring declared in the file include/osquery/num eric_monitoring.h with 3 arguments (path, value, time). Where path is the unique key of sequence; value is some interesting value to watch; time is the time of the point (can be omitted, current system time is the default vaule).
This is fairly important, it changes the default mode for what status
events are logged to INFO. It had been set to WARNING and INFO was relatively
unused.
This also removes expected support for RocksDB 'in-memory' databases.
If a shell-user requests a database via CLI flags it will now work.
Along with the platform defines and platform string defines provided by
CMake to the build, add a PLATFORM_MASK define.
Use this define as a platform-type mask with the PlatformType enum.
Prior to this change, both --disable_database=false and --database_path had to
be specified together. Now, if the user specifies --database_path the database
is enabled automatically.
