Being more Fluent with your logs
To understand what our solutions are doing we need to log events together from multiple sources - not necessarily easy, and then sharing the right events to the right tools, which is harder. Making log events actionable challenging.CNCF's star, Fluentd presents us with a means to simplify the monitoring landscape, address challenges of hyper-distribution occurring with microservice solutions, allowing different tools needing log data to help in their different way.In this session we’ll explore the challenges of modern log management. We’ll look at how it works and what it can bring to making both development and ops activities easier. To do this we’ll explore examples of Fluentd and how it makes life easier.
https://threadreaderapp.com/thread/1020188389721530368.html
Twitter had an observability team ten years ago
https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/
Distributed Systems Observability - Cindy Sridharan
Hungarian-American engineer Rudolf E. Kálmán formalized the idea of observability in a paper describing characteristics of linear dynamic systems 1961
https://en.wikipedia.org/wiki/Rudolf_E._K%C3%A1lm%C3%A1n
His work was important Nasa
Google’s 4 golden signals
Latency
Traffic
Errors
saturation
Understand the cause of performance issues
Insight into who / what is interacting with the system(s)
Spotting when unexpected errors occur (e.g. unexpected edge case scenarios)
Performance management – harvesting slow running queries, scissor lockout and deadly embraces on threads, infinite loop conditions, unresponsive threads
Blend multiple logs to get end to end picture
Understand potential causes of loss of data integrity
What is Fluentd?
Fluentd is an open source log collector, processor, and aggregator that was created back in 2011 by the folks at Treasure Data. Written in Ruby, Fluentd was created to act as a unified logging layer — a one-stop component that can aggregate data from multiple sources, unify the differently formatted data into JSON objects and route it to different output destinations.
Design wise — performance, scalability, and reliability are some of Fluentd’s outstanding features. A vanilla Fluentd deployment will run on ~40MB of memory and is capable of processing above 10,000 events per second. Adding new inputs or outputs is relatively simple and has little effect on performance. Fluentd uses disk or memory for buffering and queuing to handle transmission failures or data overload and supports multiple configuration options to ensure a more resilient data pipeline.
Fluentd has been around for some time now and has developed a rich ecosystem consisting of more than 700 different plugins that extend its functionality. Fluentd is the de-facto standard log aggregator used for logging in Kubernetes and as mentioned above, is one of the widely used Docker images.
What is Fluent Bit?
Fluent Bit is an open source log collector and processor also created by the folks at Treasure Data in 2015. Written in C, Fluent Bit was created with a specific use case in mind — highly distributed environments where limited capacity and reduced overhead (memory and CPU) are a huge consideration.
To serve this purpose, Fluent Bit was designed for high performance and comes with a super light footprint, running on ~450KB only. An abstracted I/O handler allows asynchronous and event-driven read/write operations. For resiliency and reliability, various configuration option are available for defining retries and the buffer limit.
Fluent Bit is also extensible, but has a smaller eco-system compared to Fluentd. Inputs include syslog, tcp, systemd/journald but also CPU, memory, and disk. Outputs include Elasticsearch, InfluxDB, file and http. For Kubernetes deployments, a dedicated filter plugin will add metadata to log data, such as the pod’s name and namespace, and the containers name/ID.
What is Fluentd?
Fluentd is an open source log collector, processor, and aggregator that was created back in 2011 by the folks at Treasure Data. Written in Ruby, Fluentd was created to act as a unified logging layer — a one-stop component that can aggregate data from multiple sources, unify the differently formatted data into JSON objects and route it to different output destinations.
Design wise — performance, scalability, and reliability are some of Fluentd’s outstanding features. A vanilla Fluentd deployment will run on ~40MB of memory and is capable of processing above 10,000 events per second. Adding new inputs or outputs is relatively simple and has little effect on performance. Fluentd uses disk or memory for buffering and queuing to handle transmission failures or data overload and supports multiple configuration options to ensure a more resilient data pipeline.
Fluentd has been around for some time now and has developed a rich ecosystem consisting of more than 700 different plugins that extend its functionality. Fluentd is the de-facto standard log aggregator used for logging in Kubernetes and as mentioned above, is one of the widely used Docker images.
What is Fluent Bit?
Fluent Bit is an open source log collector and processor also created by the folks at Treasure Data in 2015. Written in C, Fluent Bit was created with a specific use case in mind — highly distributed environments where limited capacity and reduced overhead (memory and CPU) are a huge consideration.
To serve this purpose, Fluent Bit was designed for high performance and comes with a super light footprint, running on ~450KB only. An abstracted I/O handler allows asynchronous and event-driven read/write operations. For resiliency and reliability, various configuration option are available for defining retries and the buffer limit.
Fluent Bit is also extensible, but has a smaller eco-system compared to Fluentd. Inputs include syslog, tcp, systemd/journald but also CPU, memory, and disk. Outputs include Elasticsearch, InfluxDB, file and http. For Kubernetes deployments, a dedicated filter plugin will add metadata to log data, such as the pod’s name and namespace, and the containers name/ID.
Any distributed monitoring and log management solution typically follows the following sequence of events.
Depending on the toolset and goal of the monitoring, it may result in one or more steps may be fulfilled by a single tool. For example the combination of Splunk agents, Splunk engine & dashboard all of these stages are covered within a single tool.
Note FluentD does NOT provide deep data analyse capabilities – for this we leaverage tools
Plugins: ~500 Fluentd vs 200 Logstash
Style: declarative – fluentd; programmatic Logstash
Performance: Fluentd more compact with smaller memory footprint
Caching: flexible Fluentd. Logstash – restrictive – memory size based
Implementation: Fluentd CRuby. Logstash Jruby
Walk through the demo resources
fluentd -c Demo/Fluentd/node2-file-source-multi-out-label-pipelines.conf
fluentd -c Demo/Fluentd/node1-file-source-multi-out-label-pipelines.conf
run-log-simulator.bat Demo/SimulatorConfig/basic-log-file.properties
run-log-simulator.bat Demo/SimulatorConfig/basic-log-file2.properties
Node 1
Node 2
Node 2
Switch to the simpler FluentBit – to reduce pod size
Explain fluentbit – but examine differences – limits on interchangability
- Switch to the simpler FluentBit – to reduce pod size