Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:web_c7:icinga:graphite [20.11.2015 21:52. ] – [graphite-web] django
+++ centos:web_c7:icinga:graphite [18.11.2024 19:11. ] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 1: / Zeile 1: @@
-====== Icinga Einbinden von Graphite zur graphischen Visualisierung - Installation und Konfiguration unter CentOS 7.x ======
+====== Icinga2 Einbinden von Graphite zur graphischen Visualisierung - Installation und Konfiguration unter CentOS 7.x ======
 {{:centos:web_c7:icinga:graphite-logo.png?nolink&250 |Bild: Graphite Logo}}  Mit [[http://graphite.wikidot.com/|Graphite]] steht ein sehr mächtiges Werkzeug zur Verfügung, wenn es darum geht in Echtzeit skalierbare Graphen zur Verfügung zu stellen.
@@ Zeile 5: / Zeile 5: @@
 <WRAP center round info 75%>
-Obgleich es aktuell((Stand: April 2015)) nur eine Vorabversion eines [[centos:web_c7:icinga:web2|Icinga Web 2]] Moduls gibt, lohnt es sich doch einen Blick auf die Möglichkeiten von Graphite und Icinga Web 2 zu werfen. Es wird spannend werden, welche zusätzlichen Möglichkeiten zur Visualisierung, insbesondere bei der graphischen Aufbereitung von Kurz- und Langzeitstatistiken bzw. Trends, das Entwicklerteam noch auflegen wird.
+Obgleich es aktuell((Stand: November 2015)) nur eine Vorabversion eines [[centos:web_c7:icinga:web2|Icinga Web 2]] Moduls gibt, lohnt es sich doch einen Blick auf die Möglichkeiten von Graphite und Icinga Web 2 zu werfen. Es wird spannend werden, welche zusätzlichen Möglichkeiten zur Visualisierung, insbesondere bei der graphischen Aufbereitung von Kurz- und Langzeitstatistiken bzw. Trends, das Entwicklerteam noch auflegen wird.
 </WRAP>
@@ Zeile 11: / Zeile 11: @@
 ===== Installation =====
 ==== Vorbereitung ====
-Die einfachste und schnellste Variante bei der **[[centos:mailserver.guru|Installation]]** ist die aus dem Repository **[[centos:mailserver.guru|mailserver.guru]]**. Hier reicht ein einfacher Aufruf von **yum** und alles wird automatisch installiert. Etwaige Paketabhängigkeiten werden so automatisch aufgelöst und Paketupdates werden so, automatisch angeboten und müssen nicht extra manuell heruntergeladen werden.
+Die einfachste und schnellste Variante bei der **[[centos:nausch.org|Installation]]** ist die aus dem Repository **[[centos:nausch.org|nausch.org]]**. Hier reicht ein einfacher Aufruf von **yum** und alles wird automatisch installiert. Etwaige Paketabhängigkeiten werden so automatisch aufgelöst und Paketupdates werden so, automatisch angeboten und müssen nicht extra manuell heruntergeladen werden.
 ==== Informationen =====
 Zum Erstellen und Einbinden der Graphen benötigen wir mehrere Programme und Daemons.
-  - **Generierung Performancedaten** \\ In Icinga Web 2 brauchen wir eine Möglichkeit, Performancedaten aus Icinga Web 2 zu erfassen und für die weitere Verarbeitung durch **Graphite** zur Verfügung zu stellen. Für diese Aufgabe benötigen wir das aktuelle Paket **python-carbon** aus dem Repository [[http://repo.mailserver.guru/7/os/x86_64/repoview/index.html|Mailserver.guru]]. \\ \\
+  - **Generierung Performancedaten** \\ In Icinga Web 2 brauchen wir eine Möglichkeit, Performancedaten aus Icinga Web 2 zu erfassen und für die weitere Verarbeitung durch **Graphite** zur Verfügung zu stellen. Für diese Aufgabe benötigen wir das aktuelle Paket **python-carbon** aus dem Repository [[http://repo.nausch.org/7/os/x86_64/repoview/index.html|Mailserver.guru]]. \\ \\
   - **Datenbank(files)**
-    - **Whisper** \\ Zum Abspeichern der Rohdaten, greifen wir auf **python-whisper** einer Datenbank-Engine für schnelle und zuverlässige Speicherung von Daten, ähnlich wie [[http://oss.oetiker.ch/rrdtool/|Thomas Oetiker's Round-Robin-Archive]] **RRD**-Tools. Auch dieses Paket beziehen wir aus dem Repository [[http://repo.mailserver.guru/7/os/x86_64/repoview/index.html|Mailserver.guru]].
+    - **Whisper** \\ Zum Abspeichern der Rohdaten, greifen wir auf **python-whisper** einer Datenbank-Engine für schnelle und zuverlässige Speicherung von Daten, ähnlich wie [[http://oss.oetiker.ch/rrdtool/|Thomas Oetiker's Round-Robin-Archive]] **RRD**-Tools. Auch dieses Paket beziehen wir aus dem Repository [[http://repo.nausch.org/7/os/x86_64/repoview/index.html|Mailserver.guru]].
     - **MariaDB** \\ Zum Speichern der Konfigurationsdaten zu den Graphiken und Dashboards sowie der userspezifischen Einstellungen nutzen wir unsere MariaDB auf unserem Monitoring Host. \\ \\
-  - **Aufbereiten der Daten und Generierung der Graphiken** \\ Zum Aufbereiten der Rohdaten und zur Generierung der Statistik-Graphen bedienen wir uns des Projektes **[[http://graphite.readthedocs.org/en/latest/|Graphite]]**. Das passende RPM **graphite-web** stellt uns wiederum das Repository [[http://repo.mailserver.guru/7/os/x86_64/repoview/index.html|Mailserver.guru]] zur Verfügung. \\ \\
+  - **Aufbereiten der Daten und Generierung der Graphiken** \\ Zum Aufbereiten der Rohdaten und zur Generierung der Statistik-Graphen bedienen wir uns des Projektes **[[http://graphite.readthedocs.org/en/latest/|Graphite]]**. Das passende RPM **graphite-web** stellt uns wiederum das Repository [[http://repo.nausch.org/7/os/x86_64/repoview/index.html|Mailserver.guru]] zur Verfügung. \\ \\
   - **Icinga Web 2 Modul graphite** \\ Zum Einbinden der Echtzeitgraphiken in **Icinga Web 2** benötigen wir dann noch das Modul **icingaweb2-module-graphite**. Eine Vorabentwicklerversion laden holen wir uns direkt von der [[https://github.com/philiphoy/icingaweb2-module-graphite|GitHub]] Projektseite.
@@ Zeile 55: / Zeile 55: @@
 Build Host  : vml000200.dmz.nausch.org
 Relocations : (not relocatable)
-Packager    : Django <django@mailserver.guru>
+Packager    : Django <django@nausch.org>
 URL         : https://github.com/graphite-project
 Summary     : Back-end data caching and persistence daemon for Graphite
@@ Zeile 213: / Zeile 213: @@
 Build Host  : vml000200.dmz.nausch.org
 Relocations : (not relocatable)
-Packager    : Django <django@mailserver.guru>
+Packager    : Django <django@nausch.org>
 URL         : https://github.com/graphite-project
 Summary     : Simple database library for storing time-series data
@@ Zeile 267: / Zeile 267: @@
 Build Host  : vml000200.dmz.nausch.org
 Relocations : (not relocatable)
-Packager    : Django <django@mailserver.guru>
+Packager    : Django <django@nausch.org>
 URL         : https://github.com/graphite-project
 Summary     : A Django web application for enterprise scalable realtime graphing
@@ Zeile 1101: / Zeile 1101: @@
 ===== Konfiguration =====
 ==== python-carbon ====
+=== carbon.conf ===
 Die Konfiguration von **python-carbon** erfolgt mit Hilfe der Konfigurationsdatei //**/etc/carbon/carbon.conf**//. Die Konfigurationsarbeit ist schnell erledigt, da wir uns auf das tägliche Logrotation beschränken können.
    # vim /etc/carbon/carbon.conf
 <file python /etc/carbon/carbon.conf>[cache]
 # Configure carbon directories.
 #
 # OS environment variables can be used to tell carbon where graphite is
 # installed, where to read configuration from and where to write data.
 #
 #   GRAPHITE_ROOT        - Root directory of the graphite installation.
 #                          Defaults to ../
 #   GRAPHITE_CONF_DIR    - Configuration directory (where this file lives).
 #                          Defaults to $GRAPHITE_ROOT/conf/
-#   GRAPHITE_STORAGE_DIR - Storage directory for whipser/rrd/log/pid files.
+#   GRAPHITE_STORAGE_DIR - Storage directory for whisper/rrd/log/pid files.
 #                          Defaults to $GRAPHITE_ROOT/storage/
 #
@@ Zeile 1143: / Zeile 1144: @@
 PID_DIR        = /var/run/
-# Enable daily log rotation. If disabled, a kill -HUP can be used after a manual rotate
+# Enable daily log rotation. If disabled, carbon will automatically re-open
-# Django : 2015-03-20
+# the file if it's rotated out of place (e.g. by logrotate daemon)
-# default: ENABLE_LOGROTATION = False
+# Django : 2015-11-20
+# default: ENABLE_LOGROTATION = False
 ENABLE_LOGROTATION = True
@@ Zeile 1171: / Zeile 1173: @@
 # stop/shutdown is initiated.  This helps when MAX_UPDATES_PER_SECOND is
 # relatively low and carbon has cached a lot of updates; it enables the carbon
 # daemon to shutdown more quickly.
 # MAX_UPDATES_PER_SECOND_ON_SHUTDOWN = 1000
 # Softly limits the number of whisper files that get created each minute.
-# Setting this value low (like at 50) is a good way to ensure your graphite
+# Setting this value low (e.g. 50) is a good way to ensure that your carbon
 # system will not be adversely impacted when a bunch of new metrics are
-# sent to it. The trade off is that it will take much longer for those metrics'
+# sent to it. The trade off is that any metrics received in excess of this
-# database files to all get created and thus longer until the data becomes usable.
+# value will be silently dropped, and the whisper file will not be created
-# Setting this value high (like "inf" for infinity) will cause graphite to create
+# until such point as a subsequent metric is received and fits within the
-# the files quickly but at the risk of slowing I/O down considerably for a while.
+# defined rate limit. Setting this value high (like "inf" for infinity) will
+# cause carbon to create the files quickly but at the risk of increased I/O.
 MAX_CREATES_PER_MINUTE = 50
+# Set the interface and port for the line (plain text) listener.  Setting the
+# interface to 0.0.0.0 listens on all interfaces.  Port can be set to 0 to
+# disable this listener if it is not required.
 LINE_RECEIVER_INTERFACE = 0.0.0.0
 LINE_RECEIVER_PORT = 2003
+# Set the TCP backlog for the listen socket created by the line receiver. You
+# shouldn't change this unless you know what you're doing.
+# LINE_RECEIVER_BACKLOG = 1024
 # Set this to True to enable the UDP listener. By default this is off
@@ Zeile 1193: / Zeile 1203: @@
 UDP_RECEIVER_PORT = 2003
+# Set the interface and port for the pickle listener.  Setting the interface to
+# 0.0.0.0 listens on all interfaces.  Port can be set to 0 to disable this
+# listener if it is not required.
 PICKLE_RECEIVER_INTERFACE = 0.0.0.0
 PICKLE_RECEIVER_PORT = 2004
+# Set the TCP backlog for the listen socket created by the pickle receiver. You
+# shouldn't change this unless you know what you're doing.
+# PICKLE_RECEIVER_BACKLOG = 1024
 # Set to false to disable logging of successful connections
@@ Zeile 1206: / Zeile 1223: @@
 CACHE_QUERY_INTERFACE = 0.0.0.0
 CACHE_QUERY_PORT = 7002
+# Set the TCP backlog for the listen socket created by the cache query
+# listener. You shouldn't change this unless you know what you're doing.
+# CACHE_QUERY_BACKLOG = 1024
 # Set this to False to drop datapoints received after the cache
@@ Zeile 1357: / Zeile 1378: @@
 # datapoint to more than one machine.
 REPLICATION_FACTOR = 1
+# For REPLICATION_FACTOR >=2, set DIVERSE_REPLICAS to True to guarantee replicas
+# across distributed hosts. With this setting disabled, it's possible that replicas
+# may be sent to different caches on the same host. This has been the default
+# behavior since introduction of 'consistent-hashing' relay method.
+# Note that enabling this on an existing pre-0.9.14 cluster will require rebalancing
+# your metrics across the cluster nodes using a tool like Carbonate.
+#DIVERSE_REPLICAS = False
 # This is a list of carbon daemons we will send any relayed or
@@ Zeile 1380: / Zeile 1409: @@
 MAX_DATAPOINTS_PER_MESSAGE = 500
 MAX_QUEUE_SIZE = 10000
+# This is the percentage that the queue must be empty before it will accept
+# more messages.  For a larger site, if the queue is very large it makes sense
+# to tune this to allow for incoming stats.  So if you have an average
+# flow of 100k stats/minute, and a MAX_QUEUE_SIZE of 3,000,000, it makes sense
+# to allow stats to start flowing when you've cleared the queue to 95% since
+# you should have space to accommodate the next minute's worth of stats
+# even before the relay incrementally clears more of the queue
+QUEUE_LOW_WATERMARK_PCT = 0.8
 # Set this to False to drop datapoints when any send queue (sending datapoints
 # to a downstream carbon daemon) hits MAX_QUEUE_SIZE. If this is True (the
 # default) then sockets over which metrics are received will temporarily stop accepting
-# data until the send queues fall below 80% MAX_QUEUE_SIZE.
+# data until the send queues fall below QUEUE_LOW_WATERMARK_PCT * MAX_QUEUE_SIZE.
 USE_FLOW_CONTROL = True
@@ Zeile 1411: / Zeile 1449: @@
 # If set true, metric received will be forwarded to DESTINATIONS in addition to
 # the output of the aggregation rules. If set false the carbon-aggregator will
-# only ever send the output of aggregation.
+# only ever send the output of aggregation. Default value is set to false and will not forward
-FORWARD_ALL = True
+FORWARD_ALL = False
+# Filenames of the configuration files to use for this instance of aggregator.
+# Filenames are relative to CONF_DIR.
+#
+# AGGREGATION_RULES = aggregation-rules.conf
+# REWRITE_RULES = rewrite-rules.conf
 # This is a list of carbon daemons we will send any relayed or
@@ Zeile 1420: / Zeile 1464: @@
 #
 # DESTINATIONS = 127.0.0.1:2004:a, 127.0.0.1:2104:b
 #
 # The format is comma-delimited IP:PORT:INSTANCE where the :INSTANCE part is
 # optional and refers to the "None" instance if omitted.
@@ Zeile 1471: / Zeile 1515: @@
 # seconds. Set CARBON_METRIC_INTERVAL to 0 to disable instrumentation
 # CARBON_METRIC_PREFIX = carbon
-# CARBON_METRIC_INTERVAL = 60
+# CARBON_METRIC_INTERVAL = 60</file>
+=== storage-schemas.conf ===
+Die Definition der Schematas der einzelnen //whisper-Dateien// erfolgt über die Datei //**/etc/carbon/storage-schemas.conf**//. Dort wir unter anderem die Retention der Dateien festgelegt. Unter Retension versteht man das Verdichten der Statistikdateien, ähnlich wie bei Tobias Oetiker's **[[http://oss.oetiker.ch/rrdtool/|RRDtools]]**, so sind z.B. bei der späteren Anzeige bei den Monatsgraphiken nicht mehr alle 1-Minuten Werte von Interesse, sondern berechnete Zwischenwerte.
+Ein weiterer wichtiger Punkt, ist die Reihenfolge der **Sectionen** in der Konfigurationsdatei. Der erste Bereich der zur definierten **Section** passt, gilt. Wir müssen also dafür Sorge tragen, dass unser **icinga2_default** in der Konfigurationsdatei steht bevor der Default-Eintrag **default_1min_for_1day** kommt. Würde dies nicht passen, würden später auf Grund fehlender verdichteter Daten keine Graphen für die Langzeitstatistiken generiert werden können. Wir öffnen also die Datei //**/etc/carbon/storage-schemas.conf**// kontrollieren und passend diese bei Bedarf an.
+   # vim /etc/carbon/storage-schemas.conf
+<file bash /etc/carbon/storage-schemas.conf># Schema definitions for Whisper files. Entries are scanned in order,
+# and first match wins. This file is scanned for changes every 60 seconds.
+#
+#  [name]
+#  pattern = regex
+#  retentions = timePerPoint:timeToStore, timePerPoint:timeToStore, ...
+# Carbon's internal metrics. This entry should match what is specified in
+# CARBON_METRIC_PREFIX and CARBON_METRIC_INTERVAL settings
+[carbon]
+pattern = ^carbon\.
+retentions = 60:90d
+[icinga2_default]
+# intervals like PNP4Nagios uses them per default
+pattern = ^icinga2\.
+retentions = 1m:2d,5m:10d,30m:90d,360m:4y
+[default_1min_for_1day]
+pattern = .*
+retentions = 60s:1d
 </file>
@@ Zeile 2089: / Zeile 2160: @@
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
-~~DISCUSSION~~