Blog Site of the SamlMan, Connecting Apps in a Cloudy World

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.

Today we released the next phase of our Threat Intelligence monitoring features at Office365Mon.Com. Office 365 monitoring has been a staple of ours at Office365Mon.Com for a number of years now, and recently we’ve expanded it to take advantage of the new Threat Intelligence capabilities provided to Office 365 E5 license holders. Our initial offering included support for threats that were delivered via email to Office 365 customers.

As explained in our initial blog post here: https://samlman.wordpress.com/2017/12/04/stay-informed-with-new-malware-monitoring-from-office365mon-com/, the Threat Intelligence monitoring we’ve launched already allows you to do things like get notified the first time a new malware is sent to your organization, when you get more than a certain number of malware within a given time period, and when any user gets more than a certain number of malware in any given day. All of that monitoring and alerting has been based on malware that arrives via email. Today, we’re adding support for monitoring malware threats in SharePoint and OneDrive for Business. By adding these additional services, you can be assured that when your monitoring Office 365, you’ll also be kept aware of when and where malware shows up in virtually all of the primary repositories in your Office 365 tenant.

In addition to the notification options described above, we’ve added a new one one that’s designed specifically for SharePoint and OneDrive for Business – alerting you when any individual user uploads and/or shares an excessive number of malware infected files in any given day. You decide what an “excessive” number is, and we do the rest. As always, configuration is incredibly simple for these features, as shown here:

Every time any user uploads an excessive number of items, you’ll be given a notification along with details around who is responsible. That allows you to take quick action in case one of your users’ devices has been compromised or they are otherwise unaware that they have pushed malware infected items into your Office 365 tenant. You’ll get the information you need to focus your efforts on the individuals who are having the most difficulties so you can lock things down and disinfect their devices.

We’ve also rolled this data into several of our existing Threat Intelligence monitoring reports, as well as adding some new ones too. Here’s a look at all of the Threat Intelligence related reports in our Advanced Report gallery; the one’s highlighted in green are existing reports that now contain additional data from SharePoint and OneDrive; the one highlighted in purple contains a set of new reports just for malware found in SharePoint and OneDrive.

When you view the Other SharePoint Threats report, there are actually a number of different ways to view data points about the malware that’s made it into your tenant:

By author, or the person that uploaded the infected item

By site, so you know which sites are most problematic for having infected materials sent to them

By malware family, so you can see which types of malware are making their way into SharePoint and OneDrive for Business most frequently

By file type, so you can see which types of files are getting infected most frequently and then subsequently working their way into your tenant

You’re really getting a comprehensive view of your tenant when monitoring Office 365 with Office365Mon.Com. The new release today further broadens the multitude of ways in which we keep you in the know and in control of your Office 365 tenant.

You can try out our new and improved Threat Intelligence monitoring features by visiting us at https://www.office365mon.com. If don’t have an Office365Mon subscription yet, you can create one for free for 90 days with all of these features turned on. We never ask for any payment information up front, so you can just click on the big Start Now link on the home page and get started. If you’re an existing Office365Mon customer, just go to the Configure Threat Intelligence Monitoring page for your subscription at https://www.office365mon.com/Configure/Threats.

As always, if you have any questions or feedback on this or any other features, please reach out to our support team at support@office365mon.com.

It seems like organizations of all types and sizes are under digital attack these days. Using email to transmit malware and then compromise an organization is a common way in which these kinds of attacks strike. Today Office365Mon is launching a new service to help keep you in the know of when and where these attacks are directed at your organization. In conjunction with the Threat Intelligence features of Office 365, we have a new feature we call Threat Intelligence Monitoring.

The Threat Intelligence features in Office 365 are included for those users that have an E5 license. The Office 365 E5 license includes numerous additional features beyond the basic email and SharePoint, and Threat Intelligence is one of them. The Threat Intelligence feature in Office 365 is a collection of insights used in analyzing your tenant to help you find and eliminate threats, proactively. The Threat Intelligence Monitoring feature in Office365Mon builds on that in some important ways. For example, you can:

Get notified the first time a new malware is sent to your organization. Know when a new type of malware has been targeted at your company so you can make sure you have the tools and plans in place to defend yourself.

Get notified when you get more than a certain number of malware within a given time period. Set thresholds for malware volume so you know if you are being targeted for broader malware attacks.

Get notified when any user gets more than a certain number of malware in any given day. Be in the know and in control if any of your users are being singled out and specifically targeted with malware attacks so you quarantine and limit the potential damage.

Configuring these options, like all features in Office365Mon, is super simple. A few mouse clicks and you are ready to go:

Once configured, you’ll have all of the standard Office365Mon notification options to keep you in the know when there’s a problem: email messages, text messages, and our webhook feature. In addition to the notifications, there are a number of interesting reports that we provide with Threat Intelligence Monitoring to help you analyze the nature of these attacks against your organization.

For example, here you can get the trend of malwares entering your organization during the current month:

In addition to the trend for the current month, there’s a similar chart that shows you a rolling two-month period so you can see what’s being targeted at you over a longer period of time.

You can also get an overview of the top 10 targeted users within your organization, so you can ensure that they are following security best practices:

There’s other reports that show you both for the current month as well as historically, data for different ways in which malware has been targeted at your organization. For example, here’s one that shows the different malware file names that were sent into your organization:

In addition to this, you can view this kind of summary data based on who sent malware infected messages, summaries of the Senders’ IP address, summaries based on the email Subject so you can look for patterns there, summaries on file type and file name as shown above, and also information on when the malware was detected.

We’re also taking this information and have added it into our Microsoft Cloud Command Center. For those of you who aren’t familiar with it, the Cloud Command Center brings together information that previously existed as islands of data and loaded up all of the key metrics that you need about everything that’s going on with your Microsoft cloud services. We’ve plugged in the malware trend report and user targeting report into the Cloud Command Center for a really great overview of the health of your organization and its cloud services:

We think features like Threat Intelligence Monitoring really expand and strengthen the base of important information you need to be in the know and in control of your organization and its cloud software services. It all starts in Office 365, so you can help yourself get connected with this information by incorporating the E5 license in your organization.

The Threat Intelligence Monitoring service in Office365Mon is available in Preview today for everyone. As with all new Office365Mon features, all existing customers have had this feature turned on for the next 90 days to try it out. All new Office365Mon customers will also have this feature enabled for 90 days so they can see it working in their environment. As always, we would still love to get feedback on how we can improve it and make it more useful to you, so please feel free to send it our way. Licensing and pricing is not yet available for the Threat Intelligence Monitoring service; that will be set in Q1 of 2018.

We really have a wide and expansive set of tools to help you with your Microsoft cloud services now. For monitoring Office 365 performance and availability, go to https://office365mon.com. For monitoring Azure performance and availability, go to https://azureservicemon.com. To monitor malware attacks using Threat Intelligence, go Office365Mon.Com and create your Office365Mon subscription, then you can configure Threat Intelligence monitoring at https://www.office365mon.com/Configure/Threats.

After a great beta test period, we are happy to announce the general availability of AzureServiceMon. AzureServiceMon provides performance and availability monitoring for your Microsoft Azure cloud resources. It’s built on the same proven enterprise class architecture of Office365Mon.Com to provide you the most secure and scalable monitoring solution around.

We’ve also tried to stay true to the design and user experience principals that have made Office365Mon so successful, which is to make everything super simple and very quick to get up and going. After you create your AzureServiceMon subscription, you tell us where you want notifications to go, grant us permission to monitor your Azure resources, and that’s pretty much it. We take it from there and do an immediate inventory of all of your Azure resources. Then you can simply check boxes next to the types of Azure resources you want us to monitor, as you see here:

After that, we continue to regularly inventory your set of Azure resources. That – again – makes it super simple for you, because as you add and/or remove web sites, databases, virtual machines, etc., you never need to come back and configure monitoring for it. We automatically pick up on those changes and will take care of it for you.

After you’ve set up the types of resources you want us to monitor for outages, you can configure how you want the performance monitored. Doing that is also designed to be quite simple, so you merely tell us what thresholds to look for when monitoring different metrics of your Azure resources. Here’s a sample screenshot:

As you can see, all you need to do is check the box to monitor the metrics for a particular type of resource, and then set thresholds at which you want to get alerted. For example, in the screenshot above it is configured so that if the average response time of pages in my web sites exceeds 22 seconds, I will get alerted. There are different metrics that can be measured for each type of Azure resource, so you just click on the section title – like “SQL Database Metrics” – to expand it, then set up your monitoring thresholds. Again – we do the rest. When you add or remove Azure resources, we keep track of that and will monitor the performance on all of them.

All of this availability and performance data rolls up into our report gallery, which features over a dozen reports, pivot tables and pivot charts. Here’s a snapshot of our gallery:

In addition to that, when you are also monitoring Office 365 with Office365Mon, you can use our new Cloud Command Center view to get the latest outage and performance information across all of your Microsoft cloud services, as shown here:

If all of these reports aren’t enough, we’re also working now on a new Power BI dashboard to display all of your Azure performance and availability monitoring data. Expect that within the next couple of months.

We hope you’ll take a couple of minutes to try out AzureServiceMon and see how it can give you tremendous insights into your Azure subscription. Combine it with Office 365 monitoring from Office365Mon and you have a true end to end pulse on the health of all of your Microsoft cloud services. You can get started today by visiting https://azureservicemon.com and clicking the big Start Now link on the home page. That will start a trial subscription that you can use for 45 days and try every part of the AzureServiceMon service. We never take any payment information up front, so you can simply try it out. If you like it, you can convert it to a paid subscription; if you don’t, there’s nothing else you need to do – we’ll just stop monitoring your Azure subscription for you.

As always, thanks for the many great ideas and suggestions you all have provided to us to help build a really comprehensive set of monitoring services. I hope you’ll keep them coming, because we read each and every one of them and incorporate many of these wishes into our services.

When we started our new Azure monitoring services at AzureServiceMon.Com, one of our goals was to be able to provide a more comprehensive view of all the Microsoft cloud services you are using. At Office365Mon.Com we already monitor a wide range of Office 365 services, such as SharePoint Online, Exchange Online, One Drive for Business, Power BI, and Skype for Business. The number of services we monitor there has grown steadily over the last couple of years and will continue to do so.

Spinning up a new service to monitor Azure though gave us an opportunity to give much broader coverage across the Microsoft service line, because many customers that use Office 365 also use Azure. We went through the first iteration of the service features and brought on availability monitoring for Azure services this summer. Based on feedback from that, we added a pretty extensive second set of features around monitoring the performance of services in Azure, down to the level of things like disk IO, CPU consumption, memory consumption, network IO, etc.

Up to this point, these two monitoring services served as “islands of data” with information on your different Microsoft cloud services. Today, we are bringing those together in a new comprehensive view we call the Microsoft Cloud Command Center. This feature is currently available in Office365Mon.Com, and will soon also be available in AzureServiceMon.Com. To start with, here’s what the Command Center looks like:

As you can see, what we’ve done is brought together information from these two services and loaded up all of the key metrics that you need about everything that’s going on with your Microsoft cloud services. We start with outages, because customers generally care about that most. You can quickly see when your last few outages for both Office 365 and Azure were, and for what resources.

As you keep going down you can see what the most recent – like last 90 minutes or so – performance has been like in your specific tenant in Office 365. Next to that we show you what the latest availability is for all of the Office 365 resources that we’re monitoring for you. This is near real-time data of your live tenant based on our own health probes that fire off every minute or two.

Down below that you can see the latest availability status of all of your Azure resources that we’re monitoring. You can drill into each of the different resource types you see there – such as web sites, SQL databases, etc. – and find out the status of each one. Finally, next to it you can see the latest set of metric alerts that were triggered. Metric alerts are a feature of AzureServiceMon that lets you set performance thresholds for metrics, and when they go outside those boundaries you are notified and we track it for you.

The new Cloud Command Center provides a true all-up, single pane of glass view of the health of all of your Microsoft cloud services. We have other features on the roadmap for Office365Mon and AzureServiceMon, and as we bring them online we’ll continue to expand the Cloud Command Center as appropriate.

We think you’ll find this single snapshot view of your cloud services very valuable. You can start with it today by visiting Office365Mon at https://www.office365mon.com/Features/CloudCommand. If you haven’t created an Office365Mon subscription yet, then just go to our home page at https://www.office365mon.com and click the big Start Now link. If you haven’t created an AzureServiceMon subscription yet, then try it out now by visiting the site at https://azureservicemon.com and clicking the Start Now link on the home page there.

Bringing this wide range of critical operational data into easy to use views is one of the things we do best at Office365Mon and AzureServiceMon. As we say, you need to stay in the know to be in control, and the new Cloud Command Center will help you do just that.

One of the things we get asked about rather often at Office365Mon.Com and AzureServiceMon.Com is how to do custom alerts and other workflow scenarios when an outage or some other interesting thing happens – maybe the version of your SharePoint Online tenant changes, you aren’t getting any search results in your tenant, etc. We’ve had a webhook feature for some time that was designed specifically to allow customers to address these one-off custom scenarios, but previously have always talked about it as writing some custom code and web site to process it. Now, based on yet another great suggestion from one of our truly brilliant customers, we’ve put together some information on how you can do all of that without writing any code at all! Instead we’re going to use the graphical workflow designer in Microsoft Flow.

To begin with, go to the Microsoft Flow site here: https://flow.microsoft.com. Click on My Flows to see the Flows you have and/or design new ones:

Once you get into your flows, we’ll click on Create from blank to create our new Flow:

When you create a new Flow, we’re going to look for an Http Request connector. The webhook fires as a simple HTTP request with some JSON. To begin, click on Search Connectors:

Search for “http request” and click on Request – When an HTTP Request is received in the search results:

The next thing that’s going to happen is that it will ask you for the schema of the JSON that’s going to be sent over in the Http request. We’ve put that together for you, but it is subject to change over time as we add new monitoring features. We’ll never break any existing schema, but we may add to it. As of today you can copy and paste the following JSON schema into the JSON Schema edit box; alternatively you may want to download from our web site at https://office365mon.com/webhookschema.txt because the formatting in the blog will likely get you all messed up:

{

“type”: “object”,

“properties”: {

“SubscriptionId”: {

“type”: “string”

},

“CompanyName”: {

“type”: “string”

},

“WebhookNotificationType”: {

“type”: “number”

},

“NotificationOutageInfo”: {

“type”: “object”,

“properties”: {

“Resource”: {

“type”: “string”

},

“ResourceType”: {

“type”: “number”

},

“OutageNotificationType”: {

“type”: “number”

},

“DistributedProbeHostName”: {

“type”: “string”

}

}

},

“NotificationServiceStatusInfo”: {

“type”: “object”,

“properties”: {

“ServiceName”: {

“type”: “string”

},

“FeatureName”: {

“type”: “string”

},

“CurrentStatus”: {

“type”: “string”

},

“PreviousStatus”: {

“type”: “string”

}

}

},

“NotificationQueryInfo”: {

“type”: “object”,

“properties”: {

“Resource”: {

“type”: “string”

},

“NumResults”: {

“type”: “number”

},

“Results”: {

“type”: “string”

}

}

},

“NotificationLongRunningProbeInfo”: {

“type”: “object”,

“properties”: {

“DistributedProbeHostName”: {

“type”: “string”

},

“Duration”: {

“type”: “number”

},

“Threshold”: {

“type”: “number”

}

}

},

“NotificationVersionInfo”: {

“type”: “object”,

“properties”: {

“OldVersion”: {

“type”: “string”

},

“NewVersion”: {

“type”: “string”

},

“ResourceType”: {

“type”: “number”

},

“ResourceAddress”: {

“type”: “string”

}

}

},

“NotificationOfflineHostInfo”: {

“type”: “object”,

“properties”: {

“DistributedProbeHostName”: {

“type”: “string”

},

“LastProbeTime”: {

“type”: “string”

},

“MaxOfflineTime”: {

“type”: “number”

}

}

},

“NotificationMailTransportInfo”: {

“type”: “object”,

“properties”: {

“TimeSent”: {

“type”: “string”

},

“MinutesToDeliver”: {

“type”: “number”

},

“DelayInformationType”: {

“type”: “number”

}

}

},

“NotificationMonitoredListInfo”: {

“type”: “object”,

“properties”: {

“ListName”: {

“type”: “string”

},

“SiteAddress”: {

“type”: “string”

},

“MaxListSize”: {

“type”: “number”

},

“ActualListSize”: {

“type”: “number”

},

“MaxRenderTime”: {

“type”: “number”

},

“ActualRenderTime”: {

“type”: “number”

}

}

},

“NotificationAzureMetricAlertInfo”: {

“type”: “object”,

“properties”: {

“ResourceName”: {

“type”: “string”

},

“ResourceId”: {

“type”: “string”

},

“AzureSubscriptionId”: {

“type”: “string”

},

“MetricFriendlyPropertyName”: {

“type”: “string”

},

“MetricInternalPropertyName”: {

“type”: “string”

},

“MetricValue”: {

“type”: “number”

},

“MetricAlertValue”: {

“type”: “number”

}

}

}

}

}

Once you’ve pasted the JSON schema in, we can now focus on this scenario using the data provided in the webhook. We want to route an email message to a different group depending upon which type of resource triggers an outage notification. To start that part of the Flow, click the New step button, then click Add a Condition:

In the Condition widget, click in the Choose A Value field and select the WebhookNotificationType field from the JSON schema:

For this scenario – to route messages to different groups when an outage occurs – create the condition for when WebhookNotificationType equals 1, which is an outage:

In the If Yes widget, click the “…More” link and select the Add Condition. This is how we’ll select which type of resource created the outage notification, and send an email to the appropriate group in our organization:

In the Condition 2 widget, select ResourceType from the JSON schema fields. It’s worth noting that the schema displayed below doesn’t distinguish between which data type the fields belong to. For example, if you look at the JSON schema provided, you’ll see that both the NotificationOutageInfo and NotificationVersionInfo objects have a ResourceType property. While I didn’t see a clear way to distinguish between them when using Flow’s designer, you can always export the Flow when you’re done. It includes the fully-qualified property names so you can ensure you selected the right object. For this particular scenario, I recommend just selecting the first item in the list when it appears more than once. That’s because the schema describes the fields for outage info first. Here’s what the Flow designer looks like as you add this condition:

Now you can set the value according to how you want to route outage messages. For example, a ResourceType of 0 equals SharePoint Online, a ResourceType of 1 equals Exchange Online, and so on. The entire list of possible ResourceType values is documented in our Subscription Management SDK, which you can download from https://www.office365mon.com/Office365Mon_Subscription_Management_API.pdf. Here’s the completed condition for the case when the outage notification is for SharePoint Online:

Now you can add an action to send a message to the appropriate group when it is a SharePoint Online outage. To do that, begin by clicking the Add an action link:

Click the Send an email action:

Now you can fill out all the details of the email that should be sent when a SharePoint Online outage occurs:

When you’re creating the content for the email, you can plug in values from the JSON that is sent over. Here we’ll add the name of the Office365Mon subscription that triggered this notification; the subscription name is kept in the Company Name field:

In the body of the email, we’ll include all the details that are sent over in the JSON. They may not all have values – for example DistributedProbeHostName will be empty if the outage notification is coming from one of our cloud probes instead of one of our Distributed Probe agents – but they will all have some kind of value no matter what, even if it is blank.

Here’s an example of the completed email:

Once that’s filled out, we can click the “…More” link at the bottom again, and create another branch for an Exchange Online outage, etc.:

We can keep going this way until we’ve covered all our scenarios. For any other cases where we don’t have a specific group to route to, on the last condition we can have the “If no” condition send an email to a general support alias.

When you’re done, click the Create flow link at the top to save your changes.

Once the flow is saved, you will finally get the Url that the Flow will be “listening” on for webhooks. You need to copy this Url into the webhook property of each Office365Mon or AzureServiceMon subscription you want to use it on. To find the Url, click the widget for the Http Request trigger at the top that was used to start this Flow:

When you do that, you’ll see the HTTP POST URL property, which is the Url that the JSON from the webhook will go to; copy it and paste into your Office365Mon subscription:

After you click the Update button it will be saved and we’ll start sending data over to the Flow whenever a notification fires. You can still have other email addresses to which we’ll send out notifications – it’s totally up to you. You can (and should) also click the Test button, and we’ll send a quick webhook and let you know if it arrived successfully or not.

Once you’ve done that, go back to the Flow designer tab in your browser and click the Done link to finish up your Flow:

After you do that, you can see all the instances where your Flow was invoked, i.e. when Office365Mon or AzureServiceMon sent over a notification for things like an Azure availability monitoring issue, an Azure metric monitoring alert, a SharePoint Online version change, Exchange Online outage, etc, etc, etc.

If you click on any of them, you can see how they were processed. The first on at the bottom was added when I clicked the Test button for the webhook in the Office365Mon site. The WebhookNotificationType for it was 0, so none of the conditions for firing our Flow were met. The second one though fired when there was a SharePoint Online outage starting. By drilling into it we can see the details of how the Flow was processed:

When you look at the “Send an email” widget at the bottom, you can see the values that came over from the JSON as they were plugged into the email template we created.

That’s it – that’s the whole process. Not a single line of code was written. After you spend a few minutes getting used to Flow, it will literally only take you a few minutes to write workflows like this. It gives you a very powerful way to connect important Azure availability monitoring and Office 365 monitoring data into any kind of workflow that’s important to your business.

I hope you all find this useful. Again, many thanks to the awesome customer of ours that suggested this approach. As always, start out at https://azureservicemon.com or https://office365mon.com and create a new monitoring subscription, and then the rest is all downhill.

For those of you who missed our beta release announcement, AzureServiceMon is a new service from the company that brought you Office365Mon. We have just released a significant new addition to the service this week, which we call Azure Metric Monitoring.

When AzureServiceMon released beta 1, we provided availability monitoring and notifications for a number of your Azure resource types. It’s all wrapped up in a simple to use interface that regularly inventories your collection of Azure resources so as you change what you’re using, you don’t need to try and keep your monitoring in sync. One of the first pieces of feedback we got from the beta 1 release was that customers wanted more. Specifically, not only do they want to know when their services are down, but they wanted a way to “peek inside” to see how their various resources are doing before they go down. That’s how Azure Metric Monitoring came to be.

Using Azure Metric Monitoring is just as simple as setting up availability monitoring for it. To begin with, you go to our site at https://azureservicemon.com and configure availability monitoring. Spoiler alert – that involves about 2 minutes to fill in a couple of fields and check some boxes – incredibly easy. After you’ve done that, you can go to our Configure Metric Monitoring page at https://azureservicemon.com/Configure/Metrics. You’ll see another very easy to use interface that looks like this:

What’s great about this approach is that it takes the same very simple and very easy approach we use for availability monitoring. You don’t need to go to the Azure portal and try and create a bunch of policies on each of the different resources you have. Instead, you can come in here and in one place – set the thresholds you want to use for notifications for *all* your resources at once. Just click on the resource type bar – i.e. SQL Database Metrics, Virtual Machines Metrics, etc. – to set the thresholds for those resource types. Click the Update button and you’re done.

After that, we do all the heavy lifting for you. Want to know when the CPU utilization on your SQL Server databases rises above 75%? Want to know when the average response time of the pages on your web sites is more than 10 seconds? How about what kind of network bandwidth you’ve been chewing up with your virtual machines? Or how many queries have been throttled by Search services? The list of possibilities goes on and on here. When any of these thresholds on any of your resources are exceeded, you quickly get notifications about it. Just like all our other notifications, you can get emails, text messages, and/or use our webhook feature so you can plug in your own workflow, on premise notification systems, on premise issue tracking systems, etc.

In addition to that, there are also reports (and more coming) that you can use to get details on what the metric statistics are for all of the resources that we’re watching for you. For example, here’s a set of metrics on all of our Azure web sites:

You can see the most recent 24 hours’ worth of metrics here, but we’ll also have reports that show you what the hourly averages, sums and counts are like over the last week, as well as monthly summaries.

Azure Metric Monitoring is available today as part of our beta 1 service release of AzureServiceMon. It’s free to use while we’re in the beta release, and when you participate you will find other options to extend your free usage once we deliver our RTM release. Check out the Beta 1 Readme for more details on that, as well as to learn about all of the other interesting aspects of this first release.

Azure Metric Monitoring was added based on feedback from our customers using the initial release of AzureServiceMon. Try it out and let us know what you think, and maybe we can get your feature requests added to the service too!

Post navigation

Search Share-n-Dipity

Search for:

SamlMan.Com

Hi, I'm Steve Peschka and I am the SamlMan - come see me at http://samlman.com. I'm always happy to talk to you about your SharePoint, o365, Azure and other cloud-related security and authentication projects.