Skip to main content
TrustRadius
ScienceLogic SL1

ScienceLogic SL1

Overview

What is ScienceLogic SL1?

ScienceLogic is a system and application monitoring and performance management platform. ScienceLogic collects and aggregates data across and IT ecosystems and contextualizes it for actionable insights with the SL1 product offering.

Read more
Recent Reviews

ScienceLogic SL1

8 out of 10
September 11, 2023
It is used monitoring infrastructe of our client, and [...] provides the management of the software, implementing all the monitoring for …
Continue reading
Read all reviews

Awards

Products that are considered exceptional by their customers based on a variety of criteria win TrustRadius awards. Learn more about the types of TrustRadius awards to make the best purchase decision. More about TrustRadius Awards

Reviewer Pros & Cons

View all pros & cons

Video Reviews

1 video

ScienceLogic SL1 Review: Provides Integration Flexibility When Managing Large Volume of Devices
02:00
Return to navigation

Pricing

View all pricing

Entry-level set up fee?

  • Setup fee required
For the latest information on pricing, visithttps://www.sciencelogic.com/pricing

Offerings

  • Free Trial
  • Free/Freemium Version
  • Premium Consulting/Integration Services

Starting price (does not include set up fee)

  • $7.50 per month per node
Return to navigation

Product Details

What is ScienceLogic SL1?

The ScienceLogic SL1 platform aims to enable companies to digitally transform themselves by removing the difficulty of managing complex, distributed IT services. SL1 uses patented discovery techniques to find everything in a network, so users get visibility across all technologies and vendors running anywhere in data centers or clouds. The vendor states the advantage of SL1 is that it collects and analyzes millions of data points across an IT universe (made up of infrastructure, network, applications, and business services), to help users make sense of it all, share data, and automate IT processes.


With SL1, the user can:

  • See everything across cloud and distributed architectures. Discover all IT components—–across physical, virtual, and cloud. Collect, merge, and store a variety of data in a clean, normalized data lake.
  • Contextualize data through relationship mapping and machine learning (ML) for actionable insights. Use this context to understand the impact of infrastructure and applications on business service health and risk, accelerate root cause analysis, and execute recommended actions.
  • Act on data that is shared across technologies and IT ecosystem in real time. Apply multi-directional integrations to automate workflows at cloud scale.

ScienceLogic SL1 Features

  • Supported: Infrastructure Monitoring (Cloud, Container, Server, Storage, Agent-Based, Network, Application, Database, UC/Video, Synthetic)
  • Supported: Closed-Loop Automations (Digital Experience Monitoring, CMDB & Inventory, Incident & Notifications, NetFlow, Configuration and Change Management, Troubleshooting & Remediation
  • Supported: Topology-Driven Event Correlation
  • Supported: Full-Stack Topology Mapping
  • Supported: Business Service Monitoring
  • Supported: Behavioral Correlation (Events, Changes, Anomalies, Topology)
  • Supported: Analytics - ML-Based Anomaly Detection
  • Supported: Incident Automation - Event Forwarding & Email
  • Supported: Dynamic Baselining Analytics
  • Supported: Manage Workflow Health & Endpoints
  • Supported: Dashboards and Reporting
  • Supported: Log Collection
  • Supported: 400+ Pre-Built Monitoring Integrations

ScienceLogic SL1 Screenshots

Screenshot of Application to infrastructure mapping with APM toolsScreenshot of CRM Business Service MapScreenshot of Mobile Banking Business Service Dashboard OverviewScreenshot of Mobile Banking Business Service Dashboard Availability ViewScreenshot of Mobile Banking Business Service Dashboard Anomalies ViewScreenshot of Business Services Leaderboard Dashboard OverviewScreenshot of Network Hotsheet DashboardScreenshot of Office Network MapScreenshot of Azure Map

ScienceLogic SL1 Videos

ScienceLogic SL1 Integrations

  • Kubernetes
  • Cisco HyperFlex
  • Nimble
  • Hyper-V
  • MySQL
  • Dynatrace
  • New Relic
  • Cloud -AWS
  • Azure
  • Google Cloud
  • IBM Cloud
  • Aliyun
  • CloudStack
  • OpenStack
  • etc.
  • Cloud Services – Amazon EKS
  • ECS
  • Fargate; Azure AKS; etc.
  • Containers – Docker
  • etc.
  • Software-defined Networks/WAN – Cisco
  • VMware
  • etc.
  • Network - Cisco
  • F5
  • Juniper
  • Meraki
  • Riverbed
  • Aruba
  • Avaya
  • Fortinet
  • HP
  • etc.
  • Storage - Dell EMC
  • NetApp
  • HPE
  • Hitachi
  • Nutanix
  • Pure Storage
  • etc.
  • Hypervisors – VMware
  • Xen
  • KVM
  • etc.
  • Operating Systems - Unix
  • Windows
  • Linux
  • Business Applications
  • Databases - Microsoft
  • SAP
  • Office 365
  • MS SQL Server
  • Oracle
  • IBM DB2
  • etc.
  • APM - AppDynamics
  • etc.
  • etc.
  • Storage - Dell EMC
  • NetApp
  • Pure
  • HP/Nimble
  • etc.
  • Cloud -AWS
  • Azure
  • Google
  • IBM
  • Aliyun
  • Openstack
  • etc.
  • Applications -Microsoft
  • SAP
  • etc.
  • Compute -VMWare
  • Microsoft Hyper-V
  • KVM
  • Linux
  • Unix
  • Converged -Nutanix
  • Unified Communications and video - Cisco
  • Polycom
  • Tandberg

ScienceLogic SL1 Competitors

ScienceLogic SL1 Technical Details

Deployment TypesOn-premise, Software as a Service (SaaS), Cloud, or Web-Based
Operating SystemsWindows, Linux, Mac, UNIX
Mobile ApplicationNo
Supported CountriesAmericas, EMEA, APAC
Supported LanguagesEnglish

Frequently Asked Questions

ScienceLogic is a system and application monitoring and performance management platform. ScienceLogic collects and aggregates data across and IT ecosystems and contextualizes it for actionable insights with the SL1 product offering.

ScienceLogic SL1 starts at $7.5.

LogicMonitor, Datadog, and Moogsoft are common alternatives for ScienceLogic SL1.

Reviewers rate Configurability highest, with a score of 10.

The most common users of ScienceLogic SL1 are from Enterprises (1,001+ employees).

ScienceLogic SL1 Customer Size Distribution

Consumers0%
Small Businesses (1-50 employees)0%
Mid-Size Companies (51-500 employees)0%
Enterprises (more than 500 employees)100%
Return to navigation

Comparisons

View all alternatives
Return to navigation

Reviews and Ratings

(380)

Attribute Ratings

Reviews

(1-5 of 5)
Companies can't remove reviews or game the system. Here's why
Benjamin Gerber | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User
Incentivized
We use SL1 predominantly for Event Monitoring and overall health in our different customer environments. One of the business problems that we addressed by using SL1's process monitoring on servers via a custom dashboard, was to identify which application was causing high CPU usage and related processes. We created a custom dashboard that combined all the pieces of the puzzle together in one window, and we could focus our attention on what needed to be done, instead of trying to log onto to each server and see what was causing the problems. Creating dashboards in SL1 is quite easy and when there are issues in any of our customer environments, a dashboard can easily be put together, that highlights certain areas of technology, and this enables us to
Both
  • Event Monitoring
  • Dashboards and creating custom Dashboards
  • Device Discovery
  • More freedom to create custom dashboards as on the previous versions we could do much more
  • The Performance TAB windows is too small and cannot be resized or maximized when looking at reports for "Overview", "File System" and any of those items.
  • There are not enough widgets to create stunning dashboard in AP2
  • The reporting feauture is a very untouched area.
In most of the scenarios I was able to assist users to view info pertaining to there specific case study. In cases where I was unable to help users or customers, it was a lack on our side, and not a problem with the product as we have not implemented all the functionality as I would have liked. SL1 is not a capacity tool, but it can be used to feed information into systems like BMC Truesight to do capacity reporting on.
AIOps Features (10)
100%
10.0
Monitoring and Alerting
100%
10.0
Performance Analytics
100%
10.0
Incident Management
100%
10.0
Service Desk Integration
100%
10.0
Root Cause Analysis
100%
10.0
Capacity Planning Tool
100%
10.0
Configuration and Change Management
100%
10.0
Automated Remediation
100%
10.0
Collaboration and Communication
100%
10.0
Threat Intelligence
100%
10.0
  • Better visibility into different customer infrastructures if you are a Managed IT Services Provider
  • Offers a "One Tool One Product Solution" to manage all of our customers infrastructures environments. Trend analyses enables us to collate event trends throughout all the customers and easily identify problems that may arise on other customers environments.
  • Reporting on devices and software have become much more faster and takes the guess work out of what is in the environment
A smooth implementation depends on the knowledge of the implementers. Our own company implements Sl1 on the different customer environments. When they encountered hurdles, they were dependent on other resources to help them figure out what the issues were, before they could continue. This puts a lot of strain on the project and the timelines they have to complete it in.
We used BMC as our monitoring tool, and BMC True Sight for Capacity Management. SL1 is great in Event monitoring, but it lacks the Capacity Management features as it is not a Capacity Management Tool. It would be great if we can use it as a Capacity Management Tool with all the rich feature sets that BMC True Sight offers. One Tool that does it all!
BMC Helix ITSM (Remedy)
  • BMC Truesight - Wee feed data into BMC TrueSight for our Capacity Management Team
  • We have integrated with our customers VMware environments to all info to report on without the need of having to access the vCenter Servers.
  • We have also integrated with our customers Citrix environments
  • We also integrated with our customers Azure environments without any issues.
With the correct access, the integrations are really seamless. One of the biggest plusses of ScienceLogic is it's ability to integrate with different systems and especially in an environment with multiple tenants.
  • Amazon Web Services
  • Service Now
We do not currently have customers that uses AWS, but ScienceLogic integrates with the platform already, so when the time comes, we will be ready.
We are standardizing our systems and Service Now is one of those systems that we will be integrating. ScienceLogic has the ability to feed information into the system, that will make our life's so much easier.
  • File import/export
  • API (e.g. SOAP or REST)
I am not part of the integration team, but again I can assure you, because of the many customers we have and the different systems they have that we need to monitor, ScienceLogic was the obvious choice and it's ease of integration with other systems. When we take on a new customer, we do not always know what to expect to find in their environments, but whatever we have faced in our customer environments, ScienceLogic was able to provide an integration.
If you have an integration that you are not sure of, reach out to the ScienceLogic Support Team. With their many years of experience and knowledge, they will be eager to help as our success, is their success. When it comes to any integration, it is always best to reach out to the vendor before attempting an integration. The chances are that they have already done this in other customer environments, and can give you guidance to help you get your integration up and running with another system, and alleviates the stress of having to figure it out all on your own.
  • Implemented in-house
Change management was a big part of the implementation and was well-handled
When doing any type of change to any infrastructure, it is always important to test the implementtation before hand and gather as much info as possible that would simulate a live scenario. Test every scenario that you can think of, as this makes your case for implementing much stronger as you have the facts at hand. When your change for implementation get presented at a customers Change Approval Board, then you would have no hassles of getting it approvedas we did with our customers as we test and test and test befor we implement.
  • Increased CPU utilization on overall VmWare infrastructure
  • Interference from customer Antivirus product
SL is always there and online when you need to get info from it. The only times when SL was not available in our own data center, was when network links from out side of the data center was down and those links were not in our controll. Having a central database and people accessing it all over the world, may put a bit of constarin on the performance of the dashboards when reports gets generated, but that is far and few n between.
SL's overall performance is outstanding, but SL's reporting sections is a bit of a nightmare and hopefully attention will be given to that section when a new release comes out. The reporting interface is not great and it looks like this section did not enjoy as much attention as the rest of the products interfaces. Depending on the info that needs to be generated in the report, the delivery of that report can vary. It will also depend on other activities taking place at the same time. Sometimes a report takes long, and when you evetually et it, it is empty.
The configurability of ScienceLogic SL1 is great and would cater for any type of business no matter how limited or complext that environment is. The only limitation would be of the person who is doing the configuration, but even that has been simplified by ScienceLogic SL1 team to allow for faster implementation and integration into a customer's environment.
It is always best to keep to the manufacturers recommendations no matter the product. If you get support from a vendour and not directly from SciencLogic support team, it is always advisable to keep to the standard recommendations as you may change in future to another vendour for whatever reason, and the new vendor would have no problem in supporting your ScienceLogic implementation due to evrything that has been configured according to best practices
No - we have not done any customization to the interface
Some - we have added small pieces of custom code
Although the product supports the adding of custom code and it is quite easy to add if you are a person that understands Python coding language, but it is kept to the bare minimum, and merely added or altered to fix a bug that have not yet been identified by SciencLogic support team.
Our company has a few members that are part of a wider group of people across the world, who regularly meets and discuss configuration or customization issues or improvements with the ScienceLogic supportteam, that helps improve the product for all customers worldwide, and this is normally considered when a new version of the product is rolled out.
5000
The business functions range from Operators that monitor Events, Administrators that use dashboards to get an overview of there specific devices, to the managers that that just need to have a birds eye view of how the environment looks on a daily basis.
20
We have most of the skills in-house to support ScienceLogic SL1 on an on-going basis. Most of them come from a tooling background and have been working with similar products. I started implementing SL1 with the team, and was involved on the Wintel side to figure and sort out all the snags during implementation. I then started to explore SL1 and how it could make my job easier, and it put me on a path to get my operator certificate, as well as my Professional certificate. I create dashboards in AP2 for the different organizations.
  • Dashboards to have an over all view of our customers infrastructure health
  • Data provided by SL1 to BMC TrueSight for Capacity Management
  • Event Monitoring of different customer environments
  • Dashboards for specific Technologies like the Exchange team, the Wintel Team, the SQL team
  • There are a lot of built in monitoring tools that we have not utilized
  • We have also just touched the tip of the iceberg when it comes to building a dashboard and we will be catering to the specific needs of our teams
  • Auto restart feature in Sl1 will allow us to get event when those crucial services has not started after server reboots and also minimize the P1's that we have as a result of that.
Our company has standardized on SL1 as we are a managed service provider and SL1 caters for all our needs. The fact that SL1 is a multitenant solution makes it an obvious choice as we do not have to implement different software for each customer. The other important thing is that we can start collating information and identify trends. This allows us to be proactive across all our customers and stop a problem before it arises.
  • We created a dashboard that shows the highest process untilisation to identify what was the major cause of High CPU usage in one of our customers.
  • We also created custom dashboards to fullfill each individual teams need to be able to perform their daily tasks.
  • Cloud Solutions
  • Scalability
  • Integration with Other Systems
  • Ease of Use
As we are a Managed Service Provider, SL1 offers scalability as we do not always know what the future holds. We needed a platform that would cater for each individual customer, but allow us to manage them all under one umbrella with ease. SL1 offer this capability without the need of different software and the resources and technical personnel to operate those platforms. We have a group of people that focusses on implementing SL1 on all the customers and grow their expertise and experience on a daily basis due to the different customer environments. Sl1 integrates with most if not all of the different systems that we encounter in our customer environments and again offers us the One Tool Solution to manage our customer environments.
I was unfortunately not part of the evaluation and selection process. But the guys in our company made the best choice that suites our needs and the needs of our customers. If we only catered for one customer, I am sure that we would still have chose SL1. No matter the size of the company or the amount of customers. SL1 caters for them all and has the scalability to grow, as your company grows. It is a modern tool for the modern world we work and live in, but it also caters for those who were left behind in the technology world.
Yes
BMC Remedy was replace by SL. Our license have come to and end on BMC Remedy, and we wanted to standardize our software across all customers that we support. Apart from the standardisation of the software, this would also allow us to see anomalies and trends accross all of our customers. This would mean that we can be more proactive and our reaction times to resoltion would be faster.
  • Online Training
  • In-Person Training
When I joined our company, I did not know about the in person training at firts. Logging onto the SL University, I realised that there were different sessions being held at different times throughout the year. The training itself was good, but being in a different time zone, made it difficult to attend, but the sessions that I attended was great!
The training is excellent and I gained a clear understanding of each module. Most importantly, I could do it at my own pace to make sure that I understood each module. I also had the privilege to test what I have learned in our own test environment before I went on with the next module which gave me much more confidence in what I was doing.
Due to us having so many customers that we support, it is vital to purchase premium support. Our customers are large companies that are result driven and cannot afford to loose money. Having premium support means that we can get the support we need, to be able to support our customers in return in the same way. SL1 aims to have happy customers and our aim is the same for our customers.
We had an issue with a report that was not working correctly. In our company, we need to log a ticket with our Service Desk, which relays the request to our SL1 team. They have an SLA they need to adhere to, and if they cannot resolve with a specific issue, they then in turn log a request with SL1. I think that the Sl1 feedback in getting an issue resolved, is quicker than what our own team get get it resolved.
No
Being one of the large customers that use the product, we always get exceptional support. Our tooling team engage with ScienceLogic team on a weekly basis. I am not involved in raising tickets for support with the ScienceLogic Team, but I will bet my life on it that we would not have chosen ScienceLogic, if they did not provide exceptional support for this product. It is not only the ScienceLogic name that is at stake when you use the product, but also our name as we implement it on a variety of different customers. Our customers success, is our success and in turn is ScienceLogic's success.
  • The Device Search Functionality
  • The Device Investigator
  • The Device Reporting function
  • Trying to run a report under the report section. Most of our reports do not work and the interface is quite shocking
There are parts of the interface on AP2 that does not work well and cannot be resized.
I have not been privelaged to have been part of the sales process. Our company has a rigurous process that is followed when a new vendor is chosen and any new vendor needs to meet our criteria before they are acepted. I can assure you, that every aspect has been taken into consideration before the choice was made and ScienceLogic was no exception to the rule.
The after sale process is just as important to our company, than the sales processand most definitely not a point that would have been overlooked by our company with there rigirous process when selecting a new vendour. The overall engagement is of the highest priority for us, and we continue regularly to engage with the ScienceLogic team on various subjects with geat interaction.
I was not privileged to be part of the principal terms while they were negotiated. I do however believe that our company would expect the same principal terms that our customers expect of us, from any vendor that we do business with. These principal terms would be: 1. Technical Support 2. Aftersales support 3. A Dedicated Account Manager 4. A product that is customizable if needed 5. A product that is maintained and developed constantly. 6. A company which strives to improve customer satisfaction. These are some of the principals that come to mind when I think of getting a vendor onboarded into our company.
I think the vendor is currently at it's peak, but that is only from my point of view at this moment. The vendor engagement is great, but it takes willingness from both parties to make effective dealings, and ScienceLogic does not lack any willingness, enthusiasim or passion when it comes to dealing with them.
Yes
Score 8 out of 10
Vetted Review
Verified User
Incentivized
I use ScienceLogic SL1 as our primary source for monitoring as an MSP. The biggest problem we face is it's not as granular as we would like it to be. Using ScienceLogic SL1, we monitor devices across different vendor equipment using SNMP, Nmap, and API.
SaaS Only
  • Powerpacks
  • Scheduling
  • Monitoring
  • Runbook automation
  • Grainularity
  • Access cli on web ui
  • More clear way on creating custom dynamic applications
I have a wide list of devices that need monitoring. Using SNMP, ScienceLogic SL1 can collect many metrics over various devices.
  • Better visibility
  • Metrics are available
Some hiccups during upgrade
LogicMonitor can get more granular and easier to create dynamic applications.
  • servicenow
  • Okta
Unfortunately I was not part of this integration.
  • We have no other systems we would use to integrate with SL1
  • API (e.g. SOAP or REST)
Read the KB articles as well as know how the API works with the systems you're integrating with.
  • Implemented in-house
  • I was not on the team when implementation was started/completed
Initially we did not have good SL1 availability until after we had upgraded. There were a lot of unplanned outages and our upgrades took 2-3 hours longer than the projected time. After the switch to the latest version and the movement to the cloud this has been resolved.
the current version of SL1 that we are utilizing is relatively good. There are times where pages do take some time to load but i chalk that up to the amount of devices that have to be populated.
I think that SL1 is pretty complex when it comes to configuration but I do wish that it was able to be more granular in events/alert generation.
Test it on our dev environment before implementing any global changes.
No - there is no facility to customize the interface
No - we have not done any custom code
I do not have any custom configurations I would like to share.
100
The users in our organization spand from NOC engineers, customer managers and our SL1 support engineers.The Noc engineers use SL1 to support our customer devices through troubleshooting. the customer managers use SL1 to audit devices and run reports for our customers. SL1 support engineers are the admins that maintain, onboard, offboard and do the majority of the work in SL1.
5
We have 5 SL1 engineers, one of them being a SME. 3 of the engineers are offshore and 2 of them are based in the US.
  • monitoring
  • SSL cert monitoring
  • reports
  • BGP monitoring
  • automation
This score is tallied on my objective opinion on SL1 and has no say in what my company decides to do.

The ease of use as well as the capabilities of SL1 when it comes to monitoring is mostly there. There are some features that would make supporting it easier.
  • Scalability
  • Integration with Other Systems
  • Ease of Use
The scalability that SL1 had for us as a MSP really helped us utilize the tool for our customers.
not specific to SL1 but we would evaluate other tools alongside SL1 to be able to get a better evaluation of SL1 relative to other tools.
  • Online Training
  • In-Person Training
  • No Training
The in-person training was done by my manager at that time.
The training portal was helpful in learning the basics of SL1 but in order to really implement more niche alerts/events you would have to go through the KBs.
I would not recommend this approach unless your team has extensive knowledge in SL1 and is able to train you
I am unsure as I was not part of the team when SL1 was implemented
SL1 support has been one the better end of support, at least from my experience relative to others. There were issues where I would have to escalate the case to either a upper engineer or change the support engineer to a different one as they were not helpful.
There were times where I would have a case open and there was one particular engineer that would always help me resolve it in a quick manner.
  • discovering devices
  • removing devices
  • maintenance windows
  • dynamic application creation
  • event creation
  • granular event suppression
No
I gave the rating of 8 because it does a fairly good job at monitoring but it does take a lot of knowledge to know how to create the dynamic applications and events that trigger for specific things that are needed as a MSP. With this in mind discovering and removing devices as well as creating maintenance windows are fairly easy.
I was not included in the sales process as this was implemented before I joined onto the team but from my experience with them so far they have been very accommodating.
SL1 has been very accommodating after the sale was done. We have open communications through our customer experience manager as well as our account manager
I was not included in this.
Be open minded and strict with wants and needs.
Yes
Historically our upgrades have not gone smoothly. We have had times where the outages would last 2-3 hours after the projected maintenance window.
  • Less phone home collector down issues.
  • Application performance
No
August 30, 2023

My ScienceLogic Review

Score 10 out of 10
Vetted Review
Verified User
Incentivized
We use it to monitor our on prem and cloud platforms (Azure, AWS). It escalates callouts to our engineers via PagerDuty and then raises a ticket in hornbill for the incident.
SaaS Only
  • It monitors our devices and reports on the detections we have created.
  • monitors web endpoints
  • can handle bespoke complex monitors
  • discovery of devices automatically
  • Most of the things I can think of have now been addressed in this new release.
  • Documentation could be less ambiguous sometimes
  • More active to detecting system alerts and having them sorted before we have need to inform them SAAS
This is well suited for medium to large business and not really needed for small companies.
Not Sure
ScienceLogic was implemented before I started 4 years ago, I don't know what they had before that.
We put this into every acquisition we make for monitoring, we are in Australia, Malta, America and the UK.
It raises callouts and hornbill tickets.
  • We have built our own Hornbill ticketing integration
  • we have also integrates SL1 into firing jobs of on Rundeck
  • It tells us when things have gone wrong or are going wrong which helps us to fix things quickly and inform our clients before they inform us.
We do not have many issues in what we need to do, it is very flexable
These are two different type's of products really that cross over each other at some intersections. Dynatrace is a Deep Diving monitoring tool as ScienceLogic monitors what can be seen on the surface, like logs, cpu memory, cpu and memory would be a crossover, and ScienceLogic would tell you about usage and Dynatrace could tell you how much each element was using.
  • AWS Cloud Platform Linux and Windows Servers
  • Azure Cloud Platform Linux and Windows Servers
  • Onsite Linux and Windows Servers
  • Mashery
  • Hornbill
  • Rundeck
  • pager duty
We monitor memory, cpu, swap, ping which are under the standard discovery along with bespoke monitors, the bespoke monitors range from checking for URL sites being down to writing python code in a dynamic app to integrate and interrogate other systems which pull back information and act upon that information, either with an alert passing the alert to pager duty or passing it to Rundeck to fire off an automation to try and fix the issue or fire off a runbook to try and fix the issue along with raising a ticket into the hornbill system for tracking. We have also integrated this into the hornbill's cloud ticketing system. If anyone would like to see a working example of python code that they can use and expand on to help integrate Hornbill ticketing with SL1 I have an example in the hornbills forums that you can create a runbook automation from. https: //community.hornbill.com/topic/22170-im-wanting-to-create-hornbill-tickets-using-linux-os-with-curl-also-by-using-the-python-programming-language-to-access-the-api/#comment-105100 Remove the space in-front of the https above This should Fastrack anyone who is trying to achieve the same. The alerts in science logic do not inherit ticket number information, i.e. an alert is raised as a major, it creates a ticket and receives a ticket number then the Alert changes to a critical state. in essence the major alert and the critical alert are totally individual and the details of the ticket reference will not be passed through, you have to manually fire off a runbook which looks for a previous state and if it exists then pull the ticket value from that and update the new alert with it. This for me was an unexpected find but I did manage to create a work around by directly calling the Database and performing queries on it to obtain the information needed. I did reach out to science logic on this, through the management team and through the support portal, once again I found them very helpful.
  • Kubernetes
ScienceLogic have given me a quick walkthrough of how they support Kubernetes as we plan to move our systems over to it next year. Although ScienceLogic does support Kubernetes, our Kubernetes runs with bottle rocket, this doesn't not use ssh for login and the ScienceLogic documentation stats that it requires it, I have to re-connect with ScienceLogic to see if there is something in this area that can be worked on. Our Migration is planned for next year so there is time to get something sorted and investigated of this style of platform.
  • File import/export
  • Single Signon
  • API (e.g. SOAP or REST)
  • Javascript widgets
Python, back end direct connection to the SL1 database using python.
This is like anything, its easy when you know, the product is so diverse to be able to give the flexibility that you need, because of this there is a lot to it. That said, it is presented in a way that that is very logical, it is very powerful, it is the only monitoring system anyone will ever need and the staff are friendly to deal with and will also support you through your learning curve.
Take out the cloud platform against taking the on-prem version, this will focus the majority of your time to setting up alerts and focusing on your company and not managing the systems other than the collectors which will be on your premis.
  • Implemented in-house
No
Change management was minimal
  • None
Its always available
Generally its very quick, we have a cloud platform so the hardware underneath is managed by them so its not an issue.
This is so configurable its amazing
use the Autodiscover where possible
Some - we have done small customizations to the interface
its a point and click configuration so it is very easy. He have changes colour's to pectate between production and test, we have changed auto refresh rates, we allow each user to configure it there own way and we have change the displayed columns in the events page
Yes - we have added extensive custom code
Bespoke Dynamic apps written in Python and it was easy to do if you have developer knowledge and we needed to monitor things that where out of the norm, like logging onto vcentre with an auth token that you get from the API and then presenting this token back to it to log on to get some metrics.
We have written automations in python to talk to our ticketing system (Hornbill) and we have written many Python scripts to integrate into RunDeck and any other third party appliance along with writing bespoke monitor's that run through lists and lists of checks .
21
Sysyops, First Line of Support Devops Second Line of support SRE's Third line of support IT managers, manage the IT departments and the many business areas that use IT functionality.
7
1 Automations and monitoring Lead Engineer, a person who looks at things and works out integrations with third party bespoke monitors. 1 Sysops Manager, manages the first line of support who's team ensure that the relevant IT areas are notified of issues being shown in monitoring. 5 Sysop engineers who handle the ad-hoc IT requests and fault cases/monitored alert that are reported to them
  • detection in our racing services, this is our largest revenue service and is global, we use science logic to ensure we have this service up 24/7 so we do not have financial penalties for going over our pre defined SLA's
  • Content, this ensures that images from reporters around the work can get pictures and stories of breaking new globally, Science logic reports to us about any issues between when the reported connect up to send us there story all the way to our editing rooms.
  • Stream, we use ScienceLogic to ensure that streaming sports video footage is working globally across our platforms and that our delivery websites are working and not going over capacity.
  • We car looking at moving into Kubernetes and we have now started to system test this monitoring
  • integrating zebrum to scan logfiles
We are likely to renew our ScienceLogic platform as there just isn't anything we have found that beats it.
  • Integration with Other Systems
  • Ease of Use
Ease of use, when you already have complicated systems that you want to monitor, you dont want to have a complicated monitoring systems to add to your burden, Science Logic makes this easy
I would do it the same
  • Online Training
  • In-Person Training
It was good, Do the online training first and understand it and you will get the most out of the in-person training that way
The online training was fine, it gives you the first step that you need to take.
Premium support is not a thing that I have heard of, I've heard of there professional services, we have never had need to purchased that and this is down to budgeting, our budgets will not allow is to allocate money to a just in case item.
That said we have always found a way to get through, and the basic level of support and documentation has always been sufficient for us to work things out.
I have found the UK (Ireland) and the US support brilliant to deal with, knowledgeable and they understand me.
Yes
Mostly the answer to this is yes its resolved professionally and in a timely fashion, some times the fix is in the next release and you have to wait until an update is rolled out, this is not an uncommon thing in our industry.
There is one particular person who often goes above and beyond, he lives on long island in the united states called Christien, he's knowledgeable, proactive, and a star for the company, he goes out of his way to get things sorted and I'd like to thank him.
  • monitoring of endpoints
  • monitoring of standard metrics
  • the ability to set threshold's on metrics
  • importing of power packs
  • Discovering new devices
  • Bespoke Dynamic Apps
  • Discovering AWS Could services and devices and disabling what you do not require to save licenses
  • My List is small for what I find cumbersome
Yes, but I don't use it
Because I have not yet found anything that it cannot do.
I have never had an issue with any of the representatives I have seen from science logic they are very professional and very helpful and try to understand what you need as a business
Very good and they where very encouraging to help us all get skilled up and to use the produce proactively
I didn't do the negotiation
None
Yes
Sometimes, we have had some unexpected errors and some of the engineers have wanted to get off and I've had to ensure everything is working before I said I was happy, else if you find out later then you are down to putting a ticket into the support portal when previously you had a team of engineers around you that you let go of.
We have very few issues.
  • Bug Fix Issues
  • More functionality
  • Oracle Linux 8 support
  • monitors been able to use TLS 3
  • AWS service detecting cache working correctly
  • Kubernetes monitoring
No
No
Score 10 out of 10
Vetted Review
Verified User
Incentivized
ScienceLogic brings significant abilities to the table (and on their roadmap) which enable critical business operations (such as maintaining our company website's health and availability) to track against our ServiceNow (CMDB) data and our ScienceLogic (IT Infrastructure Monitoring) deployment. We have replaced our legacy / homegrown system with ScienceLogic to enable our on-prem, private cloud and multi-cloud deployments (sometimes using all three) the ability to ensure health and availability. We are looking to move to ScienceLogic's AIOps and data lakes to further simplify the transformation of our event-storms to meaningful business information.
  • Deep monitoring across infrastructure components and with 8.12 across application layers
  • Device discovery which builds infrastructure components
  • ServiceNow Integration for CMDB driven device discovery as well as event-to-incident integration and automation
  • Runbook Automation controlling notification as well as leading to remediation capabilities
  • Event richness enabling detection of leading events which occur prior to a failure
  • 12 introduces #multitenancy support which enables Enterprise with many Organizations to share (read-only) properties and performance data across Organizations without compromising credentials with inappropriate access. This is the first release of this feature and we are only now evaluating the well-communicated delivery against our requirements. This has been communicated as only being applicable via the new UI.
  • Monitor thyself. We have found data gappiness issues which stem from incomprehensible / non-actionable system messages. The system is unable to communicate SIGTERM when used as a timeout (implying capacity issues) and SIGTERM when actually used as a fault (implying something non-actionable). The advisory services team is going to help, but this needs to be productized and shipped rather than be made available by customer success manager engagement. Things that SHOULD have results but do not should throw a under-collected event by the type of collection which is under reported. This should have a dynamic part of the event giving specific numbers not bland / generic statements that have to be interpreted. The platform team should immediately recognize the fault because the numbers are relevant. These events should be actionable, either referencing KB articles or some other specific remediation plan.
  • Data collector load v. capacity planning in both a vertical (cpu, memory, disk) and horizontal (more collectors). The data collector specs are very stale. 4x24G is recommended for 1000 devices but customers frequently view that as individual devices, not the DCM trees found during discovery. Those tend to be my expect N (<= 1000) devices + M (which are barely understood records and which are typically treated as zero, when in fact these devices are what blow through the assumed 4x24G capacity spec). Need a horizontal-infra-scaling event as well as a vertical-capacity-limit event to be thrown when more collectors are needed.
  • Actionable events. My end users barely understand the events. Referencing a KB article by URL might help users and admins in remediation. If you already understand the events they are obvious. If you don't, such as timeouts, having an article which helps people identify standard remediation steps will help close outages faster. Most events are contextual. Pointing users at that context will help.
Regardless of the product or solution, all monitoring systems encourage coding. ScienceLogic enables those coding skills to be leveraged across an ever growing list of technologies if one codes inside the Science Logic platform. Coding monitoring solutions outside of the ScienceLogic platform will tend to collect more technical debt and decay faster than it otherwise would if the code is embedded inside the ScienceLogic platform. For large, enterprise use cases, ScienceLogic (alone) is not as appropriate (6-digit volumes). Here, their integration with ServiceNow turns that gap into a benefit.
  • For us, the ROI has been positive, but the specific ROI isn't the money spent on ScienceLogic itself, it is the money invested in the skills of the engineers who now leverage the platform to maintain our high standards of availability and performance monitoring while trending over years (5-10+). Those resource costs and investments far outweigh the cost of ScienceLogic and not only retention but valuation of those skills more the covers the specific ROI on ScienceLogic itself.
  • Coming from a history of two decades of homegrown build (e.g. free), the cost of ScienceLogic feels like a questionable value, but when measured across the resources educated to use the ScienceLogic platform, the ability to quickly ramp up those same resources on technologies they may have scant knowledge of and be successful is incalculable.
Yes
EMAN, a homegrown, 20 year availability monitoring, performance monitoring, CMDB, Change Management, Alerting, and many other unrelated enterprise functions. The scale and complexity of EMAN includes access control, self-service mailing list management, cell phone ordering, home internet service registration and funding, pager service management, paging + email notification capability, DNS, DHCP, Telephony Number Management and probably another dozen things that I can't remember. That scale and complexity could not be leveraged into the new world order of rapidly instantiated but short-lived containers and monitoring across a host of new world technologies and APIs with an ossifying skillset and minimal support / development team. ScienceLogic allowed the vast majority of those resources supporting EMAN to move to migrate their skillset to ScienceLogic and expand our monitoring coverage with a minimum drop in functionality during the transition. The relationship with ScienceLogic gives us a higher leverage point for our development skills than we had with the EMAN platform.
We forced a common view to be rendered in ScienceLogic so that the vast majority of our 2200 users could see where they were supposed to go based on droplets of our IT culture which we sprinkled across the ScienceLogic legacy user interface. 80% of our customers will use ScienceLogic without really using ScienceLogic. 20% of our customers will deeply use ScienceLogic PowerPacks, etc. Everything has changed, but our core structure is visible throughout. If anything, the new structure is now more inline with our recently updated CMDB (ServiceNow) structure as opposed to our legacy CMDB (EMAN) structure. (These have been multi-year change cycles.) ScienceLogic IT Services are how our IT culture currently renders Host Clusters, Application Clusters and Application endpoints (regardless of lifecycle). We will be working with ScienceLogic on the 8.12 view of Application Management (which as configured won't match our model or requirements). We expect sometime in the 8.13 or 8.15 release cycle that we may have something usable which we will move our Application Monitoring and Service health monitoring onto Business Services and Application Health. For now, we will continue to use IT Services though Host Clusters will slide down into Device Services. It is unclear if we will move Application Clusters will move up to Business Services. We need more discussions to determine how we will interact with Business Services since our IT Management wants Application Monitoring, but we can't consume it because our view of an application isn't supported by ScienceLogic's definition that it is rooted by a process in memory on a given box. (We run many applications through the same nginx / apache process... Exactly which application is up and which is down?)
ScienceLogic has supported our ability to integrate with AppDynamics before they really have support for it. ScienceLogic is helping ensure that their Cisco ACI support matches as various engineering groups continue to rev it. ScienceLogic is helping us support and monitor our multi-cloud strategy even as we struggle to comply with InfoSec, CASPR and other compliance processes governing what can / should be allowed to be hosted external to the corporate network.
We have only a few of our domain teams which have started to look at this. The vast majority of integration and automation is limited by what SyncSever and our own platform / deployment integrations with ServiceNow for Host Composites, AppMon and AppMon Composites. The teams doing this work are currently limited to event-to-incident automation, though we are looking forward to our migration to Integration Server.
  • This question is ambiguous. As stated, it suggests that we might have found an unexpected or innovative way which ScienceLogic (the platform) is used which surprises us. The reality is that we are driving how ScienceLogic is used and we are surprising ScienceLogic (the company) with our scale and Enterprise Use Case specifications and articulations. The remainder of the questions will answer from a company perspective, not a product perspective.
  • #multitenancy - Enterprise Use Case wants to share many data elements in a read-only way to the IT world. As originally deployed, 8.3 > 8.11 suffers from Managed Service Provider Use Case where Organizations are expected to be 100% independent from each other with no read rights and no world implications. 8.12 delivers our first glimpse of how we will allow a more seamless Enterprise Use Case experience by allowing configuration of a WORLD rights permission that grants read (but not write; as is the case in 8.9 and prior) permissions to device configuration and performance data.
  • We have 467 Organizations with some 2200 users. Many in multiple organizations.
  • IT Services have been how we folded our host clusters onto Science Logic stacks. We've been involved in early discussions about Device Services and Business Services and as those become tangible in the platform we will provide our feedback based on issues we find due to our scale.
  • Given 467 Organizations and some 2200 Users, we found that pre-generating Critical Ping Failure and Availability runbook automations and actions and external contacts so that all of our teams had a starting point in the platform was a surprise to use as a mechanism whereby we provide base training to our end-users in the RBA space. Our statement is these are yours. Play with them. Learn from them. Delete them if you need clean copies and we will regenerate those for you.
  • Our use of ServiceNow as our upstream CMDB with monitoring configuration paint being applied downstream has been a great boon to us. This allows our operations teams to force a repaint to clean up problem configurations without concern to multi-master issues. We consistently find that SyncServer and Integration Server use cases are inverted for us in that ScienceLogic pushes to ServiceNow and a hand-wave on whether or not ServiceNow does its own discovery (thereby creating a multi-master problem).
We held a bake-off between Zenoss 5.0 and ScienceLogic 8.3 and while our unified communications / video team found the support for their devices to be better in Zenoss 5.0, our platform / deployment team found that ScienceLogic 8.3 was more sustainable and easier to deploy / maintain / grown. We were unhappy with the failure rate of Zenoss during the non-prod test deployment (full loss of the VM and rebuild required multiple times). No such problems occurred with ScienceLogic. We found that ScienceLogic IT Services and powerpacks would get us farther down the road than the Zenoss 5.0 release would as we heard that the 5.0 release was a fundamental change for Zenoss at the time.
  • Implemented in-house
Yes
NPRD and PROD. Subphases included per-domain-team capabilities. This included migration from the legacy system (which included spinning down the legacy monitoring system). Networking wanted large router verification and modeling. Hosting wanted large vCenter verification and modeling. Unified Communications and Video wanted CMDB assistance (which wasn't a ScienceLogic concern, but was a migration concern).
Change management was a big part of the implementation and was well-handled
There are ways to force change and there are ways to force change. Engaging the key stake holders (Compute/Hosting, Networking, Storage, Unified Communications and Video, Engineering IT) were critical for the success. We gave those infrastructure teams (20% of our end-users) nearly a year to understand how things might work, worked them across all of the challenges each group had with the migration. For all other users (80%) we forced the change in less than 90 days (since their use of the platform is paper-thin).
  • Undersizing the central database file system. 1.2TB was consumed surprisingly quickly. Default data retentions surprised us significantly and we had to scramble to ratchet down the data retentions until we could rebuild to 4TB internationally and 26TB (domestically). The engineering recommendations was 3-5TB "for someone our size". We no longer believe them at our scale and we feel much more comfortable with 10TB+ than we do with 4TB. (We're not concerned with one of our 4TB stacks, but we're keeping the data retention limited on our other 4TB stack because it is heavily used; a surprise based on our user consumption patterns.)
  • Disparity between the way we used to count and the way that ScienceLogic counts. They are not the same. You won't know until you start discovering devices how off your estimates are because the DCM trees balloon quickly and surprisingly.
  • This has implications on data collector sizing. Are you using large vCenters? Large routers? Large storage arrays?
  • Your resiliency strategy should inform how you should view your RAID configurations. We started at RAID-6 and rebuilt to RAID-10, then dropped to RAID-0 because we use a DR configuration. The starting point of RAID-6 was found to not be healthy for a heavy-write MySQL database. A RAID-10 did moderately well. The RAID-0 (with a DR config) actually performs very nicely, with all that this configuration means.
Know your use case. Know which inherent use case ScienceLogic approaches you with. (They still have a long history of Managed Service Provider that influences their thinking and they are learning to be self-aware and thoughtful about you rather than your deployment being just a templated deploy that they've done many times before.) They are making progress, but your clear and persistent insistence on deployment according to your use case will help minimize problems.
Our deployment model is vastly different from product expectations.

Our global / internal monitoring foot print is 8 production stacks in dual data centers with 50% collection capacity allocated to each data center with minimal numbers of collection groups.

General Collection is our default collection group.
Special Collection is for monitoring our ASA and other hardware that cannot be polled by a large number of IP addresses, so this collection group is usually 2 collectors).

Because most of our stacks are in different physical data centers, we cannot use the provided HA solution. We have to use the DR solution (DRBD + CNAMEs).

We routinely test power in our data centers (yearly).

Because we have to use DR, we have a hand-touch to flip nodes and change the DNS CNAME half of the times when there is an outage (by design). When the outage is planned, we do this ahead of the outage so that we don't care that the Secondary has dropped away from the Primary.

Hopefully, we'll be able to find a way to meet our constraints and improve our resiliency and reduce our hand-touch in future releases. For now, this works for us and our complexity. (I hear that the HA option is sweet. I just can't consume that.)
For us, monitoring needs to degrade gracefully. That means that, by design, you allow your monitoring system to begin giving you less and less information until an ultimate failure point. Our motto is Last-Down / First-Up and our deployment architecture reflects specific design choices to minimize being part of someone else's failure-mode.

ScienceLogic SL1 at 8.12 provides a wealth of monitoring data. This comes at a cost as you scale up.

Can you consume the wealth of monitoring data?
Can you consume the wealth of warnings and errors that being to get generated as you scale up?

There are challenges, most of which are due to our deployment design choices and scale.

We are working with ScienceLogic to introduce Priority as a first-class data element. We've added this as a Custom Attribute for all of our CIs. We use this to distinguish between the failure of a development host vs the failure of our production website.

The score represents the known opportunity for improvement that we see on our joint roadmaps.
Care should be taken when creating dashboards which present all of the collected data available to you.
We have many routers at work.
Almost all of them have 10K interfaces on each one.

Creating dashboards which present many different views of many different, large routers can create undue database load. (We're actively discouraging their use as a long-running process because each dashboard widget gets its own database connection, not a shared database connection.) We will kill all long running queries in the database if they run longer than 30 minutes.

The database schema design makes interesting trade-off decisions (optimizing for ease of write at the expense of complex / cross-device reads).

The new GraphQL schema model looks promising, but we're still waiting for that to begin to appear in the SL1 core functionality.

Given enough hardware and budget, you can go a long ways before you start pushing the boundaries of the platform architecture.

Being conservative in what you monitor for the vast majority of your CIs allows you to retain compute capacity for dashboards, runbook engines and the like.

Having large routers or vCenters will require an upscaling of your data collector sizings just to complete the Device Component Map data collection.
SL1 mostly scales our our needs. We had to break our monitoring into 8 regional stacks, but within that space, the configuration seems to work.

We introduced Custom Device Attributes to contain the standardized meta data from our ServiceNow CMDB. We have 22 attributes in play, which includes CI priority, ServiceNow SYS_ID (we have a few distinct types, so multiple attributes) and last sync-type (very crucial to know that the monitoring configuration data is current with our CMDB data).

Being disciplined about what elements of configuration we encourage our end-users to consume is a key to managing the complex offering from ScienceLogic.
  1. Have your CMDB be upstream from your monitoring system(s). Allows you the benefit of repainting the configuration when you feel it is bad, including deletion and recreation (at the cost of lost of historical data, which you should be pulling out and centralizing somewhere else if you're on multiple stacks).
  2. Use CI Priority to allow you to distinguish between Critical (Severity) events and know which one to focus on first.
  3. For on-premise deployments, deploy half of your capacity to two(2) regionally close data centers, if you have them. Plan to be the last-to-fail and the first-to-recover.
  4. Use ActiveDirectory groups to authorize access. Use your access control systems to populate those AD groups.
  5. Limit the amount of distinct rights (Access Hooks) which you deploy. (We use 3; Operators (default rights); Leads (slighly elevated from Operators); and Admins.)
  6. If you have multiple teams with differing responsibilities, pregenerate their default runbook automations and runbook actions so that they can just "turn their stuff on" (because it already exists).
  7. Look at Business Services, IT Services and Device Services as you model your "behind-the-load-balancer" cluster availability monitoring and capacity. Make this as simple as possible for your end-users to consume from their CMDB definitions. Do the math for your customers in the IT Service configuration.
Some - we have done small customizations to the interface
  1. In the old UI, we have added Custom Navigation to allow users to get from a Device > Registry > (wrench) page to the following page types:
    1. IT Services when the current CI is a member of an IT Service.
    2. The "default" Run Test (it varies by device class for us) but the canonical button allows our users to ignore those differences and have a single place in the UI to go trigger that monitor.
    3. Links to our independent test transaction verification UI (is ScienceLogic broken? Or is your CI really down?)
  2. We have not yet seen the new UI, so we don't know how these limited navigational aids will be rendered there.
  3. Several of our larger teams have created dashboards to help them understand their fleets.
Yes - we have added extensive custom code
We have done limited amounts of in-product coding (dynamic applications). We usually leverage Professional Services to build those as needed for our end-users.

We have done extensive off-box integrations and audits and range the following gamut:
  • User account injection and Secondary Organization Alignment based on external access group definitions.
  • SyncServer Discovery Session Template generation based on end-user Device Template existence.
  • CMDB to SL1 custom monitoring configuration (we lifted and shifted our entire application monitoring semantic from our legacy, homegrown system onto SL1 in about a quarter).
  • Custom code deployment on our Central Databases / Data Collectors / Messaging Servers via our own RPMs and yum repos.
  • Ansible playbooks to handle all configuration of each server type; includes command-line access and named account creation / removal as people enter / leave the platform team.
  • ServiceNow Change Management injection (not all Changes are facilitated by SyncServer).
  • Replacement of SyncServer functionality due to our scale (includes physical device Change Requests which hit 2000 CI limits in the CR and then broke).
While we prefer to use the available APIs, we find that we frequently have to touch the database directly.

Much of our outside-in integrations and coding has been to support our multiple stacks (consistency enforcement).
Try to avoid doing configurations as much as possible. (You'll likely get dragged in due to your own business rules.)
Once you've developed the skillset needed to support doing integrations (or in the simple case, dashboarding), you'll feel more comfortable doing these types of things.

Our #1 requirement is being able to rebuild any machine in as little time as possible, that means that all of our central database configurations (under the hood and inside the UI) needed configuration scripts which could be run against a newly built machine.

These scripts allowed us to leverage them in Vagrants, which we use heavily to plan out our upgrade process before we touch any non-production environment where end-users might be testing. We upgrade the majority of our non-production environments before attempting a production environment.

Using Ansible and yum / RPMs has been a boon to our ability to satisfy "last-down / first-up" when the world is burning.

Avoid making hand-tweaks at all costs. Make it a script that makes it repeatable if you have to rebuild a server.

All are IT users, mostly from the operational response teams. Networking. Hosting Storage Unified Communications and Video Engineering IT (the IT group which supports engineering business units) Application teams (such as those supporting our corporate website), but ranging to anything which we call an Application.
15
Python developers (or those developers migrating from Perl) Able to create RPMs Able to create Ansible scripts Able to create web interfaces Able to interact with ServiceNow APIs at speed. Able to create CLI infrastructure. Able to create ELK stacks and facilitate deep product operational state analysis Scrum Master Product Owner Functional (People) Manager
  • Infrastructure Monitoring (20% of our user base is in this category)
  • Application Monitoring via synthetic test transaction (80% of our user base is in this category)
  • Ability to feed all priority (P1 and P2) events through an Elasticsearch engine and render only P1 / P2 events (outages) on a single pane of glass given that we have 8 independent stacks due to our scale.
  • Minimal disruption to the vast majority of our users as we effect a sea-change in our monitoring capability (dump our old, homegrown system) and replace it with 8 independent ScienceLogic stacks around the world.
  • Educate our users to accept event-to-incident for non-priority (P3-P6) use cases
  • Drive AIOps and data lake construction so that we can be agnostic of the 8 independent stacks and treat the data as wholistic and global rather than regional and constrained.
  • Ensure that ScienceLogic product capabilities fit more and more Enterprise Use Cases over time. Use our relationship as a large Enterprise deployment to educate ScienceLogic on the Enterprise Use Case and the challenges that come from a large deployment so that the product improves overtime.
  • Maximize the viability of our on staff engineering resources to support / grow the capability consumption for internal IT clients in spaces that we currently can't get to in a timely manner, such as multi-cloud monitoring configurations.
We migrated away from our 20-year-old homegrown solution and have no back-tracking capability. ScienceLogic is demonstrating new capabilities that we would not have been able to do on our own using our legacy system. We understand the capabilities of competitors based on our bake-off selection where ScienceLogic won on capabilities and future near-term potential (expandability, platform growth). We know that those competitors are not really close to where we have been able to push ScienceLogic (as a partner).
  • Product Features
  • Product Usability
Our starting position was the retirement of our homegrown / legacy monitoring platform which had survived some 20 years.
Our key requirement was not whether ScienceLogic could meet all of our custom demands (we understood that moving from custom-fit to commodity-fit was going to be painful), but rather could ScienceLogic give us the ability to meet all of the new monitoring capabilities our internal customers were demanding as we re-oriented towards Cloud offerings and still maintain at least some level of translation from our existing expectation set without too much drop in functionality.
It won't change.

Our requirements will be:
[1] Do we have the talent in team to overcome any produce deficiencies?
[2] Which product offering provides the least amount of product deficiencies (from our expectation-set) which we then have to back-fill?
[3] Which product offering provides the most leverage to perform said back-fill?
  • In-person training
  • Self-taught
On our side (students), we had a number of teams who were provided the deep developer training. Of those students, the customized training provided a complete, 5 day training which enabled the deployed platform team to successfully deploy and mitigate user-experience issues for the vast majority of our end-users, including some of the teams who attended the developer training. The knowledge kept pace with the class and sped up / slowed down (within the time constraints) as needed throughout the course. This was developer to developer training and for those students who were developers the training worked well. For those who were just coders it probably worked less well as some of the topics still do not apply (a function of our course outline specification based on our knowing nothing). Due to problems in sequencing we did the developer course BEFORE the admin course and realized that our requested ORDER was wrong. The onsite admin course was much better received and led to deeper understanding of the developer course held a few weeks prior.
I specialize in reverse-engineering systems. I would not recommend that developers try to reverse-engineer the system. I have yet to take the online courses, but will so that I can honestly evaluate their recommendation to new users in my end-user set for their ramp-up on the platform usage.
Yes
We are working through the reproducibility cost-of-entry issues. There is room for improvement, but I also clearly want to commend the support team for their responsiveness and remediations when our stacks have significant problems.
Yes
My bugs are long-range bugs, so reporting bugs to Support (all Support organizations are quick-fix / break-fix / remediation organizations; they are not long-term bug reporting organizations). For issues where Support is the appropriate venue, ScienceLogic Support does a better than average job. They are more attentive than I can be responsive. Our Customer Success Manager is extremely helpful in allowing us to have long-range feature influence with the product team.
Our EAST1 stack had been suffering from repeated Medium Rows Behind scenarios with a MTBF of around 10 days. One night I needed to report the issue because it didn't look like it could wait for morning. They understood the severity of the issue for us. They moved the issue around their follow-the-sun support model. Even though I had to hand the issue off to my follow-the-sun support team offshore, they were still able to get to a real root cause and remediate the symptom within a few hours of my falling off of the call. The complexity of the product sometimes forces the invocation of the support team with an impacting severity and the priority-response portion of the support team was awesome! The normal priority support team supports us in very key ways, which, while not "emergency" in nature, should still be recognized as above average support.
  • Once configured, the runbook automations can be magical. Doing the configurations requires technical skills. The platform deployment team pre-populates the obvious runbook automations and actions and all configurations so that most of our users don't have to touch them. They just have to enable them. The Cisco IT team pre-filtered event types down from nearly 5000 to just about 25 interesting event types.
  • Once designed, the authentication model works moderately well. We have operators, leads and (platform admins). The configuration design was interesting because our first swing was to grant rights to each Organization. We found that a two dimensional rights / orgs matrix made this simpler. We almost have two rights, but the leads have a very few extra rights which the operators don't have.
  • We take ServiceNow data for clusters and paint IT Service configuration onto each of our stacks so that our end-users don't have to deal with the configuration of an IT Service. (Doing that integration took a little time.) We are looking for ways for ScienceLogic to consume our implementation semantics so that the behaviors make it into the product, presumably via Integration Server.
  • Our deployment goes to great lengths to allow the vast majority of our users to ignore most of the legacy user interface by focusing on a few local / cultural works to trigger behaviors which those users need to execute (RunTest, AppMon Bypass). The 8.12 Unified UI solves these issues. We are currently evaluating when we can move our end-users to that Unified UI later this summer.
  • Designing whether ScienceLogic should participate with ServiceNow in a multi-master scenario or if ScienceLogic should be the single-master or if ServiceNow should be the single-master requires assistance. Cisco IT prefers ServiceNow as our single-master allowing us the flexibility of repainting a configuration downstream if things go sideways. This is an Enterprise Use Case concern.
  • We generate Availability and Critical Ping runbook automations for each of our end-user teams (by Organization). The design and implementation work was left as an exercise to Cisco IT. We will be looking for ways to encourage ScienceLogic to make this Enterprise Use Case concern simpler for future Enterprise adoptions. Our implementation was complicated by our desire to NOT use ServiceNow group data. We expect this to be migrated to the new Integration Server as we continue to morph this integration over time.
  • Multiple stacks (an Enterprise Use Case concern) is a challenge for configuration, especially if you design for rebuild repeatability. We've lost disks on our secondaries on one stack and have been forced to rebuild because we failed to estimate our disk capacity correctly. We originally estimated 1.2TB, but due to our scale, we rebuilt (several times) against 4TB internationally and 26TB domestically using RAID-0 with a dual-data center DR configuration. We found that RAID-6 cost us database speed on UCS 220C bare metals. We found that RAID-10 was better, but that RAID-0 was the fastest. We accept the DR fail-over model as our resiliency strategy rather than a full backup (since we're downstream from the CMDB and almost everything is disposable and repaintable from the single-master). We didn't find out these problems until after we had started deploying to the production environment which meant full rebuilds on each of our 8 stacks. The reconfiguration after each rebuild was made simple only because we reverse-engineered the authentication configuration and all other central database configurations and pushed those into our Ansible playbooks.
Yes
The legacy and new user interface seem to work well from an iPad. While I've seen reference to the mobile UI, I've not played with it as we had originally deliberately designed around the need for it.
The core functions are there. The complexity is due to the complexity of the space. The score is based on comfort (I no longer notice the legacy UI) and the promise that I see in the 8.12 Unified UI (a vast improvement). It is also based on the fact that with 8.12, you can now do everything in the new UI but you still have the legacy UI as a fallback (which should now be unnecessary for new installations).
  • ServiceNow (CI sync, Change Management, Application Monitoring Configuration, Host Clusters)
  • Cisco IT's Epage service and organization membership (breadth)
  • Cisco IT's Access Request Tool (ART) for access rights.
ServiceNow - We currently use SyncServer (starting our migration to Integration Service / PowerFlow soon). We had to take Change Management away from SyncServer and do it for Host Clusters, Application Clusters, Application Endpoint monitoring as well as SyncServers Host monitoring) because of our scale / load.

Epage - We have long done our own paging service. Recipients have long been put into groups which are responsible for CIs. During our initial stand up, we took those groups and instantiated them as on-stack Organizations with members from the same source. (This is a very different view of who has access from the normal ScienceLogic / ServiceNow Company focus, but it fits our culture which continues to prefer our custom-fit solution.)

ART - Our ART integration grants users rights (basic rights, slightly elevated rights or platform admins). The Epage Organizations define what CIs can be seen. (A continuing pain-point in the platform, but we are working with ScienceLogic to introduce a solution that fits our needs and is part of the core platform in coming releases.)

  • Cisco ACI
We are working with each of the domain teams (Networking, Compute, Storage, Unified Communications/Video) as well as application teams to figure out what simplifies their lives and/or complies with our internal company-on-company program where we deploy product as it is released so that we can represent to the world how to deploy at scale.

ScienceLogic helps us get there faster than we could get there on our own.

Their work on the Cisco ACI PowerPack in our scaled environment helps us support the IT Networking team deploy and monitor (without crushing) our ACI fabrics.
  • File import/export
  • API (e.g. SOAP or REST)
  • ETL tools
Because we run 8 production stacks, we find that we have to extract data from all 8 stacks to a centralized, priority event clearing house dashboard. Our Enterprise Operations Center (EOC; our global NOC) uses that dashboard to engage priority response teams to resolve issues.

Some of our teams have done early work (organization-specific) wherein events are translated into our teams application.

Our long term plans include using ServiceNow / CMDB role-data for notification purposes via our teams application. For example, notifying IT Service Owners that they have an active P1 / P2 event on something within their service. Same thing for Support Managers and Responsible Managers at the Business Application level. Once we understand how those notifications work out, we will target Service Executives at our Architecture Service Grouping level above our IT Service level.

As part of that notification design, we intend to start the clock on the first failure and then close the clock on the last recovery so that teams have accurate outage numbers in each of those spaces. Obviously these details will be added to the active Major Incident associated with the events.
There is usually more than one way to integrate with ScienceLogic SL1.
We use the REST API heavily.
We are starting to gear up to use the GQL API and expect that to be a heavy integration.
We cheat and go directly to the central database and lean on that interface far more than we should.
We are working with ScienceLogic to start looking at the Developer persona and start aiming docs, powerpacks, education and support at that persona.
We are very encouraged by the coming SSH / REST powerpacks as we expect those to significantly lower development cost and speed our ability to bring a wider range of integrations to our end-users as well as to ourselves (the platform team).
Be clear on what you're trying to accomplish. When you abdicate your deployment to ScienceLogic Professional Services you get a best guess as to what you SHOULD deploy based on their experience. Be definitive and look at your requirements so that ScienceLogic Professional Services accommodate your needs and requirements. (Should be obvious, but there are spaces where I don't hear this all the time.)

Be prepared for when you have to do integration because the product doesn't quite fit your use case. You can use Professional Services to boot-strap your integration by paying them to do the heavy integration work or you can boot-strap your own skills development and do the integration in tag-team form or by yourself. (We frequently do it ourselves, but there are always times when that cost of doing it ourselves is more expensive than having Professional Services do the heavy lifting until we can take over the integration.) Use Professional Services to your advantage, but don't become overly reliant on them. Build your own team to support your platform.
They provided a very competent technical account manager on site with us for a limited amount of time. He answered design and deployment and configuration questions as we had them allowing us to assimilate the product capabilities at our own pace as we figured out the bake-off comparison with other vendors.
The post-sales engagement was periodic onsite presence by the Technical Account Manager who helped design our deployment and facilitated our early conversations with product management and product engineering teams about some of our long-term concerns and desires. The success of our deployment, regardless of the hiccups, is a testament to this Technical Account Manager.
I was not involved in the negotiation process.
Once you sign, figure out how you want to deploy. This is far easier as an Enterprise Use Case deployment as you already have specific must-do capabilities that you have to fold into the product somehow. Be precise. Write clear and unambiguous PROBLEM STATEMENTS. Draw diagrams. Articulate your onboarding requirements. Articulate your end-user communities. Challenge the initial spreadsheet which you'll get when you're being helped with the initial deployment planning. Identify your MUST-DO and WOULD-BE-NICE critieras. Know your own skillset contributions to the deployment. Expecting them to deploy for you with zero skin in the game on your side won't be pleasant or successful. You can get them to do the deployment for you, but they still come from a Managed Service Provider semantic and their default reaction is based on that use case. If you are an Enterprise Use Case, you have inverted concerns at time from their default mode and you have to make sure that what they give you matches your use cases. If your use cases are not crystal clear or written down, you will be unhappily surprised by being deployed with the wrong deployment use case. Know when you want simplicity for your end-users. Know when you need to apply your own elbow grease to maintain that simplicity for your end-users. Work with the vendor. Don't just expect them to read your mind.
Yes
I stepped in to take over the platform upgrades (8 stacks of 2 baremetals in dual data centers). We have a huge deployment. Your times will be far smaller.
Previously, the two minor upgrades seemed to take a long time and seemed to have lots of problems.

At our 8.5.1.2 to 8.9.0 upgrade, we quantified for ScienceLogic the number of pain points required to upgrade and regain a measure of stability.
We suggested that use of RPM under the hood would ease their upgrade problems.
These were painful at 8-10 hour days per stack with a fair amount of cascading problems after the upgrade.

We worked with ScienceLogic to prepare for the 8.12 upgrade and had them verify our upgrade procedures.

At our 8.9.0 to 8.12.0.1 upgrade, we still had problems, but the overall stress of 8-10 hour days was replaced by a leisurely 4-6 hour days where one could take an hour out for lunch away from the desk.

Our upgrade process is now:
1. Install and upgrade on a vagrant - write the procedure.
2. Upgrade our non-prod environments.
3. Upgrade our prod environments.
4. Consult with ScienceLogic on upgrade challenges when complete.

  • Getting over the 8.10 update process change. Future upgrades are expected to be simpler.
  • Getting closure to the delivery of device role-based access capability in the new user interface. Expected in 8.14.
  • Staying relatively current in terms of patch updates. Getting too far behind makes the process painful and complex.
  • ScienceLogic Engineering has moved to semi-annual releases.
  • We are timed to upgrade shortly after each semi-annual release.
  • Device role-based access in the new user interface. (As an Enterprise Use Case customer, we want our teams to see most information across organizational boundaries without having to elevate rights inappropriately and risk exposure of credentials to unrelated organization members.)
  • 14 will be our production platform on which we deploy our Integration Service (replacing the now end-of-lifed SyncServer) to handle our basic ServiceNow / CMDB integrations.
  • Enabling our transition away from bolt-on ServiceNow integrations into Integration Service integrations so that we can simplify our integration costs and platform dependencies.
Yes
We are already at the Enterprise level. We will not be changing that. (The form doesn't allow me to clarify my "No".)
No
Score 8 out of 10
Vetted Review
ResellerIncentivized
As we are a large company we have many different requirements and due to the way ScienceLogic works we are having to spend a lot of time creating standards and disabling some features from the product that may impact on our customer's requirements. Regarding tool the specifically, it seems to be a very powerful tool but as the famous phrase from Spiderman says, with great power comes great responsibilities. The level of knowledge from the maintainers must be on a higher level than the previous tools required.
  • Flexibility through scripting.
  • Easy installation and upgrade.
  • Wide community on the internet.
  • Unwanted automation that causes rework like the auto alignment monitoring.
  • Database monitoring on a full spectrum.
  • Old GUI still connected with Nagios.
Personally, I believe ScienceLogic requires more management than the usual monitoring tools. Due to that, the management required on huge environments may be a problem. However, it would fit well with small and medium companies and it would be viewed as a strong ally to IT departments.
  • Still not possible to measure and personally I'm not involved in the money area.
No
Still too early to tell, in the next months we will have a better understanding on this topic.
One of the strengths of ScienceLogic is the flexibility to monitor cloud env. as this is something we are aiming to do with it.
Currently, we are not integrating ScienceLogic yet but with the flexibility provided by the scripting feature, we may be able to do it with not much effort.
  • Cloud monitoring
  • Containers
  • Virtual machines
As a big company we use almost all monitoring tools on the market but ScienceLogic may be different since it can be used as part of our offerings.
  • Implemented in-house
No
Change management was a major issue with the implementation
DB monitoring, Auto alignment, SNMP dependencies, sub component relationship, those were some issues we had and are impacting out environment.
  • DB monitoring
  • Auto Alignment DA
  • SNMP dependency
  • Power Shell connection issues
  • Sub components relationships
The complexity on monitoring non-network devices is quite complicated.
Initial configuration (out of the box) is simple but when you need to do a fine tuning it become complex (snippets).
Auto Align is a good solution for small env. but for medium and bigger there should be a middle term
No - we have not done any customization to the interface
Some - we have added small pieces of custom code
Some extra DA not covered by the current powerpacks and some runbooks.
We are still testing the tool in a world wide scale, a few deployments are going on in parallel too.
Different from other tools SL is more complex so I believe high skilled personal would be required to support the tools and all code it requires for deep monitoring (aka Snippets, RunBooks).
  • Integration with IBM Omnibus
  • Database monitoring using subcomponents
  • Cloud monitoring
  • In small environment it can be used as a full solution, from alerting to event enrichment then ticketing.
Even being certificate on the tool I believe only with the work I will be able to reach a deeper understanding on the tool.
  • Product Features
  • Product Reputation
The product is being used over the world with good reviews on it and it is also more aligned with new technologies such ask Cloud and Containers.
Speaking on technical perspective we have other good players available but a decision is not only based on technical perspectives so I believe SL would be the choice again.
  • Online training
  • no training
Only cover the basic, the most powerfull part of the tool was not covered.
For the basics yes, the part where coding is necessary is complex and should have the first steps guided by someone with more experience.
With auto align a wrong change can be catastrophic
Not Sure
The cases I opened took some time to be solved but the the personal support is a good point.
Yes
Took some time but we had a huge team involved and it was fixed in the end.
The issues I had were well solved but speaking about a specific issue me and my team had a excellent support on doubts related with Power Packs and its behavior.
  • SNMP monitoring, it is clean and easy to deploy.
  • VMware monitoring, quick deployment and easy to understand.
  • Discovery but DB discovery specifically
  • Dynamic Applications auto alignment
Yes, but I don't use it
System still has an interface correlated with Nagios which is not a good thing.
  • Netcool
  • SNOW
  • LDAP
  • None at the moment.
  • File import/export
Simple interface but there is still some gaps at integration purposes.
Not applicable to me.
Not applicable to me.
Not applicable to me.
Not applicable to me.
Yes
We had two scenarios, big environment were way more complicated.
  • Performance.
  • Failover capablity
  • More details from collector side
Return to navigation