Module: check_mk
Branch: master
Commit: ca8b5074a2745c7aad6c9d57769f41cc8b1e9b94
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=ca8b5074a2745c…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Fri Mar 25 08:10:43 2011 +0100
Cleaned up directories
---
BI.fehlt | 14 +++++++++++---
figheader => doc/helpers/figheader | 0
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/BI.fehlt b/BI.fehlt
index 092d448..96efbe2 100644
--- a/BI.fehlt
+++ b/BI.fehlt
@@ -20,9 +20,6 @@ Modi, untern denen eine Aggr berechnet werden kann:
* mit 'force worst'
* Downtimeanalyse (Downtime wie crit behandeln)
-Pending muss korrekt behandelt werden. Am einfachsten wäre ein
-eigener BI-Status dafür.
-
Berechtigungen für:
Aggregationen ansehen generell??
Assume state ausführen
@@ -45,9 +42,20 @@ FEATURE: Icon zum Assumen soll auch bei den normalen Icons erscheinen, wenn:
* Überhaupt Aggregationen definiert sind (len(config.aggregations) > 0)
* Man das Recht dazu hat, was zu assumen
* Die (neue) display option dafür eingeschaltet ist.
+ * Man könnte auch anstelle der jetzt vorhandenen Legobausteine das Assume-Icon
+ malen?
FEATURE: Downtimes: sollte man hierfür nicht auch einen BI-Status machen?
Oder muss diese Information separat noch oben driften?
+Wenn ja, dann muss aber klar sein, ob der Status - wenn man die Downtimes
+ausklammern - grün wäre? Besser ist es so:
+Wenn das Aggregat rot ist gilt es dann als "in downtime", wenn alle Zustände,
+die zum rot beitragen, selbst in Downtime sind. Solange die Downtimes nur
+Komponenten betreffen, die nicht den kritischen Status hervorrufen,
+gilt es nicht als in Downtime?
+
+Das Aggregat gilt als "in downtime", wenn
+
FEATURE: Acknowledgements: Sollen wir diese auch nach oben leiten?
diff --git a/figheader b/doc/helpers/figheader
similarity index 100%
rename from figheader
rename to doc/helpers/figheader
Module: check_mk
Branch: master
Commit: 254ec4aad49c42d8528489f22bf706f83fcc1e79
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=254ec4aad49c42…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Wed Mar 23 07:59:32 2011 +0100
updated ChangeLog
---
ChangeLog | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 508afbc..f77780b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -51,7 +51,7 @@
* windows_update: Added check to monitor windows update states on windows
clients. The check monitors the number of pending updates and checks if
a reboot is needed after updates have been installed.
- * FIX: Linux mk_oracle: Updated tablespace query to use 'used blocks' instead of 'user blocks'
+ * FIX: mk_oracle: Updated tablespace query to use 'used blocks' instead of 'user blocks'
* FIX: bluecoat_sensors: Using scale parameter provided by the host for reported values
Module: check_mk
Branch: master
Commit: dbabe349caa26432e2407885c0c8ab5ed4822766
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=dbabe349caa264…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Tue Mar 22 16:27:22 2011 +0100
Added README for setup in OMD
---
doc/README.setup_in_omd | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/doc/README.setup_in_omd b/doc/README.setup_in_omd
new file mode 100644
index 0000000..7ba6ed7
--- /dev/null
+++ b/doc/README.setup_in_omd
@@ -0,0 +1,28 @@
+How to install Check_MK into an exisiting OMD site
+==================================================
+This feature is experimental: You can install Check_MK
+into an existing OMD site by unpacking the installation
+tarball and running ./setup --yes as OMD site user.
+This will install Check_MK into the site's local/
+filesystem hierarchy.
+
+After that relogin (to make sure the shell really
+executes the new cmk command) and do a cmk -U in order
+to re-create your Nagios configuration.
+
+Uninstalling must be done manually. This can be
+done with the following commands provided that no
+other files you need are lying around below local!
+Use at your own risk!
+
+omd stop
+cd ~
+find local -type f | xargs rm
+cd etc/apache/conf.d
+ln -sfn ../../check_mk/apache.conf check_mk.conf
+cd ~/etc/nagios/nagios.d
+ln -sfn ../../mk-livestatus/nagios.cfg mk-livestatus.cfg
+rm -f ~/etc/check_mk/apache-local.conf
+rm -f ~/etc/mk-livestatus/nagios-local.cfg
+cmk -U
+omd start
Module: check_mk
Branch: master
Commit: 8a2abb4e20ed874cfdd6a98e6568832f03b256c1
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=8a2abb4e20ed87…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Tue Mar 22 08:25:30 2011 +0100
Cleaned up source tree
---
README.writing_checks | 167 -------------------------------------------------
1 files changed, 0 insertions(+), 167 deletions(-)
diff --git a/README.writing_checks b/README.writing_checks
deleted file mode 100644
index 7fd1df0..0000000
--- a/README.writing_checks
+++ /dev/null
@@ -1,167 +0,0 @@
-This file will help you to write *good* checks for Check_MK.
-
-Naming
-
-* Check file names should be named short and unique. They must consist
- only of lower case characters, digits and underscores and begin
- with a lower case character.
-
- Vendor specific checks must be prefixed with a vendor specific unique
- abbreviation (which you think of). Example: fsc_ for Fujitsu Siemens Computers.
-
- Product specific checks must be prefixed with a product abbreviation, for
- example "steelhead_status" for a Steelhead appliance of Riverbed.
-
-* SNMP based checks: if the check makes use of a standardized MIB which
- is or might be implemented by more than one vendor, then the check should
- not be named after the vendor but after the MIB. An example are the
- hr_* checks.
-
-* The service description of different check types that essentially
- do the same must be identical (e.g. if/if64/ifoperstatus). Reason:
- this makes rules in main.mk simpler for the user!
-
-
-Coding style
-
-* If the check is contributed by a third party (like you), you must
- add your name and your email address.
-
-* Avoid long lines. In an optimal case your lines don't exceed 80 chars.
- 100 chars.
-
-* Use four spaces for intending your code. Just don't use tab chars.
- And if you really can't life without tabs set the tab width to 8 spaces.
-
-* For parts part of the official Check_MK the file header with the
- copyright information must be present. This will be automatically
- created if you call 'make headers' in the main source directory
-
-* TCP-Agent based checks *must* put an output example of the
- agent in comments into the check file right after the header
- and before the implementation. If the agent output can have
- different formats or output style then put an example for each
- kind of style the check supports (e.g.: the output of multipath -l
- has changed its layout between SLES 10 and SLES 11).
-
- For SNMP based checks put examples if the kind of output is
- in some respect remarkable.
-
- The example output is very helpful for understanding how the
- check parser works.
-
-* Configuration variable for main.mk should be named after
- the check, if they are only used by this check. This does
- not hold for variables, that are used by several checks
- (e.g. filesystem_levels is used by df, hr_fs, df_netapp, ...)
-
-* If a check does not use check parameter, then the inventory function
- must return None as parameter and the check function must name
- the parameter argument _no_params.
-
-* The name of the inventory and check function must be
- prefixed with the name of the check type, for example
- inventory_h3c_lanswitch_cpu for 'h3c_lanswitch'
-
-* Order of implementation:
-
- 1. fileheader with GPL
- 2. example output from agent
- 3. default settings of configuration variables
- 4. helper functions and variable, if any needed
- 5. inventory function
- 6. check function
- 7. check_info[] definition
- 8. snmp_info[] definition
- 9. snmp_scan_functions[] definition
-
-* Configuration variables for main.mk
-
-* Variable naming. Use lower case variable names where the keywords are splitted by _ signs.
-
-* Creating nagios state strings: There is a dictionary named 'nagios_state_names'.
- You can use it to get nagios state string from nagios return codes. e.g.:
- nagios_state_names[0] gives you 'OK'.
-
-SNMP Scan function:
-
-* Every SNMP check *must* have an SNMP scan function. That function
- should as *minimal* as possible: It should only fire at those devices
- that really can support the check. Reason: unneccessary SNMP walks
- on devices not supporting that check must be avoied.
- The scan function must on the other hand not be so strict that it
- rules out devices where the check would work. If in conflict between
- these two issues than rather make the scan function not too strict.
- The scan function should avoid fetching non-standard-OIDs by any
- means. It should rather try to use the basic SMIv2 OIDs as these will
- already have been fetched and cached by the scan functions of other checks!
- All scan functions of all checks together should fetch as few OIDs as
- possible!
-
-Other issues:
-
-* Default values for check parameters (e.g. switch_cpu_default_levels) must be
- chosen in a way that they make sense for *everybody*, not just for your special
- case. In case you are not sure then rather choose too loose than too tight levels.
- This helps avoid false alarms.
-
-* If the same configuration variable is used in multiple checks, *all* of them
- must set a default value and all those values must be identical!
-
-* Your check should assume that the agent is always producing valid data. It
- should *not* try to handle cases where the agent output is broken. This is
- handled by Check_MK via Python exceptions. Otherwise you would make the code
- uglier and also disable the debug handler.
-
-* int() vs. saveint(), float vs. savefloat(): int(s) will throw an exception if
- if is not a valid number string (or empty). Then Check_MK will catch the exception
- and make the check result "UNKNOWN" with an according error message. saveint(s) will
- assume 0, if s is not valid. Important: use saveint() in all places, where you know
- or suspect that some device does not supply valid data *but* the check can work
- with the rest of the data and produce useful results. use int() in all other cases,
- e.g. if the check does not make any sense if you have no valid data.
-
-Performance data:
-* Only set perfdata flag when the check really produces performance data
- output.
-
-* Each check that outputs performance data *must* have a dedicated PNP
- graph definition in pnp-templates. If the check has warning and critical
- levels then the graph must display those levels as yellow and red
- lines.
-
-* Each check that outputs performance data must also have an RRA definition
- the specifies which of MAX, MIN and AVERAGE is needed to display the
- graph in its current (and maybe future) forms. Those are in pnp-rraconf.
- Use a symlink here.
-
-* Each check that outputs performance data should have a perf-o-meter.
- For checks part of Check_MK this must be done in web/plugins/perfometer/check_mk.py.
- For third party checks this should be done in a separate file in web/plugins/perfometer.
-
-SNMP based checks:
-* Only use numeric OIDs in your checks. Name based OIDs rely on MIB files
- and the check won't work when the MIB files are not in place.
-* The used numeric OIDs MUST be given with a leading dot.
-
-Forbidden things:
-* Neither the check- nor the inventory function may use the print command
- or otherwise output any data to stdout or stderr nor otherwise communicate
- with the outside. An rare exception to this are checks that need a dedicated
- data storage (such as logwatch: it keeps unread log messages in files).
-
-Manpages
-
-* Each check *must* have a man page. This should be:
- - complete
- - precise
- - terse
- - helpful!!
-
-* Information that must be contained in the description:
- - What does the check exactly?
- - Under which circumstances goes the check to WARN/CRIT?
- - Which devices are supported by the check?
- - Does the check require some configuration of the agent or
- some separate plugin? (example: The logwatch check requires
- the agent plugin mk_logwatch to be installed)
Module: check_mk
Branch: master
Commit: 29172561decbf95e3cac9527e12220ae3a324184
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=29172561decbf9…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Tue Mar 22 15:31:23 2011 +0100
Updated bug entries
---
.bugs/183 | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/.bugs/183 b/.bugs/183
new file mode 100644
index 0000000..6647e82
--- /dev/null
+++ b/.bugs/183
@@ -0,0 +1,14 @@
+Title: bluecoat_sensors pnp links/hover menus are broken
+Component: multisite
+Benefit: 2
+State: open
+Cost: 3
+Date: 2011-03-22 15:25:58
+Class: cleanup
+
+The bluecoat sensors check creates checks with plus signs in the name, eg +12V bus voltage.
+This seems to break the links/hovers to pnp. This might also be a problem in pnp.
+
+The rrd files are named '+12V_bus_voltage.rrd'.
+
+Need to be analyzed.
Module: check_mk
Branch: master
Commit: 934a3d999f5df32e28acbaa468dbe4ea0643953f
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=934a3d999f5df3…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Tue Mar 22 14:43:17 2011 +0100
FIX: Linux mk_oracle: Updated tablespace query to use 'used blocks' instead of 'user blocks'
---
ChangeLog | 1 +
agents/plugins/mk_oracle | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 31a3487..e75f9ff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -48,6 +48,7 @@
* windows_update: Added check to monitor windows update states on windows
clients. The check monitors the number of pending updates and checks if
a reboot is needed after updates have been installed.
+ * Linux mk_oracle: Updated tablespace query to use 'used blocks' instead of 'user blocks'
1.1.10:
diff --git a/agents/plugins/mk_oracle b/agents/plugins/mk_oracle
index 4f311ea..e6ad4a2 100644
--- a/agents/plugins/mk_oracle
+++ b/agents/plugins/mk_oracle
@@ -66,8 +66,14 @@ echo '<<<oracle_tablespaces>>>'
for SID in $SIDS
do
sqlplus "$SID" <<EOF | sed 's/READ ONLY/READONLY/g'
-select f.file_name, f.tablespace_name, f.status, f.AUTOEXTENSIBLE, f.blocks, f.maxblocks, f.USER_BLOCKS, f.INCREMENT_BY, f.ONLINE_STATUS, t.BLOCK_SIZE, t.status from dba_data_files f, dba_tablespaces t where f.tablespace_name = t.tablespace_name
+select f.file_name, f.tablespace_name, f.status, f.AUTOEXTENSIBLE, f.blocks, f.maxblocks, f.blocks - b.free_blocks as used_blocks, f.INCREMENT_BY, f.ONLINE_STATUS, t.BLOCK_SIZE, t.status
+from dba_data_files f, dba_tablespaces t ,(SELECT file_id, SUM(blocks) free_blocks FROM dba_free_space b GROUP BY file_id) b
+where f.tablespace_name = t.tablespace_name
+and f.file_id=b.file_id
UNION
-select f.file_name, f.tablespace_name, f.status, f.AUTOEXTENSIBLE, f.blocks, f.maxblocks, f.USER_BLOCKS, f.INCREMENT_BY, 'TEMP', t.BLOCK_SIZE, t.status from dba_temp_files f, dba_tablespaces t where f.tablespace_name = t.tablespace_name;
+select f.file_name, f.tablespace_name, f.status, f.AUTOEXTENSIBLE, f.blocks, f.maxblocks, f.blocks - b.free_blocks as used_blocks, f.INCREMENT_BY, 'TEMP', t.BLOCK_SIZE, t.status
+from dba_temp_files f, dba_tablespaces t ,(SELECT file_id, SUM(blocks) free_blocks FROM dba_free_space b GROUP BY file_id) b
+where f.tablespace_name = t.tablespace_name
+and f.file_id=b.file_id ;
EOF
done