diff options
author | Chris St. Pierre <chris.a.st.pierre@gmail.com> | 2013-04-23 14:50:09 -0400 |
---|---|---|
committer | Chris St. Pierre <chris.a.st.pierre@gmail.com> | 2013-04-23 14:50:09 -0400 |
commit | 46a47b4120b3d892b8149a5e181e4d976ad87f99 (patch) | |
tree | f2697f233fc7f5ad5022864222a5ca87715a651b /doc/reports | |
parent | e1f99d1d5045e0511db42debb30aa97da2018796 (diff) | |
parent | 3d06f311274d6b942ee89d8cdb13b2ecc99af1b0 (diff) | |
download | bcfg2-46a47b4120b3d892b8149a5e181e4d976ad87f99.tar.gz bcfg2-46a47b4120b3d892b8149a5e181e4d976ad87f99.tar.bz2 bcfg2-46a47b4120b3d892b8149a5e181e4d976ad87f99.zip |
Merge branch '1.4.x'
Conflicts:
debian/bcfg2-server.install
doc/server/plugins/grouping/metadata.txt
src/lib/Bcfg2/Client/Client.py
src/lib/Bcfg2/Client/Tools/Portage.py
src/lib/Bcfg2/Client/Tools/RcUpdate.py
src/lib/Bcfg2/Client/Tools/YUM24.py
src/lib/Bcfg2/Client/Tools/__init__.py
src/lib/Bcfg2/Client/Tools/launchd.py
src/lib/Bcfg2/Options.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/Plugin/helpers.py
src/lib/Bcfg2/Server/Plugins/Metadata.py
src/lib/Bcfg2/Server/models.py
src/lib/Bcfg2/Utils.py
src/sbin/bcfg2-info
src/sbin/bcfg2-test
testsuite/Testsrc/Testlib/TestClient/TestTools/Test_init.py
testsuite/Testsrc/test_code_checks.py
Diffstat (limited to 'doc/reports')
-rw-r--r-- | doc/reports/static.txt | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/doc/reports/static.txt b/doc/reports/static.txt deleted file mode 100644 index 00c1867f8..000000000 --- a/doc/reports/static.txt +++ /dev/null @@ -1,100 +0,0 @@ -.. -*- mode: rst -*- - -.. _reports-static: - -============================= -Bcfg2 Static Reporting System -============================= - -The Bcfg2 reporting system collects and displays information about the -operation of the Bcfg2 client, and the configuration states of target -machines. - -Goals -===== - -The reporting system provides an interface to administrators describing -a few important tasks - -* Client configuration state, particularly aspects that do not match the configuration specification. - Information about bad and extra configuration elements is included. -* Client execution results (a list of configuration elements that were modified) -* Client execution performance data (including operation retry counts, and timings for several critical execution regions) - -This data can be used to understand the current configuration state -of the entire network, the operations performed by the client, how the -configuration changes propagate, and any reconfiguration operations that -have failed. - -Retention Model -=============== - -The current reporting system stores statistics in an XML data store, by -default to ``<repo>/etc/statistics.xml``. It retains either one or two -statistic sets per host. If the client has a clean configuration state, -the most recent (clean) record is retained. If the client has a dirty -configuration state, two records are retained. One record is the last -clean record. The other record is the most recent record collected, -detailing the incorrect state. - -This retention model, while non-optimal, does manage to persistently -record most of the data that users would like. - -Setup -===== - -In order to configure your Bcfg2 server for receiving reports, you -will need to list the Statistics plugin in the plugins line of your -``bcfg2.conf``. You will also need a [statistics] section -in your ``bcfg2.conf``. You can find out more about what goes there in the -``bcfg2.conf`` manpage. - -Output -====== - -Several output reports can be generated from the statistics store with -the command line tool ``bcfg2-build-reports``. - -* Nodes Digest -* Nodes Individual -* Overview Statistics -* Performance - -The data generated by these reports can be delivered by several -mechanisms: - -* HTML -* Email -* RSS - -Shortcomings and Planned Enhancements -===================================== - -When designing the current reporting system, we were overly concerned with -the potential explosion in data size over time. In order to address this, -we opted to use the retention scheme described above. This approach has -several shortcomings: - -* A comprehensive list of reconfiguration operations (with associated - timestamps) isn't retained -* Client results for any given day (except the last one) aren't uniformly - retained. This means that inter-client analysis is difficult, if - not impossible - -We plan to move to a database backend to address the dataset size -problem and start retaining all information. The move to a SQL backend -will allow many more types of queries to be efficiently processed. It -will also make on-demand reports simpler. - -Other sorts of information would also be useful to track. We plan to -add the ability to tag a particular configuration element as security -related, and include this in reports. This will aid in the effective -prioritization of manual and failed reconfiguration tasks. - -Capability Goals (posed as questions) -------------------------------------- - -* What machines have not yet applied critical updates? -* How long did critical updates take to be applied? -* What configuration did machine X have on a particular date? -* When did machine X perform configuration update Y? |