ScienceLogic SL1 Reviews

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.

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.

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.

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.

Better user interface.

API integration with other tools.

Message collector for syslog should be incorporated, not an option.

Real-time context

Distributed architecture

Network

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.

Need more PowerPacks for large vendors.

Can take some time to get PowerPacks updated.

Better application monitoring.

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

Documentation completeness and accuracy

QA of new features

Pricing

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.

Customization on monitoring needs.

Facilitate the credentials process.

Dynamic applications

BGP monitoring

Windows monitoring as a whole (Asynchronous collections)

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.

PerconaCluster.

Patching and support

Fixing built-in power packs

Making the system more efficient--collectors can't handle 1000 devices without issues

Reporting is somewhat lacking on some data rollup functions.

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.

Dynamic applications features

BGP monitoring

Improve Windows monitoring

Out-of-box reports are not useful; need paid support for any modification.

Normal incident takes more time to resolve from SL1 support.

Bugs left unaddressed

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.

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.

Complex.

Steep learning curve.

Dated UI.

Clarity around alerting

Roadmap for alerting and technologies

GUI and ease of use

Reporting

Scheduling.

Log monitoring.

Message collectors.

The support process is slow.

Support level one has proven very unhelpful to power users.

The upgrade process is tedious and prone to failure.