Project

General

Profile

Actions

User story #5293

closed

Add a 'changes only' compliance mode, only reporting changes on systems

Added by François ARMAND over 9 years ago. Updated over 9 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Config management
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

Today, Rudder only support one reporting mode which is a compliance assessing mode.
That means that at any time, Rudder knows what execution report each node should have send, compare it to what the node actually sent, and based on that display what is ok and what is wrong.

To be more precise, when a node run the agent, it execute compliance assessment on a list of rules, composed of several directives, composed of several components, composer of several values, possibly avaiting several message (execution reports).

Compliance assessment on each component produces reports among success (yes !), error ("the component is not in the correct state and I can't change that"), "repaired" (the componenent was not on the correct state and I corrected it to the correct one), and other status failing in either of this 3 kinds or not relevant for compliance (log/info messages).

In compliance checking mode (the current, only mode available), Rudder will look if the node exactly sent the correct number of messages throught execution reports, even if they are ALL success, because getting 0 or more than two success when exactly one isexpected is an error, and getting "success" for unknow components is clearly spurious and need investigation.

That mode is great but generate a lot of traffic on the wire. So sometime, we could afford, even prefer, a mode where only changesù ("error" and "repaired" status) are sent back to the server. In that mode, we assume that the absence of error is a success, and so that account for the "compliance disabled" semantic. In that mode, we will not be able to detect compliance drift like on the compliance one above, but on the other hand it will be far less chatty.

From a more technical point of view, even in changes-only mode, we will keep the system logs "agent run start / agent run end" that a node send to indicate that the agent runs during that period if other changes have to be notified to the server. We will consider that any reports not sent by the node in that interval are actually success reports.

Moreover, some "agent run start / agent run end" may not be send to the server because no changes happened in that run. In that case, periocically, even if everything is ok, a heartbeat message can be send (surrounded by run start/run end), so that the server knows that the node is alive and actually check things.


Subtasks 25 (0 open25 closed)

User story #5296: Create the logic to get execution reports for "error only" modeReleasedNicolas CHARLES2014-09-24Actions
User story #5568: Add migration script for new property "rudder.jdbc.maxPoolSize"RejectedFrançois ARMAND2014-09-24Actions
Bug #5658: full-compliance default value is wrongReleasedFrançois ARMAND2014-10-20Actions
Bug #5667: Bad logic in the computation of number of reportsReleasedNicolas CHARLES2014-10-21Actions
Bug #5710: Rudder 3.0 is missing migration elements (SQL script and property)ReleasedJonathan CLARKE2014-11-06Actions
Bug #5745: Rudder 3.0 configid migration uses the wrong conditionReleasedJonathan CLARKE2014-11-06Actions
User story #5294: Add a configuration option for the "error only" mode in admin tabReleasedFrançois ARMAND2014-09-05Actions
User story #5335: Set the value of the system variable RUDDER_REPORT_MODEReleasedFrançois ARMAND2014-09-05Actions
Bug #5494: Compilation error: missing modification in the PRReleasedFrançois ARMAND2014-09-05Actions
User story #5297: Adapt display to handle new compliance/change only modeReleased2014-07-22Actions
User story #5320: Update technique to understand "error only" modeReleasedNicolas CHARLES2014-07-24Actions
User story #5351: Create definition of system variable RUDDER_REPORT_MODE for reporting mode of RudderReleasedNicolas CHARLES2014-08-01Actions
User story #5434: Change the frequency of the agent executionReleasedNicolas CHARLESActions
User story #5473: Add node config id in StartRun/EndRun reports messageReleasedFrançois ARMAND2014-09-03Actions
User story #5501: Add Twitter boostrap CSS & JS in RudderReleasedVincent MEMBRÉ2014-09-08Actions
User story #5576: Add a heartbeat feature that force agent to periodically contact RudderReleased2014-09-26Actions
User story #5577: UI for configuring heartbeat by nodeReleasedFrançois ARMAND2014-09-26Actions
User story #5578: Heartbeat Rudder/technique integrationReleasedFrançois ARMAND2014-09-26Actions
User story #5579: Send reports from the agent to provide a heartbeatReleasedNicolas CHARLES2014-11-29Actions
Bug #5874: Start message from system techniques is sometimes not printed due to over-zealous lockingReleasedNicolas CHARLES2014-11-29Actions
Bug #5878: Apply fix from #5874 to ncf's copyReleasedNicolas CHARLES2014-11-29Actions
Bug #5883: Missing system variables for RUDDER_HEARTBEAT_INTERVAL and SEND_METRICS in TechniquesReleasedNicolas CHARLES2014-11-29Actions
Bug #5882: System variable RUDDER_REPORT_MODE is never setReleasedFrançois ARMAND2014-11-29Actions
Bug #5855: RUDDER_NODE_CONFIG_ID not in bundle common gReleasedJonathan CLARKE2014-11-28Actions
User story #5399: Create a system variable RUDDER_NODE_CONFIG_ID to store the node current configuration identifierReleasedNicolas CHARLES2014-08-18Actions

Related issues 1 (0 open1 closed)

Related to Rudder - Bug #5334: The archiving logic of execution reports needs to be adapted for "error only" report modeRejected2014-07-31Actions
Actions

Also available in: Atom PDF