ScienceLogic Reviews

The solution is a hybrid monitoring solution for infrastructure and cloud environments. It offers discovery, relationship mapping, and integration with CMDB and ticketing systems. We use the product to integrate relationship mapping to CMDB in real-time and automate incidents. After monitoring the infrastructure and cloud, the product performs incident automation, including data center automation. We also use the product for remediation or diagnostic-level automation.

The solution has a patented technology called Dynamic Component Mapping. This feature works with CMDB. Dynamic Component Mapping is key and unique. ScienceLogic is a Python-coded tool. The product offers flexibility to fulfill our requirements by enabling us to develop our own automation use cases. The product can be integrated with our application monitoring tools.

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 been using the solution for almost seven years.

The tool is stable. I rate the stability an eight out of ten.

Since the tool runs on a SaaS model, it can be scaled horizontally and vertically. I rate the scalability a ten out of ten.

Sometimes, there are a lot of hiccups until we complete implementation, and we need to seek help from ScienceLogic’s support team. We also have to do different feasibility studies for each PowerPack, so we rely on ScienceLogic’s deployment team.

Neutral

It is easy to set up the solution.

The deployment time for the solution depends on the customer's environment. The end-to-end deployment takes around five weeks if all the prerequisites are met.

The pricing depends upon the GSI and customers.

The solution can be compared with OpsRamp and LogicMonitor. These tools have robust security standards as part of platform consumption. They are DoD-certified and have a lot of encryption standards. There are no Java components in these tools. Customers do not consider products based on Java because of the recent vulnerabilities in Java. The tools have the advantage of having non-Java components.

People looking to use the solution must religiously use the tool's capabilities instead of trying to reinvent something that the tool does not do. They must use the Python capabilities available in the solution. It's helpful. The product needs a lot of improvement. I rate the tool nine because I have not completely utilized the potential capability of the tool yet. The tool has a lot of automation and integration capabilities. We can integrate the tool with many other tools. The solution is capable of integration both inside and outside. It comes with a lot of features, including discovery, monitoring, event management, and automation, for our hybrid cloud monitoring environment.

Overall, I rate the solution a nine out of ten.

When discussing network devices, for example. When you enable network monitoring, you should be aware of what is being monitored, such as devices, switches, and hubs. You must be aware in order to enable monitoring, but when you try to discover a device within ScienceLogic, it performs granular discovery. You don't have to worry about which location, site, place, or subset or subset of devices is installed or placed. It performs granular discovery. 

We know when we talk about certain appliances, such as XClarity or certain Cisco appliances or other appliances, many nodes or hub switches, servers, and devices are connected to a single hub in an appliance. When you find a specific appliance, it will perform a granular discovery until the last child is found. If you try to find a parent, it will only find up to the last child, which is not the case with other monitoring tools. This is one of ScienceLogic's best features.

This happened in our previous company's environment, they didn't have a proper inventory where they could have given us the details of devices, hubs, and switches, because if it's a large company with a large infrastructure, they rarely get to have an updated inventory. It is extremely difficult to obtain each and every inventory when working on such projects or transitions. That's when ScienceLogic came up with this granular discovery, in which it discovers each and every child within that specific parent, appliance, or device.

As a result, we were able to return a report. Essentially, ScienceLogic is used as a reporting tool. Instead of giving us the inventory, we ran a report after the entire discovery to show the customer, what they have in their environment that they were not aware of. It was a nice thing to boast about because they were unaware of their inventory, but we were able to provide them with that inventory.

Another application was to use ScienceLogic as a source of truth. When we say the source of truth, we generally refer to CMDB in large environments. When we go for ticketing or any kind of event management, it generally refers to the CMDB, pulls the data, pulls the server information, drags it to the ticketing into the system, and it provides all the details in the ticket.

But sometimes the CMDB is not updated, either because it requires manual updating or because someone is attempting to upgrade or update it through some script or something, and somewhere, there is a miss. However, when we use ScienceLogic as a source of truth, there is nothing to miss because whatever is discovered within ScienceLogic can be used as a source of truth. Essentially, ScienceLogic would have the information that CMDB does not have.

These were two cases, test cases, or things that we came across. And we were overjoyed to offer the customer the solution, that they could use ScienceLogic as a source of truth, instead of referring to CMDB. That's when we suggested that they integrate ServiceNow with ScienceLogic and use ticketing instead of a CMDB. At the time, we had completely removed CMDB. Maintaining CMDB is also an expense. We actually save the customer money with the help of ScienceLogic.

As I previously stated, as an example, ScienceLogic can help you save money. It is not necessary to monitor your environment with multiple tools and applications.

When it comes to business problems, the first thing that comes to mind is cost reduction. I believe that most companies have a CMDB, I believe that if you want to cut costs, that can be a very good business value. It adds monetary value to the company. That is one of the factors.

Another issue that arises in the course of doing business is billing. Billing the customer, and billing the client. ScienceLogic can be an excellent tool for taking out or reporting such inventory, KPIs, and so on. 

ScienceLogic can be used as a reporting tool.

When I was working as a transition manager, we had to create these reports every day after discovering certain devices. We had to create these pie charts, graph charts, and other graphics and then present them to the customer. We would tell the customer how many devices we had built, how many are being phased out, how many must be in place by next month, and how many have been temporarily shut down. It provided us with a comprehensive view of the entire infrastructure.

When it comes to features, the power pack is the most valuable. When you look at the current IT industry or IT market, you will notice that there is a lot of trust in the market. Everyone wants to integrate with a monitoring or event management system. I also understand that SAP and Oracle, for example, have their own monitoring tool. However, even if they have their own monitoring tool, they also require a ticketing tool, an automation tool, or a tool that generates tickets for those events.

In this case, we have ScienceLogic. With the help of these power packs, we can integrate any third-party tool. When it comes to storage, network devices, and third-party applications, there are over 400, 500 power packs available on the market. You can always integrate those third-party application tools within ScienceLogic and use them to create an event management solution.

It is not necessary to use ScienceLogic solely as a monitoring tool, because, to be honest, ScienceLogic has some limitations when it comes to application monitoring. If you ask my opinion on ScienceLogic, I believe it is a very good tool for infrastructure monitoring. You can use ScienceLogic for event management at the same time. Where will you make the dashboard, where you integrate third-party applications and create tickets and other solutions of this nature.

There is a lag somewhere on the application monitoring side. People typically use their own application monitoring tool. Take, for example, SAP. SAP-mon is its own monitoring tool. It selects its own application tools, SAP-mon, but ScienceLogic can be integrated with SAP-mon and events generated in our system. You can then create tickets from ScienceLogic for the SAP-mon team and the SAP team. As I previously stated, ScienceLogic as a tool has several power packs and there are numerous options for integrating a number of applications and integrating several third-party applications with ScienceLogic.

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.

I have been working with ScienceLogic for two and a half years. 

I worked for a company that initially had a monitoring tool called Netcool, which was an IBM product. We were in charge of transferring ITM monitoring from IBM Netcool to ScienceLogic, as well as infrastructure and some aspects of cloud monitoring.

I worked for the previous company until last year. I worked on the transition project for one and a half years, during which we had to replace the IBM tool monitoring with ScienceLogic. Essentially, I was working as a transition manager as well as an individual contributor due to a resource crunch. We had to manage all of the customer requirements' sites.

I changed jobs after one and a half years. I returned to my current company, where similar to IBM when they have these managed services for customers, for monitoring, they have this GSA solution, which is completely a Kyndryl or an IBM-based solution. They have now decided to switch from ITM monitoring to ScienceLogic monitoring because ITM is an expensive product. The license is very expensive. As a result, we are currently working to transition from ITM to ScienceLogic. We are currently working on the integration phase.

We have two parts when it comes to monitoring. One is for monitoring, and the other is for event management. As a product, ScienceLogic can enable event management. IBM has decided to stay with NetCool because they have certain customization on GSM's side and they don't want to get rid of NetCool as a product. At the same time, they want to switch from ITM to ScienceLogic for infrastructure-level monitoring. There are quite a few advantages with ScienceLogic. That's when we decided to use ScienceLogic as our infrastructure monitoring platform instead of ITM.

Stability is fine. To be completely honest. I have been using ScienceLogic for almost two years. I don't believe there is a problem.

So far, performance has been satisfactory. As I previously stated, we had some issues with this Windows PowerShell. If you're talking about the PowerShell part, if we have a solution in the future, I believe it should be good enough. But, once again, PowerShell is a major issue within Microsoft. ScienceLogic has nothing to do with it, but there are certain businesses that are at ease with SNMP configuration. If you use SNMP to configure Windows machines and don't have any security concerns, you'll be fine. You can see that you don't have any infrastructure issues.

I don't believe there is any issue in terms of performance. Only the fact that, as I previously stated, I believe ScienceLogic, which is widely used by everyone these days, lacks application monitoring. I believe if it comes up with certain, within-the-box application monitoring or something along those lines. I believe it will be an excellent replacement for market monitoring tools.

When we were doing this transition phase, three of us worked, but later we had a team of 12 because the project started working. 

We began receiving numerous requests for user creation, followed by your adding of devices, discovering devices, fixing issues with PowerShell, and fixing issues with other connectivity. 

We used to have infrastructure issues from time to time. For example, the database layer is ScienceLogic's main layer; everything fails if it fails. We had some Docker issues at times. Everything will come to a halt if Docker is not running. The application is stopped.

We had to create ScienceLogic support cases. Then we had to sit with them, figure out what was wrong, and troubleshoot. We had a lot of other things, a lot of other work that gradually began to pile up in our queue. 

Then there was a team that was solely responsible for reporting, every day we would pull out a report and see how many servers were collecting data and how many were failing to collect data. 

We had to troubleshoot why the ones that were failing to collect data were failing to do so. There were numerous BAU-related activities. 

When doing a project activity, you don't need many people at first, but when you start working at a BAU level, you definitely need a team of at least ten.

As a tool, it is quite effective, but there are a few issues here and there, that we have to look into. 

We also have this Azure environment, that we have to ensure is scalable, has high scalability, and high availability, and that you don't have an issue with all of those things. It all depends on how you intend to build your infrastructure. When it comes to scalability and high availability, I don't believe there will be any problems because we are using the cloud, which should be properly planned.

When we first started doing this we are not given any instructions. Every time there is a new problem, we must file a complaint or open a case with ScienceLogic technical support. We have professional services as well as technical services. Professional services are services that you will be provided with when you first approach ScienceLogic as a product and want to have it in your environment.

Professional assistance Hours are the time you spend on integrations, building your intranet, and other tasks. After planning, you implement your environment, and when you begin working on a BAU, you begin working on technical services.

They offer two different types of services. One is professional, while the other is technical. Technical is mostly used to support BAU-related issues and activities. For example, as I previously stated, Docker will occasionally fail to work on the database layer, and when this occurs, you must refresh, stop and restart specific processes, and sync all data collectors and message collectors with the database layer. There are some steps that you must take.

In general, I've noticed that they don't have a step-by-step process. You must always log a case whenever you encounter a problem. They will arrive and log in. And that's when they go over all the steps with you, "Do this, do that, do this, do that." And they will assist you in resolving the problem. Again, their assistance is prompt. I will not say that we had to wait for something or that they made us extremely frustrated at any point in time because their support is extremely quick and pleasant. Whenever we had a problem, we filed a complaint, and they responded quickly.

They provide support around the clock, so we never had a problem with them. Whether it's with professional or technical services.

When compared with NetCool. The first point I'd like to make is about licensing. Every company would like to have some rule that is budget-friendly. When it comes to ITM Netcool, the licensing is far more expensive than any other product on the market. At the same time, IBM never sells its products as standalone products. If a person wishes to purchase only Netcool/OMNIbus, they must do so as part of a package. ITM will come with Netcool/OMNIbus, Netcool/Impact, and Netcool dash, you'll have to buy everything together.

Customers do not always want everything. They only want one component of the product, but IBM refuses to sell it, and in that case, you're paying far more than you should. When it comes to Netcool Tivoli, one of the main constraints is money. 

The second issue is that Tivoli is an old product that lacks many issues and granular monitoring. When I was talking about ScienceLogic, I told you that if you find one appliance, it will find all of the child's devices. In ITM, this is not possible.

However, there is also log file monitoring, for example. Log file monitoring is a common practice within IT infrastructure. Any team may wish to monitor or log. Whereas in ITM, we have to write custom scripts, which is not as simple. When comparing ScienceLogic to the ITM, we have power packs that allow us to integrate any number of third-party applications. We can't do that at ITM. There are times when I have to use IT-Cam to monitor applications because I cannot use ITM.

There are many differences I believe I have used a lot of monitoring tools, such as Nagios, Zabbix, and others. These are free and open-source tools. However, once I began using ScienceLogic, I discovered that the main thing that fascinated me was discovering each and every child, which I had never seen in any monitoring tool. It surprised us, and it surprised the customer as well. They were surprised to learn that switches, and hubs existed in the environment.  Customers were pleased with the inventory report and that the product is so efficient, that it picks up everything.

We were working on the cloud; our entire infrastructure was set up on the cloud, and we were using the Azure cloud. Our overall architecture was built on the Azure cloud. We also had specific collectors. ScienceLogic has three layers.

The collection layer, the main servers, the user interface or administration portal, and the database layer were all always based on Azure, but the collection layer was deferred. We also deployed the collection layer and message collection at the Azure, GCP, and AWS levels. Our infrastructure was mostly cloud-based. This was a private cloud environment for the company I worked for, as we never used a public or shared cloud environment.

The initial setup is not complex at all; in fact, it's quite simple. It's fairly straightforward because we already have the binary and images. There is nothing complicated about enabling the ScienceLogic environment.

When I deployed it for the previous company, there were only three of us. We also never worked together because we had shifts and a ScienceLogic support team that was initially assisting us on a few buildings. Because the support team is spread across the globe, two people had to work on the US shift, a few on the EMEA shift, and a few on the India shift. We had to report to management during the EMEA shift because the company is based in Switzerland, and we had someone to report all the issues and handle all the requests from the customer and other stakeholders. But, to be honest, you don't need much; it all depends on the environment, and how big your environment is. As the previous company is a large environment, we only had three resources working around the clock.

Initially, prerequisites must be met, we worked with the Azure team to open up all Firewall requests and such. The length of the process varies from company to company. After all of the prerequisites were met, it didn't take us a long time. Because we only needed three layers, the entire environment was built in about two weeks. The administration portal, the database layer, and the collection list are all available. There were two collection layers. The first was a message collector, and the second was a data collector.

Message gatherer, It's similar to an SNMP-based collector. It gathers information. It does not send any data. The data collector will collect data from other servers. When I mention servers such as AIX or Windows, or servers that send you data, I mean that all data is accumulated in this data collector. However, there are some devices, such as network devices, that continue to send without being asked. A message collector is required for these data.

Initially, when you try to implement an environment, not everything happens at once. You must take it one step at a time. The customer will initially advise if they want to go ahead with AIX or go ahead with Linux or go ahead with what is the easiest. An environment contains numerous elements, such as storage, network, Windows, AIX, Linux, hubs, switches, and a variety of other components.

We first decide which ones will be the first to be discovered. As a result, we develop data collectors. We continue to add data collectors as the load increases. You cannot decide that we need this many data collectors all at once. However, you should have the inventory ready when planning the implementation. In terms of the initial inventory, you will know how many data collectors to install. You begin with those items and gradually expand your data collector. However, as I previously stated, I believe that two to three weeks is sufficient for the initial setup.

When we talk about maintenance, we have to keep checking because the IT environment changes so quickly. We have a lot of switches, and a lot of child components coming or attaching to the appliances, and in those cases, we must constantly monitor the RAM, how it is being used, how loaded it is becoming, and how many child devices are being added, and so on. 

When it comes to maintenance, we don't have to think about it because ScienceLogic has its own dashboard. You can add widgets to the dashboard, as well as all of your components, such as collectors, data collectors, message collectors, portals, and database layers. You can create a check in your dashboard.

On a daily basis, you can simply go to the dashboard and see how your environment is performing. It keeps alerting you that the file system is now full, or that we are using too much RAM, or that the processor is being overworked, and so on. It alerts you. We can create a dashboard like that. 

There are some things that we need to check on a daily basis such as the collector because collectors are responsible for collecting data. Occasionally, too much data is loaded during data collection. That is when we must investigate. 

We have this dashboard, and you can create your own. You continue to check your health on a daily basis. Whenever you decide to start working on any product, not just ScienceLogic. There are always these health check scripts, health checks, or dashboards. You can create that and have something ready or, actively look into it on a daily basis, and avoid unwanted situations.

I'm not the best person to discuss pricing, but what I do know is that it's a use-and-go structure. You use this much storage and pay this much for it. That's how it is. Every time, we continue to add a large amount of data to the environment.

We are constantly adding new devices. Initially, if you have taken, say, 500 GB of storage within ScienceLogic, because ScienceLogic also needs to store your data, to report or to do anything, or to do any survey or data analysis, it needs to store, so you must have storage. Or perform any activity automation on the events, consolidate, or do anything with the events, you need storage.

When monitoring a company's entire environment, you need more and more storage. When you first started implementing ScienceLogic, you may have needed one GB. You'll need five GB tomorrow as you add more and more devices. You are adding data. You continue to pay each time you add storage to your application. They have brackets where you pay this much from this GB to this GB. or If you use more, you will be charged more. It's not on a usage basis; the licensing is not on the product, but on the storage that you are using.

We need good planning when implementing ScienceLogic. And planning in the sense that, for example, when I was transitioning from ITM to ScienceLogic, I'll just give an example to make it clear. We already had certain monitoring for the customer when I switched from ITM to ScienceLogic. First, we must collect all of the monitoring data and create our own inventory. Then we must determine what is the current application that the company desires to have in the future. We must look at the present, the future, and the past. And we have to create a good plan for what we will see.  And documentation is critical for any and all planning. After receiving those documents, you must have them approved by the customer.

We sometimes think we can do things on the fly. But, as I previously stated, ScienceLogic performs granular discovery in this case. Sometimes, such as with the network team, granular discovery is not desired. Because they do not want certain devices monitored, we must ask them again, what devices they need to be monitored. These are some of the things that should be considered or thought about. That is why I emphasize the importance of proper planning when implementing ScienceLogic. This is what I discovered because once you start discovering devices in ScienceLogic, you can't stop. It will discover everything from A to Z.

When you discover everything from A to Z, that, in turn, will cost you storage it will cost you everything. Then, when you start reporting it, there will be a lot of  data, unnecessary data, that it will slow down your CPU.

There are numerous possibilities. When it comes to planning or implementing ScienceLogic, you must have a solid plan in place, as well as documentation and technical documentation. All of these factors are critical if ScienceLogic is to be implemented.

I would rate ScienceLogic an eight out of ten.

I'm working on a monitoring environment and would like a product to monitor a specific part of the application. Not more, not less, but a little of both. When we talk about SAP and ScienceLogic, for example, I know you can integrate SAP with ScienceLogic. You can also monitor processes, but only at the process level; you cannot monitor at the application level. That brings us to this point. However, I would give it an eight because the infrastructure was excellent. It appears to be a far superior product to IBM Tivoli.  However, it does not support application monitoring. It had some collector issues at one point, but I'm not sure if it has since been improved or if new versions of ScienceLogic have been released. But, based on my limited experience, I like the product.

ScienceLogic is primarily a network monitoring tool. We used it alongside another tool. Initially, ScienceLogic was supposed to replace the old tool, but we used it for so long and never fully transitioned. ScienceLogic has a lot of benefits, with additional functionality through power packs and the ability to build things out manually. It is also more flexible than other tools but very manual to configure.

Initially, we received some help configuring ScienceLogic to monitor externally polling databases. ScienceLogic also combined that with its network device polling and gave us a complete picture. We had about 1500 branch locations and 100 on-premise network devices, so ScienceLogic was the tool that could merge those two worlds.

The best feature is the highly flexible graphs. If you have the time, the output allows you to input the precise information you want. In addition, the solution enabled us to make a single dashboard displaying about 12 vital statistics as we needed them.

It is also fairly extensible, and power packs are available. The modules slot in and extend the functionality. We had the most mileage out of monitoring UPSs, and power supplies in our data center.

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.

We used this solution for about seven years at my previous company. I moved to a new company two months ago. The solution was deployed on-premises.

The stability was very good, and we only experienced one isolated issue. The stability was good because we were versions behind with ScienceLogic for about a year and a half, rebooted it every other week, and it still ran fine for years. So realistically, all things considered, I would say it's more resilient than average for the products in that market.

The solution is scalable, but it was challenging onboarding users to ScienceLogic even if we gave them an AD and put them in an AD group. The user would log in, fail, and their profile would lock. It would then create a nonfunctional profile, and we would have to go to that profile and assign them a read-only, administrator, or power user level. Then, we would have to give them access after they logged in or tried to log in and failed. It was an issue for several years and made it difficult to onboard new users. ScienceLogic should have a good access control model that does not rely on just locking the user out. We had about 30 users that actively used the solution, but about five to eight were administrative users.

I rate the technical support a six out of ten for break-fix issues. However, their installation assistance was better when we upgraded, and I rate that an eight out of ten.

The initial setup was average. It was not difficult to turn on. We had a dedicated appliance that was very easy to use. You plug it, turn it on and give an IP address.

The second time we set up Science Logic, we put it on a VM. Turning it on was pretty straightforward but getting it configured was a Herculean task and a lot of work. It was a very manual process apart from the power packs, which give you specific settings that make some of it easier.

So, if you want to use ScienceLogic, you need to include the costs of a minimum of two consultants for six months, depending on the size of your network or hire one person full-time to take care of it. It is a lot of work. For example, people re-patch a cable, and you have to change labels, or weddings show up on your graphs, which requires upkeep.

I am unsure of the exact ROI. Other solutions are cheaper, but for a national enterprise, it may be worth it to pay. When a branch network was down, it became costly to manage. ScienceLogic was good at proactively identifying problems. When a branch was down, ScienceLogic will act and turn a 45-minute outage into a 20-minute outage, or they would see the early warning signs and solve it in advance. We had about eight occurrences where our branch network was down, and ScienceLogic reduced the outage length for about three of them.

I rate this solution a seven out of ten. It is as good as any tool on the market for true network monitoring and robust features. It is flexible and relatively extensible, but it is not easy to use.

ScienceLogic is slow to adjust to a rapidly changing market as everything is moving towards a holistic SRE approach. ScienceLogic is moving in that direction with the change ticket system, change tracking system pipes into a Datadog or a BigPanda and AI ops tools, but they are not keeping pace with the market.

We chose this solution because we knew how it worked, and the core competency of ScienceLogic is its core network monitoring functionality. It provided the needed features and bridged the gap between our distributed branch network and quarter enterprise network, which was sufficient.

If someone were using this solution for the first time, I would recommend getting a consultant and understanding what matters to the business. The business needs should dictate the monitoring. You need to ask questions like, How long does it take to load? When does the network circuit blip? Are the servers overloaded? It would help if you also had an expert who could understand the tool and have answers to these questions. If you already have a knock engineer or an SRE, ScienceLogic, it would be difficult for them to understand the tool. You may have to pair somebody who knows the business, needs and environment with somebody who has all the ScienceLogic expertise.

I work for three companies where the usage is different. Earlier, the main usage is to monitor customer service. Later on, it was a tool used for a combination of both Splunk and ScienceLogic. Now it is different, and now we are using it to look for limited server monitoring. It's different in all the different ways I have been worked with the tool. However, basically, it's for monitoring for the most part.

The monitoring is very good.

It is simple. We can see whatever is going on. Easily, we can discover everything. We can monitor our virtuality. Mainly the monitoring is simple on the server, and we can easily correct things if there is any problem on the server.

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've been using the solution for around four years.

In terms of stability, whenever we have a huge device that's mounting, if one of the devices gets a lot of events it can go down. We need to be careful. We need to add a device monthly to ensure the solution doesn't get flooded. 

The scalability is good in that you can always add more users. There's no limit to the number of users. I'm not sure the exact amount of people that are using it right now as everyone has access to a lot of tools. IN my team, however, only three people use it currently. 

I've been in touch with the technical team. In the beginning, we dealt with them a lot more as we didn't have any real knowledge of the solution. As we picked up processes we've used them a bit less. However, they were always helpful.

Neutral

We did previously use NETSCOUT. We didn't have the equipment, however. It came from the client. 

There are two types of architecture. One is an all-in-one, and the other one is like a distributor. We went for the all-in-one option. It's very easy to set up. The distributor is a bit more complex. However, items like message collected, data collected and admin portal and database are like deploying one component at a time. Once we deployed them, we needed to connect to them. We needed support during that period. We needed a team. 

The deployment is quick. We could do it over a few hours on a Sunday.

While you do have to pay for licensing, I can't speak to the exact cost.

We're a customer.

I'd recommend the solution to others.

There are many marketing tools in the market. I have less experience with those. I do, however, have experience with ScienceLogic. It has a good design. You might need someone from support to do the installation. However, apart from the installation, you can understand everything very easily. It has a lot of integration capabilities as well. We can integrate with a lot of things. We can monitor emails. We can monitor APL. We can handle customization and automation and there is a great dashboard. They have lot of features to take advantage of. That's why people should go and use the tool.

I'd rate the solution ten out of ten.

We use the solution for monitoring networks, applications, and server environments.

ScienceLogic has all functions in one solution.

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.

I have been using ScienceLogic for three months.

The product is stable.

The footprint and complexity of ScienceLogic can require significant memory, CPU, and disk space. This can lead to overloaded servers and components, resulting in a sluggish user interface.

A total of 400 users are using this solution.

I rate the solution’s scalability a six out of ten.

We had very limited contact with customer support.

I can compare it with Broadcom. ScienceLogic is cheaper with less functionality.

The initial setup is very complex.

ScienceLogic comes with a good price.

I rate the product’s pricing a ten out of ten, where one is cheap, and ten is expensive.

Overall, I rate the solution a six out of ten.

We use the product to monitor our servers, network switches, and other devices. We can check if there are any issues with the patching.

ScienceLogic allows us to create and customize a user-friendly dashboard. Additionally, there are role-based access features for admins.

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. 

I have been using ScienceLogic as a customer for the last nine months. We are using the latest version.

Initially, we encountered customization-related issues. I rate the product’s stability a six out of ten.

Adding resources is easy and accessible in ScienceLogic. You can customize and monitor and can have automated management. You can write automation scripts with the right level of access and send alerts and notifications. It is a built-in feature, but only some have access to it.

In my team, we have 25 ScienceLogic admins. In the AIOps team, we have another 50 users. Its scalability is a seven or eight out of ten.

Our AIOps team manages the application and does the customizations for each team. They initiate contact with the technical support team.

The setup is straightforward. It is easy to manage and check for alerts. The classification of alerts is specific. It makes it easier for admins to manage alerts. We can quickly identify what is critical and a warning-level alert. We move the managed servers across the network while migrating the clients' data from other products to ScienceLogic.

ScienceLogic is a great tool for system administrators. It is convenient and feature-rich, with a lot of customization options available. The dashboards and support information are very specific and detailed; you can customize it for convenience. The pre-built information is also very useful and granular, making it easy to identify problems. The alert levels are well-defined and can be customized for each customer. ScienceLogic is also very intuitive and can automatically pick up signals and categorize alerts.

ScienceLogic's alert system is already top-notch, but you can also customize it further to meet the needs of each customer specifically. For example, you can set different alert levels for different SLAs. You can also customize the alert notifications to be sent to the appropriate people. This way, you can ensure all alerts are handled quickly and efficiently. We can also customize the alert levels depending on the nature of the issue. The alert system is designed well and provides very specific load ratings. However, we can customize the alerts per our customer's SL agreements.

Overall, I rate ScienceLogic an eight out of ten.

It's an IT infrastructure monitoring tool. It's mostly used by the IT team. It monitors the environment like the server database and cloud environment. 

ScienceLogic is a good tool. It has good capabilities as an SaaS product. 

It has good monitoring capabilities across cloud environments, data centers, and hybrid environments. 

It covers lots of technologies from a monitoring perspective and with its AIOps and event management there. It has good capabilities around that. 

I like the APM, the topology mapping they have, and the business service mapping that they can pick up and then feed into any CMTP like in the ICMTP. It has a good feature in that area. It's a good tool from a utilization perspective for monitoring the environment.

The scalability is excellent.

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.

I've been using the solution for five years.

We have had issues with stability. When it is in a huge environment, we did have seen some issues around the stability in that area when using it for monitoring large environments.

The product has outstanding scalability. We did not see many issues around that so far.

Support is lacking. They are not very knowledgeable sometimes. 

Neutral

It is easy to set up. It is a SaaS product and has agentless monitoring. From a setup perspective, it is easy.

The deployment depends. It can be set up in two weeks or six weeks. However, normally, we're seeing the deployment done in two to three weeks. It's a quick deployment that is happening. It all depends upon the environment and the requirements that need to be there. Generally, it's a quick deployment.

We have seen an ROI.

The monitoring tool does not give a return on investment in the first year. Normally, it happens in the second or third year. In the first year, it is more about improving the capability of their environment, and managing the environment. From the second year, they resolve incidents or improve visibility. So from the second year onwards, ROI may not be that high, however, we have seen that customers are getting that benefits.

They are subscription based. From the pricing model perspective, it's very simple, and licensing is not very complex. It's based on the number of network devices. They have some calculations which are very straightforward and very easy to use. There are no hidden charges.

We are a partner and reseller.

The product has multiple deployment options. They do offer us a SaaS product. Therefore, it's available in the public cloud. Users have the option to deploy on-premises. It can be deployed in a private cloud or according to the customer's requirements. It has the flexibility to do that.

I'd rate it a seven out of ten. 

It's a good tool for monitoring hybrid environments. I would recommend it to others from a hybrid monitoring perspective and from a server database perspective. However, it does not have good capabilities for monitoring networks. It should not be used as a network monitoring solution. It needs to be more focused on infrastructure.

Our primary use case of ScienceLogic is as a monitoring tool. We wanted something adaptable that could monitor numerous environments and specific monitoring based on the vendor. We're a supporting organization with 170 data centers around the world. I'm a technical lead and we are customers of ScienceLogic. 

The most valuable feature is an OS that enables the deployment of a virtual machine. The product provides agentless monitoring which is based on SNMP so there's no need to install the monitoring agent on each and every server. Other credentials and monitoring are also included. We get great reports and integration is also excellent. This is a simple, easy-to-use tool. 

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

I used this solution for six years. 

This is a stable solution and there are rarely any issues.

Scalability is good, we can increase the number of users we want. 

We have premium support so the customer service is generally good. They sometimes choose to lower the urgency of our request and then it can take a few days to get a response which can be an issue for our customers. 

Positive

The initial setup is pretty straightforward. Deployment time depends on the infrastructure. If you have less than 1000 servers, then the setup doesn't take long and can be completed within a few weeks. A larger deployment will take longer. 

The solution is an OS so a license is mandatory.

This is a pretty user-friendly tool. Much has improved in the newer version from a monitoring perspective. Everything will be in the UA so nothing is required at the back end. 

I rate this solution nine out of 10 because of its simplicity.