One of the questions we see from time to time is around where and how we monitor Office 365, and what all gets monitored. In a nutshell, what we deliver out of the box is monitoring from a set of Azure cloud services, that will then go and do performance and availability monitoring of your Office 365 tenant, where ever those resources may be.
In terms of what gets monitored, that really boils down to “how many” of a particular resource type are we going to watch for you. Some people have misconceptions around that, thinking that they may want to monitor every single SharePoint site, or every single mailbox, in an entire organization. While some companies may have used solutions like that when all of their services were on premises, that is a model that doesn’t really make sense when the data is hosted in the cloud. The reasons why, and the way we DO look at ensuring coverage for a tenant, dovetails nicely into a broader conversation about “how do we do that” when you have parts of your tenant distributed geographically.
To begin with, let’s talk a little bit about why you really don’t need, want, or even should try monitoring every single resource in your tenant. Here are a few of the most obvious reasons:
- Security – in order to monitor a resource, you need to have access to the resource. Opening up your tenant and granting access to your entire corporate email and document repository set to a monitoring service (or any application for that matter) is about as bad an idea as you’ll come by. This is how data gets leaked people.
- Signal overload – over time, you’ll see many short, transient errors with your cloud resources. It doesn’t mean the service or even your tenant is going down; it’s just the nature of life on the Internet. If you try and wade through tens, hundreds or thousands of these signals a day, you’ll be worn out probably before your first coffee break. You need to be able to establish an appropriate cross section of your service offering to sample, not gorge yourself on data.
- Necessity – frankly, it just isn’t necessary. What I’ve seen from my many years working at Microsoft, and then subsequently at Office365Mon, is that you will get an excellent view of the health of your tenant by monitoring one to a few resources based on data center. For example, in most cases (but not all), if one SharePoint site is up, they are ALL up. It’s incredibly rare to have only one or two site collections within a tenant down and all the others up, or vice versa. With Exchange it’s a lot of the same thing – while it’s more likely there that you may randomly have issues with one or two mailboxes now and again, in most cases when one mailbox is up within a data center, they’re all up; when one is down, they’re all down. Again, this is not true in all cases (and Exchange itself has some other factors based on its architecture that can contribute to more of these outages than SharePoint), but it’s a good general rule to follow.
So how does that pertain to monitoring geographically distributed Office 365 resources? Like this – today, Exchange can have mailboxes for a single tenant split between different data centers. In the future, SharePoint Online will support having different segments of its service split across multiple data centers. For more details on what’s happening with SharePoint Online in this respect, see this TechNet article: Multi-Geo Capabilities in OneDrive and SharePoint Online in Office 365. At Office365Mon, we tackle this in a couple of different ways:
- Cloud probes – when your data is split across multiple data centers, create multiple Office365Mon subscriptions. With each subscription we can target a different resource or resources in the different geographic locations where you have resources. All of our licenses at Office365Mon support having multiple subscriptions; for more details see our Pricing page. By pulling a representative resource or two from each different data center and configuring Office365Mon subscriptions to monitor them, we can track all of your data centers with our cloud-based probes.
- Distributed Probes – we also have a feature that you can download and install locally called Distributed Probes and Diagnostics. This can be installed on as many different devices in as many different locations as you want. So you can install the agent on different physical or virtual machines that are in or near the same regions where your Office 365 resources are at. Each of these devices issues health probes from the location at which it’s installed, and then it “reports back” with both performance and availability data so you can keep track of what’s happening with your Office 365 tenant worldwide.
When you start breaking down your monitoring plan by mapping it to the geographic regions in which you have data, and then matching that to Office365Mon subscriptions and Distributed Probes, you can pretty easily and pretty quickly develop and deploy your Office 365 monitoring in a way that will keep you in the know and in the control, no matter how big your organization is. As always, the first step is to create your Office365Mon subscription, which you can do at https://www.office365mon.com. The first 90 days is free and you don’t need to provide any payment information up front. You can continue to add additional subscriptions during your trial period and map out a workable, sensible monitoring strategy.
As always, we love to hear feedback so if you have questions feel free to shoot them to our support staff at support@office365mon.com.
From Sunny Phoenix,
Steve
Share-n-Dipity 