 Hi, this is Hosu Kumbhatiya and today we have with us once again, Eduardo Silva, founder and CEO of Deleptia and creator of Flurn Bit, Eduardo is great to have you back on the show. Hi Sunil, thanks for the invitation to participate, happy to have a conversation again with you. We have covered Flurn Bit early in the early days, but just to refresh memories of our viewers, tell us what is this project all about? Yeah, a bit of background is like you have distributed systems, right, you know everybody knows now that Kubernetes is used to coordinate how this distributed system with based on containers can be scheduled and all of that, right? But that once your applications are working, after that, your next journey just to start is about how do you monitor these applications, how do you know what's going on, right? And then you have a whole concept of observability that is based on logs, metrics and traces. Flurn Bit initially is a log processor, which is part of the Flu and D ecosystem. It's like our new project for them to solve the same problem at a higher scale and nowadays Flurn Bit does logs and metrics and shortly we do trace management. Can you also talk a bit about when we do look at the whole cloud native stack? Where does Flurn Bit fit in the picture? We look at the whole security landscape, we look at the observability, where does this fit? Yeah, as part of this stack in observability in general, one of the main problems that when you have these user applications running, right, first of all, they are distributed. Second, every application might ship their log information in a different format. And your goal as somebody who's deploying this application, right, or the developer that initially created that application is to be able to perform some analysis, how the application is doing, what's the load on the application, right? But in order to accomplish that, means that you want to do some data analysis, you need to centralize all your information in one place for that. So now how you go from a distributed system where your application is running in multiple nodes in the distributed fashion, and you centralize all this information in one place for analysis, and that's where you need some custom specialized tool like Flu and Bit and Flu and D. Now, as part of the stack, for example, Flu and Bit is not the unique solution for this. Also, you wanted to deal with metrics, you wanted to deal with traces. It's pretty much common, like Prometheus is using for metrics, Open Telemetry nowadays is using for traces. So, and this all come together as one of the solutions in the stack of the CNCF in a better neutral way. So, how have you seen the evolution of observability space and how the scope is also kind of growing because knowing is not enough, doing something about it is also important at some point. Yeah, that's a really good question. Actually, it's a very challenging topic, observability in general. One of the biggest problem that we got five, six years ago is like, how do we do data analysis, as I said, on a distributed environment, right? We saw that problem and now they said, how do we take this data and add context to the data, right? Because data comes from different sources, like meaning different nodes. For example, if you're using any cloud provider, you might want to add some kind of project ID, some where this application was added. So, you wanted to enrich your information with context, right? And we pretty much solved all those problems. But now the next problem is like every year, and we're seeing this in the last years, users has more application, bigger clusters, they need to process more data at a higher rate, but at a lower cost of competing resources, right? It's not that you can assume that your whole agent that is taking this data will will use this very low resources for one, two years ago than now, because two years ago, the amount of data people were generating was quite low. So, one of the challenges right now is scalability, right? I'm just talking about when we move the data from one place to the other. Now, the evolution for that is like, okay, there are many ways to scale up an agent, but also users, and actually we see that with customers, they say, we have this agent, we have this tool that's from CNCF, this collecting data, and we choose flow embed because it's very low resource profile, right? And why that is important? Because you have many applications running also on the same machine. So, your agent cannot consume half of the resources to process all that information. And that with flow embed, we have been able to solve that problem. And now, how this has been evolving, for us, from a flow embed perspective, is like the last year, the last 12 months, we just focused on performance, performance, performance, improvement, be able to process more records per second, transfer the data file in a faster way, scale up with threads internally in the agent, but also there's other challenges that are how things are switching in observability. When I say at the beginning, it's like, people care about data analysis, right? Take my data from the left, from many services, and put it on the right in one database, so I can do analytics and get my insights or run machine learning, whatever you want. But now there's a trend where this, a concept of moving the data from left to right, sometimes it has, it's pros and cons, and one of the cons is like, it takes time, because you have to increase the data, you have to make sure that if you get any error, or something's going to be retried from the agent side, you're not going to get the data right on time, because as bigger your cluster is, more time you need to process this data, or this data gets available to be in a critical state. So the trend we see in observability is like, users are asking to split this processing of data of this kind of analytics, and instead of doing everything on the right, on the central database, just perform some analytics on the edge, where the data is degenerated. For example, in Flowing Bit we implemented some time ago, like years ago, a stream processing support with SQL. So you can say, take this information, query for this pattern, and if it matches, create a new stream of data that goes to Xplace. And that happens in real time. If you want to do the same thing with a more traditional database after indexing, yeah, it might take you a couple of minutes or more. And I'm not saying that one is better than the other, but it's like, if you have a big problem, you have to, you need to split the problem in parts and attack every component separately, right? And moving analytics to the left is something that has been working out really well. Now, for example, that is about loss. If we talk about metrics, we're seeing this explosion of metrics, right? And one of the, because another problem in metrics in observability that is changing now, is like, now, hey, the same thing that happened with loss, and you might recall, as I need people, you know, talking about Splunk, that the bills are so high, you were ingesting so much data. The same thing is happening now with metrics, because there's more implementation for metrics, but also we are sending more metrics. That means your bills are going up. So it's like, what are the solutions to take my metrics, get control of my metrics, and make sure that I can reduce those metrics and just get whatever I need, and not extra information. So things are switching from more to the left. In analytics, they are also going into more preprocessing on the left. And also, well, Trace is a different world, I would say, an interesting monster, where now OpenTelemetry is taking over that, those challenges, right? With tracing. And we, as a fluent project, our vision is like, we see also another problem in observability, talking about OpenTelemetry, talking about Prometheus, because we're doing metrics too. It's like, most of applications in production are, you know, instrumented with Prometheus. That's the standard now. Now OpenTelemetry, which originated for Traces, is jumping into metrics space now. We see the user that questions themselves, saying, how do I take my metrics in Prometheus, and then get into an OTLP OpenTelemetry backend? There's no easy translation layer. And that's what we're be able to connect not just with cloud providers, with vendors and solutions, but also interoperate between the stack that we have in CNCF, how we take Prometheus metrics components, payloads, and we transfer that to OpenTelemetry. And that's another of the current challenges that we're facing at observability. Now, if I may also ask, first of all, thanks for explaining that. I also want to understand, can you talk about the adoption of this project, how it's being embraced, and what role is it in playing in the larger CNCF landscape? Yeah, the adoption has been quite interesting, you know, originally Fluembet was created for embedded Linux. We're talking about six years ago and quickly switched it to as a cloud native solution. So it was at the same time that Kubernetes was running Fluent D Fluent, it was not fast enough and Fluembet was the answer from our same community to that specific use case. Now, that option has been quite great, despite we don't have all the numbers that, for example, cloud providers to use Fluembet, for example, AWS, Microsoft Azure, Google Cloud, all of them use Fluembet in the Kubernetes cluster and their own services. We don't have those numbers. But at least from a community perspective, we saw that our container registry on Docker Hub starting getting more and more deployments per day. So we have just a general metric of how many times this image has been downloaded, right, and assuming being deployed. And now we just cross the limit of one billion times. So this one billion looks like, I think that four to five years in general. But today we see a number of, I don't know, two millions deployments per day. So that means there is a train where this is going up, right? So we have more Kubernetes clusters. That means that all the notes on those clusters need to have an agent to process logs, to process metrics, and that one is Fluembet. Yeah, you folks also released, if I'm not wrong, version 1.9 this month. If you can tell me, you know, what are some of the new features and functionalities of this release? Yeah, so we hit this biggest milestone for us. We call 1.9 a major version that we have been closing really close with the cloud providers in our community. And one of the biggest things is around 1.9 I would say is performance, right? Performance, you know, we work it a lot in order to tweak and make sure that the agent can scale even to a higher number of messages per second. And also the throw, in general throughput would be higher. We got new connectors, you know, we connect to different backends. Now one of the biggest ones is OpenSearch, right? So we are working closely with the OpenSearch community. And now we used to support just a last search, but now we support elastic plus OpenSearch. We just landed a new Kafka input plugin, right? We didn't have that at the moment before, but we allowed the agent to subscribe to a Kafka topic, get the messages in and process that through the fluent bit pipeline. And also we got this new Prometheus connectors, so Prometheus exporter, Prometheus remote, right? We got a new Prometheus scraper, so you can use fluent bit also to scrape metrics from a remote application instrumented by Prometheus. And in experimental way, we are launching new OpenTelemetry plugins for metric sources and for destination around metrics. In the next video, following weeks, we are going to launch the trace support. Can you also share what kind of roadmap you have for the project? Or let's say, what are the things you'll be focusing on in this year? Yeah, we just had a protocol this morning, right, with maintainers. And I will say that we are in Q1. For Q2, and the remaining part of the year, we keep working on in performance, right? And one of the biggest challenges that we are working in technical terms right now is support threading for the input lines, but as well support goal and input plugins. That is something that has been in the to-do list for a while, but now we are just putting all the pieces in place so also more people can contribute back to the project. Your fluent bit is reading in C, so sometimes that adds a barrier to contributors, right? But now we are extending to that to support goal lines, so we have our expectations and more people will be able to create their own connectors, their own implementation, and enrich their data for their own specific use case. So one of them is perform. So if you would take the category will be like a performance and give more power to developers through the pipelines. Excellent. Thank you so much for taking time out today and talking about the project. And as usual, I'd love to have you back on the show. Thank you. Okay, thanks for the name. Thanks for the invitation.