Welcome to our webinar “4 ways to use Microsoft Azure Monitor Beyond Azure”
Hi. My name is Cameron Jones. I am the Principal Product manager at Blue Medora. Here’s just a little bit of background me before I get into it. I’ve been working with our platform BindPlane, which I’ll show you today and how that interacts with different platforms including Azure Monitor for quite a while now. So let’s go get into it.
So today, what I am hoping to discuss. First, just real briefly we’re going to be talking about Azure Monitor and then we’re going to talk about the four new ways that we see that you can use Azure Monitor. These are the different use cases that we’re seeing out in the field as we’re working together with different customers. We’ll also get into a brief demo of those use cases. I will definitely have some time for questions and we’ll try and cover everything that the people ask.
So let’s kick it off. You know, really quickly let’s take a look at “Why Azure Monitor.” I’m assuming a lot of people on this call are either currently using Azure Monitor or maybe I looked at starting to use it. Really it’s built around using Microsoft Azure. So out-of the box you may be already using services like Application Insights, Log Analytics, maybe Service Map. When you start using Azure Monitor, it’s going to natively integrate with all these different Azure resources that you’re already using. It’s kind of a…you know we call it here the “Log Analytics Hub.” This is where you going to be bringing all your logs. This where you going to be bringing in any performance metrics or configuration properties that you want to look at. It’s going to give you a lot of functionality with those things. It’s going to allow you to view those different metrics, create alerts on those different metrics, look at things like health and create dashboards to be able to view these different pieces of information. But that’s all going to be local to these different services that you’re using with Microsoft Azure.
Now, where we’re coming in and where we’re trying to work. We see that there are new opportunities to use Azure Monitor a little bit differently. To really expand on the number of different things that you can look at with Azure Monitor. So here’s a big list of a number of the different endpoints that we’re looking at with BindPlane…going anywhere from infrastructure, you know, actual hardware. In our local data center sources, you’ll see things like server, storage, networking and even things like load balancers and different virtualization technologies. You’ll also see a number of different cloud providers…from AWS, Google, Alibaba and IBM. So if you’re using a multi-cloud environment, you can pull in these different metrics and start using Azure Monitor as your single place to view all your different clouds that you’re looking at. And then, of course, we have different applications and DevOps and databases that you can use. Things that are going to be used on top of our Azure workloads. We see things like Oracle and MySQL in different integrations like Cloud Foundry or Docker being used in conjunction with your Azure Cloud environments. So we pulling these hundreds of different data sources that allow you to really take a look put these things together and use Azure Monitor as your single point to not only monitor Azure workloads, but these additional workloads as well.
So, how do you start using Azure Monitor beyond…for looking at more than just the Azure workloads inside of Azure Monitor. We see it really splitting into three major use cases or three major groupings. I kind of started talking about this when I was talking about these additional new integrations that we are allowing you to pull into Azure Monitor. The first one the first one is Azure workload monitoring. Azure workload monitoring is going to allow things like databases things like different dev tools like Microsoft IIS, like web servers, databases like Oracle and MSSQL and be able to get deeper-dive not only into the Azure service that is running on but the actual service itself. A lot of times, probably one of the most common use cases I see is when people are running different databases on their Azure VMs and be able to take a deep dive into that database.
Obviously we’ve already talked a little bit about it here but the multi-cloud monitoring is a big piece as well. A lot of people moving from the traditional datacenter up into the cloud aren’t going to only move to one, but move to a number of different clouds. We see different cloud monitoring from AWS and Google and trying to monitor that all within Microsoft Azure.
And finally we have the on-prem datacenter monitoring. Again in the very common case of migrating to the cloud, people do not migrate all the workload at the same time. We’ll see a number of people who are still trying to view those hardware integrations, those virtualization pieces that you’re using your data center and moving that up into monitoring it all within Azure Monitor.
So today in the demo, we’re going to kind of go through a couple of different workloads. We’re going to look at the hybrid cloud solution and we’ll just jump in to it here. So with hybrid cloud, we’re look at not only how you can monitor your Azure workloads, we’re going to look at how you can monitor the private cloud that you may already be working with inside your own environment. So whether that’s running on something like VMware or Hyper-V or even something like a Citrix. The hybrid cloud is sort of an interesting use case where we see a number of people trying to monitor both Microsoft Azure and their own private cloud that they that they’ve been using all within Microsoft Azure.
We’ll also, of course, I mentioned a few times now but taking a look at that multi-cloud environment when you’re running both Azure as well as Google or AWS or any of the other cloud like an Alibaba or an IBM. There’s some important information to be tracked. Obviously, of course, you’ll want to look at what’s going on with those services, but you’ll also want to look at what is going on with things like credit usage, so you can look at things like…”Hey billing’s not getting too high.” That can be a big pain when you’re trying to do that across multiple clouds trying to take a look at different dashboards and making sure your costs are going to stay similar. The nice part about having all that data in one place is being able to see the cause, to have that break down and understand where the majority of your cloud cost is going to be going month-to-month and quarter-to-quarter.
We will take a look, of course at some of those workloads that I’ve been mentioning. A lot of times we’ll see integrations for people who are running running different databases, different web servers on top of Azure. Obviously there’s some native Azure databases which are also being used frequently, but that does that doesn’t always fit every use case. So to be able to see workloads when you’re running it on an Azure VM and being able to use it and to be able to see, to have visibility into that’s important. So we’ll take a look through one of those.
And then the final one, we’ll kind of go a little bit deep dive and take a look at the different databases and how you can go all the way down to see database query level monitoring. This is often times, you know, when we’re looking at the workload…database health is good, but being able to dig down all the way and see things to the level query granularity to make sure that this application or the service is running fine, but maybe I’m seeing a performance issue. To be able to diagnose that it is key and this is just one of the examples. And this is just one of the examples of what you can do with some of our integrations, but it’s a pretty common use case that we see across a lot of our customers.
From here I’m going to jump into a demo. I’d like to start off showing you guys a little bit of what BindPlane is and how it works and then from there we’ll go right into Azure and show you all these different use cases that I was just talking about. How they work, the different places you can see the data, and how you can make that data work for you. I just like to take a quick pause here too and remind everyone that if you have any questions, feel free to just ask. I am more than happy to dive in anywhere. But of course if we miss any you’ll be able to jump in towards the end.
Let me share my screen here. I’m actually going to jump over to our first tab over here which is the BindPlane service itself. So this is a software that Blue Medora has created and is a service that were using called BindPlane. This is what’s going to allow us to push all that data that I’m talking about from these different sources like your hardware and your different workloads like SQL Server and get that data inside of Azure monitor so that we can start solve some of those different use cases. I’m not going to spend too much time getting into the depths of the software, but I do want to make sure everyone’s familiar and can understand where we’re getting this data and how you guys can use it in the future, so you can see what’s going on.
I really feel that this homepage is a good place to start off to show you what’s happening, what’s going on. So we start off at the bottom with these clusters. Each of these clusters are representative of different data sources that we’re pulling in. You can see we have some examples. You’ll recognize some of the logos. We have a Docker environment that we’re pulling data in. We have a Hadoop cluster, a Tomcat web server. We also have things like our hardware that I was mentioning earlier like Cisco UCS, Dell EMC servers, NetApp storage. And then even some of those cloud environments like we’re looking at earlier, like an AWS Lambda. We look at some budgeting information. We’ve got a Redshift database up in our AWS cloud.
The way we do this we have you start off and install of these things that we call a collector. So you can see these collectors are represented by the blue hexagons here in the center. You can see we have of these collectors in our Azure cloud. We have one up here in our AWS environment. And then we have one over actually in our on-prem data centers. Each of these collectors is reaching out and connecting to these different data sources, like the Cisco hardware we connect here or our Citrix environment. We’re going to reach out and connect remotely to each of these data sources, collect data and then send it up to BindPlane.
Now BindPlane is not actually going to store any of that data. BindPlane is a service we’re providing, and we actually basically tunnel that data over to Microsoft Azure. Now the data that we collect here and basically the information that we’re going to show you it’s just some metadata information inside of BindPlane that’s going to let you know, like, “hey we can no longer connect to this environment” or hey “we’re no longer able to connect to your Nimble storage.” This is just some information to help you understand when your monitoring goes down before somebody has an issue that they then realized that environment hasn’t been able to connect for the last day. So at a high level again, we basically have these collectors and they’re going to gather your data and they’re going to send it over into Microsoft Azure.
Now when we jump into Microsoft Azure, specifically Azure Monitor, we’re going to collect all this information and it’s all going to come in into your environment through the to the logs over here. I’m in my Azure Monitor environment. I’ve gone down into our logs. One thing, I just want to point out here to maybe some of the people who are just looking at Azure Monitor and haven’t used it before or are fairly new. You’re going to get a lot of Azure metrics and Azure logs out of the log management category here. So here we can see, you know with our Azure environment, we’re already looking and we can see a bunch of pieces of different information anything from Azure metrics, audit logs activity logs, heartbeats performance metrics different logs and performance metrics here inside the log management tab.
Now all of the data that we’re going to send you going to come in right underneath it in the Custom Logs. So you can see here as I kind of expand the custom logs a huge grouping of a bunch of different tables, essentially, from Alibaba and our Amazon environments. They are alphabetical. And as I scroll through here you can see a bunch of integrations that we have sending new data to us in these different tables.
If I take one of these examples, and let me jump down here to…maybe our SQL Server examples. We can look at a couple of these tables more in-depth. And so for SQL server, for example, will see you know the level of the instance to the database and all the way down into individual queries. Each of these tables are going to have a number of different pieces of data for us. As I expand, like for example, the instance we’re going to be able to pull in metrics how much physical memory are we using, what’s our badge data look like, what’s our buffer pool, and do we need to be able to adjust that? So all these metrics are going to be available to you, and Microsoft Azure has that nice query language and will allow you to query and look at any of that data individually.
Obviously when you’re trying to perform and start to look more in-depth at metrics you’re not going to always want a query something to try and figure out what’s going on. So the other nice part about this query language that Microsoft Azure provides is that your actually able to take these queries and turn them into different graphs and dashboards and look at performance monitoring that way.
If I jump over into our first dashboard here I’m going to look at our VMware vCenter environment. And just to kind of jump back to the slide deck, this is where we’re going to kind of address that hybrid cloud environment. So we have our public cloud. We’re in that right now. We have Azure set up and Azure Monitor that I just showed you. Those logs are already collecting different performance metrics and logs that were using to monitor Azure services. So in this example our private cloud is set up using some automation around VMware vCenter. With each of these dashboards that we can use, we’ll provide you with what we call an “Environment Dashboard” or kind of like an overview dashboard. We’re going to give you an idea what the this environment looks like what’s key, what kind of metrics that we should be looking at. For example in VMware vCenter were talking about like looking at things like CPU, memory and disk. And then kind of digging into each of these. So with each of these dashboards that we’re looking at here, we start off with just a health score. This health score is for each of our esxi hosts. Luckily for us right now all these hosts are healthy. But very quickly I want to be able to show you when something’s unhealthy, and not only currently, but then over time.
Now if something, you know, we need to dig in a little bit deeper. Obviously, we’re going to start looking at, you know, what metrics are making it unhealthy. We’ll look at things like CPU utilization, memory utilization on these hosts. We’re not going to look at things over time, like across. We’re going to give you that average so, in general, our CPU utilization on our esxi hosts are fine. We even kind of break it down one by one. A a peak our worst host is around 42% and our least utilized host is at 27%. All within reason, and that explains some of those 100% health scores.
And as we still look a bit deeper, we’ll start looking at some of the, you know, another step down from the host . We look at things like virtual machines. Again, showing you some of the virtual machines that we have here. We’ll look at CPU, memory, disk. The nice part about here, is that in general we’re not very CPU constrained, we’re not very memory constrained, but we actually do have a couple of offenders here that are pegging the the CPU at 100%. These are VMs that we’re going to want to go investigate. Especially when we’re talking about something like virtualization, where if it’s starting to consume too much/too many resources these VMs could actually be affecting their neighbors as well. So we want to go make sure that why are these VMs taking so much CPU. Maybe these are the VMs that we’re going to have to provision more resources to, or maybe even turn off.
So being able to identify not only what the average is but also the worst offenders. We’ll do that, you know, not only for CPU, but for memory and disk. The last kind of table here that I want to show you guys, we’ll do this with a lot of these overview dashboards, we also provide you with a bunch of additional pieces of information. So if you want to see, maybe we didn’t focus so much on network information on the virtual machine and we want to see more network information. We will give you these links to actually show you the full queries and we’ll actually give you that data as well.
So if I click into the network information here. You’ll see that query that we wrote to be able to gather this information. I’ll run that query live here and we’ll start to populate the results. This can take just a minute. What it’s going to end up doing is take a look at what we have as our network throughput information. We’re going to see OK, what’s our total network throughput like for all these virtual machines. Now obviously some of these are going to be blank, because these are virtual machines that are turned off. The nice part about these different charts as we are looking at here cuz we can actually take the data from these charts and implement them into the dashboards as well.
One of the nice things that Azure Monitor does that is very nice for us and for the for their users is that all these dashboards are customizable. We do a pretty good job here with all of our use cases, with all of our dashboards to be use-case centric and try to give you the best metrics that we see as important to monitor, important to use. That doesn’t necessarily mean it fits everybody’s use case. So oftentimes what we’ll see is people take these dashboards edit them and start taking some of these queries that we added over to the right or add their own queries to customize them and get more out of the integration.
Now I am going to actually jump to our next dashboard. This is our Amazon EC2 dashboard. With this dashboard, we’re actually going to jump into the next use case, which is another other public cloud. We’re looking at a multi-cloud environment. Obviously were using Azure Monitor already, so we’re going to be using Azure Monitor to Monitor all the Azure all the services themselves. We have an EC2 environment dashboard here that’s actually going to provide us with a health scores and information on the actual EC2 instances running in our AWS cloud.
We can see information very similar to what we were looking at in the VMware environment, but specifically for our AWS cloud. And if we take a look at some of the actual performance metrics example again, our EC2 instances seem to be up. They seem to be healthy. We have no issue with them. But maybe if we take a look at some of the actual performance metrics that were looking at… we can look at things like how much are we reading, how much are we writing. These can be important metrics to look at in EC2 when we’re trying to determine cost and which of these instances are going to be costing us the most money.
On average, when we’re looking at reading, we’re looking at 1.4 million or 1.4, yeah, million bytes. But we have one right here on the bottom that’s much, much higher doing most of the reading, as we can see. Maybe we want to take a look at what’s going on in that EC2 instance. We also have our writing here. Very similar, right? We have one or two that are really doing most of the writing, and so maybe want to make sure that something’s not going out…you know really spinning out of control there, or going crazy because we want to be able to keep our cost down. Obviously, it might be okay, and so we can move on from there. And we’ll continue to go through some of the other EC2 metrics here, like status fail checks and CPU utilization. Just like we did on the VMware environment we’re looking at things like network, CPU properties, things like that that are available here as well.
Now one of the deeper use cases that I wanted to get into here, especially with the cloud environments. Now I’m going to switch over here from the AWS environment to looking at our Google environment. Is really digging into that cost side. Because when we’re looking at a multi-cloud environment, one of the number one things that we just want to look at right away is how much money are we spending. Are things where we’re expecting them to be billing wise? Obviously you’re going to be getting a lot of that out of Microsoft itself, when you’re working in Azure, but you won’t get that view into Google or AWS. In the Google dashboard, we actually have a Google Cloud billing dashboard that allows us to dig in deeper around things like pricing and how that pricing is breaking down. So we start, right at the highest level when, you know, the account that you set-up to monitor. How are we going to take a look at that, what’s the cost looking like. We’ll will show you things like the total account on that cost. You see here our total cost has been totaled up to 513. We can kind of see what that cost is looking like over time…it’s charging us around a little over $20 over time, but then totals up to 513.
That’s what we’re being charged, but maybe we don’t understand why were being charged that. So, we’ll break it down in a couple of ways for you as well. We’re breaking it down by pure project. In Google you have different projects, and so will start saying these are your most expensive projects. You’ll take a look at, hey why why are these costing us the most? We will also break it down by service cost, over here on the right. So I have one of those kind of like groupings on whatever project you running and then on the way right will break it down for service. These are the different services we’re using within Google Cloud. So you see in our environment at least most of our cost is coming from our Stackdriver monitoring and our compute engines that we have set up in Google. We have a lot of other services that really aren’t costing us anything at all. And then right in the middle we’ll do a combination of both. This is how much each service is costing you per project so in this case, again, just because we have a couple of projects up here running, but in general most of them are using Stackdriver and that’s going to be a per-project basis. Stackdriver is costing us the most amount of money, followed by compute engine. Just like anything else, really quickly, we’ll give you a high level of what’s your total cost, how this broken down by project, how that’s broken down for a service and kind of combination of both. But if you want to understand those services better, you want to understand those projects better, we have those links here to the logs as well. So if you want to really dig in and say, okay, why is this project costing me so much money. Let me get more details on this project, or more details on the service that I’m looking at, we have queries that allow you to do that over here on the right.
The third use case here is around our our SQL-server workloads and in workloads in general. So earlier we were talking about and this, it is probably the most common thing that we see isyou’re in Azure Cloud, you’re using as you’re using as your cloud provider, and you’re using some different services. But, you’re running things on top of those services and you don’t have any visibility into those services. So I took a number of examples there, starting with our SQL-server dashboards. We do have a number of different SQL-server dashboards that are available, but I think this workload one shows something that the rest of them don’t. This is something that I haven’t had a chance to talk about deeply yet. We’ll look at things, again, like CPU utilization, memory utilization on these SQL server instances. What’s IOPs looking like on these different databases that I’m monitoring. But then we’ll also relate it to the virtual machine. So this is something that we haven’t got into much detail yet here, so these are virtual machines just related to our SQL instances. Here we can see things like CPU. What is our CPU looking like, what’s our memory, what’s our total network looking like. We’re only showing the virtual machines that are related to our SQL Server instances here. For example, we have 3 SQL Server instances, only one of them here is necessarily running inside our Azure environment, and that Azure one is running on in Azure VM. We’re pulling some of those Azure VM metrics to show CPU ready, memory and network. And the way we do this is by using something we call relationships.
Automatically BindPlane will find these relationships and putting that into Microsoft Azure, where one service is relating to another service. If you’re running an Oracle database inside of VMware it’s going to find that that databases, which VM that database is running on. Another example might be if you’re running a Tomcat server, web server, inside of a Hyper-v. It’s going to, again, make that relationship. So we do that even in hardware, like in a FlexPod environmental. We’ll find all those different hardware pieces and create that relationship together, but it doesn’t end there. The example I’m looking at today, we’re not only doing it between our own software, but between your Azure resources you’re looking at here as well.
As I mentioned, one of these databases is running inside our Azure environment and that’s how we’re getting these related Azure piece of the metrics. This is important because it allows us to see we have an issue with our database, and we look at our database metrics and see everything is fine, sometimes it can be the underlying infrastructure it’s running on whether that in the cloud or on-prem or in our private clouds. We want to be able to see these pieces of data together, so that when you’re trying to troubleshoot you’re not running blindly and trying to figure out what’s going on because all of the metrics look good. Sometimes it can be that next level. So with this, we’re able to combine these dashboards and be able to troubleshoot things like that.
Now I’m going to show one more dashboards while we’re talking about these services. As I said, you know, running workloads on top of Microsoft Azure is one of the biggest use cases that we see a lot of our users doing. I just want to go into one more, which is running like a Microsoft IIS server on top of an Azure VM. And this one is very specific to our different…it’s basically around cache hits. So not only do we have these overview dashboards that I’ve been showing you earlier but we do have different dashboards like this around cache hits and other use cases like that, like the SQL Server one I just showed you. You’ll have these dashboards that will show you, like “Hey, we have all these different sites, what’s the hit rate like ?” You’ll see that they’ve been marked red, because our hit rates ares lower than we wanted to be. So we’ll look at things like the website file cache hit, the URI cache hit, the output cache hit and then even look at the, you know, the different cache misses here on each of these different websites.
So there’s two levels of dashboards, one’s more focused in on a specific piece of a service, like that IIS cache hits, like that SQL Server one running on different VMs that I was showing you.
This really brings us into that last use case that I was talking about and this is, again, because we see a lot of workloads, this can be a pretty common use case that we see when people are using our different integrations. So, when we’re looking at these different integrations, and looking specifically at the database ones, being able to identify which queries are running slowly, which ones need to be optimized, which ones need, you know, we’re going to want to take a look at becomes on the main use cases. We break it down in a couple of different ways.
The first one is our query execution time. So on the query execution time, we’re going to show you which queries are running the slowest based on our average execution time. So we can see here, very quickly, you know, in milliseconds…here’s the ones that are taking the longest and then a pretty steep drop off. If you’re going to try to optimize a query or take a look at which queries are going to be running the best or the worst these are two that we’re going to want to take a look at why they are running so slowly and address those immediately.
Now sometimes, it’s not just which ones run slowest, but we also want to take a look at how often they are executing. There may be something that only executed once, but they took a really long time, so that average execution time can still be very high. We also break down all these queries here by which ones are being executed the most often and we’ll also continue break it down here where by things like reads and writes. So very quickly we can take a look at “hey this one is being executed often and it’s doing a ton of reads.” Maybe we’re okay with that, maybe that’s something we want address. We can see one over here that is taking a bunch of time, but let’s see where it is in the execution. So that we can just determine if it’s worth our time to drill down and try and optimize a query like that.
You’ll notice up here, the top two, we break each of these down by the databases are a part of it as well. We have two pretty pretty passive databases, I guess I call it, not doing a whole bunch here. If we do want to address that as well we can see, you know maybe this is a test database and we don’t need to care about it, or maybe this is a prod database and things are being executed much more frequently than we thought or at a much slower pace, so let’s go take a look at it that way.
I want to just highlight one more thing before we jump off our Azure side. I’m going to jump back over to our logs tab here, where we were looking earlier at all the basic different piece of the data that we are looking at. Although it’s not a part of a deep dive that we’re going into in this webinar. I do want to highlight that with all these different metrics that we pull in here. Not only can you the raw data that we’re pulling in with all the different logs can you take them and turn them into different dashboards, and use the dashboards that we create out of the box here and in the dashboard and feature. You can also create alerts on any of those metrics. So, not only is this data available to you in a visual way, if you’re using more of an alert-based system, you can create alerts here with all this data that we’re pumpin in here as well.
So with that, I’m going to jump back to BindPlane for a second and just highlight again. All that data that I showed you here, and all the dashboards I was showing you inside of Microsoft Azure, all that data was coming in through BindPlane. All those dashboards you can install basically out of the box when you get started with BindPlane. You can take all that data and do your own customizations and create your own dashboards.
One thing I just want to highlight is when you’re in BindPlane, basically monitoring the different integrations that you set up. There’s a couple of pretty cool things that you can do. And really those come down to the individual sources. Maybe we’ll take one that we haven’t looked at yet like Oracle database source. Earlier I mentioned that we collect different monitoring metadata on each of these different integrations. So we can show you how many metrics per minute you’re sending over to Azure or were collecting and sending over. Your also able to see how long it’s taking us to collect that data, what that collection interval is. And we have ways to adjust that as well. So if you want to collect data…you know, maybe it’s a database that’s very key to you. You know, it’s production and you want to set your collection time to collect data every 10 seconds. You can collect data all the way down to every 10 seconds. Maybe it’s a database that the more of a test/dev kind of database and with those kind of databases you could update this collection interval all the way up to 10 minutes. So you have this functionality to, adjust based on how often you want to send data over to Microsoft Azure.
Not only can you customize how often you send data. You can customize which metrics you care about and which metrics do you want to send in here. So here, you know, we take a look at Oracle database and we’ve already turned off a large number of different metrics that we decided we didn’t want to send over into our Azure environment. So we’re collecting information on the high-level objects like the instance, the database the query. But we’ve turned off information on things like the on PGA and SGA. We decide we didn’t want to look at the redo log file. I have turned metrics off like that. Obviously you don’t only have to do it as a grouping. These groupings relate to the the tables I was showing you in Microsoft Azure, but you can actually go into like something like the query, look at all the metrics and turn on and off any of the individual metrics that we are looking at here. So like disk reads, disk writes we can decide that maybe we don’t want to look at those and turn those on and off.
So with that, let me just jump back to our slides. It I’m going to forward it on and if there’s any questions instead I’m more than happy to jump back into the screen share and show anything in more detail or or highlight something or maybe just answer questions that are related to something I didn’t cover.
Thanks, Cameron. We are going to switch over to a brief Q&A session, so if you have any questions for Cameron to answer please submit them in the question box. Cameron, we have seen a couple come through so far. The first one is how is your solution priced?
Sure. That’s a great question. So earlier when I was showing you the toggles for metric collection and collection timing, that was because how we base our pricing is on how many metrics that were sending into Azure. So you can adjust your pricing. It is pretty flexible. As I mentioned if there’s a database that you don’t really care about, you can reduce your collection time up to 10 minutes and basically reduce your pricing by 10. We base pricing on a per metric per minute.
Great. Another one here, is BindPlane agent-based?
Sure. Yeah, so I’m actually, real quick for that one let me jump back into the screen share and just highlight this homepage. We don’t actually have you install an agent on any of your different data sources. As I mentioned earlier, we actually create these different collectors. The collector just has to be within your within your network and be able to remotely reach out to the different services. Like for example I take my on-prem one, it just needs to be able to have network access to the server that I want to monitor or the Docker environment. So, not agent based, but we do have a collector that we usually ask you to spin up a VM for and set it up within your environment.
We have another one here. Do you offer trials?
Yes. We do trials of the software. I’m more than happy to let you get in and play with their trial. All of our trials are fully functional as well, so everything I showed you today you’d have access to and then on top of that, of course, there’s a huge list of a ton of other integrations that I didn’t even highlight today. So if you want to get in and play with any of the integrations, you’re more than welcome to do that.
Do you have an integration for Oracle?
Yes, we do. I started to highlight one at the end. I didn’t get too in depth with it. It covers Oracle databases as well as Oracle RAC. With that one we’re going to, you know, dig all the way into things like queries and and PGA and SGA. It’s very similar to some of the SQL Server use cases that I was highlighting for some of the other databases, but Oracle has a lot more metrics than most the other databases. So there is a lot there for the Oracle database.
We have another one. How do you connect to the different sources?
Another great question. Each of the sources is a little bit different. Now for some of the databases like Oracle and SQL Server and some of the ones I was talking about earlier, those are all going to be connected using JDBC remote connection. For the other integrations were looking at things…either something like SNMP to connect some of the network devices or a lot of them have their own API, so we’ll connect using a rest API to gather that information and collect it that way. Obviously, if anybody’s interested after the call we’re more than happy to address the thing that you’re specifically interested in. We can dive into the technology you’re really want to look at we can discuss how that’s connected, as well, so you can take a look at it a little bit deeper. Thank you for your time today and thanks to everyone who joined.