Share your experience using Prognosis Platform

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.

On-premises

IBM

The primary use case of ScienceLogic for me is hybrid monitoring. This involves monitoring cloud infrastructure, data centers, or hyper-converged environments like Nutanix, as well as hardware monitors.

ScienceLogic is a Python-coded tool that allows me to create customized monitoring enablement. It offers a discovery and CMDB sync feature, ease of integration with the service management system, and particularly excels at building business service mapping. Notably, its automation features, such as Runbook action, enable domain experts like me to execute one-click automation solutions, which contributes significantly to reducing MTTR.

ScienceLogic is working towards a kind of AI, DKAIRA enablement, but I find one dependency is the frequent need to rely on professional services. If the knowledge for implementation could be spread through articles, it would reduce this dependency.

I have been working with ScienceLogic for almost nine years.

There were no challenging deployment issues for me. Although there are first-time deployment challenges with any tool, we managed to complete it within eleven months and migrated 35-plus customers, which included 65,000 configuration items. It is all about having a pool of implementation engineers and expertise to carry it forward.

I received excellent support from ScienceLogic. Considering the scale, we implemented everything with great support and timely assistance from their team. We even managed two upgrades of the platform collaboratively.

Positive

The initial setup was not particularly challenging for me. Although the deployment took 11 months for migrating 35-plus customers and 65k configuration items, it was manageable with the right implementation engineers and expertise.

The implementation involved having a pool of implementation engineers and training them, which was crucial for a successful deployment.

It created a lot of value in our ready-to-market approach, saving both time and money.

ScienceLogic is not that expensive and is cost-effective overall.

I evaluated other competitors like Datadog or LogicMonitor, but ScienceLogic's custom enablement, which I can achieve as a Python developer, is unique.

I would rate ScienceLogic between 8.5 to nine out of 10.