They need a little more self-service. Some of the places where there's still a dependency on defense logic. If those could be eliminated, that would be ideal.

They've done a fantastic job eliminating a lot of those dependencies and there's a lot of self-service. However, some of the areas where we could have it connect to, for example, Splunk or ServiceNow, in a self-care version versus having to go back to their engineers, that's an area where they could do a little more.

There are still a lot of engineers who get involved versus if it's a little more API-driven and self-served dashboard connections. Doing it the other way would just make life easier for users.

There are a lot of interventions when we go through professional services. The product must educate its strategic partners for deployment. Then, the deployment will be quicker, and we need not rely upon ScienceLogic’s core professional services team. Some automated reports must be improved.

I've used SolarWinds, Datadog and Grafana, but ScienceLogic has a particular architecture that is difficult to understand. There may have been some improvements, but the fundamental architecture around the design is different from other tools. All the other solutions have similar architecture like S&P and OIDs and play with the same four underlying technologies. ScienceLogic, however, is not very user-friendly. It has very interesting design paradigms but is not the easiest to use until you understand it.

Regarding additional features, it would be great if ScienceLogic could improve its notification feature. The company had a good-sized network team of about 30 people. However, only about two or three people did most of the work in ScienceLogic. For example, somebody would re-patch cables or turn up a new switch, and they wouldn't change the things in the monitoring tools. Instead, they would physically change the equipment or the configs. Also, if we didn't have proactive communication, dashboards would break, graphs would stop working, and alerts wouldn't fire because no one was aware. Therefore, some notification would have been helpful. For example, some tools send notifications saying, "Hey, this isn't working anymore. Do you want to do something about it?". ScienceLogic has a tiny little icon that looks like a bomb. If you go into a dashboard panel, it will say, "Hey, missing data." But aside from that, it is just a blank dashboard panel. It doesn't notify us to say, "Hey, I'm no longer receiving data," So I would recommend a proactive notification feature.

In addition, we lobbied for a Runbook automation feature for a long time and were told it may be included in a future release. I am unsure if they have included it now. We wanted it completed overnight when we had offshore people working and during the day when the actual engineers were on the phone or in the office. But they couldn't complete time-based, contextual Runbook automation. We argued with them for about a year and a half, so I hope it has been included.

ScienceLogic could improve the implementation, it could be made easier.

The back end is all right. However, when we are in the documentation area, we don't get any details. We want to understand: how does the back end work? What if some problem occurs? What we can do? They need to provide more information. 

Maybe they should do more Power Packs. We do take requirements from the customer. If they want to add to Power Packs, we need to write our own custom scripts. It might be helpful to already have it included. 

I didn't work much on ScienceLogic, but I was completely involved in the integration and transition of the product, as well as meeting with management and discussing the product.

In addition, I have worked as a visual contributor to discover devices and communicate with the networking team about how to come up with solutions.

Aside from all of this, there are limitations. When I mentioned limitations, one of the things I mentioned was application monitoring. However, if I talk about infrastructure monitoring, as I previously stated, I would prefer to use ScienceLogic as an infrastructure monitoring tool. When it comes to infrastructure monitoring, we have options such as Windows, and Windows environments. Each and every customer will have their own Windows 80 servers, as well as their own active directory and other Windows-based servers. When it comes to Windows-based servers, ScienceLogic suggests using PowerShell to monitor them.

PowerShell configuration, resource groups, and so on are not simple. Because, when you first start using PowerShell to monitor, you must manually configure all of these things by logging into the server, because PowerShell is not always configured. PowerShell has not been updated. PowerShell has some issues that you must troubleshoot. Believe me, I literally worked to discover approximately 12,000 Windows devices within the previous company around the world. When I first tried to discover it using normal discovery, it only found about 5,000 devices. Where exactly are 5,000 and 12,000? I literally had to work on each and every one of those 7,000 devices to figure out why it wasn't being discovered.

When it comes to Windows monitoring, we must plan ahead of time before we begin discovering devices. We must have knowledge of where the devices are and what exactly the legacy servers are, can just get rid of those legacy servers, what are the active directory servers, and how many active directory servers are there. 

When we talk about Linux, Unix, AIX, and these devices, your storage devices, and network devices have little trouble. However, if you want to find these Windows-related devices, you must plan ahead of time. This was one of the issues I encountered.

ScienceLogic does not have application monitoring. We definitely need something integrated within ScienceLogic to monitor applications so that we don't have to rely on monitoring tools to monitor other applications. At least the ones that are market leaders, such as SAP, Oracle, and others.

It may try to start a monitoring application at some point. At the same time, it should have some automation options, such as the ability to automate events. Though it has, it does not have inside the box; however, we will need to do some scripting and other things to automate things. Perhaps it could include some within-the-box automation that can assist us in consolidating events or taking action on the consolidated events within ScienceLogic.

The tool must provide a deep-down view of the infrastructure. It must add API. I would like to see how many items are waiting in a queue. I would like to monitor the database performance and know how many queries are going on or how much CPU space is used. The product is not user-friendly. We need to familiarize ourselves with it. We must gain some knowledge before starting to work with it.

The product's reporting functionalities have certain shortcomings, making it an area where improvements are required. The tool is more or less good. The tool needs to improve its APM capabilities.

We often face bugs when there's a new release. 

The user interface could be improved. The sizing and footprints of the central environment need improvement, too. 

The solution lacks functionality. The main issue is the granularity of user management.

Admins do not have direct access to the reporting. It goes first to the AIOps team, who have access to reports. They forward based on what is required and requested through us. We have to follow up protocols to get through that. It needs improvement. 

Simplified Interface - ScienceLogic can be a bit overwhelming when you begin working with it. The amount of customization is sometimes too much. A simplified user interface would help to alleviate this.

NetFlow Support - I would like to see ScienceLogic support Netflow so that it can be used to identify applications that could be affecting network bandwidth.

Configuration Backup - Another feature I would like to see added to ScienceLogic. It is unfortunate that I have to use different systems to perform certain functions of a Network Management System (NMS)

From a performance perspective, it needs to improve a lot. Even though it says that it's enterprise level, we have seen lots of issues from a monitoring perspective. When we monitor a huge volume there are problems. We need more customizations on the templates. They're not that useful. To customize it, you have got to go through a lot of effort. 

The professional support that ScienceLogic provides most of the time does not have that skill set to help.

The stability could be better.

Support for vendor private MIBs, simplify the approach to setup monitoring of all available SNMP data for a given platform type.

The reporting module needs work. We often find ourselves creating reports by accessing the backend database directly instead of the built-in tools. We would also like to see improvements in the modelling capabilities for the IT service toolset.

One important area we feel could be improved is the UI. It takes a lot of clicks to do very simple tasks. However, I know this is an area where they are investing and the first version of the new UI/UX is due out soon. I am confident it will be greatly improved with the next release.

I would like to see out-of-the-box standard dashboards for common services.

In many different areas of the product there are terminology inconsistencies, these inconsistencies are within the product and also within the IT world, these are definite area’s that need improvement; however with a little use they become second nature.

It doesn't have the complete application-level topology. It could have service topology and business service monitoring. 

I would like to see how business service monitoring will function with agent-based installation, and how flexible and business-oriented it is for service modeling and service infrastructure. I have a lot of experience in using business service monitoring, service topology, and service hierarchy functionalities in similar products from BMC and Micro Focus (OpenView), and I want to see how these functionalities will look like in ScienceLogic.

I would like to see an expansion of the API.

I believe the knowledge base leaves a little room for improvement. Troubleshooting can be a little difficult without the help of a ScienceLogic technician. That may not be the case for our customers of ScienceLogic but we do not currently employ a Python technician to translate the error codes.

They are also beginning to expand the video portion of the product. This will help going forward.

The UI takes a bit to learn but once you get past that it gets the job done. Creating dashboards is also complex but that is because of the sheer number of options.

Things that are key for me are really good turnkey integration with external platforms. I'm seeing a lot of interest in lately from our customers is synthetic transaction monitoring. Introducing that into their continuous monitoring practice, so seeing them integrate with folks like Ghost Inspector or AlertSite that do synthetic transaction monitoring, as a service, as a platform, and being able to ingest data from their APIs the same way they do with AWS and other platforms would really be key in giving a true 360 view of a customer's application health.

They should include chat support, like Zenoss. The ScienceLogic support team takes too much time.

They should improve database issues in HA and Failover mode, and provide documentation for all users , even if they are not customers.

Addressing duplicate IPs: There is the ability to edit the DB and fix this, but adding some logic to understand them would be a plus.

Ticketing improved dramatically from when I started working with the EM7 platform. Guys at ScienceLogic are always open to new suggestions and their voting system allows them to develop tools that are truly needed.

The upgrade process occasionally proves to be exciting. ScienceLogic Support is always able to resolve the exciting issues promptly, but I'd rather seem them not appear in the first place.

One of the main areas for improvement would be the reporting section of ScienceLogic. There is a lot of great information that ScienceLogic collects but the current reporting option are very limited without extensive customization.

Reporting is still a gigantic pain point, we invest a lot of cycles in manufacturing reports off-board -#notfun. While EM7 covers a lot of ground quickly and is capable of consuming enormous amounts of event and performance data, EM7 ironically has a hard time reporting on it - basic reporting is there, but if you let's say want to run a report for the last 90 days how many Cisco 2900 routers had a critical power supply incident that for one isn't easy and two needs a developer to write a custom report.

QA of their power-packs has been an uphill battle at times, and I feel like it's in part due to how EM7 is marketed. When a vendor claims they have a management pack for a given manufacturer, that doesn't necessarily mean its going to be dead on accurate for production use. If you need to make dead certain that the release is going to deliver I have come to learn every in step of the way to production needs thorough testing before putting it into a production environment - moral of the story here is make no assumptions and read your release notes. Also your team time for tuning the software release, like I said EM7 consumes alot of data, that always isn't a good thing.

For me the UI lays out very logically, then again I use it every day, but for many of our users navigating the UI gets confusing quickly and before long the user gets lost and frustrated and they give up. The UI for any end user facing systems needs to welcome all walks of life, EM7 at present( I know they are working on the UI currently) is really geared to the end users who are professional engineers not necessarily the weekender admin - which if you are professional engineer you're going to feel right at home.

Overall monitoring capabilities could be improved. We run into instances where we are not able to configure monitoring for specific things and requires quite a bit of manual labor to accomplish these tasks.

Outside of key to the kingdom they are doing a good job with updates and patches for adding new features.

Product works great and I feel what the team is doing and how they are moving is a testimony to their success.

Usability is important. The interface is nice, but very complex and requires lots of learning involved in managing and navigating the product.

Need to have a better export data/copy to clipboard option to transfer the data to do more analytics on the events/trends/graph.

I see room to do better in the network and SNMP trap processing. A major bug was discovered on the asset warranty alarm mapping, I hope the problem has been resolved by now.

Reporting needs to be improved. It was sold as a tool we could use for out clients and it was a complete failure. Also, built in applications should be more to best proactive monitors.