Hey, folks. Thanks for joining today's webinar. My name is Matt Morrissey, and later, I'll be joined by my colleague, Peter Marshall. So before we jump in, just quick housekeeping note. If questions come up at any point, please feel free to drop them into the chat. We'll keep an eye on them throughout the session and do our best to answer as many as we can, either live or during the q and a at the end. So with that, let's get started. Today, we're gonna dig into a challenge a lot of teams are running into. Observability is getting harder and harder to scale. Data keeps growing, complexity keeps rising, and the exact moment you need answers most, searches slow down or you hit a retention wall. What I wanna walk through is a different way of thinking about the stack. A decoupled observability architecture powered by Splunk Federated Search that lets you keep Splunk as your home base, it lets you keep your workflows, and at the same time opens the door to more speed, more scale, and more overall efficient spend. So here's the outline for today. First, we'll start the we'll set the stage with what's happening in the market. Then we'll look at how business intelligence went through this exact same evolution. And from there, I'll introduce Imply Lumi, which is our observability warehouse, and show you how it slots right into your existing Splunk environment. And then I'll hand things over to Peter for a demo so you can see how this all works in action. So quick intro on Imply. We are the company behind Apache Druid, which is a open source real time analytics database built for sub millisecond queries at scale. So we've been around for about ten years now. We have grown into a series d company. And across our customers, Druid processes over five hundred trillion rows every year with queries consistently coming back in under a hundred milliseconds. So one of the things that we are known for is is just speed at ridiculous scale. That's given us a a front row seats over the past decade to how organizations are working with streaming data, how they're working with event data, and most importantly, they're running into limits with their observability stacks. So let's talk about observability for a second. We all know observability has gotten a a lot more complicated over the last few years. Data volumes are exploding. You've got microservices. You've got multi cloud. You've got Kubernetes. Every new service throws off more logs, more metrics, and more traces. So it imply we commissioned a survey to try and quantify all of this. And what we heard was is that over seventy percent of the executives said that they're actively trying to cut observability spend. Now not because observability isn't important, but because the costs are starting to outpace the value teams are getting from their own tools. Now at the same time, lot of enterprises are running anywhere from ten to twenty different tools across across logging, across metrics, tracing, security. And all of that sprawl creates silos and it creates blind spots. And what we heard from, is from close to seventy percent of IT leaders said that those that those silos and all of that fragmented data, well, it's directly increasing their MTTR. So that what is happening is that that's putting teams in a in a really tough spot. You you want the visibility. You want the fast searches that Splunk gives you or can give you, but the only way that you're getting there is by making a a bunch of different trade offs. You're cutting your your retention, you're dealing with slower performance, or you're just throwing data away. So the big question is is how do we keep the Splunk experience that everyone loves without being boxed into those into those trade offs. So here's some good news is that Splunk has already taken a really important first step in that direction with Splunk Federated Search. So what is Federated Search? It lets you query across multiple Splunk environments. So on prem, cloud, hybrid without changing how you work. So instead of copying data everywhere, we're trying to guess where something lives. You keep Splunk as the center of gravity and reach out to different back ends as needed. Now this is a big step forward in terms of breaking down those data silos I was talking about about reducing duplication and keeping users in the same UI. And what's really interesting here is that this move, this this decoupling search from a single back end, well, looks a lot like something we've seen before in another market. Now what's interesting is that we've actually seen this kind of shift before, almost play by play. And if you look back at the history of business intelligence of BI, the patterns we're seeing in observability right now look very familiar. In history, well, it really does repeat itself. Itself. Back when BI first emerged, everything started out bundled then slowly broke apart into layers. And that's exactly where observability is is going. It's where it's headed. So if you if you go back in time, all the way back to the seventies, analytics lived inside mainframes in big package applications. Everything was bundled together. You had your computes. You had your storage, reporting, all in this one monolithic stack. Powerful, yes, especially for its time, but also very rigid and completely siloed. So, for example, if you bought one vendor, you lived in that world. No. One moment. As we moved into the eighties, package apps like ERP, like CRM systems, they started to explode. But each one came with its own database. They came with its own reporting tool. That meant every system became its own island, and nothing talked to each other. Companies ended up with dozens of of disconnected silos, and all those silos created a a really big opportunity. So if you start to fast forward into the nineties, now new tools start to emerge. Now you've got products like business objects, Cognos, Crystal Reports. These tools sat on top of the database and focused just on analytics. They focused just on visualization. And for the first time, analytics became its own category and not just a feature bundled with your ERP system. That was the first major unbundling moment. And that unbundling only continued into the two thousands. So now you're in the odds. You've got ETL. You've got data pipelines. They're all starting to go mainstream. People wanted to move data between systems. They they wanted to normalize it. They wanted to build data warehouses with unified views. This is when the idea of separate layers really started to take shape, ingestion, storage, compute visualization. And then cloud computing, it only poured fuel on the fire. So now you're in the twenty tens and in the cloud era, tools like Redshift, Snowflake, BigQuery, they really they really redefined what scalable storage and compute looks like. And then you had visualization tools like Tableau, Looker, Power BI. They all exploded in popularity. And what you had was is that everything was decoupled. Each layer could innovate independently and the BI market well, at this point, it absolutely took off. So why why do I walk through all that? I think it sets up exactly what's happening in observability today. BI today, it's built on this idea that the stack should be it should be open. It should be modular, collection, storage, computes, UX, all separated into layers. And that's the shifts observability is going through right now. We've moved from bundled all in one platforms toward a layered architecture where collection, storage, and interaction can evolve independently. And when you decouple those things, everything gets more flexible. Performance, cost, scale, and you've got just a lot more choice. So with that in mind, let's let's bring this back to observability and talk about what we've built at Imply, which is imply Lumi and where this kind of fits into this new layered world that I've been describing. Okay. So building on what Splunk has started with federated search, we see the natural next step as adding a dedicated data layer underneath your observability stack. And that's exactly what implied Lumi is. We call it an observability warehouse, a high performance, cost efficient data layer designed specifically for logs and events. So if you think about it, just like Snowflake became the data warehouse behind modern BI tools, Lumi is designed to sit behind the tools you are already using for observability. And here's the most important part is that Splunk Splunk remains your home base. Same SPO, same dashboard, same workflows. We're not asking teams to learn a new query language or to move to a a new UI. Instead, Lumi lets you do more with Splunk. We want you to ingest more data. We want you to get more speed. We want you to open up more use cases, but all at a fraction of the cost. So now that we've introduced Lumi, let's talk about where it actually fits in the stack. Today, most observability platforms blur these three things together, collection, storage interaction. Your forwarders, your indexers, your UIs all live inside one tightly bundled system, and that's what forces you into the trade offs as your data grows. So with Lumi, we cleanly separate those layers. Collection stays exactly as is. Your Splunk forwarders, if you're using Cribl, your Cribl pipelines, your OpenTelemetry agents, nothing changes there. Interaction also stays where it is. Your teams continue to use Splunk. They can use Grafana or whatever whatever tools that they rely on day to day. There's no new UI. There's no new retraining. And in the middle, Lumi becomes the data layer, the part that's optimized for performance, for scale, and for cost. So by by decoupling these layers, the entire system becomes more open, becomes more flexible, and a lot easier to scale. You can evolve each part of the stack on its own timeline instead of being boxed into this all in one platform. And once you once you start to pull these layers apart, you can keep Splunk exactly where it belongs, which is right at the center of your observability workflow. So before we go any further, I I can't emphasize this enough that that Splunk remains your home base. We're we're not asking your teams to learn a new query language. We're not asking them to to move to a new UI. You know, we don't want them to rebuild dashboards or change how they work. Everything your your teams do today, the SPL, the dashboards, the saved searches, your alerts, all of that stays exactly the same. And, honestly, as a as a technology leader, the last thing you want is yet another tool your teams have to learn or yet another UI that they are forced to kind of bounce in between. Our goal is very different. Very it's the opposite. We wanna bring more of your observability world back into Splunk instead of forcing teams to spread out across five, six, or more different tools. So with Lumi sitting underneath the stack, Splunk continues to be the place your teams start, the experience they know. But now they're not limited by cost or retention or performance. It's that same Splunk experience just with heck of a lot more headroom. Okay. So if if Splunk is still your front door, what is doing more with Splunk actually look like in practice? So let's let's try to unpack that. So first is more data. A lot of teams today, they're forced to drop high volume sources because of cost. Think of the cloud data, your VPC flow logs, your CloudTrail, your DNS logs, you know, you name it. With Lumi as the back end and Splunk Federated Search on top, those suddenly become very practical to retain inquiry. You don't have to choose between visibility and cost anymore. Now number two is more intelligence, more AI. Because Lumi exposes open APIs, the same observability data can flow into your LLMs, your automation tools, tools like Cloud, ChatGPT, LangChain agents, whatever you use. The main point here is that, you know, AI can now actually help you work through incidents. Maybe start spotting weird behavior or just guiding guiding you along the investigation. And then third is more ecosystem reach. You can point tools like Grafana or Tableau directly at Lumi without duplicating any of that data. So, again, Splunk stays the center of gravity, but now more people than ever can access and explore the same data from whichever tools they prefer. So that's really the the value side of doing more with Splunk. More data coming in, more intelligence coming out, and, you know, a heck of a lot more flexibility across your entire ecosystem. So, of course, we're, you know, we're bringing in more data. We're exposing it to more users and more tools. The obvious question is is does it say fast? And that's exactly where the performance comes in. So when customers put Lumi underneath Splunk, the first thing that they notice is is the speed. It is not just about shaving a few milliseconds off a a simple query. It's about making the hard queries viable, Broad time ranges, wild cards, heavy aggregations, those are the kinds of searches you need when you're in an incident or doing a deep investigation. And historically, those are the ones everyone was really afraid to run. So with Lumi, we can routinely see anywhere from three to twelve times faster performance on those workloads. So the practical impact is is you can iterate faster. You can ask more follow-up questions. You can reduce MTTR. And frankly, make Splunk feel like it's running on on rocket fuel. Now speed is just one side of it. The other side is can we store more without blowing up the bill? And that's where the storage efficiency comes in. So to support these workloads, we've built a new compression approach tailored for log and event data. So the result is is that Lumi is often around three times more efficient than just say g zipping data into object storage. And with that, you'd you'd it's just simply raw text. With us, you also include indexes. So what does that do for you? It buys you the ability to keep more data online and searchable for longer without your storage bill just going off the rails. And that's I mean, that's not just an accounting win. It means longer look backs. It means higher fidelity data. It means making fewer compromises when you're deciding what to keep versus what to drop. So, ultimately, the the net effect is is faster queries. It's more retention, and it's just a more powerful overall Splunk environment. Okay. So let's try to pull all this together and look at where where we actually sit in your architecture. So here's how this looks end to end. On the ingest side, the forwarders, Lumi looks like just another indexer. You can send data to us using familiar mechanisms, your Splunk orders, your your Cribl screen, HTTP. You point the configuration at Lumi, and we immediately start compacting and optimizing it. On the query side to Splunk search heads, Lumi looks like just another remote search engine. This is where Splunk federated search comes in. Splunk sends us an SPL. We execute the query in Lumi's engine, and we return the results back to Splunk all transparently. So from a user's point of view, nothing changes. They've run a search, Splunk fans it out to Lumi where appropriate, and results come back. You get the compression, you get the performance, you get the scale without asking users to change how they work. So setup is is super easy. We wanted Lumi to fit right into what you already have. You simply point your existing data forwarders to Lumi's HTTPS endpoint and events start flowing immediately. Lumi takes care of retention, takes care of the indexing, making that data visible in the UI. Now on the Splunk side, you just add a federated search provider to Splunk and it knows how to reach Lumi. That's really all there is to it. Most teams go from zero to their first federated query in in under an hour. Okay. With that, rather than just talk about it all in slides, let's actually show you how it works. I'm gonna hand it over to Peter who's gonna walk through a short demo so you can see Lumi working underneath Splunk in real time, how that data flows in, how federated search is configured, and what the performance gains look like in practice. Thanks for that team. Great to meet you all. Welcome to the webinar. I'm Peter Marshall. I'm director of developer relations here at Imply. I'm gonna talk to a little bit more about Lumi's approach to search and query handling, that thing that helps us search that data at very high speeds, and a little bit about the compression, that thing that's reducing the storage footprint because those two things together is what makes Lumi really cost effective. So my task here today is to translate all the good stuff you've been hearing about Imply and about Imply Lumi from my colleagues and to show you what that looks like in the real world. So let's get going. I'm gonna open a browser here, and let's log into a leading observability platform. Now note there are no add ons. There's no custom applications. We're just looking at standard features that come with this tool off the shelf. So in the background, my team has been preloading a demo dataset here. We've got some web data from a make believe ecommerce website. So let me answer the first question you might have, which is how easy is it to look at this data if I'm looking in Lumi? Well, it's very easy. We are dual loading this exact same dataset into Lumi. And to get to it, I'm gonna take exactly the same search command that I used show you the local demo data. I'm just gonna make one small change. When I hit go, these two technologies are now working together. They're searching for the matching records and computing the final results from the copy of the data that I have in Lumi. And in the results, as you see here, I'm getting exactly the same raw data, the same field, the same results because the commands I use, the language I use, stays the same even though I'm now using Lumi. So let's now turn to that exciting advantage of Lumi, speed. To see that more clearly, let's get a bit more complicated. I'm gonna run this more complicated command on the local data. And meanwhile, let's open the same search. I'm gonna put this now so that it goes and searches Lumi. This is exactly the kind of command that any of your users who use these tools day in, day out will be very familiar with. And look how much faster results came back when Imply Lumi is involved. Meanwhile, that local search, let's have a look. Oh, yeah. That's still working away. So my team undertook comprehensive benchmark testing. We looked at a range of different searches and queries and observability tools consistently get at least four x performance boost when observability is stored in, and those answers are being computed in partnership with imply Lumi. That kind of speed really counts when you care about MTTR, when you're looking at speedy access to the latest data, when you're asking challenging questions, when you're trying to really dig into what you know about your environment. So how do we set this all up? It's really quite easy. Lumi presents itself as part of the infrastructure that these tools are used to. It's about maximizing fit, about minimizing friction when it comes to integration. That means in this main tool, all the searches, the dashboards, the alerts, everything benefits. But Lumi doesn't just make searching and querying faster. It's also about how stores the data. And as you can see here, this sample dataset was compressed by over ninety percent. Now that's really not unusual. Lumi's approach to intelligently compressing all sorts of observability data is what opens up options for rethinking about how and where you store your observability data. You might reconsider your retention policies and avoid that pain of rehydration. And whether it's now possible to collect and search things like Kubernetes or DPC flow logs. Maybe today, you've been thinking that's gonna be way too expensive to store, let alone in terms of compute to try and search for stuff. Again, Lumi isn't about replacing what you have. It's about doing more with what you have. Implies there to fit really neatly into existing architecture, both collecting data and for generating insights. You know, this gets to the heart of how we are gonna deliver on what the market is calling decoupled observability. So with that in mind, let's look at some of these integrations. So this is the integrations page here inside Lumi. To load data into this environment, we actually use OpenTelemetry. If you're Splunk users, well, you can see there's HEC and s two s connectors here. That's really easy to configure, therefore, on your forwarders to push the data through into Lumi. And we also have a pull mechanism in here in the demo environment that picks up data automatically from s three buckets. So how am getting the data out? Well, starting here with Splunk, Lumi appears as a remote search head. So hooking up to search the data that we have stored in Lumi as with all of our integrations, it's just copy and paste. We're building Lumi to fit neatly into your architecture. We also see here we've got Grafana. And in Grafana, Lumi appears as Loki. We've got a JDBC connector to BI tools. We have an MCP server. So I have a bit of fun with this. I've connected this demo environment to desktop. I have a play around with natural language search. I have a colleague who's using land chain modules to build a chatbot for anomaly detection. That's really quite cool as well. So under the hood, in summary then, we've got Lumi's speed for its compression. That's what's making querying and searching all this data really cost While that decoupled approach to integration, that's what's opening up the possibility of fewer silos, of better collaboration between teams, more efficient workflows. You can preserve your workflows and use the tools that you already have. Just making small configuration changes, and you can do more thanks to that high compression, thanks to that really great performance. When you're ready to activate this decoupled observability architecture, you can then take advantage of those native integrations and open up your Lumi data to other tools as well. So I hope that was all helpful, useful, and interesting for you. That, I'm gonna hand back over to the team. I'm gonna stay in the background here and answer any questions you might have. With that, back over to you. Alright. Thank you, Peter. So while folks are are dropping some questions into the chat, I well, there's a couple that I always get, so, let me walk through them pretty quickly. One is is the data secure and how is access controlled? So first off, absolutely. Security is built in from the start. All data is encrypted in transit and at rest. Lumi supports RBAC. It supports private networking, audit logging, and, you know, customer managed keys for full control. And, again, because Splunk remains the front end, your existing access controls carry over automatically. So the same users who have access in Splunk get access through Lumi, and the ones who shouldn't don't. Okay. Other question I get a lot too is does Lumi work outside of Splunk? Yes. Splunk is the most common way teams start because of federated search. Federated search makes the integration very, very straightforward, but Lumi isn't just tied to Splunk. You can query Lumi directly or point other tools at it that, that Peter was showing, like Grafana, Tableau, or, you know, AI assistance. So the the idea here is is really simple. If your teams live in Splunk, they get to keep that Splunk experience. But if other teams prefer other tools, they can access the same data without duplicating it. So I'm looking through the chat here. It looks like everything has been covered. So let me try to kinda, I don't know, wrap this up. What we walked through today is a pretty big shift in how observability gets done. You know, we talked about data volumes growing, costs are rising. This traditional all in one approach just isn't keeping up. Splunk Federated Search laid the groundwork, And when we build on that by adding an observability warehouse, that that dedicated data layer that allows you to keep more, search it faster, and just expand the number of use cases without blowing through your budget and without changing how you work. Same SPL, same dashboards, same workflows, just a heck of a lot more headroom. So if anybody wants to dig deeper, if they wanna try Lumi with their own data or just talk through what this could look like in your own environment, we would be happy to connect. And I guess just in closing, thanks again for spending the time with us today, and, and a big thanks to Peter for for the demo. Take care. Thank you.