Azure Monitor Reviews

As a Microsoft MVP and MCT, I help our company's clients use Azure Monitor in different ways depending on what types of activity they want to monitor. From a big picture perspective, this entails checking and testing both the performance and efficiency of cloud-based applications.

Starting from the basics, such as when monitoring VMs, you are able to integrate Azure Monitor with the virtual machine so as to create alerts and notifications that are automatically triggered when, for example, the machine's performance rises above 60-70%.

You can also use Azure Monitor to help you understand the total internal activity, including the CPU or RAM performance, of specific applications on the cloud. And beyond that, there are many other metrics detailing which users have logged in (or are concurrently logged in) to the application or VM, while showing the ratios of their activity in total.

For me, the best feature is the log analysis with Azure Monitor's Log Analytics. Without being able to analyze the logs of all the activities that affect the performance of a machine, your monitoring effectiveness will be severely limited.

Although it's not always the case, the price can sometimes get expensive. This depends on a number of factors, such as how many services you are trying to integrate with Azure Monitor and how much storage they're consuming each month (for example, how large are the log files?).

Of course, this totally depends on the particular customer's environment. As the implementer, we can typically only advise on the technical outcomes for a certain usage scenario of Azure Monitor, and not necessarily the advantages or disadvantages of paying for Azure Monitor in their particular use case. For example, if they are paying $400 per month, the advantages for the customer might be that they reduce technical headaches in ensuring proper service performance without having to invest in a separate IT member to handle the monitoring. And for many customers, this makes good business sense, which is why when we propose the use of Azure Monitor in such a way and give them an example, they often take us up on the proposal, despite the costs involved.

I have been using Azure Monitor for five years.

Azure Monitor is definitely a stable product once we have deployed it to our target. Azure Monitor, when deployed to a VM, will give you a stable interface for taking readings on various aspects of a machine's performance, such as what's going on with the CPU, memory, and data communications.

When it comes to more advanced usage with deeper monitoring, Azure Monitor can integrate with AI to make the process of advising what to do about resolving certain problems much easier.

Azure Monitor is a key part of service integration and it is easy to scale and extend as needed. You can also integrate other services, even third-party ones, with it.

It provides options for scaling it to your own needs in various ways, such as by providing a choice of what types of logs will be generated and how many days you would like to keep the logs for. It also provides options for how many servers you would like to monitor, and whether you will be logging on an hourly, per-minute, or per-second basis.

I am largely satisfied with how the technical support from Microsoft explains their solutions to the issues that we've raised. Although, most of the time, they simply share the most current link from their blog of knowledge base that explains the specific activity that must be done to resolve a problem. This is because Microsoft engineers don't actually provide the technical work themselves, but instead act as advisors, where companies like mine will then be the implementer of the suggested solutions.

The setup for Azure Monitor itself is easy to understand and, for generating logs and such, it's a simple process of configuring how you would like to gather your logs and for how long you would like to keep those records, etc.

It won't take anyone that much time to deploy their monitoring system with Azure Monitor. This is especially true if you understand your business needs well, because you can then quickly integrate Azure Monitor (and Log Analytics or Workbooks) inside your application as appropriate. As an estimate, it could take up to three or four hours at most.

We implement Azure Monitor in-house. Our deployment plan is to first obtain the Azure identity and then make an effort to better understand the service that will be running on the Azure cloud. For example, is it IaaS or PaaS? If it is based on PaaS, then we'll go straight to the application inside the PaaS, and if it's on a VM, then we'll go to the VM (or container) instance and set up the deployment from there. Here, the deployment also depends on the specific resources or Azure subscriptions in use.

Customers of Azure Monitor must pay an amount that depends largely on how many services they need to integrate and the storage space required in terms of logs, etc. If they only have a few small services to monitor, the price won't be too high, but on the opposite side of the spectrum, it can certainly get pricey.

Fortunately, customers can use the calculator provided by Azure to easily estimate the total monthly costs based on the customer's requirements. 

Along with Azure, I also have experience with New Relic, for which I have handled both deployment and connectivity.

I can definitely recommend Azure Monitor for most people, but before recommending it to all I would caution that whether you choose to use it depends largely on the type of service that you are running on the cloud.

One must first be clear about the outcomes of the service that is to be monitored; if it is a critical service or application where you absolutely must monitor each data point or watch for incidents, then you will certainly want to use Azure Monitor.

On the other hand, some companies are running services on the cloud that are not actually critical in the grand scheme of their operations, and to these companies I would not blindly encourage using Azure Monitor. Of course, if they are interested nevertheless, then I would say, sure, they can go forward with it as long as they understand that they will have to pay Microsoft accordingly in order to get something out of Azure Monitor. 

I would rate Azure Monitor an eight out of ten.

We use Azure Monitor to log all the activity logs and the resource logs to something similar to AWS CloudWatch. It is enabled for most of the services as it goes hand in hand with application insights.

Alerts are set up using robust metrics that we are able to retrieve from Azure Monitor, allowing us to automate and look at different rules and action groups. 

Our component configuration keeps changing. Because of this, we need to put alerts on the components to figure out who changed them and what did they changed in them.

We have been using Azure Monitor quite regularly, both for internal usage and for our customers. Customers will have to use Log Analytics in combination with Azure Monitor. 

Azure Monitor is a one-stop place to look at what's happening across all the resources. It provides a bird's eye view with histograms and gauges that we can build within IT. 

The alerting feature is also very valuable. 

Azure introduces new services almost every year. Recently, they have improved their integration with other resources, so we get even more robust data.

Unfortunately, Azure Monitor stalls quite a bit. Azure Monitor can take up to 60 seconds to bring up metrics data. That length of latency is terrible and needs to be improved. The ripple effect of one wrong configuration affects multiple resources within milliseconds. Azure Monitor then reports after more than a minute that something went wrong. To improve this, Azure should create a visual representation of what the resource configuration was and compare it to what changed.

Alerts are queries to figure out what has happened. If there was a reliable infrastructure diagram available, it could tell me where the configuration changed. Azure gives you so many logs, to understand where the change happens you have to review thousands of rows of logs.

In the cloud, there are too many resources, so you end up trying to find the needle in the haystack to determine what is actually happening. 

In future releases, I would like to see Azure Monitor improve its diagram capabilities. Azure, in the last few years, has started to provide some basic diagramming where you can visualize from an Azure point of view, what is happening at the Kubernetes cluster and how the various resources are related to each other, we still need to use a lot of third-party tools.

Imagine if an Excel sheet was thrown to you with a few thousand rows, and you were asked to determine what happened, within a minute or two, before a disaster strikes. A visualization tool is required to know what the previous configuration was as compared to the current configuration.

The solution is also reactionary and not proactive or intuitive. Azure Monitor should be able to alert you that certain changes will cause certain outcomes before making the change using futuristic infrastructure diagrams.

Lastly, I would like Azure Monitor to provide a separate portal for large operations teams, as there currently is no solution for them.

I started using Azure Monitor regularly in 2015.

The stability of Azure Monitor is good. It has not been a problem. The solution does not require maintenance. When we adopt new services, we need to configure things as part of a checklist of items. This is a minor step.

I would rate the stability a five out of five. 

Being a SaaS service, Azure Monitor is scalable. 

Customer service and support for Azure Monitor is good. I rate it a five out of five for technical support.

Positive

The initial setup of Azure Monitor is easy. The deployment took a day or two because it is available by default. It is really an out-of-the-box solution.

Our DevOps side handled the implementation of Azure Monitor themselves. 

The implementation strategy was and continues to be that whatever resources we want to monitor through Azure Monitor, we enable them. 

The ROI for Azure Monitor is poor. I would rate it a two out of five.

Because we have to use Log Analytics, in combination with Azure Monitor, it is expensive. It is expensive because the logs are getting generated for store requests across all the Azure resources. This is all that needs to be stored, and both in terms of hot and cold storage. Cold storage after 30 days, but hot storage is required for the NOC and the SOC teams, the network operations, and the security operations teams.

Typically, we do try to encourage our customers to keep at least 30 days within Azure Monitor.

I would rate Azure Monitor a two out of five for affordability.

We evaluate options through our customers' requests. We have found that Azure Monitor actually monitors every resource better than New Relic, Datadog, or Splunk.

Splunk is very good for on-premise servers. However, internally, we do not hold logs for more than 30 days, so Azure Monitor works for us. 

Azure Monitor has a lengthy latency period for dashboard alerts. Sometimes we get data in New Relic and Datadog faster than with Azure Monitor.

Anyone considering implementing Azure Monitor into their organization should consider the length of retention time required for their logs and applications. If it is beyond 30 days, Azure Monitor becomes expensive. 

Overall, I would rate Azure Monitor a seven out of ten. The features included in the solution are good, however, they lack development. They are allowing their partners to come up with good offerings, but not developing the core products themselves.

We use it for proactive infrastructure monitoring. It's being used for monitoring the key metrics and availability of infrastructure.

We most probably use its latest version.

It's a Microsoft native tool, so it works well with other Microsoft technologies, which is predominantly what our customer end-user base is.

Automation is a key benefit of it as well. You can link one box to automatically resolve the issues off the back of another. There's quite a lot you can do with it.

The query builder could be better. In comparison to other monitoring tools, in order to use Azure Monitor, your engineers need to have KQL experience. If they don't, it's not intuitive as a system. They need to understand KQL and get the right queries to get the value that they want, whereas a lot of out-of-the-box solutions, such as FrameFlow and Datadog, can be given to somebody untrained, and the UI will guide them through what they need to do. You lose some customization with that, but you don't need to train people on it. It would be good if Microsoft had some form of query builder in place so that you can choose a metric and it writes the code for you. Some kind of AI elements would help with that skill gap for organizations.

Their support also needs to be improved. I've had a lot of issues with their support.

I've been using this solution for two years.

I've not had any issues with it so far. I'd rate it a ten out of ten in terms of stability.

You can scale it pretty easily. I'd rate it a nine out of ten in terms of scalability. 

We probably have about 30 people using this solution.

Their support is not great. We pay for Premier Support because we're a partner, and even that's pretty bad. I've had a lot of issues with their support. It has nothing to do with Microsoft Azure Monitor as a tool. I'd rate Microsoft's support for any of their systems at the absolute lowest number that I possibly can because it's pretty bad. The time to get engineers is an issue, and their skills and knowledge are also questionable. My team is more knowledgeable than them on some of the platform-related things.

They also make a lot of mistakes. They have brought the platform down a couple of times in recent months. There has been a whole heap of stuff. I've had quite lengthy conversations with our account manager about how poor the service is, and there isn't anything they're going to do about it because it's at the organizational level. It's not one team. It seems Microsoft is going through some struggles at the moment.

Negative

We used FrameFlow. We switched to being native. It's a Microsoft native tool.

The deployment duration depends on the use case. It depends on what you want. You don't deploy Azure Monitor itself. It's not like other tools where you have to install nodes and install the software and deploy it. It comes natively with Azure as a platform, so the implementation time is just dependent on what the client wants out of it. For our use case, we set up a template of about 15 to 20 key metrics that we monitor, which probably doesn't take longer than a day to deploy. It's all templated. We just run a bunch of CLI commands, and it deploys those templates, but if you have a customer who wants to start monitoring more intricate or complex things such as SQL databases and applications, you can probably spend months on it.

In terms of the number of people required, one person can do it if he or she has the skills for it.

I don't really measure return on investment. It's about visibility. It's about providing the service for us. If we compare the implementation versus the visibility we get, we do get a return. It doesn't take that long to deploy, but it can subsequently create a lot of visibility. So, its return on investment is probably okay.

Its cost depends on the ingestion of the logs. It could go anywhere. For an out-of-the-box platform such as FrameFlow, you pay pretty much a fixed price and you get what you get, whereas, with something like Azure Monitor, you pay by the ingestion charge, so you can have one client who pays hardly anything for the same alerts, and another client pays loads and loads. From experience, Azure itself isn't a cheap system. It's not a cheap tool at all. If you don't configure it correctly, it's really expensive. I'd rate it a nine out of ten.

I'd advise learning KQL before you think about it. If you know KQL, you can do a lot with it. If you understand KQL, then it's really powerful, and you can do a lot with it. If you don't understand it, you should probably steer away from it because you won't be able to do much. You won't get much value out of it.

I'd rate Azure Monitor a seven out of ten.

We are currently testing the Azure Monitor, yet we've not turned it on for production yet.

We were looking for a monitoring tool. We needed a few features, and then we thought that Azure Monitor might not be able to do everything for us out of the box. There might be some development work that may be involved if we have to use Azure Monitor. However, we've really not used it. We are just trying it out now.

The major thing we will use it for is to monitor applications and then resources. For the ones that are on the app services, they are straightforward; however, we're looking at monitoring applications that are running on the virtual machines, on VMs. That's not straightforward. You need to be able to use some APIs to be able to do the logs from the applications that are running on the VM and all that. 

We are in the POC phase. We're still testing things out. 

I'm not working with it directly and therefore haven't noted any outstanding features. 

I'm not working with it directly and therefore haven't noted any missing features.

The setup so far has been complicated.

It might not have all of the capabilities we will need. 

We've barely used it. We just tested it now. We are now trying to turn on our production environment for a while. We just started using it a week or two ago.

We've barely used the solution for production. It's hard to grade the stability at this point. 

I'm not working with the solution directly and can't comment on the scalability.

From what I've seen so far, for our use case, it's a bit complicated if we have to monitor directly from the virtual machine or if we need to pull logs and stuff from the virtual machine to create an API and all that. You need a developer to be able to create an API for you so that the Azure Monitor can consume or pull the logs. From the discussions I've had with the cloud engineer and what we've seen, that area is a bit complicated. That said, it's not like it can't be done.

The pricing is a bit tricky with regard to the storage and then the load. You need to be very particular about what the storage is about. You need to consider the size of storage you need and then the load that you be pushing as well. If you look at the fact sheet, then it is expensive. However, you can't go with the fact sheet since the fact sheet doesn't factor in the environment to determine the cost estimation.

It could be cheap, or it could be expensive, depending on how you deploy or configure it.

We've also looked at SolarWinds. We are looking at ManageEngine, and we're also looking at Foglight Evolve. These are some of the solutions that we are looking at for monitoring.

I'm not sure which version of the solution we're using. We usually just turn it on. 

The upside to the solution is if you are working in a Microsoft or Azure environment, it makes things easier. It's like a Mercedes mechanic working on a Mercedes car as opposed to a Toyota. If you are within the Azure umbrella, it's easier. However, it depends on the company and what it wants to achieve.

I'd rate it six out of ten. 

We use Azure Monitor as our alert system. We also use it for other types of measurement.

Currently, we use Power BI for our data visualization, and Azure Monitor is a very good fit with those cases. Another thing I like about the solution is that we can easily export the data, and the tool seamlessly works together with Datadog, though in terms of visualization in Azure Monitor, it's not as beautiful. It also doesn't have as many features as Power Bi, and this is why we were comparing it with Datadog.

We use Power BI because it has many features, so that's the main part we consider when selecting which tool to use. As for Datadog, people think of it as an application performance monitoring tool, rather than a data exporting tool, so they will still use Azure Monitor for exporting data. In some cases when the data analyst team needs some type of data, we can set that up for them on Azure Monitor, then consider using Datadog as a platform monitor.

Visualization in Azure Monitor needs improvement. Adding more features to it would also make the solution better.

My experience with Azure Monitor is six months.

Azure Monitor is a stable tool.

Azure Monitor is scalable, but the only downside to it is that it's not an out-of-the-box (OOTB) solution, so we cannot scale it to something outside of Azure ServiceNow. Currently, we use ServiceNow as a ticketing system, then use Datadog as the incident and alert system to trigger a ticket in ServiceNow, which we cannot do in Azure Monitor.

Azure Monitor is a low-priced solution.

We evaluated Datadog.

I was comparing Datadog and Azure Monitor. We had a POC for Datadog and we were trying to test it with the trial account for our current data solution in Azure, so we tried to measure the differences between the two solutions.

Now we use Azure Monitor for our alerts and other measurements, but not as an application performance monitoring tool, so we're considering Datadog for that purpose. They made the final decision to use Datadog for application performance monitoring.

We are not in the setup phase for Azure Monitor yet, because we're still doing a POC for visibility, so we still have no idea on whether it'll be complex or straightforward to set up the tool.

As we are very small, we have not had the chance to contact tech support for this solution, plus we have a dedicated team from Microsoft who handles our questions and issues. Currently, we don't have an issue on Azure Monitor, but have raised issues about other Microsoft solutions, and the Microsoft dedicated team have been very supportive.

My advice to others looking into implementing Azure Monitor is that if they're working on small-scale projects and their projects fit Azure, then Azure Monitor will be the best solution for them, particularly because it is low-priced. The tool is also good when building a solution, e.g. they won't need to explore outside of it, but if they're building a multi-cloud solution, and they have a mix of on-premises and cloud, my suggestion is for them to use Datadog.

I will rate Azure Monitor a seven out of ten, because this solution has two things that we don't like, e.g. it doesn't tell you what and how it happened. It just says: "Hey, that happened", and "Go and check it". This is the reason why I don't recommend Azure Monitor, e.g. it's not a very informative tool, so we don't use it for our root cause investigation.

We use the solution for only production monitoring mainly, however, we are trying to engage it with the quality flows for moving the code between platforms from dev to test environments, et cetera. We'll implement this procedure afterward.

The detailed logging is great. Detailed logging is the most impressive part. Also, we are observing our cost on the live environment. We know what kind of budget is required. 

Also, we are getting all the problematic area details, so we can arrange ourselves according to the application development part. 

The alert parts are great. It's crucial for our site, just getting the alerts on time.

It's easy to set up.

It is a robust, stable product.

The solution scales well. 

We are sometimes confused about the details. We would like to have a flow in terms of how a new application should engage with Azure Monitor. We must understand: what is the most crucial part of our monitoring or support? We are not very good at it yet. 

Currently, it seems it's complicated to get the correct information in terms of what to do and how things work. Maybe it would help if they offered some guidance or written guides. For example, we say that project manager should follow their quality issues before putting the application into production. It's so complicated from their side for the project managers. Some kind of simplification is required for people engaged in the platform. 

Still, it's very new, and we will be gaining experience, and we may see much more substantial things in the future as we uncover more capabilities.

We've newly engaged with the product. We've only used it for a few months at this point. 

The solution is very stable. It's robust. The performance is excellent. There are no bugs or glitches and it doesn't crash or freeze. The reliability is high. 

We'll continue with Azure Monitor.

It is a scalable solution. It's not a problem if you need to expand it. It reaches about 200 users right now. 

We do have access support and get it when we need it. We are satisfied. They are okay. 

We've also used New Relic. We moved away due to the cost. 

The solution is straightforward and very simple. It's not complex at all. We're effortlessly engaging with it. We implemented ten applications in one week.

Only two people are needed for deployment and maintenance. They are admins. 

We did not need to get the help of consultants or integrators. We handled the setup ourselves in-house. 

The licenses require a subscription based on the log file sizing.

The pricing is better than, for example, New Relic. New Relic was too costly for us. 

Based on what we see right now, I'd rate the solution eight out of ten. Maybe, as we use it more, we will rate it higher in the future. Currently, we are very new to using this product. 

Azure Monitor can be used to monitor on-prem servers. You can install the agent on a server on-premise and you can pull out whatever telemetry you want. Additionally, you can install it on servers that are on the public cloud. It's similar to hybrid solutions. However, it depends on the use case. If there's a server on-premise, you deploy the server in AWS or GCP. If the server is on Azure itself, then it plugs directly in which is a hybrid setup.

Azure Monitor can be used if you are trying to look for how all the applications are tied together, such as application mapping. It helps to know what ports are open, what services are running on certain servers as one. 

We are able to monitor CPU utilization for specific servers to determine if they are running specific types of workloads or high resource utilization type workloads. We use Azure Monitor to be able to see if the server gets to a certain threshold, such as 70 percent CPU utilization, then send an alert to the operation center or reliability center to go look at it. They could then expand or increase the CPU resource there to fix the issue. The tool is used for monitoring purposes.

Azure Monitor has helped our organization to have insights into issues and informs us before an issue becomes a very critical stage. It provides us a baseline on how to prevent serious issues in the future. You don't want it to get to 90 percent usage, if you catch it at 70 percent, it helps preserve the lifespan of that sever or allow your services to keep running efficiently or effectively. It keeps the availability of whatever service that you're running on that server, is in check. This is one of the most important parts of the service.

Azure Monitor is useful because of the useful application insights and telemetry, such as metrics and logs.

Azure Monitor could improve the visualization aspect and integrate better with other third-party services.

I have been using Azure Monitor for approximately four years.

Azure Monitor is a stable solution.

The scalability of Azure Monitor is very good because it is on a public platform.

We have approximately 500 users using this solution. We are extensively using Azure Monitor and we are always adding to it.

The support we have received from Microsoft has been good. Depending on the issue you might be facing, they could respond within less than 24 hours during business hours.

The initial setup of Azure Monitor is straightforward. The process took us approximately one hour.

We did the implementation of Azure Monitor in-house.

The price of the solution is reasonable. 

I have evaluated Datadog before choosing Azure Monitor.

I rate Azure Monitor an eight out of ten.

Our company is a service integrator and we use the solution to monitor logs, metrics, and applications for customers. We have 200 users throughout our company. 

The tools for logs and metrics are pretty good and easy to use. We can do metric monitoring, log monitoring, and prepare queries to monitor something based on  customers' requirements.  

The Kusto query language is powerful and similar to SPL. We can do a lot of things with the language. 

The solution is very easy to use and maintain. 

Alerts cannot be configured to monitor at a certain point in time. For example, we might want to alert people at zero hours but that is not possible. Splunk can accomplish this and its alerts are far better than the solution's options. The alerting mechanism is not up to the market. 

The default interface should be improved. You can prepare your own dashboard by using custom query language, but the default interface is not good. 

I have been using the solution for almost three years. 

The solution is very stable. 

The solution is scalable. 

Technical support is good and very helpful. 

Support does have some limitations or challenges because they can only help with things they know. For example, we contacted them about an alert issue because we could not log off the solution's Event Hub component. Unfortunately, they were not able to help. 

Overall, support is very helpful and provides an immediate response. When they cannot help, it is a product issue. 

I have experience with Splunk, AppDynamics, BMC Proactive Document Management, Microsoft ACCM, New Relic, and Grafana. 

The setup was challenging initially because we were not familiar with the solution. Now that we have experience, everything is easy. 

We implemented the solution in-house.

Ongoing maintenance is performed by three members of our team. 

The solution is very costly because you have to pay for various things such as adding to logs and internet alerts. 

Logging costs are very high so should be lowered. Companies who log one TB or more will have very high costs. We should be able to log in a storage account to save costs.

Splunk is also very costly. 

The best solution depends on use cases.

AppDynamics or New Relic are the best products for application performance management.

Splunk is the best for logging and the solution is the second best. 

If you have a Microsoft environment, then you should use the solution as much as possible.

Azure Metrics is free and covers a lot of features. You can set it up and use it for monitoring.

You can definitely use the solution for logging but be aware that there are costs. 

I rate the solution a seven out of ten.