20151030淡然

续上

1.                                               repeated options like `check_load -w 10 -w 6 -w 4 -c 16 -c 10 -c 10`

2.                                               for brevity, the above can be expressed as `check_load -w 10,6,4 -c 16,10,10`              nagios安装

3.                                               ranges are expressed with colons as in `check_procs -C httpd -w 1:20 -c 1:30` which will warn above 20 instances, and critical at 0 and above 30

4.                                               lists are expressed with commas, so Jacob's check_nmap uses constructs like '-p 1000,1010,1050:1060,2000'

5.                                               If possible when writing lists, use tokens to make the list easy to remember and non-order dependent - so check_disk uses '-c 10000,10%' so that it is clear which is the precentage and which is the KB values (note that due to my own lack of foresight, that used to be '-c 10000:10%' but such constructs should all be changed for consistency, though providing reverse compatibility is fairly easy).

As always, comments are welcome - making this consistent without a host of long options was quite a hassle, and I would suspect that there are flaws in this strategy.

---

7. Test cases

Tests are the best way of knowing if the plugins work as expected. Please create and update test cases where possible.

To run a test, from the top level directory, run "make test". This will run all the current tests and report an overall success rate.

See the Nagios Plugins Tinderbox server for the daily test results.

---

7.1. Test cases for plugins

These use perl's Test::More. To do a one time test, run "cd plugins && perl t/check_disk.t".

There will somtimes be failures seen in this output which are known failures that need to be fixed. As long as the return code is 0, it will be reported as "test pass". (If you have a fix so that the specific test passes, that will be gratefully received!)

If you want a summary test, run: "cd plugins && prove t/check_disk.t". This runs the test in a summary format.

For a good and amusing tutorial on using Test::More, see this [  /~mschwern/Test-Simple-0.62/lib/Test/Tutorial.pod]link[/url]                    开源监控软件

---

7.2. Testing the C library functions

We use [  /trac-bin/trac.cgi/wiki/LibTap]the libtap library[/url], which gives perl's TAP (Test Anything Protocol) output. This is used by the FreeBSD team for their regression testing.

To run tests using the libtap library, download the latest tar ball and extract. There is a problem with tap-1.01 where [  /trac-bin/trac.cgi/ticket/25]pthread support doesn't appear to work[/url] properly on non-FreeBSD systems. Install with 'CPPFLAGS="-UHAVE_LIBPTHREAD" ./configure && make && make check && make install'.

When you run Nagios Plugins' configure, it will look for the tap library and will automatically setup the tests. Run "make test" to run all the tests.

---

8. Coding guidelines

See [  /prep/standards_toc.html]GNU Coding standards[/url] for general guidelines.

---

8.1. C coding

Variables should be declared at the beginning of code blocks and not inline because of portability with older compilers.

You should use /* */ for comments and not // as some compilers do not handle the latter form.

You should also avoid using the type "bool" and its values "true" and "false". Instead use the "int" type and the plugins' own "TRUE"/"FALSE" values to keep the code uniformly.

---

8.2. Crediting sources

If you have copied a routine from another source, make sure the licence from your source allows this. Add a comment referencing the ACKNOWLEDGEMENTS file, where you can put more detail about the source.                    nagios配置

For contributed code, do not add any named credits in the source code - contributors should be added into the THANKS.in file instead.

---

8.3. CVS comments

If the change is due to a contribution, please quote the contributor's name and, if applicable, add the SourceForge Tracker number. Don't forget to update the THANKS.in file.

If you have a change that is useful for noting in the next release, please update the NEWS file.

All commit comments will be written to a ChangeLog at release time.

---

8.4. Translations for developers

To make the job easier for translators, please follow these guidelines:

1.                                               Before creating new strings, check the po/nagios-plugins.pot file to see if a similar string already exists

2.                                               For help texts, break into individual options so that these can be reused between plugins

3.                                               Try to avoid linefeeds unless you are working on a block of text

4.                                               Short help is not translated

5.                                               Long help has options in English language, but text translated

6.                                               "Copyright" kept in English

7.                                               Copyright holder names kept in original text

8.                                               Debugging output does not need to be translated

---

8.5. Translations for translators

To create an up to date list of translatable strings, run: tools/gen_locale.sh

---

9. Submission of new plugins and patches提交新插件和补丁

9.1. Patches

If you have a bug patch, please supply a unified or context diff against the version you are using. For new features, please supply a diff against the Git "master" branch. 如果你有一个补丁，请提供一个与你当前使用的版本一致的，或者提供与你当前使用的版本的差异。           监控软件

Patches should be submitted via [  /tracker/?group_id=29880&atid=397599]SourceForge's tracker system for Nagiosplug patches[/url] and be announced to the nagiosplug-devel mailing list.

Submission of a patch implies that the submmitter acknowledges that they are the author of the code (or have permission from the author to release the code) and agree that the code can be released under the GPL. The copyright for the changes will then revert to the Nagios Plugin Development Team - this is required so that any copyright infringements can be investigated quickly without contacting a huge list of copyright holders. Credit will always be given for any patches through a THANKS file in the distribution.

---

9.2. Contributed plugins

Plugins that have been contributed to the project and distributed with the Nagios Plugin files are held in the contrib/ directory and are not installed by default. These plugins are not officially supported by the team. The current policy is that these plugins should be owned and maintained by the original contributor, preferably hosted on NagiosExchange.

If patches or bugs are raised to an contributed plugin, we will start communications with the original contributor, but seek to remove the plugin from our distribution.

The aim is to distribute only code that the Nagios Plugin team are responsible for.

---

9.3. New plugins

If you would like others to use your plugins, please add it to the official 3rd party plugin repository, NagiosExchange.              nagios实施

We are not accepting requests for inclusion of plugins into our distribution at the moment, but when we do, these are the minimum requirements:

1.                                               Include copyright and license information in all files. Copyright must be solely granted to the Nagios Plugin Development Team

2.                                               The standard command options are supported (--help, --version, --timeout, --warning, --critical)

3.                                               It is determined to be not redundant (for instance, we would not add a new version of check_disk just because someone had provide a plugin that had perf checking - we would incorporate the features into an exisiting plugin)

4.                                               One of the developers has had the time to audit the code and declare it ready for core             nagios培训

5.                                               It should also follow code format guidelines, and use functions from utils (perl or c or sh) rather than using its own

6.                                               Includes patches to configure.in if required (via the EXTRAS list if it will only work on some platforms)

7.                                               If possible, please submit a test harness. Documentation on sample tests coming soon

本帖关键字:Nagios

20151030淡然

续上

1.                                               repeated options like `check_load -w 10 -w 6 -w 4 -c 16 -c 10 -c 10`

2.                                               for brevity, the above can be expressed as `check_load -w 10,6,4 -c 16,10,10`              nagios安装

3.                                               ranges are expressed with colons as in `check_procs -C httpd -w 1:20 -c 1:30` which will warn above 20 instances, and critical at 0 and above 30

4.                                               lists are expressed with commas, so Jacob's check_nmap uses constructs like '-p 1000,1010,1050:1060,2000'

5.                                               If possible when writing lists, use tokens to make the list easy to remember and non-order dependent - so check_disk uses '-c 10000,10%' so that it is clear which is the precentage and which is the KB values (note that due to my own lack of foresight, that used to be '-c 10000:10%' but such constructs should all be changed for consistency, though providing reverse compatibility is fairly easy).

As always, comments are welcome - making this consistent without a host of long options was quite a hassle, and I would suspect that there are flaws in this strategy.

---

7. Test cases

Tests are the best way of knowing if the plugins work as expected. Please create and update test cases where possible.

To run a test, from the top level directory, run "make test". This will run all the current tests and report an overall success rate.

See the Nagios Plugins Tinderbox server for the daily test results.

---

7.1. Test cases for plugins

These use perl's Test::More. To do a one time test, run "cd plugins && perl t/check_disk.t".

There will somtimes be failures seen in this output which are known failures that need to be fixed. As long as the return code is 0, it will be reported as "test pass". (If you have a fix so that the specific test passes, that will be gratefully received!)

If you want a summary test, run: "cd plugins && prove t/check_disk.t". This runs the test in a summary format.

For a good and amusing tutorial on using Test::More, see this [  /~mschwern/Test-Simple-0.62/lib/Test/Tutorial.pod]link[/url]                    开源监控软件

---

7.2. Testing the C library functions

We use [  /trac-bin/trac.cgi/wiki/LibTap]the libtap library[/url], which gives perl's TAP (Test Anything Protocol) output. This is used by the FreeBSD team for their regression testing.

To run tests using the libtap library, download the latest tar ball and extract. There is a problem with tap-1.01 where [  /trac-bin/trac.cgi/ticket/25]pthread support doesn't appear to work[/url] properly on non-FreeBSD systems. Install with 'CPPFLAGS="-UHAVE_LIBPTHREAD" ./configure && make && make check && make install'.

When you run Nagios Plugins' configure, it will look for the tap library and will automatically setup the tests. Run "make test" to run all the tests.

---

8. Coding guidelines

See [  /prep/standards_toc.html]GNU Coding standards[/url] for general guidelines.

---

8.1. C coding

Variables should be declared at the beginning of code blocks and not inline because of portability with older compilers.

You should use /* */ for comments and not // as some compilers do not handle the latter form.

You should also avoid using the type "bool" and its values "true" and "false". Instead use the "int" type and the plugins' own "TRUE"/"FALSE" values to keep the code uniformly.

---

8.2. Crediting sources

If you have copied a routine from another source, make sure the licence from your source allows this. Add a comment referencing the ACKNOWLEDGEMENTS file, where you can put more detail about the source.                    nagios配置

For contributed code, do not add any named credits in the source code - contributors should be added into the THANKS.in file instead.

---

8.3. CVS comments

If the change is due to a contribution, please quote the contributor's name and, if applicable, add the SourceForge Tracker number. Don't forget to update the THANKS.in file.

If you have a change that is useful for noting in the next release, please update the NEWS file.

All commit comments will be written to a ChangeLog at release time.

---

8.4. Translations for developers

To make the job easier for translators, please follow these guidelines:

1.                                               Before creating new strings, check the po/nagios-plugins.pot file to see if a similar string already exists

2.                                               For help texts, break into individual options so that these can be reused between plugins

3.                                               Try to avoid linefeeds unless you are working on a block of text

4.                                               Short help is not translated

5.                                               Long help has options in English language, but text translated

6.                                               "Copyright" kept in English

7.                                               Copyright holder names kept in original text

8.                                               Debugging output does not need to be translated

---

8.5. Translations for translators

To create an up to date list of translatable strings, run: tools/gen_locale.sh

---

9. Submission of new plugins and patches提交新插件和补丁

9.1. Patches

If you have a bug patch, please supply a unified or context diff against the version you are using. For new features, please supply a diff against the Git "master" branch. 如果你有一个补丁，请提供一个与你当前使用的版本一致的，或者提供与你当前使用的版本的差异。           监控软件

Patches should be submitted via [  /tracker/?group_id=29880&atid=397599]SourceForge's tracker system for Nagiosplug patches[/url] and be announced to the nagiosplug-devel mailing list.

Submission of a patch implies that the submmitter acknowledges that they are the author of the code (or have permission from the author to release the code) and agree that the code can be released under the GPL. The copyright for the changes will then revert to the Nagios Plugin Development Team - this is required so that any copyright infringements can be investigated quickly without contacting a huge list of copyright holders. Credit will always be given for any patches through a THANKS file in the distribution.

---

9.2. Contributed plugins

Plugins that have been contributed to the project and distributed with the Nagios Plugin files are held in the contrib/ directory and are not installed by default. These plugins are not officially supported by the team. The current policy is that these plugins should be owned and maintained by the original contributor, preferably hosted on NagiosExchange.

If patches or bugs are raised to an contributed plugin, we will start communications with the original contributor, but seek to remove the plugin from our distribution.

The aim is to distribute only code that the Nagios Plugin team are responsible for.

---

9.3. New plugins

If you would like others to use your plugins, please add it to the official 3rd party plugin repository, NagiosExchange.              nagios实施

We are not accepting requests for inclusion of plugins into our distribution at the moment, but when we do, these are the minimum requirements:

1.                                               Include copyright and license information in all files. Copyright must be solely granted to the Nagios Plugin Development Team

2.                                               The standard command options are supported (--help, --version, --timeout, --warning, --critical)

3.                                               It is determined to be not redundant (for instance, we would not add a new version of check_disk just because someone had provide a plugin that had perf checking - we would incorporate the features into an exisiting plugin)

4.                                               One of the developers has had the time to audit the code and declare it ready for core             nagios培训

5.                                               It should also follow code format guidelines, and use functions from utils (perl or c or sh) rather than using its own

6.                                               Includes patches to configure.in if required (via the EXTRAS list if it will only work on some platforms)

7.                                               If possible, please submit a test harness. Documentation on sample tests coming soon

本帖关键字:Nagios