Reviews (1-25 of 133)
- Automation engine - easy to take scripted action on specific device events.
- Automation action open source - the platform allows you to custom build snippet actions with Python to remediate any unhealthy event detected on devices.
- Manager of managers - the platform has several ways of receiving inbound alerts and alarms not only from directly monitored devices but from 3rd-party solutions in the form of traps, emails and REST API connections.
- Built-in Reporting - the reporting engine that comes with the platform is woefully inadequate to perform most of any report request that is not a very simple and basic output of data.
- Continuous Integration/Continuous Deployment support - the platform is bound by Power-Packs for deployment of monitoring solutions for specific device types. These are great when first starting out using the platform as they allow you to on-board several types of device support, but when you mature and start building your own actions and monitoring solutions, they are cumbersome to work with.
- Current Platform Architecture - the main CDB design requires lots of memory and CPU to handle the load of all the threaded processing of even a few thousand monitored devices. To scale up to several thousand or tens of thousands if devices becomes a pricing hurdle. Also, in a cloud deployment strategy, this processing power comes at a hefty price for cloud resources, not including the pricey SL1 license costs as well.
- Custom development support - when you start developing your own snippet actions for monitoring custom devices or solutions, ScienceLogic only provides a pay-for Professional Services resource to assist you in even the smallest of development questions. The product customer support desk will not spend time discussing development solutions and providing development support. This has been an issue for SL from the beginning and the company needs to put together a development support arm.
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.
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 Cisco IT currently renders Host Clusters, Application Clusters and Application endpoints (regardless of lifecycle).
Cisco IT will be working with ScienceLogic on the 8.12 view of Application Management (which as configured won't match the Cisco IT 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 Cisco IT will interact with Business Services since Cisco IT Management wants Application Monitoring, but Cisco IT 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?)
- In-person training
Previously, the two minor upgrades seemed to take a long time and seemed to have lots of problems.
At our 188.8.131.52 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 184.108.40.206 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.
- The ability to mix collection methods makes ScienceLogic SL1 particularly flexible.
- Built-in device-specific dashboards provide a one-stop place to see everything associated with a monitored device. It's good to see the new UI has continued this with the device investigator.
- API access to pull from or push to the SL1 platform is a powerful aspect of the integration capabilities of ScienceLogic SL1.
- Easily adding new data points makes it easy to expand the scope of the collected data and the importance of the ScienceLogic SL1 platform in the enterprise.
- Reporting: The reporting mechanism is too complex for the average user. An easier method to query the underlying data would be very beneficial.
- UI inconsistencies. The new UI appears to resolve that.
- Documentation: while there is a vast amount of documentation, examples that are applicable to the real world would go a long way towards the adoption of more features of the platform.
- Modularization; ability to add monitoring to new technologies via downloadable "power packs"
- Customization and granularity of alerting
- Big potential for automating processes for those with developer-like knowledge
- Reports are confusing and crafting new ones is very tedious
- Some basic functionality lacking in alerting (ex: cannot keep a dynamic list if one item is removed from it).
- Web console and menus can be overwhelming for those without training.
- SL1 can be used to monitor any kind of devices both physical and virtual including cloud systems.
- SL1 gives you the ability to automate tasks using simple pre-define templates.
- SL1 uses AIOPS, which is one of the best practices for this modern times for any tool.
- Better user interface.
- API integration with other tools.
- Message collector for syslog should be incorporated, not an option.
- Real time discover
- Analytics/machine learning
- Data lake
- Real-time context
- Derive relationships
- Applications, infrastructure, cloud, and IoT
- IT operations
- Refine data
- Real-time context
- Distributed architecture
- There is no other platform on the market that offers the flexibility as ScienceLogic.
- If you have a clear vision of where your organization wants to go, ScienceLogic gives you the platform and tools to make that happen.
- The rich feature set out of the box is excellent, and the customizations available through powerpacks and snippet data collection is extremely powerful.
- The lack of clear communication on upcoming features and additions to the product can be a little confusing at times, but they are working to improve this.
- The UI is a bit rough, however this is being addressed in an upcoming release.
- Robust platform able to be easily upgraded
- Great support
- Not locked into vendor monitoring solutions - you can create your own
- Able to scale up to many thousands of devices
- The remote monitoring of devices using distributed collectors
- Better guides are needed on how to implement various features, particularly writing code snippets
- It takes a lot of work to bring a new system up to speed and better out of box functionality is needed.
- Release notes can be limited and often do not describe new features
- Short time to market, quick intuitive deployment and standard based on standard powerpacks and consolidation of monitoring parameters.
- Ease of use and comprehensive presentation of monitoring data in standard or customized dashboards.
- Integration with ServiceNow (this architecture and features could well be enhanced).
- Integration with ITSM, ServiceNow in particular, reference architecture, best practice, user group.
- Interoperability with Azure - how to apply SL1 monitoring on Azure.
- Interoperability with Cisco UC - how to apply SL1 monitoring on Cisco UC.
- Helpful dashboards.
- Agent-less - easy to implement.
- Easy to add collectors or increase the number of device monitored.
- Good support.
- Customization on monitoring needs.
- Facilitate the credentials process.
- Incident reduction
- P1 Outage handling
- On your website, please include a doc for the offline upgrade if it is not there, as I didn't find one.
- ITSM testing with ServiceNow.
- Flexibility in how you can code your specific monitoring needs
- Patching and support
- Fixing built-in power packs
- Making the system more efficient--collectors can't handle 1000 devices without issues
- ScienceLogic is generally quick to respond to issues we find.
- ScienceLogic provides very detailed monitoring solutions for the major product vendors.
- QA does not test the product to the scale that some customers may use it leading to potentially revenue impacting outages.
- Documentation around some of the power-packs released for public consumption.
- Certain things have been broken in the existing UI and have gone overlooked while developing the "new" UI.
We see it has significant value to the question here, however, we have not had time to quantify and evaluate.
- The platform has been relatively stable. As far as I know no outages outside of upgrades.
- The platform has good out of the box support for common enterprise platforms like VMWare and Pure Storage.
- It provides a nice event viewer for a single page displaying all events happening in your environment.
- The point in time nature of the data points can be misleading. The data would be more valuable in some cases if the 5 minute polling interval was an average value of the previous 5 minutes, not point in time when the collection happens.
- Container and Kubernetes monitoring is poor. Granted we are a few months behind of upgrades, so haven't been able to try out the latest versions.
- Snippet development within the platform is not ideal. There really needs to be a way to source snippets from Git repositories, so code can be versioned and tested outside of the platform.
- Testing snippets outside of the platform can be challenging. We would really like to have some mock test framework we could pull into our testing suite so unit testing complex snippets is easier.
- Quick Infrastructure discovery.
- Correlation of the discovered events to the services they affect.
- Automated baselining.
- Short deployment time.
- Low price when compared to the competitors.
- Integration with other systems (ticketing, change, etc.).
- Compliance with the industry standards (ITIL).
- Ticketing system could be improved.
- User interface can be confusing to the new users.
- Flexibility to customize almost everything, thresholds (per device), access, etc.
- Amount of data in product, closest to single pane of glass.
- Ease of use, navigating product is simple. New UI is great.
- Ability to utilize Downstream Suppression within different organizations. Monitoring multiple organizations requires an all or none with downstream suppression.
- Access and hooks to the product can be cumbersome and almost too granular.
- No configuration management or Netflow data. These additions could be game-changers for the product.
- Auto-scanning for inventory registration
- Write your own powerpack and can use in all similar environments
- No agent installation required to perform monitoring
- Need Python skill
- Remote connection method for monitoring may be blocked by security compliance control
- Each server or monitoring target will require credentials stored in SL1. If different devices use different credentials, they may cause trouble.
It's less appropriate for the more complicated and less standard (customized) environment, each monitoring target will require different customized environment. It will need to customize in SL1 and cost us lots of monitoring implementation schedule.
(1) the agentless function is different from the traditional one and supports rapid deployment with the standard platform.
(2) Event handling function is different from traditional tool and can prevent duplicate alert and prevent mass tickets (after integrating with ITSM tool for auto-ticketing)
ScienceLogic SL1 Scorecard Summary
About ScienceLogic SL1
SL1 enables companies to digitally transform by removing the difficulty of managing complex, distributed IT services. SL1 collects and analyzes millions of data points across IT to help make sense of it all. It automatically provides a complete inventory, tracks dynamic relationships between technologies, notifies about issues needing immediate attention, and enables corrective actions–all in real time.
With SL1 the user can:
- See everything across cloud and distributed architectures. Discover all IT components within enterprise–standard and unique–across physical, virtual, and cloud. Collect and store a variety of data in a clean and normalized data lake.
Contextualize data through relationship mapping, artificial intelligence (AI) and machine learning (ML) for actionable insights–understand relationships between infrastructure, applications, and business services. Use this context to gain insights.
- Act on data that is shared across technologies and IT ecosystem in real time. Apply multi-directional integrations to automate actions at cloud scale.
ScienceLogic SL1 Screenshots
ScienceLogic SL1 Videos (4)
ScienceLogic SL1 Downloadables
ScienceLogic SL1 Integrations
ScienceLogic SL1 Competitors
- Does not have featureFree Trial Available?No
- Does not have featureFree or Freemium Version Available?No
- Has featurePremium Consulting/Integration Services Available?Yes
- Entry-level set up fee?Required
|SL1 Infrastructure Health||$0||per device|
|SL1 Application Health||$0||per node|
|SL1 Service Health||$0||per device|
|SL1 Incident Automation||$0||per device|
ScienceLogic SL1 Customer Size Distribution
|Small Businesses (1-50 employees)||0%|
|Mid-Size Companies (51-500 employees)||0%|
|Enterprises (> 500 employees)||100%|
ScienceLogic SL1 Support Options
|Video Tutorials / Webinar|
|Customer Success Managers|
|Online Training / eLearning|
ScienceLogic SL1 Technical Details
|Deployment Types:||On-premise, SaaS|
|Operating Systems:||Windows, Linux, Mac, UNIX|
|Supported Countries:||Americas, EMEA, APAC|