tyler.durden
/
icinga2
mirror of https://github.com/Icinga/icinga2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update graphing section in the docs 

fixes #10157
This commit is contained in:
Michael Friedrich 2015-09-16 15:00:12 +02:00
parent 16de7bdcd5
commit 4dffe67a8f
2 changed files with 45 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/13-addons-plugins.md
View File

@ -52,30 +52,51 @@ for sending real-time metrics from Icinga 2 to Graphite.
There are Graphite addons available for collecting the performance data files too (e.g. `Graphios`).
### <a id="addons-graphing-ingraph"></a> inGraph
A popular alternative frontend for Graphite is for example [Grafana](http://grafana.org).
[inGraph](https://www.netways.org/projects/ingraph/wiki) requires the ingraph-collector addon
to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data) will
write to the performance data spool directory.
### <a id="addons-graphing-influxdb"></a> InfluxDB
[InfluxDB](https://influxdb.com) is a time series, metrics, and analytics database.
It’s written in Go and has no external dependencies.
Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature
for sending real-time metrics from Icinga 2 to InfluxDB. Note: There are [API changes](https://github.com/influxdb/influxdb/issues/2102)
in InfluxDB 0.9.x.
# icinga2 feature enable graphite
A popular frontend for InfluxDB is for example [Grafana](http://grafana.org).
## <a id="addons-visualization"></a> Visualization
### <a id="addons-visualization-reporting"></a> Icinga Reporting
By enabling the DB IDO feature you can use the Icinga Reporting package.
By enabling the [DB IDO](5-advanced-topics.md#db-ido) feature you can use the
[Icinga Reporting package](https://wiki.icinga.org/display/howtos/Setting+up+Icinga+with+Reporting).
### <a id="addons-visualization-nagvis"></a> NagVis
By using either Livestatus or DB IDO as a backend you can create your own network maps
By using either [Livestatus](16-livestatus.md#setting-up-livestatus) or
[DB IDO](5-advanced-topics.md#db-ido) as a backend you can create your own network maps
based on your monitoring configuration and status data using [NagVis](http://www.nagvis.org).
The configuration in nagvis.ini.php should look like this for Livestatus for example:
[backend_live_1]
backendtype="mklivestatus"
socket="unix:/var/run/icinga2/cmd/livestatus"
If you are planning an integration into Icinga Web 2, look at [this module](https://github.com/divetoh/icingaweb2-module-nagvis).
### <a id="addons-visualization-thruk"></a> Thruk
[Thruk](http://www.thruk.org) is an alternative web interface which can be used with Icinga 2.
[Thruk](http://www.thruk.org) is an alternative web interface which can be used with Icinga 2
and the [Livestatus](16-livestatus.md#setting-up-livestatus) feature.
## <a id="log-monitoring"></a> Log Monitoring
Using Logstash or Graylog in your infrastructure and correlate events with your monitoring
Using [Logstash](https://www.elastic.co/guide/en/logstash/current/introduction.html) or
[Graylog](https://www.graylog.org) in your infrastructure and correlate events with your monitoring
is even simpler these days.
* Use the `GelfWriter` feature to write Icinga 2's check and notification events to Graylog or Logstash.
@ -96,9 +117,11 @@ There's a variety of resources available, be it different notification scripts s
* Ticket systems
* etc.
Additionally external services can be integrated with Icinga 2:
Additionally external services can be [integrated with Icinga 2](https://www.icinga.org/icinga/integration/):
* [Pagerduty](https://www.pagerduty.com/docs/guides/icinga2-integration-guide/)
* [Pagerduty](https://www.icinga.org/partners/pagerduty/)
* [VictorOps](https://www.icinga.org/partners/victorops/)
* [StackStorm](https://www.icinga.org/partners/stackstorm/)
More information can be found on the [Icinga Website](https://www.icinga.org)
and the [Icinga Wiki](https://wiki.icinga.org/display/howtos/Home).
@ -110,7 +133,7 @@ touch with their developers. The Icinga project does not provide a configuration
yet. Follow the [Icinga Blog](https://www.icinga.org/blog/) for updates on this topic.
If you're looking for puppet manifests, chef cookbooks, ansible recipes, etc - we're happy
to integrate them upstream, so please get in touch at [https://support.icinga.org](https://support.icinga.org).
to integrate them upstream, so please get in touch with the [Icinga team](https://www.icinga.org/community/get-involved/).
These tools are currently in development and require feedback and tests:
@ -118,7 +141,6 @@ These tools are currently in development and require feedback and tests:
* [Puppet Module](https://github.com/Icinga/puppet-icinga2)
* [Chef Cookbook](https://github.com/Icinga/chef-icinga2)
## <a id="plugins"></a> Plugins
For some services you may need additional 'check plugins' which are not provided

21
doc/5-advanced-topics.md
View File

@ -572,17 +572,17 @@ The performance data can be passed to external applications which aggregate and
store them in their backends. These tools usually generate graphs for historical
reporting and trending.
Well-known addons processing Icinga performance data are PNP4Nagios,
inGraph and Graphite.
Well-known addons processing Icinga performance data are [PNP4Nagios](14-addons-plugins.md#addons-graphing-pnp),
[Graphite](14-addons-plugins.md#addons-graphing-graphite) or [OpenTSDB](5-advanced-topics.md#opentsdb-writer).
### <a id="writing-performance-data-files"></a> Writing Performance Data Files
PNP4Nagios, inGraph and Graphios use performance data collector daemons to fetch
PNP4Nagios and Graphios use performance data collector daemons to fetch
the current performance files for their backend updates.
Therefore the Icinga 2 `PerfdataWriter` object allows you to define
the output template format for host and services backed with Icinga 2
runtime vars.
Therefore the Icinga 2 [PerfdataWriter](6-object-types.md#objecttype-perfdatawriter)
feature allows you to define the output template format for host and services helped
with Icinga 2 runtime vars.
host_format_template = "DATATYPE::HOSTPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tHOSTPERFDATA::$host.perfdata$\tHOSTCHECKCOMMAND::$host.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.state_type$"
service_format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tSERVICEDESC::$service.name$\tSERVICEPERFDATA::$service.perfdata$\tSERVICECHECKCOMMAND::$service.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.state_type$\tSERVICESTATE::$service.state$\tSERVICESTATETYPE::$service.state_type$"
@ -600,8 +600,9 @@ remove the processed files.
### <a id="graphite-carbon-cache-writer"></a> Graphite Carbon Cache Writer
While there are some Graphite collector scripts and daemons like Graphios available for
Icinga 1.x it's more reasonable to directly process the check and plugin performance
While there are some [Graphite](14-addons-plugins.md#addons-graphing-graphite)
collector scripts and daemons like Graphios available for Icinga 1.x it's more
reasonable to directly process the check and plugin performance
in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
write them to the defined Graphite Carbon daemon tcp socket.
@ -609,8 +610,8 @@ You can enable the feature using
# icinga2 feature enable graphite
By default the `GraphiteWriter` object expects the Graphite Carbon Cache to listen at
`127.0.0.1` on TCP port `2003`.
By default the [GraphiteWriter](6-object-types.md#objecttype-graphitewriter) feature
expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
The current naming schema is