| Plattform | Befehl |
|---|---|
| Ubuntu/Debian (td-agent) | curl -fsSL https://toolbelt.treasuredata.com/sh/install-ubuntu-jammy-td-agent4.sh \ | sh |
| RHEL/CentOS | curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh \ | sh |
| macOS | brew install fluentd |
| Ruby Gem | gem install fluentd |
| Docker | docker pull fluent/fluentd:latest |
| Kubernetes | Als DaemonSet bereitstellen (siehe Konfigurationsabschnitt) |
| Befehl | Beschreibung |
|---|---|
fluentd -c fluent.conf |
Starten Sie Fluentd mit der angegebenen Konfigurationsdatei |
fluentd -c fluent.conf -vv |
Mit ausführlicher Debug-Ausgabe ausführen |
fluentd -c fluent.conf --dry-run |
Konfiguration ohne Start validieren |
fluentd --setup ./fluent |
Standard-Konfigurationsverzeichnisstruktur erstellen |
fluentd --version |
Zeige Fluentd Versionsinformationen |
sudo systemctl start td-agent |
td-Agent-Dienst starten (Linux) |
sudo systemctl stop td-agent |
td-Agent-Dienst stoppen |
sudo systemctl restart td-agent |
td-Agent-Dienst neu starten |
sudo systemctl status td-agent |
td-Agent-Dienststatus prüfen |
sudo systemctl reload td-agent |
Konfiguration ohne Neustart neu laden |
sudo systemctl enable td-agent |
td-Agent beim Systemstart aktivieren |
sudo journalctl -u td-agent -f |
td-Agent-Dienst-Protokolle in Echtzeit verfolgen |
echo '{"msg":"test"}' \ | fluent-cat debug.test |
Sende Test-Log-Nachricht an Fluentd |
curl -X POST -d 'json={"event":"test"}' http://localhost:8888/test.cycle |
HTTP-Testprotokoll senden |
td-agent-gem list \ | grep fluent-plugin |
Installierte Fluentd-Plugins auflisten |
Enrich logs with metadata¶
Calculate response time metrics¶
Forward to APM system¶
sudo systemctl restart td-agent
``yaml
<match app.metrics>
@type prometheus
<metric>
name fluentd_processed_records_total
type counter
desc Total number of records processed
</metric>
</match>pos_filefür Tail-Eingaben und setze entsprechendetimekeyWerte in Puffern, um Speicherplatzprobleme zu verhindern. Verwenderotate_ageundrotate_size`für Dateiausgaben.
-
Logs hierarchisch taggen: Verwende Punkt-Notation-Tags (z.B.,
app.production.web), um flexible Weiterleitung und Filterung zu ermöglichen. Dies erlaubt das Matching von Mustern wieapp.**oderapp.production.*. -
Fluentd-Performance überwachen: Verfolge Pufferwarteschlangenlänge, Wiederholungszählungen und Emissionsraten. Verwende Prometheus-Plugin oder integrierte Überwachung, um Engpässe zu erkennen, bevor sie Datenverlust verursachen.
-
Sensible Daten schützen: Verwende
@type secure_forwardfür verschlüsselte Log-Übertragung, filtere sensible Felder mitrecord_modifierund beschränke Dateiberechtigungen auf Konfigurationsdateien mit Zugangsdaten. -
Konfigurationsänderungen testen: Verwende immer
--dry-run, um Konfigurationssyntax vor der Bereitstellung zu validieren. Teste Routing-Logik mit kleinen Log-Volumina, bevor sie in Produktion angewendet wird. -
Multi-Worker-Modus umsichtig verwenden: Aktiviere Worker für CPU-intensive Operationen (Parsing, Filterung), aber sei dir bewusst, dass einige Plugins den Multi-Worker-Modus nicht unterstützen. Beginne mit 2-4 Workern und überwache CPU-Auslastung.
-
Graziöse Degradierung implementieren: Konfiguriere
overflow_actionin Puffern, um Rückdruck zu handhaben (verwendedrop_oldest_chunkoderblockbasierend auf deinen Anforderungen). Setze vernünftigeretry_timeoutWerte, um unendliche Wiederholungen zu verhindern. -
Aspekte mit Labels trennen: Verwende
@labelDirektiven, um isolierte Verarbeitungspipelines für verschiedene Log-Typen zu erstellen. Dies verbessert Wartbarkeit und verhindert unbeabsichtigte Weiterleitung. -
Plugins aktuell halten: Aktualisiere Fluentd und Plugins regelmäßig, um Sicherheitsupdates und Performanceverbesserungen zu erhalten. Fixiere Plugin-Versionen in Produktion, um Konsistenz zu gewährleisten.
Fehlerbehebung¶
| Problem | Lösung |
|---|---|
| Fluentd won't start | Check syntax: fluentd -c fluent.conf --dry-run. Review logs: sudo journalctl -u td-agent -n 100. Verify file permissions on config and buffer directories. |
| Logs not being collected | Verify pos_file exists and is writable. Check file path patterns match actual log locations. Ensure log files have read permissions. Test with tail -f on the log file. |
| High memory usage | Switch from memory buffers to file buffers. Reduce chunk_limit_size and queue_limit_length. Enable multi-worker mode to distribute load. Check for memory leaks in custom plugins. |
| Buffer queue growing | Increase flush_interval or reduce log volume. Check downstream system capacity (Elasticsearch, S3). Verify network connectivity. Review retry_max_interval settings. |
| Logs being dropped | Check buffer overflow_action setting. Increase queue_limit_length and chunk_limit_size. Monitor disk space for file buffers. Review retry_timeout configuration. |
| Plugin installation fails | Ensure Ruby development headers installed: sudo apt-get install ruby-dev build-essential. Use correct gem command: td-agent-gem not gem. Check plugin compatibility with Fluentd version. |
| Parse errors in logs | Validate parser configuration with sample logs. Use @type regexp with proper regex patterns. Add error handling: emit_invalid_record_to_error true. Check time format strings. |
| Cannot connect to Elasticsearch | Verify Elasticsearch is running: curl http://elasticsearch:9200. Check firewall rules. Validate credentials if using authentication. Review Elasticsearch logs for rejection reasons. |
| Duplicate logs appearing | Check pos_file location is persistent across restarts. Verify only one Fluentd instance is running. Review read_from_head setting (should be false in production). |
| Slow log processing | Enable multi-worker mode. Optimize regex patterns in filters. Use @type grep before expensive parsers. Profile with --trace flag to identify bottlenecks. |
| SSL/TLS connection errors | Verify certificate paths and permissions. Check certificate expiration dates. Ensure CA bundle is up to date. Use verify_ssl false for testing only (not production). |