# Configure APM log forwardingsudo tee /etc/td-agent/td-agent.conf > /dev/null <<'EOF'<source> @type tail path /var/log/app/*.log pos_file /var/log/td-agent/app.pos tag app.logs <parse> @type json time_key timestamp time_format %Y-%m-%dT%H:%M:%S.%NZ </parse></source># Enrich logs with metadata<filter app.logs> @type record_transformer <record> hostname "#{Socket.gethostname}" environment ${ENV['ENVIRONMENT'] || 'production'} service_name myapp trace_id ${record['trace_id']} </record></filter># Calculate response time metrics<filter app.logs> @type prometheus <metric> name http_request_duration_seconds type histogram desc HTTP request duration key response_time </metric></filter># Forward to APM system<match app.logs> @type http endpoint http://apm-server:8200/intake/v2/events <buffer> flush_interval 5s </buffer></match>EOFsudo 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_file`für Tail-Eingaben und setze entsprechende`timekey`Werte in Puffern, um Speicherplatzprobleme zu verhindern. Verwende`rotate_age`und`rotate_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 wie`app.**`oder`app.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_forward`für verschlüsselte Log-Übertragung, filtere sensible Felder mit`record_modifier`und 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_action`in Puffern, um Rückdruck zu handhaben (verwende`drop_oldest_chunk`oder`block`basierend auf deinen Anforderungen). Setze vernünftige`retry_timeout`Werte, um unendliche Wiederholungen zu verhindern.- **Aspekte mit Labels trennen**: Verwende`@label`Direktiven, 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). || **Zeitzonen-Probleme** | Setze`utc`oder`localtime`im Zeitparser. Verwende`time_format`mit Zeitzone:`%Y-%m-%dT%H:%M:%S%z`. Konfiguriere Systemzeitzone korrekt. |
This site uses cookies for analytics and to improve your experience.
See our Privacy Policy for details.