Dieser Plug verwendet den [monitor_agent] von td-agent (http://docs.fluentd.org/ja/articles/monitoring#). Überwachen Sie den Puffer von td-agent.
Bereiten wir monitor_agent
vor, bevor wir blackbird-td-agent installieren.
Fluentd monitor_agent
monitor_agent
ist ein fließendes Plugin, mit dem Sie den Pufferstatus über HTTP abrufen können. Da es standardmäßig installiert ist, muss kein neues Juwel installiert werden.
<source>
type monitor_agent
bind 0.0.0.0
port 24220
</source>
Wenn Sie config wie oben schreiben und fluentd neu starten, wird monitor_agent
aktiviert. Der Endpunkt für monitor_agent
ist http: // localhost: 24220 / api / plugins.json
. Wenn Sie zu dieser URL gelangen, können Sie die Bytegröße des Puffers und die Länge der Pufferwarteschlange abrufen. Das Blackbird-td-Agent-Plugin analysiert diesen Wert und ruft den Wert ab.
Aufgrund der Eigenschaften von monitor_agent
gibt es bei mehreren Ausgangs-Plug-Ins mehrere JSON-Ausgänge. Deshalb habe ich mich für das Raw Level Discovery Item von zabbix entschieden, um Items dynamisch zu vergrößern oder zu verkleinern.
Wenn es sich um ein Ausgabe-Plugin handelt und in json buffer_queue_length
vorhanden ist, wird das Zielelement auf den mit der zabbix-Vorlage verknüpften HOST erweitert. Der Artikelname wird "plugin_id" zugewiesen. (plugin_id wird für jedes Plugin ein eindeutiges Plugin zugewiesen, und json im Format "{" plugin_id ":" object: XXXXXXXXXXX "}" wird ausgegeben.)
Items(Normal)
Sie können die folgenden Elemente als normale Elemente erhalten
Law Level Discovery Items(Dynamic)
Folgende Elemente ändern sich dynamisch mit Law Level Discovery
aktuellen Warteschlangenlänge ÷ buffer_queue_limit
berechnet.buffer_total_queued_size
aus http: // MONITOR_AGENT_HOST: 24420 / api / plugins.json
buffer_queue_length
aus http: // MONITOR_AGENT_HOST: 24420 / api / plugins.json
Triggers
Folgendes wird als Trigger implementiert
retry_count
ist mehr als eine bestimmte Anzahl von MalenGraphs
Jeder Wert von ist ein einzelnes Diagramm.
Wenn fluentd in der Warteschlange steht und gefährlich ist oder wenn das Ziel falsch ist und nicht gesendet werden kann, wird es zu einem kombinierten Monitor mit der Überwachung anderer Host- ODER Middleware, oder die Protokollüberwachung ist die einzige Möglichkeit, retry_count überhaupt zu erkennen. Ich habe das Gefühl, dass es auf subtile Weise schwierig zu überwachen ist, oder weil es schwierig ist, habe ich das Gefühl, dass ich es später nicht mag. Sie können fluentd selbst mit monitor_agent überwachen.