ScienceLogic Reviews

Our usual use case of ScienceLogic is as a strategic monitoring tool for all the customers in our company, and because of that reason, all the accounts and projects are migrated from other monitoring tools to ScienceLogic. Before migrating from other monitoring tools to ScienceLogic, first, we need to build the database servers as well as collector servers. Once the setup is ready, we then need to build the onboarding for the devices.

Before onboarding any device into ScienceLogic, we need to check the prerequisites, such as whether ping is open from the collector to the endpoint server, whether Telnet is working, and whether WMI is open. These are the basic prerequisites that need to be met before onboarding any device into ScienceLogic. Once the prerequisites are met, we then go for onboarding. Before we onboard, we first need to build the device groups and create the credentials we are using, either Windows or Linux.

Additionally, we need to prepare the templates based on whether it is a Windows server or a Linux server, reflecting the dynamic application which is essentially a small script that helps collect information from the endpoint server. For instance, if it is CPU, the script connects to the server to capture the CPU metrics. Similar dynamic applications exist for disk memory and others, based on customer requirements. Once the template is ready, I will push that template to the server, and that's the basic onboarding. After onboarding, when the OS classification is prepared, such as Windows 2021 or 2019, we need to validate data collection issues and enable the alerting rules and configurations. Alerts can be directed to ServiceNow tickets or email notifications, and based on that, we need to create the alerting rules.

The features and capabilities of ScienceLogic that I have found the most valuable include its ability to monitor server metrics as well as application-level metrics, similar to other infrastructure monitoring tools in the market. While each tool has its capabilities, ScienceLogic stands as one of the tools that monitor the server and application metrics effectively. However, it is not as capable for OS cloud platforms like Azure and AWS, and even for Azure, we need to build the collector with multiple processes involved. In comparison, other monitoring tools such as LogicMonitor are designed specifically for cloud-based monitoring. When it comes to infrastructure-level monitoring, tools such as SolarWinds, LogicMonitor, Nagios, and Zabbix are limited to scripting.

The integration of ScienceLogic with our existing IT ecosystems has significantly benefited our organization, as all alerts now directly go to IBM Netcool and then to the ITSM tool, ServiceNow. Initially, all alerts went through email notifications to specific users, but once integrated with ServiceNow, all alerts automatically create tickets through IBM Netcool, which then are assigned to the relevant teams based on SLAs and which ensures immediate response without missing deadlines. In the previous setup, there was always the chance an email could be missed, hence the integration with the ITSM tool has improved our alert management.

I am interested in improving the flexibility of ScienceLogic's user interface, configuration, and customization. I am particularly keen on learning about issues raised by the ScienceLogic support team. Whenever we encounter difficulties, I raise vendor cases and am eager to deepen my understanding of those cases. Additionally, I want to learn more about ScienceLogic's dashboards, which display crucial metrics about collectors, their health, and devices aligned to them. The dashboard should be more detailed.

Regarding improvements to ScienceLogic's technical support, my last company was IBM in India, and I worked on IBM MQ monitoring until my last day. I engaged with the LogicMonitor support team for MQ-level incidents, but these issues remained unresolved even after 10 to 15 days. On my last working day, I assisted with one such vendor case, and I am unsure if that issue was ever resolved.

ScienceLogic's technical support should respond more efficiently in terms of time. During my time working on MQ-level cases, including a power pack upgrade that did not fix the issues faced, I provided all necessary steps with the help of the middleware team. However, there were still gaps that needed addressing.

I rate the stability of ScienceLogic as eight out of ten. I rate ScienceLogic's stability as nine out of ten.

On a scale of one to ten, I rate ScienceLogic's scalability as eight.

I would rate the support of ScienceLogic around seven to eight out of ten. I am very much interested in supporting vendor cases, as providing solutions often requires reading in depth and documenting findings and updates. We have a lab environment to test solutions before offering them to customers, ensuring everything works correctly. If any relationships exist with dynamic applications or other dependencies, these are documented before providing a detailed resolution in the ticket.

The initial setup of ScienceLogic involves building inventory by getting details from the customer regarding their infrastructure. This involves assessing how many collectors and databases there are and their required hardware configurations. We must consider cloud servers, network devices, storage boxes, and the associated databases such as Oracle, SQL, and MySQL. Each request counts the RPM, or responses per second, surveilling how many KPIs exist. Based on these details, we design the infrastructure, enabling the installation of the SL1 agent afterward, which includes the ScienceLogic software. This is combined with the inbuilt ISO image that configures collectors, databases, and message collectors for handling syslog and traps for networking devices.

The module system I refer to is actually the dynamic application, with each dynamic application working to collect data from the endpoint server and reporting the same data to the ScienceLogic engine, which, in turn, reports to the centralized server. This is the architecture of ScienceLogic.

I use ScienceLogic's dynamic mapping capability for our IT applications. However, there is no option in ScienceLogic to enable the dynamic application automatically. For instance, in tools such as LogicMonitor, once a device is onboarded, all features such as CPU, memory, disk, ping availability, and other KPI metrics automatically align and start collecting data without manual intervention. In ScienceLogic and other tools such as SolarWinds, data collection only begins after a template is applied.

Dynamic mapping has helped me gain insights into the operational health of my environment. In our environment, the real-time analytics and event correlation of ScienceLogic are useful in maintaining incidents, as alerts from ScienceLogic are directly sent to IBM Netcool, which is an event management tool. This tool enriches the alerts, correlates events, drops duplicates, and creates tickets in ServiceNow for all customers using IBM Netcool.

I have implemented end-to-end processes in ScienceLogic in my previous organization, including collector build, onboarding, off-boarding, and monitoring various applications such as SQL, MySQL, Oracle, and DB2, as well as OS-level monitoring. I have also been involved in ScienceLogic's version compatibility and upgrades, but I feel satisfied with the current performance and if new concepts arise, I am eager to learn and enhance my skills.

I give ScienceLogic a rating of 9 out of 10.

I use the solution for IT infrastructure monitoring, specifically in complex IT environments with enterprise-grade level solutions. If I were a small to medium business, I probably wouldn't choose this provider. It is a heavily configurable, heavyweight, and scalable IT solution for IT infrastructure monitoring.

The solution excels in three areas: application monitoring, server monitoring, and network performance monitoring. Adding server monitoring into that list is quite key. 

One of its biggest features is its coverage of all the public clouds, which is significant because it is mostly an on-premise hybrid technology. If I have a complex hybrid infrastructure, it can look across all the major public clouds and virtualization solutions. 

It accommodates VMware, Hyper-V, KVM, and even older storage arrays and video conferencing and wireless technology. The real strength lies in its ability to operate across multiple landscapes, both modern and old, facilitating all of them. A major benefit is eliminating visibility gaps, which motivates me to consolidate tools. 

It offers over 500 integrations with a wide range of device types, referred to as PowerPacks, which are prebuilt integrations for hundreds, if not thousands, of integration types.

There is room for improvement in the speed of setting up the service and integrating PowerPacks. Although these prebuilt features are great, there is considerable complexity in bringing them together to create a unified dashboard. Even with many good integrations and deep visibility, the implementation takes time, especially when it doesn't involve these integrations. 

While some other companies have easier APIs, using this solution demands significant expertise. It's challenging for new customers to implement independently. The implementation speed of non-PowerPack or non-out-of-the-box integrations should be improved. Additionally, the AI automation feature is not yet very rich due to resource constraints supporting a wide platform.

I have used the solution for five to nearly six years.

The platform is generally stable but has a few bugs. Whether these bugs are considered unstable or routine maintenance can be subjective. Stability should relate to whether the platform fails, stops working, or breaks. None of these issues cause significant flaws. The stability rating is nine out of ten, acknowledging some bugs, but indicating these are minor issues.

The core platform likely offers high customer service. However, Skylar, the new feature, doesn't have as rapid a service. If rated, combining the core product and Skylar, it averages around seven out of ten. Problems with Skylar may require longer wait times due to limited resource expertise.

Neutral

The last three roles clearly outline my contribution; I am not a customer. Instead, I resell, implement, and support their customers, including their internal ones. I handle half of the implementations in EMEA, acting as an outsourced team. I can officially resell, implement purchased ScienceLogic solutions, and informally extend their internal implementation team.

The return on investment is fair but often challenged by medium-sized businesses who may question its adequacy. For larger enterprises, it usually meets expectations. Medium businesses find it tougher compared to enterprise customers.

I would also question why people aren't considering newer SaaS companies. While these may have fewer features, they deliver higher returns on investment and easier implementations. They require about half the time to implement, presenting an intriguing alternative.

If I am an enterprise customer seeking comprehensive visibility and basic AI features, this solution is recommendable since few companies can guarantee an enterprise-level solution scalable at the right cost. Newer SaaS companies may offer fewer features but boast high return on investment and easier implementations. 

Principally in the enterprise sector, this is a viable option over traditional legacy alternatives, whereas for medium or smaller customers, it may not be suitable. 

The overall product rating is six out of ten. 

It's suitable for specific customers, although slower in implementation and offering tougher ROI compared to some. This rating reflects my consideration of various customers, conversations, and observations. I should make sure to highlight the Skylar feature, as it is an exciting development. 

It's new and focuses on prediction and automation—where innovation in this category is leading. It's geared towards proactive and predictive monitoring, relevant for those seeking ITIL level five performance. Its potential is substantial, yet since it's still developing, comprehensive evaluation is difficult.

Positive

We started off with infrastructure monitoring, then, over a period of time, we added on the application monitoring and cloud monitoring as well. It's been an incremental thing for us.

I like the collectors and I like the agent-less collector's functionality a lot. To me, that's been the top ones. I also like their integrations with the various types of devices that they've built out over a period of time. The power flow is great.

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.

I’ve been using the solution for six years now.

I don't have any stability concerns. At least I haven't seen any issues on our side. The performance is good. It’s reliable. There are no bugs or glitches, and it doesn’t crash or freeze.

The solution is scalable. It’s great for enterprise-level organizations.

We have 30 to 35 engineers on the solution right now.

We do deal with technical support. For example, if there's a new upgrade, that's hard to keep up with or there's a new connector that we don't know about then we'll reach out to them.

Positive

We have experienced a few different solutions. We’ve used IBM products in the past, and we've used Solarwinds as well. I do prefer the agent-less option, and I also like the roadmap, especially everything ScienceLogic had on the IOPS for five years.

On a scale of one to ten, I’d give it six in terms of ease of setup. We don't need to have some level of engineering expertise. It's not as straightforward as rolling out a Power BI or a Tableau, for example. Also, the infrastructure is multilayered, and it is complex. The rollout should have some level of engineers involved.

For us, the deployment took about two weeks.

We have seen an ROI.

The solution is license-based. It's between $8 and $15, depending on what you need from the product.

We are a customer and a partner.

We are currently operating multiple versions of the product.

It may not be the right product if you want to solve a certain use case. You have to have the right use case. It's an excellent product if you have a broader strategy, either as an MSP or as an enterprise. If you just need to replace product “A” with ScienceLogic to monitor 100 endpoints, it's not the perfect use case for them. The perfect use case is how you get it to cover across multiple layers of network, applications, and cloud, especially towards hybrid monitoring. Potential users need more roadmap-based approaches versus a one-point use case.

I’d rate the solution a nine out of ten. My experience with other products and the support I received from ScienceLogic across multiple levels, from engineering to product, especially at the leadership level, has been good. The support and everything they do to help you and your customers are successful. Overall, I really like the product, and I recommend it.

The primary use case is mostly centered around monitoring infrastructure and management.

The CMDB update and the automatic CMDB update are valuable, along with the new function of Skyler.AI, where I can use JNEI PeerSpot's assistance.

Integrating observability and APM monitoring into the overall portfolio would be beneficial.

I have been using it for around five to six years now.

While it is okay, the solution still needs improvement. I use other automation tools, like ScienceLogic, to pass information to automation tools like Ansible, due to its broader use cases for automation.

Since it is a SaaS-based product, the setup is not very difficult. However, it is not so easy either. It is relatively easy to set up initially.

The cost is medium. It could be cheaper.

As part of my job, I propose ScienceLogic for infrastructure monitoring. I recommend it to customers. 

The overall rating is seven out of ten. I recommend ScienceLogic to other users.

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 use the solution in my company mainly for infrastructure monitoring.

The most valuable features of the solution stem from the fact that it is an agentless tool, and users have ScienceLogic PowerPacks available for most of the technologies. The tool is quite easy to deploy, and it offers very good support.

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.

I have been using ScienceLogic for three years.

The response or turnaround time from the support team is quick. If my company contacts the support team, they set up a Webex session or Microsoft Team meeting at our convenient time to provide help. I rate the technical support a ten out of ten.

Positive

My company needs additional reporting tools like IBM Cognos or Tableau. My company uses additional reporting tools to extract data and then design the reports per the customers' requirements. If users of ScienceLogic get features similar to those offered by other reporting tools, it would be great.

The solution is deployed on an on-premises model.

The solution can be deployed in a day.

My company has an enterprise-level contract with ScienceLogic, so it is available to my organization at a good price.

The solution is useful for monitoring hybrid environments, clouds, and traditional data centers.

From a cloud perspective, we use the tool's very basic features as per our company's requirements. In our company, the tool helps us with the KPIs we plan to achieve.

Right now, my company usually goes for about five minutes porting into it, so we use it as a tool that provides us something near real-time monitoring.

My company doesn't use ScienceLogic's features, though it has good automation features. Our company uses Ansible for all automation, and we have integrated ScienceLogic with Ansible.

ScienceLogic sends events to IBM Netcool, where events are handled through event automation.

In terms of the reporting and analytics part, whatever out-of-the-box or default reports are available can be useful to some extent. There are times when there is a requirement for some additional customizations to serve our company's purposes in the area of reporting.

The tool improves our company's response time to incidents.

I recommend the product to those who plan to use it.

From the monitoring perspective, the tool fulfills my requirements.

I rate the tool an eight out of ten.

We use the solution to monitor servers and DNSs.

The solution provides good infra-monitoring features. It sends me alerts.

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.

I have been using the solution for a year.

I rate the tool’s stability a nine out of ten. It is quite stable. It is always up. It hardly ever goes down.

The tool has medium scalability. I rate the scalability a seven out of ten. We have more than 1000 users. I use the product every day. We might increase the usage if we get more add-ons.

We were using Nagios before. ScienceLogic is a bit better.

The solution is deployed on the cloud.

The tool works well. I do not have any issues with it. Overall, I rate the solution a six out of ten.