We recently launched our new observability product, Cockpit. Cockpit is a comprehensive, fully-managed, multi-cloud solution to store, monitor, and get alerts for all your metrics and logs.
We created this guide presenting various use cases to make it super easy for you to see what Cockpit can do for you and what you can do with Cockpit. We’ll cover the three components that will likely determine how you’ll use Scaleway Observability:
*The latter is more like the persona-based approach you’re probably used to seeing when it comes to use cases.
Cloud infrastructure is admittedly complex, and so is observability. But that doesn’t mean it has to be complicated as well. Cockpit is flexible and gives you as much or as little insight into your infrastructure and applications as you need and want.
Cockpit is built on open-source technologies that you might already know and work with (Grafana, Loki, Mimir), which makes for hassle-free onboarding. You can use our pre-built dashboards to quickly dive into your data and start monitoring without extra configuration. Of course, Cockpit integrates with most of our Scaleway products, and you can also ingest data from other cloud providers.
So, let’s get started helping you figure out how to implement Cockpit for your projects.
One factor that will inform your decision will, of course, be pricing, so let’s get that out of the way real quick. It’s pretty straightforward.
We have two plans: a free plan and a premium plan. The difference between the two is the retention period which determines for how long we keep your metrics and logs around:
That is the only difference between the free plan and the premium plan. Pretty simple, right?
Our pricing for ingestion is also straightforward. When you want to ingest data from other cloud providers, you pay:
Ingestion of Scaleway data is always free!
Now, let’s look at the different ways you can use Scaleway’s Cockpit before diving into who will most likely use it and for what.
We identified three common ways to use Cockpit:
Here’s what that means in detail:
The first and likely most common use case will be that of a regular Scaleway user who just wants to monitor their infrastructure and perhaps set up some alerts. This is also the most straightforward use — simply activate Cockpit, decide which level of retention you need (see pricing structure above), and get started.
The second use case is for multi-cloud users who also have instances on other cloud providers but don’t like using the monitoring tools provided there or want to gather all their data sources in one place. You might already enjoy using Grafana and want everything in the same place. Cockpit can provide exactly that; you simply have to choose how much retention you need.
All you have to do is configure your Grafana agent that sends logs and metrics to Scalway’s Cockpit from other providers. You’ll be able to monitor and have alerts for all your infrastructure from all the cloud providers you use.
Our third use case is those users who want to monitor both their infrastructure and the applications that run on it. For example, if you’re running a React application, you will also want to know when something goes wrong there, not just when your infrastructure has a problem.
With Cockpit, you get the logs and metrics for your application in the same place as those for your infrastructure. That makes it easier to keep everything in sight and get an overview of how things play into each other. And that, in turn, makes it easier for you to react to any issues that arise based on real data.
Let’s look more closely at four potential Cockpit users and their needs. This is based on who a user is — their job in a company — but also considers how deep someone might want to go when it comes to observability. Some folks just need a bit of oversight over what’s happening, while others will want to wade knee-deep into logs and metrics because they need a lot more data to do their job well.
So, let’s look at our four main user personas and the different ways they would use Cockpit. Chances are you’re one of them or a mixture of some.
A DevOps engineer knows how to use infrastructure and run low-level code. Their goal is to constantly improve performance, so they need to be able to look at how infrastructure is impacting other code.
They want to be able to monitor resources they use from a cloud provider and see how they could improve the software they’re developing to get better performances and usages.
The DevOps engineer will actively open Cockpit (probably on the free plan) to monitor logs and metrics and dig into the data, whether single-cloud or multi-cloud.
This might sound a little flippant, but a SysAdmin doesn’t really care about the code itself. But here’s the thing: they don’t have to! However, they do want to keep providing devs with the right infrastructure and monitor it to see what needs changing.
For example, they want to be able to easily spot that one of their instances is high on CPU usage so that they know when to spin up another one. They want to monitor the resources they manage for developers, so they can warn them about critical usages and make sure everything is always “on track”.
The SysAdmin pretty much always has Cockpit open, and retention is important to them, so the premium plan would be the best option for their use case.
The CTO doesn’t run code; they just want to know the overall situation of the company’s infrastructure. They don’t need to go down to the micro level; a macro view is perfectly fine for them.
The CTO will probably open Cockpit 1–3 times a day just to check if things are okay and monitor the system’s status. They do, however, appreciate the longer retention periods that come with the premium plan.
The Developer is not focused on performance but on information. They don’t care about performance further than whether the machine can run their code. They want to get metrics and logs for the software they’re developing and to understand their code and issues better.
For example, imagine a solo developer in a startup with ample funding to buy infrastructure, so cost isn’t relevant. They don’t need to optimize infrastructure or performance. They ’ll buy another machine or add more power to the existing system if they need to. So they just want their code to run and to know when something goes wrong.
The Developer will probably only open Cockpit when something is wrong, and they need to find out how to fix it. The free plan should suffice for most.
As you can see, Cockpit is pretty flexible, and you can use it in whichever way makes the most sense to you and for your needs. The free version is, of course, already included with your Scaleway account. It’s quick to set up, especially with our Quick Start Guide.
A bunch of our customers have already extensively tested Cockpit in our public beta and helped us iron out any kinks. One of them, Antoine Martin-Julien, the CTO of FriendlyHome, called it the “Swiss army knife observability solution” and said it was easy to set up as well.
So head over to your Scaleway Console right away, activate Cockpit, and start monitoring your metrics and logs as needed. And stay tuned for more blog posts about observability! Next up, the engineering team will tell you how they built Cockpit using open-source tooling.
By the way, if you’re feeling a bit of FOMO now because you missed out on the public beta for Cockpit, check out our Betas & Previews page, where you can opt into our private and public betas for various products. No more FOMO for you! 😉
Meet Cockpit, Scaleway’s observability product! Cockpit is a fully-managed, multi-cloud solution to store, monitor, and get alerts for your metrics and logs. And it’s built using open-source tools.
Over the past decade, many startups have been lured into believing a myth: that one cloud provider can cover all of their needs.
Learn how we built Cockpit to be both an internal ecosystem tool and a fully-fledged observability product for our customers, allowing them to monitor both infrastructure and application data.
