Lessons learned: Azure Operational Insights (Preview)
- select the contributor at the end of the page -
Azure Operational Insights: Getting started
Azure Operational Insights (AOI) was formerly known as System Center Advisor. However, now that AOI is tied to Azure, you're dealing with a cloud service and will you need an Azure account to use it.
You can sign up on the Azure Operational Insights homepage or log in with your Microsoft account, which may already have some Azure services connected to it. If you're brand new to Azure, you can get a free 30-day trial. Or, if your organization is already using Azure, you'll need to get set up using an organizational account, or you'll be on your own for the test. If you connect via your organization, make sure you've got approval before you setup your Azure account-during the testing of AOI, you're likely to be testing on premises servers, and that means you'll be sending data to the cloud.
Onboarding systems into Azure Operational Insights
Getting set up is the easy part, but after that you could be sitting in front of an empty dashboard. I nominated several on premises servers in our development environment to be added to Azure Operational Insights. While I assumed this was going to be a low-impact change that wouldn't affect other technicians, I was wrong.
But before I get to what went wrong, I'll tell you about the part I liked: it was really easy to onboard systems to AOI from System Center Operations Manager. Since I was already using System Center Operations Manager 2012 Service Pack 1, there was a configuration setting waiting to be connected in the Administration section of the Operations Console.
So onboarding all of my systems into AOI took very little time and was completely done from inside the SCOM console.
There are two parts to setting up the servers:
1. Make the connection to Azure: Configuring the connection works simply through a very short wizard, which starts by signing into Azure again. Then, select the workspace that you created earlier.
2. Allow the wizard to complete with a summary of the configuration: After the connection is made, add in some servers. Like I mentioned, I didn't want to add all of the servers that I had in SCOM into AOI, just a few of the servers in the development environment.
This was also easy to do from SCOM. After selecting “Add computers” from the administration console, you're given a simple dialog where you can filter servers by name, search and select the servers that you want and add them to the service. At this point, I thought this was the easiest thing ever. But I wasn't done.
Azure Operational Insights: How to avoid the headaches
Log data not syncing with the cloud
Now, I didn't know what to expect; and due to poor communication on my part, plus some unexpected behavior on the part of AOI, a lot of this proof of concept started hitting some bumps. The biggest bump being that log data was not making its way to the cloud-even though SCOM said it was connected and I could connect to the internet to log into Azure. Azure Operational Insights said it was “collecting log data,” but it never got there.
Finally, I tracked down the issue to a firewall rule, which was preventing internet access to the SCOM server. Even though I was authenticating to Azure, that connection was made from the console on my workstation, which of course did have internet access. Luckily, the firewall rules and ports were an easy find.
Once my friendly network and firewall administrator lifted the restrictions to the net for the URLs and ports required, log data started flowing-slowly. It actually took several days for the logs to show up. I came back after the weekend and was surprised to see that I actually had log data there, when I thought my Monday was going to be spent trying to figure out why I didn't.
Servers reporting errors
Since I was finally getting log data on that Monday back in the office, I thought for sure I was on the right track. But errors soon started cropping up in System Center Operations Manager, reporting that some servers were having problems connecting to logs.
Of course, it was all of the servers that I had connected to AOI. And to make matters worse, other engineers were looking at the errors and trying to troubleshoot the recent outcropping of computers in the development environment suddenly reporting errors.
It was a couple of days before we had crossed our paths and realized that we were both working on the same problem from opposite ends. But that still wasn't the worst of it.
Adding Intelligence Packs
Well, they were there. That's my only defense.
Logging into the Azure Operational Insights, and realizing that I actually did have log data to look at was encouraging. And, again, they were right there looking at me. Intelligence packs.
There were close to a dozen different Intelligence Packs-just as easy to install as putting a check in a box. I added configuration data, malware assessment, SQL assessment, change tracking and every other item I could. I figured I might as well see what they look like. They looked like screaming people.
Not only did it find tons of problems that I never even knew existed, it told me problems in ways I didn't expect. Because not only does SCOM upload data up to AOI, but AOI sends instructions back to SCOM to teach it how to look for these configuration problems on the servers. So you get to hear about it in your cloud dashboard, and you get to hear about it in your SCOM email notifications.
And the SQL guys went nuts. And the SCOM guys went nuts. And I went nuts. And they all looked at me with really bad intentions.
My lessons learned with Azure Operational Insights
Honestly, not all of the problems that I had were problems with AOI.
Add the Intelligence Pack for a “second opinion”: Did AOI show me too much about ways that my systems were not adhering to best practices? Actually, I already knew that, and maybe I added that Intelligence Pack because subconsciously I was looking for that “second opinion” that would prompt me to make some improvements to things that I can never find the time to improve.
Issues can affect others. Don't assume they won't: Had I gone into AOI assuming there would be issues that would affect other people – instead of thinking it would be a quick evaluation and nobody would even be bothered – I could have taken away a lot of frustrations and saved myself some of those evil stares.
It can meet log and insight needs: In the end, I found that Azure Operational Insights was worth my time, and I'm glad I've got it setup. It meets my needs of having logs all in one place (there are more blog posts coming to help you with that), and the insights I gained are definitely helpful.
AOI doesn't replace SCOM: AOI just adds another level to SCOM, and all in all it's an analysis piece that is done well. Just take it easy with the Intelligence Packs and you'll be fine.
Stay tuned for follow-up posts on how to use Microsoft Azure Operational Insights to organize logs and gain insights.
