15 Jul
2019
15 Jul
'19
2:50 p.m.
Branch: refs/heads/master
Home: https://github.com/tribe29/checkmk
Commit: 1e274977c5149781e6ee552dfd5841d0111f2153
https://github.com/tribe29/checkmk/commit/1e274977c5149781e6ee552dfd5841d01…
Author: Óscar Nájera <oscar.najera(a)tribe29.com>
Date: 2019-07-15 (Mon, 15 Jul 2019)
Changed paths:
M tests/git/test_find_debug_print.py
Log Message:
-----------
Simplify tests avoiding debug statements on executable
Change-Id: I61c595dd4213c849c4b5d9a23584261e6244d269
Commit: 72b1c5a0548cf504c6e0066fb4f7b0d94d784b7b
https://github.com/tribe29/checkmk/commit/72b1c5a0548cf504c6e0066fb4f7b0d94…
Author: Óscar Nájera <oscar.najera(a)tribe29.com>
Date: 2019-07-15 (Mon, 15 Jul 2019)
Changed paths:
A bin/update_rrd_fs_names.py
Log Message:
-----------
Script to update rrd info files for new df.include output
Change-Id: I0bbcc4896df13b01785812c29a42a1de5554b9b6
Commit: 9da1057b7479fc8602b36e76e4652ad7959ed104
https://github.com/tribe29/checkmk/commit/9da1057b7479fc8602b36e76e4652ad79…
Author: Óscar Nájera <oscar.najera(a)tribe29.com>
Date: 2019-07-15 (Mon, 15 Jul 2019)
Changed paths:
A .werks/7444
M checks/df.include
M cmk/gui/plugins/metrics/check_mk.py
Log Message:
-----------
7444 FIX Rename metric name in Filesystem checks from mount point to fs_used
Filesystem Nagios check plug-in stored the filesystem usage of every mount
points in the RRD databases under the path of each mount point. Checkmk
assigned to every mount point a service, still it kept naming the
filesystem usage with the mount point path for compatibility. Our graphing
system learned to deal with this unpractical convention, however new
features in Checkmk performing bulk access to data can't.
<ul>
<li>All sites created with Checkm 1.6.0 onwards will automatically use the
new naming convention and don't need to be migrated</li>
<li> The migration is not mandatory, your Checkmk instance will continue
working under the legacy mode until you migrate.</li>
<li>If you use CRE, you don't need to de the migration</li>
<li>If you don't plan to do bulk access to data as required by the Historic
Data Views for filesystems (see Werk #7445), you don't need to migrate your
RRD databases.</li>
<li>If you want to use the Historic Data Views for Capacity Management on
Filesystems, you need to do migration.</li>
</ul>
The incorporation of Historic Data Views, for Capacity Management,
requieres querying the filesystem usage of all host in a given time
window. It becomes prohibitive expensive to do such request since first
every service is queried for its mount point name and then every RRD is
individually queried again for the mount point name data.
In this werk we provide a migration script that would edit all meta data
files describing the RRDs that receive output from all our supported
filesystem checks. It will also set a flag in your config so that
Filesystem check plug-ins start delivering usage perfomance data under the
static name of fs_used.
You are advised to do a backup of your RRD files and journal files before
performing the migration and your Checkmk instance needs to be stopped
during the migration.
Migration is one way and needs to be performed once per site any rollback
has to be done from your own backup.
CMK-2261
Change-Id: I0f1f0f7ebfed5053a2d314a83af6f09271259167
Commit: 0a13d17fc050b44e763982eaf77f812299751dcb
https://github.com/tribe29/checkmk/commit/0a13d17fc050b44e763982eaf77f81229…
Author: Óscar Nájera <oscar.najera(a)tribe29.com>
Date: 2019-07-15 (Mon, 15 Jul 2019)
Changed paths:
A .werks/7445
Log Message:
-----------
7445 Historic Data Views and Painters for Capacity Management
Capacity management allows you to work with the service metrics historical
data. When configuring a view you can select for a column the "Service
Historic Metrics" option from the drop-down menu, available for the "All
hosts" and "All services" data-sources.
This customizable painter allows you to select, which service metric you
want to analyze, over which time range should data be recovered from your
RRD database, how data is to be consolidated and aggregated. Finally, you
need to label this column to your best convenience.
Some ideas you might want to consider when creating your views:
List all your hosts Peak CPU utilization, over the last week, and also last
month. Maybe you want also to create a new column corresponding to the to
the times a new version of your software was deployed. Time ranges are
completely flexible, and you can keep adding columns for any time window
you prefer.
Analyze over the same time window, the peak, average and minimum CPU
utilization of all your hosts over the last week or last month.
You can also get data from different services at the same time. For example
showing CPU utilization, used memory and disk IO averaged over the last
week.
One last note. Because you will be querying from the RRD data of many hosts
at the same time, query time will increase linearly with the volume of data
you are processing.
Change-Id: Ie7d2d94b2f1c456274c9d793b60ce818144d9279
Compare: https://github.com/tribe29/checkmk/compare/aabe38e6cf94...0a13d17fc050