Share your experience using CA Automation Point

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.

Currently, my use case for OpsRamp is using it as an infrastructure monitoring tool for customers, where we can provide infrastructure monitoring as a platform. We can have AI appended to those monitoring capabilities where we can have correlations, alert prediction, some automations, deduplication, noise reduction, and these features predominantly.

What I appreciate most about OpsRamp is that while many tools in the market provide standard monitoring, OpsRamp stands out as a differentiator by providing AIOps features, including correlation, deduplication, and automation where we can run RBA scripts on top of created alerts. Additionally, it has multiple out-of-the-box integrations available where we can connect to various external tools and integrate them for orchestration between systems.

As a monitoring tool, compared to standard monitoring tools, the benefits include increased productivity and significant noise reduction through its correlation capabilities. The comprehensive monitoring capabilities cover infrastructure monitoring, synthetics, network monitoring, and integrations. It can act as a monitor of monitors, which we currently utilize when customers have multiple monitoring tools in their landscape. OpsRamp can integrate with these monitoring tools and create leverage by providing monitoring as a comprehensive solution.

If we treat OpsRamp as an infrastructure monitoring tool, there are many positive aspects. However, when viewed as an AIOps tool, there are numerous potential additions. Currently, it performs infrastructure monitoring but has limited capability in application monitoring, which needs improvement. They are introducing observability as a feature where metrics, logs, and traces can be implemented, but this is currently in a primitive state that can grow over time.

The platform is very stable, and the UI is excellent. However, regarding AIOps features, enhancements could be made to provide more value, such as dynamic thresholding and other capabilities that competitor tools have, such as LogicMonitor.

I have been using OpsRamp for the past four years.

We have discussions with both the customer success team and the support team. When we encounter platform challenges or issues, we raise a ticket. Previously, when it was smaller and not acquired by HP, support was more primitive. Now that it is HP's OpsRamp, things are improving, but there is definitely scope for better support.

The availability could be improved. With other tools, there is dedicated support for specific customers or implementation partners and MSPs. Having a dedicated firefighter team for each MSP would be beneficial, as we are handling around 30 to 35 customers where we are implementing OpsRamp. With the current generic support system, issue resolution takes considerable time. I would rate their support at seven out of ten.

Positive

I have worked with ignio initially, a tool made by TCS that functions as an AIOps tool performing automation, RPA, and monitoring. I have also used Zabbix, SolarWinds, and OpsRamp. Currently, I am being trained with LogicMonitor.

The initial setup is very straightforward. Compared to other monitoring tools, the initial configurations in OpsRamp are simpler. However, regarding AI capabilities, one definitely needs substantial hands-on knowledge of the tool to provide value to the customer.

We have a partnership where we act as an MSP and implementation partner to HP's OpsRamp.

We are implementing OpsRamp successfully as it is an excellent tool for infrastructure monitoring for a standard customer base. However, overselling features can complicate implementation. It is important to stick with available features and provide customers with clear, precise details about what can and cannot be done to avoid anomalies.

I use the capability for predictive analytics. The feature is effective in its current form. OpsRamp provides prediction features on the alerts themselves by analyzing data from created alerts and predicting future alert creation. However, it does not predict utilization or forecast utilization from the metric details collected for each monitored parameter.

The flexibility of being deployable both in cloud and on-premises is beneficial as it is a SaaS platform that doesn't require extensive infrastructure. You only need gateways in your customer landscape to operate. Compared to other tools with on-premises setups that require managing numerous servers, this makes it more cost-effective for implementation teams.

I rate OpsRamp 8 out of 10.