Our initial use case is to use Devo as a SIEM. We're using it for security and event logging, aggregation and correlation for security incidents, triage and response. That's our goal out of the gate.
Their solution is cloud-based and we're deploying some relays on-premise to handle anything that can't send it up there directly. But it's pretty straightforward. We're in a hybrid ecosystem, meaning we're running in both public and private cloud.
We're very early in the process so it's hard to say what the improvements are. The main reason that we bought this tool is that we were a conglomeration of several different companies. We were the original Qualcomm company way back in the day. After they made billions in IP and wireless, they spun us off to Vista Equity, and we rapidly and in succession bought three or four companies in the 2014/2015 timeframe. Since then, we've acquired three or four more. Unfortunately, we haven't done a very good job of integrating those companies, from a security and business services standpoint.
This tool is going to be our global SIEM and log-aggregation and management solution. We're going to be able to really shore up our visibility across all of our business areas, across international boundaries. We have businesses in Canada and Mexico, so our entire North American operations should benefit from this. We should have a global view into what's going on in our infrastructure for the first time ever.
The solution is enabling us to bring all our data sources into a central hub. That's the goal. If we can have all of our data sources in one hub and are then able to pull them back and analyze that data as fast as possible, and then archive it, that will be helpful. We have a lot of regulatory and compliance requirements as well, because we do business in the EU. Obviously, data privacy is a big concern and this is really going to help us out from that standpoint.
We have a varied array of threat vectors in our environment. We OEM and provide a SaaS service that runs on people's mobiles, plus we provide an in-cab mobile in truck fleets and tractor trailers that are both short- and long-haul. That means our threat surface is quite large, not only from the web services and web-native applications that we expose to our customers, but also from our in-cab and mobile application products that we sell. Being able to pull all that information into one central location is going to be huge for us. Securing that type of landscape is challenging because we have a lot of different moving parts. But it will at least give us some insight into where we need to focus our efforts and get the most bang for the buck.
We've found some insights fairly early in the process but I don't think we've gotten to the point where we can determine that our mean time to resolution has improved. We do expect it to help to reduce our MTTR, absolutely, especially for security incidents. It's critical to be able to find a threat and do something about it sooner. Devo's relationship with Palo Alto is very interesting in that regard because there's a possibility that we will be pushing this as a direct integration with our Layer 4 through Layer 7 security infrastructure, to be able to push real-time actions. Once we get the baseline stuff done, we'll start to evolve our maturity and our capabilities on the platform and use a lot more of the advanced features of Devo. We'll get it hooked up across all of our infrastructure in a more significant way so that we can use the platform to not only help us see what's going on, but to do something about it.
So far, the most valuable features are the ease of use and the ease of deployment. We're very early in the process. They've got some nice ways to customize the tool and some nice, out-of-the-box dashboards that are helpful and provide insight, particularly related to security operations.
The UI is
They've put a lot of work into the UI. There are a few areas they could probably improve, but they've done a really good job of making it easy to use. For us to get engagement from our engineering teams, it needs to be an easy tool to use and I think they've gone a long way to doing that.
The real-time analytics of security-related data are super. There are a lot of data feeds going into it and it's very quick at pulling up and correlating the data and showing you what's going on in your infrastructure. It's fast. The way that their architecture and technology works, they've really focused on the speed of query results and making sure that we can do what we need to do quickly. Devo is pulling back information in a fast fashion, based on real-time events.
The fact that the real-time analytics are immediately available for query after ingest is super-critical in what we do. We're a transportation management company and we provide a SaaS. We need to be able to analyze logs and understand what's going on in our ecosystem in a very close to real-time way, if not in real time, because we're considered critical infrastructure. And that's not only from a security standpoint, but even from an engineering standpoint. There are things going on in our vehicles, inside of our trucks, and inside of our platform. We need to understand what's going on, very quickly, and to respond to it very rapidly.
Also, the integration of threat intelligence data provides context to an investigation. We've got a lot of data feeds that come in and Devo has its own. They have a partnership with Palo Alto, which is our primary security provider. All of that threat information and intel is very good. We know it's very good. We have a lot of confidence that that information is going to be timely and it's going to be relevant. We're very confident that the threat and intel pieces are right on the money. And it's definitely providing insights. We've already used it to shore up a couple of things in our ecosystem, just based on the proof of concept.
The solution’s multi-tenant, cloud-native architecture doesn't really affect our operations, but it gives us a lot of options for splitting things up by business area or different functional groups, as needed. It's pretty simple and straightforward to do so. You can implement those types of things after the fact. It doesn't really impact us too much. We're trying to do everything inside of one tenant, and we don't expose anything to our customers.
We haven't used the solution's Activeboards too much yet. We're in the process of building some of those out. We'll be building dashboards and customized dashboards and Activeboards based on what those tools are doing in Splunk. Devo's going to help us out with our ProServe to make sure that we do that right, and do it quickly.
Based on what I've seen, its Activeboards align nicely with what we need to see. The visual analytics are nice. There's a lot of customization that you can do inside the tool. It really gives you a clean view of what's going on from both interfaces and topology standpoints. We were able to get network topology on some log events, right out of the gate. The visualization and analytics are insightful, to say the least, and they're accurate, which is really good. It's not only the visualization, but it's also the ability to use the API to pull information out. We do a lot of customization in our backend operations and service management platforms, and being able to pull those logs back in and do something with them quickly is also very beneficial.
The customization helps because you can map it into your business requirements. Everybody's business requirements are different when it comes to security and the risks they're willing to take and what they need to do as a result. From a security analyst standpoint, Devo's workflow allows you to customize, in a granular way, what is relevant for your business. Once you get to that point where you've customized it to what you really need to see, that's where there's a lot of value-add for our analysts and our manager of security.
Devo has a lot of cloud connectors, but they need to do a little bit of work there. They've got good integrations with the public cloud, but there are a lot of cloud SaaS systems that they still need to work with on integrations, such as Salesforce and other SaaS providers where we need to get access logs.
We'll find more areas for improvement, I'm sure, as we move forward. But we've got a tight relationship with them. I'm sure we can get anything worked out.
This is our first foray with Devo. We started looking at the product this year and we're launching an effort to replace our other technology. We've been using Devo for one month.
The stability is good. It hasn't been down yet.
The scalability is unlimited, as far as I can tell. It's just a matter of how much money you have in your back pocket that you're willing to spend. The cost is based on log ingestion rate and how much retention. They're running in public cloud meaning it's unlimited capacity. And scaling is instantaneous.
Right now, we've got about 22 people in the platform. It will end up being anywhere between 200 and 400 when we're done, including software engineers, systems engineers, security engineers, and network operations teams for all of our mobile and telecommunications platforms. We'll have a wide variety of roles that are already defined. And on a limited basis, our customer support teams can go in and see what's going on.
Their technical support has been good. We haven't had to use their operations support too much. We have a dedicated team that's working with us. But they've been excellent. We haven't had any issues with them. They've been very quick and responsive and they know their platform.
We were using Splunk but we're phasing it out due to cost.
Our old Splunk rep went to Devo and he gave me a shout and asked me if I was looking to make a change, because he knew of some of the problems that we were having. That's how we got hooked up with Devo. It needed to have a Splunk-like feel, because I didn't want to have a long road or a huge cultural transformation and shock for our engineering teams and our security teams that use Splunk today.
We liked the PoC. Everything it did was super-simple to use and was very cost-effective. That's really why we went down this path.
Once we got through the PoC and once we got people to take a look at it and give us a thumbs-up on what they'd seen, we moved ahead. From a price standpoint, it made a lot of sense and it does everything we needed to do, as far as we can tell.
We were pulling in all of our firewall logs, throughout the entire company, in less than 60 minutes. We deployed some relay instances out there and it took us longer to go through the bureaucracy and the workflow of getting those instances deployed than it did to actually configure the platform to pull the relevant logs.
In the PoC we had a strategy. We had a set of infrastructure that we were focusing on, infrastructure that we really needed to make sure was going to integrate and that its logs could be pulled effectively into Devo. We hit all of those use cases in the PoC.
We did the PoC with three people internally: a network engineer, a systems engineer, and a security engineer.
Our strategy going forward is getting our core infrastructure in there first—our network, compute, and storage stuff. That is critical. Our network layer for security is critical. Our edge security, our identity and access stuff, including our Active Directory and our directory services—those critical, core security and foundational infrastructure areas—are what we're focusing on first.
We've got quite a few servers for a small to mid-sized company. We're trying to automate the deployment process to hit our Linux and Windows platforms as much as possible. It's relatively straightforward. There is no Linux agent so it's essentially a configuration change in all of our Linux platforms. We're going through that process right now across all our servers. It's a lift because of the sheer volume.
As for maintenance of the Devo platform we literally don't require anybody to do that.
We have a huge plan. We're in the process of spinning up all of our training and trying to get our folks trained as a day-zero priority. Then, as we pull infrastructure in, I want those guys to be trained. Training is a key thing we're working on right now. We're building the e-learning regimen. And Devo provides live, multi-day workshops for our teams. We go in and focus the agenda on what they need to see. Our focus will be on moving dashboards from Splunk and the critical things that we do on a day-to-day basis.
We worked straight with Devo on pretty much everything. We have a third-party VAR that may provide some value here, but we're working straight with Devo.
We expect to see ROI from security intelligence and network layer security analysis. Probably the biggest thing will be turning off things that are talking out there that don't need to be talking. We found three of those types of things early in the process, things that were turned on that didn't need to be turned on. That's going to help us rationalize and modify our services to make sure that things are shut down and turned off the way they're supposed to be, and effectively hardened.
And the cost savings over Splunk is about 50 percent.
Pricing is pretty straightforward. It's based on daily log ingestion and retention rate. They keep it simple. They have breakpoints, depending on what your volume is. But I like that they keep it simple and easy to understand.
There were no costs in addition to their standard licensing fees. I don't know if they're still doing this, but we got in early enough that all of the various modules were part of our entitlement. I think they're in the process changing that model a little bit so you can pick your modules. They're going to split it up and charge by the module. But everything was part of the package that we needed, day-one.
We were looking at ELK Stack and Datadog. Datadog has a security option, but it wasn't doing what we needed it to do. It wasn't hitting a couple of the use cases that we have Splunk doing, from a logging and reporting standpoint. We also looked at Logstash, some of the "roll-your-own" stuff. But when you do the comparison for our use case, having a cloud SaaS that's managed by somebody else, where we're just pushing up our logs, something that we can use and customize, made the most sense for us.
And from a capability standpoint, Devo was the one that most aligned with our Splunk solution.
Take a look at it. They're really going after Splunk hard. Splunk has a very diverse deployment base, but Splunk really missed the mark with its licensing model, especially when it relates to the cloud. There are options out there, effective alternatives to Splunk and some of the other big tools. But from a SaaS standpoint, if not best-in-breed, Devo is certainly in the top-two or top-three. It's definitely a strong up-and-comer. Devo is already taking market share away from Splunk and I think that's going to continue over the next 24 to 36 months.
Devo's speed when querying across our data is very good. We haven't fully loaded it yet. We'll see when the rubber really hits the road. But based on the demos and the things that we've seen in Devo, I think it's going to be extremely good. The architecture and the way that they built it are for speed, but it's also built for security. Between our DevOps, our SecOps, and our traditional operations, we'll be able to quickly use the tool, provide valuable insights into what we're doing, and bring our teams up to speed very quickly on how to use it and how to get value out of it quickly.
The fact that it manages 400 days of hot data falls a little bit outside of our use case. It's great to have 400 days of hot data, from security, compliance, and regulatory retention standpoints. It makes it really fast to rehydrate logs and go back and get trends from way back in the day and do some long-term trend analysis. Our use case is a little bit different. We just need to keep 90 days hot and we'll be archiving the rest of that information to object-based long-term storage, based on our retention policies. We may or may not need to rehydrate and reanalyze those, depending on what's going on in our ecosystem. Having the ability to be able to reach back and pull logs out of long-term storage is very beneficial, not only from a cost standpoint, but from the standpoint of being able to do some deeper analysis on trends and reach back into different log events if we have an incident where we need to do so.
We are in four public clouds. We are in AWS, Azure, and GCP. While we do Oracle cloud, we only have a small footprint there. We are monitoring all the virtual server environments as well as all the services in those environments and alerting on various set points depending on what it is: virtual, server and service.
We are also monitoring our colos. We have on-prem hardware, networking, and server solutions that we are monitoring with LogicMonitor. We are in both the cloud and on-prem. The breadth of cloud and on-prem that we have is a good use case for LogicMonitor
We have very fine-tuned alerting that lets us know when there are issues by identifying where exactly that issue is, so we can troubleshoot and resolve them quickly. This is hopefully before the customer even notices. Then, it gives us some insight into potential issues coming down the road through our environmental health dashboards.
The breadth of its ability to monitor all our environments, putting it in one place, has been helpful. This way, we don't have to manage multiple tools and try to juggle multiple balls to keep our environment monitored. It presents a clear picture to us of what is going on.
When I first started, it was less granular in terms of the fine tuning and the ability to tune out specific servers running high CPU. Keeping a global general standard has really helped. We now modify the environment where we need to alert and ignore those areas where we're not as concerned. This has helped our company in ways that maybe management doesn't even realize, e.g., we're not waking up our engineers in the middle of the night. Therefore, there is more job satisfaction in being able to get a good night's sleep. For example, we had one team that was being alerted every couple hours, which was ridiculous when you're on call and need to sleep. This was one of my first prime objectives when I started: To improve the quality of life, so we don't have as much turnover in our engineering support staff.
At the top of the list of most valuable features is the ability to modify and add data sources, to use other people's data sources, and the LM Exchange itself. It gives LogicMonitor a lot of flexibility. It gives the end user the ability to monitor just about anything that can connect to a network and send data, which is a nice. You can take the data sources for what you are trying to do, then modify and adjust them to what your new parameters are or your use cases. With a lot of other applications, you either don't have the option at all (because you have to use what they have out-of-the-box) or it takes a lot of work to be able to enable monitoring something new. That is the best thing about being an administrator of LogicMonitor.
I have written my own data sources in a number of cases. We have also leveraged existing data sources and modified them to fit our specific cases. We don't typically publish them, but I know with the LM Exchange that it's becoming easier to do that.
I know management very much likes the dashboard presentations that LogicMonitor has. They are very comprehensive. You can pull in other things and add them in as a widget. You can see more than just what is in LogicMonitor, as it gives a single pane of glass for whatever management is interested in or whatever environment they're looking at when they are the monitoring software metrics. Then, it is presented all in one location, which is really nice.
We have SLAs for uptime, all our hardware, and all our infrastructure: hardware, servers, and storage. I have spun up a number of services based on the specific metrics for all those devices, then determine SLAs based on the uptime of those metrics. We have a nice SLA dashboard that shows the uptime of all of our environments, so when my manager or his manager comes to me, and asks, "What was the uptime of our environments or this area in storage?" Then, I can quickly look at the dashboard and tell him. Therefore, I really like that feature.
Another dashboard that we find valuable is environmental health. We have a number of dashboards for all of our products. We have product teams for whom we created dashboards to look at the product, not just see what's happening now or in the past, e.g., what is currently having an issue. We also use it for forecasting, where we potentially might see an issue with storage on this server with a CPU that generally runs high or if there is an increasing trend in network traffic on the pipe. The environmental health dashboards have helped us stay ahead of potential issues that were coming down and ensure we had uptime for our customers' environments.
LogicMonitor has the flexibility to enhance networking gear as well as handle our unique environment: servers, hardware, cloud, and Kubernetes. There are a lot of features that we like about LogicMonitor.
I would rate it a nine out of 10 in terms of alerting. It is doing everything that we wanted it to do. We did a lot of tweaking in the last year and a half. In the last two years, since I have gotten really familiar with the product, I have been able to mesh with the teams to learn what we need to alert on. Previous to my arrival, we were sending a lot of alerts to teams, waking them up in the middle of the night. We have cleaned up a bit of their garbage so we are pretty clean in terms of what we're alerting on. It is doing a good job of letting us know when there is a problem in the environment, which is nice.
I have struggled a bit with the SLA calculations though, because I have some issues with the reporting having no data. However, I have worked around those issues and we have a solid process for reporting the SLA.
Automated remediation of issues has room for improvement. I don't know how best to handle it, but I know that they're kind of working on it. I know there are some resources that can do automated remediation. I would like them to improve this area so it could be completely hands-free, where it detects an issue, such as, if a CPU is running high. There are ways to do it even now, but it's a bit more involved. Also, for a LogicMonitor program, it really depends upon the hardware and environment that it is running on to make that call.
In terms of when it alerts, there are times when we do get alert storms because one device kind of fails on an interface where there are a number of things. Even if only one out of the five things on the interface fails, then everything on the interface will alert.
I would like it to able to create network maps and connectivity structures so you don't have to manually do it. This piece hasn't been a big hitch for us, but I imagine there are other customers who would really like to see the mapping piece of it grow and become a little bit more automated.
I personally have been using it for almost three years. The company has been using it for six years.
The stability is very good. There are times when we get specific alerts based on if there are issues with this piece or that, but those generally haven't affected us.
It can handle scaling. It is like any other cloud service. There is a cost associated with scaling, so we currently don't monitor all of our environments. We monitor just the customer-facing production environments. It would be nice if we could monitor our dominant environments, but we will have to pay a lot more due to the scaling issue. So, there's a balance there between what we would like and what we are willing to pay for.
We have had issues in the past with data collection. Maybe it is due to pushing the limits of what LogicMonitor can do, or even the devices its monitoring. For example, we have a couple of F5s that are heavily used with a number of data sources on them and the SNMP couldn't actually pull all the information back in time, which was causing blind spots.
We have probably close to 100 users who use LogicMonitor, not all of them on a regular basis:
There are heavier and lighter users in all those areas. We have primary admins who administer LogicMonitor, and we're the heaviest users of it.
Their technical support is very good. When we have an issue, they are usually knowledgeable enough to handle it. If not, they at least know what the issue is. It seems like they're sitting right next to a DevOps software engineer because it doesn't take them long to escalate to the developers. They are very good at getting back to us. I would give them 10 out of 10 in terms of their response.
LogicMonitor has become our standard for all the products. Each product is basically an acquisition, e.g., we got rid of Datadog recently and phased out Splunk. The other solutions all came with their own tools, and we have gotten rid of all those other tools. A lot of that happened before I joined.
I was not involved in the initial setup.
I was at the company for enabling the cloud and Kubernetes, which was a fair amount of work to pull that information in and reconfigure the cloud devices. We had them monitored as regular resources, but needed to migrate them over to monitoring them as cloud devices. It was a fair amount of work with no good way to automate it.
We haven't had as big a cost for downtime, so that has saved us a lot of money.
I am on a call every Monday where we evaluate all the alerting that has been done in the previous week. We have gone from constant complaints two years ago down to basically nothing.
When we spin up new servers and network devices, we have NetScans that are going on in LogicMonitor. It's a weekly scan on each subnet. If it detects a new device, then it will look it up in the DNS. From there, we have everything named appropriately, such that they are named in a way where LogicMonitor can, using property sources, figure out who the device belongs to and what the device does. This is in addition to it doing a standard SNMP network monitoring for the device to determine what it is. It uses that information, along with the name and property sources, to automatically assign where that device goes in our resource tree, then starts holding that device. That has been a lot of work, but it has been very fruitful in terms of being able to be hands-free and hands-off for bringing new devices into LogicMonitor. This saves us about five man-hours a week.
When we were evaluating software packages (and we were already using LogicMonitor at that point), LogicMonitor became one of the few solutions that ended up on our short list because it can handle cloud and on-prem. They are really good at both. Solutions, like Datadog, don't give you the option to monitor on-prem hardware. They assume that you are just in the cloud because why would anyone be on-prem when there is cloud available, then you can spend a lot of money in the cloud.
We have used dynamics thresholds in only a couple of cases. We didn't necessarily see the application of dynamics thresholds in looking at critical alerts. So, we haven't used that a whole lot. Also, we haven't really leveraged the AI pieces of LogicMonitor. We are at a point with our tuning that we haven't needed to do so. If teams started complaining about specific alerts, like specific servers showing trends, increasing or decreasing, then we would probably do it, but we have been able to handle those concerns with static thresholds at this point.
I would rate the solution a nine out of 10.
The main benefit of NetApp Cloud Insights is that it's agentless. It just collects information from the SNMP protocol.
We had NetApp ONTAP installed and we paired with VMware. The biggest challenge for any company is to find the bottleneck on the Edge of the technologies, like between VMware and NetApp. Both products have great reporting and monitoring tools, but whenever it comes to finding issues on the Edge between those products, you can hardly identify whether it's a storage issue or whether it's a virtualization issue. NetApp Cloud Insights greatly blends the performance data, approximates, links together the performance usage from the VMware and NetApp perspectives, and provides you a single pane of glass in terms of the reporting and monitoring through the virtual machine to the hardware storage.
You can find any major bottlenecks or any issue points you need to work on. In any IT infrastructure, whenever you improve, like if you buy faster storage, then you move bottlenecks from storage to the network or to the servers. The biggest challenge is to find where that bottleneck is to resolve the issue. I personally found NetApp Cloud Insights very useful in this sense because we were a heavily virtualized environment.
We were a heavily virtualized environment with the NFS Protocol, as our storage main Storage Protocol, we were able to easily nail, locate, and resolve some performance issues using Cloud Insights, which would have been very hard to identify.
The biggest challenge though is the licensing model for Cloud Insights. For example, for our environment, the price of purchasing was close to the price of the storage itself, which is why we didn't actually pursue using Cloud Insights further.
Cloud Insights has helped us to optimize Cloud spend by removing inefficiencies and identifying abandoned resources in VMware. There were a bunch of older virtual machines that were powered off and they were just left there, forgotten to be decommissioned. That was costing us premium storage space.
The visibility and usage optimization are the most valuable features. I liked the product very much. Its dashboards and the alerting systems are very easy to implement in any environment.
Its ability to quickly inventory our resources, figure out interdependencies across them, and assemble a topology of your environment is brilliant. There is a price associated with it. Whenever you target a NetApp environment, it is included in the price but whenever you want to add different vendors, like VMware and Cisco, the price greatly spikes. Inventorization helps us a lot to visualize the environment.
It's priceless when you work with eight different vendors, in a multi-vendor environment and Cloud Insights can actually identify those links between VMware and physical servers and storage, and that helps to troubleshoot and solve issues right there. It helps to proactively make decisions.
Their advanced analytics for pinpointing problem areas are great. If you're using separate tools, for example, vRealize Ops manager and Unified Manager from vRealize from VMware and Unified Manager from ONTAP, you can find some anomalies in both of them, but you can never link them together in one logical structure. Unified Cloud Insights, however, really goes through and links them together. For example, if you have a contention, like virtual CMTS contention, it doesn't mean that your storage has issues. It also can mean that there is a network problem below or some faulty network adapter network port, or even a physical server. In this sense, Cloud Insights is very valuable. It enables you to find out multi-tiered issues.
Advanced Analytics also helped to reduce the time it takes to find performance issues. It just reduces the time to find issues. And it can predict issues which otherwise, would take hours or days to find.
Their pricing model needs improvement.
We were testing Cloud Insights for a period of around five months. I installed it, configured it, and just didn't touch it for the first two months because I was busy. For the next three months, we actually used it to troubleshoot some issues and to gather more information on the performance of the environment. We found it very useful and helpful.
We have to install the collectors in your environment and then collectors send information into the NetApp private cloud.
It is a greatly stable environment. I didn't have any issues during my assessment time.
Scalability is also great. You just add notes and it works.
I only showed it to two or three people. The number of users doesn't impact the performance of Cloud Insights. It's more about how many connected devices there are.
We had a six node cluster and maybe around a thousand VMs.
We didn't use a solution like Cloud Insights before. We were just given a license with instructions and we extended the license three or four times. NetApp reached out to us and pitched the idea of how great Cloud Insights is. We liked that it offered the opportunity to work with a multi-vendor environment.
The free trial of Cloud Insights helped inform our buying decision. We found value in Cloud Insights.
We also use Datadog but it doesn't have the same functionalities as Cloud Insights.
The initial setup is straightforward. You just spin-up the collector. I think one per vendor, one for NetApp, one for VMware, and then link them to Cloud Insights in the private Cloud. That's it.
You can spin-up the environment within an hour for the entire thing. You have the collectible information after the next hour, you will have your environment on a dashboard in Cloud Insights.
The price that came back to us was so ridiculous that we didn't end up implementing it.
The biggest lesson I have learned is that basic licensing that is free, is useless. That is the biggest lesson. The basic free Cloud Insights does everything, but only with NetApp products, and this information alone doesn't add value to our troubleshooting.
I would rate NetApp Cloud Insights a nine out of ten. I really liked the product. I would have bought it if it wasn't for the cost. I had a perfect business case for it but it didn't work out.
We use New Relic APM to monitor our public cloud-hosted application and infrastructure.
Not so far. Although, we haven't really got a very mature system of defining our application processes from end-to-end and certainly not our client-centric impact.
I'm reasonably satisfied. We haven't run the rule over it too much because it hasn't been a massive investment.
It has been quite valuable to demonstrate how we can change our views for our services due to their service. It has proved value so far.
We don't have any problems with this solution.
The configuration isn't terrible when compared with other products.
It does everything we wanted it to do. We haven't been too critical in our thinking about where it can improve.
There really is nothing that stands out with New Relic. With the insight, I think it will be found lacking for its report aggregation capabilities. How granular I could go down at looking at certain data, especially related to the operations, is limited.
The API integrations that they have for us to automate our configuration was fine, but I think for some of these tools, it was over-engineering for us to try and automate any of that. So, we just use the user interfaces.
I have been using New Relic APM for approximately two months.
We are using the latest version.
It's a stable solution. We have not encountered any issues. We're not plugging too much traffic into it. We're not reporting on it heavily. It's not feeding into our service management processes heavily. So we haven't seen anything.
We have not yet explored the scalability, it's too early for us.
There are approximately 15 of us using it altogether. We are called infrastructure engineers, who are third line infrastructure support and architecture people.
Some of the lead developers have access, but there are 15 of us and we are all pretty similar.
We have not contacted technical support.
We have two custom in-house processes that do our application data flow monitoring. We have manually and in a custom nature, built out a performance monitoring platform in Splunk using our knowledge of the system over the years.
I have used App Dynamics in the past with another company. There really is nothing that stands out with New Relic. It is similar to AppDynamics and Dynatrace.
The initial setup was straightforward.
I don't think any of these tools are tools that anyone can pick up and install.
I wouldn't say it was any more difficult to configure than some of the other solutions. It is definitely not more difficult to configure than AppDynamics.
The price was one of the reasons we chose this solution. It's reasonably priced. It's cheaper than the likes of AppDynamics and Dynatrace, based on how our subscription is.
We looked at Datadog initially and found the initial setup to be far more complex than what we found in New Relic.
Our proof of concept has been successful.
Getting an order in and reporting is an industry in itself, don't think it can solve the problems it's not trying to solve. It is an application performance monitoring tool. Don't try and make it anything else.
The big problem with Splunk for us is that it can do everything. The thing that's nice about New Relic is it doesn't try and do everything, it does what it does. So far, it does it to satisfaction, but don't try and fill multiple holes in your toolchain with it. It's good at what it does.
We had some pretty informed opinions on what it was going to do. We knew where it wanted us to get, and so far it has cost the amount we wanted it to cost and done everything that we wanted it to do.
I would rate New Relic APM a ten out of ten.
We use the solution in server monitoring, application monitoring, and roam and synthetic monitoring. We have 1,000 Dynatrace users in our organization.
The solution can be deployed quickly on-prem. Once it's deployed, you can use discovery and review the process and service on this application.
Dynatrace would be closer to a perfect tool if it could bring an interface similar to a standard for metrics like Prometheus and Grafana, New Relic, and Datadog, and the way they present these panels. It would help if Dynatrace allowed more features that work with metrics like Grafana or New Relic because the data is there in Dynatrace. Dynatrace collects all the information but some companies consider integrating, for instance, Dynatrace metrics with Grafana.
I've been using this solution for more than one year. It's a SaaS solution, and it's deployed on a private cloud.
Support is okay but could be better and faster. The documentation for the tool could be better. The documentation with Elastic and Datadog is more detailed.
Initial setup is simple but it depends. In the server monitoring, it's only install and discovery. That is very quick. To install with a cloud like OpenShift, it requires some Sandcastle configuration about tokens and operators, but with old data, it's fast.
Two people were required for deployment.
I have a little experience with Datadog, but it doesn't have the power to discover with some libraries like Dynatrace. With Dynatrace, you can discover all libraries and technologies that exist on the market today. With Datadog, that's not 100% the case. Datadog is a very good product but it works differently. Datadog has machine learning, too, but not in all discovery options of SQL and in all layers of our monitoring like infrastructure, service, process, and applications—like Dynatrace. With Dynatrace, 100% of all options are included in your machine learning, in your AI.
For development, Datadog is a little more friendly to your front end and development teams. There are some areas, particularly the Apdex of Datadog, that are more understandable for the development teams. Dynatrace is a little more difficult to understand for development teams. It requires some more learning.
The APM feature in Datadog is easier to understand. It works manually, like New Relic, Grafana, or Elastic. That's more understandable for software development teams.
I tested New Relic between 2019 and 2020. Like Datadog, I tested and did proof of concept for New Relic in about one month. New Relic is strong and the APM is easier for teams of dev to write. The scope of New Relic is like Datadog. It doesn't cover all technologies and all libraries and just works efficiently with all items of applications for work with QA and dev.
I have not tested the integration of New Relic. I know some colleagues that integrated between the tools for the infrastructure coverage in Datadog and the APM coverage in New Relic.
I would rate this solution a 9 out of 10. It's not a 10 because there are some little things that could be enhanced. Otherwise, the product is great.
