Moogsoft vs ScienceLogic SL1

It is able to perform as it is supposed to and it does a good job of what it's advertised to do, but we see other offerings with a lot more capabilities and a lot more available customizations. For example, things like predictive capabilities using machine learning and AI, in order to prevent outages.

Great for enterprise deployments where there is a single standard of devices and monitoring practices in place. Managed Service Providers have a harder time deploying the solution across multiple customers due to constantly changing customer requirements, device types and monitoring and security requirements and scenarios.

We migrated away from our 20-year-old homegrown solution and have no back-tracking capability.
ScienceLogic is a Cisco Partner and we are supported in ensuring their success.
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).

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).
Further, the score is influenced by ScienceLogic being a Cisco Partner and while Cisco IT is a customer, we are also executing on internal expectations to make our partners successful by constructive (and sometimes pressured) criticism to better the platform.

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.

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.

On the Cisco IT 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 Cisco IT 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.

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.)