Welcome to the ScienceLogic SL1 Discussion Forum
We would like to welcome you to this forum where you can participate in open collaboration and meaningful discussions about all things SL1. The purpose of this area is to foster collaboration about ScienceLogic SL1 topics and ideas and for you to find solutions. As a community of IT professionals, we're always eager to learn new things and improve our skills. In this forum you can find people with similar ideas and challenges who can help you learn and be inspired. We hope you look forward to participating in these discussions and contributing to the community. Cheers to fostering connections, sharing insights, and driving the future of AIOps together. The ScienceLogic Community TeamHow will the Hollywood update affect AI insights and the SL1 platform?
Explore everything about the SL1 12.2 Hollywood release with this learning track which includes a press release, solution sheet, on-demand webinar, and more. Explore how our AIOps platform, SL1, harnesses the immense power of artificial intelligence (AI) and machine learning (ML) to empower IT teams with human-ready root cause analysis. See how SL1 shows real-world examples of how our actionable insights enable IT teams to rapidly pinpoint anomalies and their root causes, auto-remediate issues, and work 10X more efficiently. After reviewing these resources, you’ll understand how ScienceLogic SL1: Delivers human-ready AI insights using generative AI Helps filter out the noise using AI/ML Unlocks operational efficiencies with automation I also encourage you to check out the 12.2 release notes and documentation for a deeper dive into the Hollywood release.Tips for How to Optimize your SL1 System
ScienceLogic SL1 is a very powerful system that can make the lives of your operations staff easier, but those outcomes require some maintenance and optimizations. Read on for a few tips about how to get the most out of your SL1 System 1. Use Event Insights You probably know that Event Insights (Expand left menu -> Events -> Event Insights) is a powerful view to see how SL1 is reducing noise in your system, but did you know that it helps you see potential optimizations also? On the right side of the Event Insights page there is a section called “Tuning Targets”. By looking at what devices are creating the most events and which event policies are resulting in the most events, you can see actions that you can take to clean things up. In the example screenshot above, I would want to look at device 203.0.113.249 to see what is going on to trigger so many events. It could be a misconfiguration on the system, a hardware issue that needs to be remedied, or a threshold that could be tweaked. The lower section shows event policies that are being triggered the most. Noise-reduction options here include requiring multiple triggers within a time frame to be sure that the events are persisting, suppressing the events for test or dev devices, or tweaking thresholds to be sure that the event reflects an actionable problem to fix. 2. Use Operational Insights Operational Insights is a powerpack built by ScienceLogic to help manage your SL1 stack. There are separate versions for self-hosted and SaaS customers, but most of the functionality is the same. Once it’s installed and configured, it presents data on a series of dashboards. These dashboards can help you see the status of your collectors, keep track of the trends in the number of devices discovered and business services configured, and even keep an eye on under-the-hood metrics like Configuration Push time and the Event processing backlog. 3. Daily Health Tasks Did you know that the SL1 Documentation has a list of daily health tasks? Some of these items are covered by Event Insights and Operational Insights, but some are not. For example, it’s a great idea to check the System Logs periodically to make sure you know how things are running. If you have concerns about other items in the “Healthy SL1 System” table, you can set event policies and automations to make sure that you are notified in case of any issues. 4. Join the ScienceLogic Nexus Community! Finally, the ScienceLogic Nexus Community is a great resource to keep things working at your best. Interacting with fellow customers, submitting enhancement ideas to the Product Management team, and keeping up with the latest information on new releases helps you plan appropriately and use your time and energy well. To get started: Register with the Nexus Community (its easy) Visit our Community Information Forum for assistance and tips Thanks for your time and I would love to see some feedback and ideas for topics of interest.How do I activate a catalyst to achieve superior IT automation?
IT leaders have long recognized automation’s key value in accelerating IT incident response and eliminating downtime. Unfortunately, the challenge of diagnosing modern, complex IT stacks often frustrates teams attempting to realize automation’s full potential. Fortunately, recent innovations in Generative AI can help. From advanced ITSM process automation to one click issue remediation, generative AI is the catalyst. It accurately advises you on what happened, recommends resolution actions, and takes the most effective action for you. But only if it’s part of an end-to-end AIOps platform. Listen in with industry expert and principal analyst Carlos Casanova for a conversation on automation, generative AI, and trustworthy machine insight. You’ll learn how to leverage AI to break through barriers to increased IT productivity and lower downtime. Watch On-Demand: AI/ML: Activating Catalyst for Superior IT AutomationSL1 Hollywood 12.2.4.1 Release Notification
We are pleased to announce that SL1 Hollywood 12.2.4.1 is now available. The release and documentation can be accessed using the following link: https://support.sciencelogic.com/s/release-file/aBtVL0000000V5R0AU/12241 Please note that The SL1 Hollywood 12.2.4 release has been removed from the ScienceLogic Support portal and replaced with the 12.2.4.1 release. This is due to an added security update. 12.2.4.1 release contains additional security updates on top of 12.2.4 release. You can upgrade to 12.2.4.1 directly from the following SL1 versions: 12.2.1.1 12.2.1.2 12.2.3 IMPORTANT: If you are currently on SL1 12.1.2, do not upgrade to 12.2.4.1 until ScienceLogic publishes upgrade instructions in a Knowledge Base article. For full details, please see the SL1 Hollywood 12.2.4.1 release notes: https://docs.sciencelogic.com/release_notes/sciencelogic_12-2-4-1_release_notes.pdf2024 Customer Success Honoree Award Winners
Any community whether online or in person is a place to share and learn. As leader of Customer Advocacy, my role too encompasses sharing the voice of our customer in many formats in order for our peers to thrive from this knowledge. In case you missed it, we recently launched our ScienceLogic 2024 Customer Success Honorees - an awards program recognizing those who have made significant progress in a specific area, and have been an integral champion for SL1 success. I wanted to share with you these wonderful advocates, our finalists, in the hopes it inspires you to share your stories of success with our new Nexus community! Stay tuned for our upcoming 2024 Innovators Awards, an application-based awards program celebrating and recognizing customers and partners who are leading the charge in digital transformation, operational excellence, innovation, and business impact utilizing SL1 in innovative ways. Applications are opening early June! Read more in our CS Honoree eBook. Congratulations to each of our 2024 Honorees! 👏💣 If you're interested in telling your SL1 story, please reach out to me, and join our Pathfinders customer advocate program.
ScienceLogic Meraki Monitoring Best Practices
Hello all, I wanted to take a little time to share my thoughts as the Product Manager for the Meraki PowerPack. I believe we have a great solution for integration with Meraki's API, but I find that due to Meraki's focus on more simple management and monitoring, a slight shift in mindset may be required to extract the most value. Unfortunately, when I meet with some of you, I find you may be unaware of some of our best practices that would really improve your experience! A condensed version of this information can be found in the PowerPack Manual. Some context to consider as you read: Meraki is not the typical power-user tool you're used to, although it is adding features constantly and at a rapid pace. It is not intended to have every knob and lever. It is intended to be simple and easy. Meraki monitoring is entirely through the cloud API. SNMP monitoring or SSH connections into appliances is not a typical workflow and doing so provides little benefit beyond using the REST API. Meraki really doesn't seem to want you to do this. Meraki's API does not expose all of the data you may expect. However, in my experience. the Meraki API is one of the best APIs out there. This is not because of breadth and depth of data, but due to Meraki's focus on being "API first", having proper documentation, and how quickly they iterate on their API's features. ScienceLogic Meraki Best Practices Don't expect to have all the data for everything. Meraki does not expose everything in the API and they don't intend the tools like ScienceLogic provides to, in effect, replicate their database into SL1. As Meraki abstracts some of the complexities away from the operator, reconsider what your goals are and what you want to monitor. For example, do you care about CPU util for an AP or do you just care about the overall health of the AP or the network as a whole? Don't expect per minute collections for interfaces. The Meraki API will not support that much data. Don't merge devices unless you have static IP address. Meraki recommends you use DHCP. Meraki also doesn't expose much information through SNMP anyway. If you merge physically discovered Meraki devices with components discovered through the API and IP addresses change, you will have a bunch of devices incorrectly merged. Perhaps discovering via hostname is an option for you, but in general it is advised to just stick with component mapping from the API. Use Email/Webhook alerts! The Meraki PowerPack is designed very carefully to not hammer the Meraki API and surpass the fairly gracious API rate limit. In theory SL1 could make up to 800,000 API calls per day per Meraki Org and you'd be surprised how quickly SL1 can hit that if you try to collect everything all the time. Our PowerPack is designed to scale to over 100,000 devices on a single SL1. As such, we do not attempt to collect much data that is already alerted on with the built-in Meraki Alerts. Enable Meraki Alerts and configure them to be sent into SL1 and you will effectively double your monitoring coverage of Meraki with SL1. Our PowerPack is designed to provide you visibility into the things Meraki doesn't alert you to out-of-the-box. Simplicity is key! I don't know about you, but I think the best software is simple software. We avoid doing as many "custom" things as we can in the Meraki PowerPack and we rely on core features of SL1 where possible to keep the integration stable and easy to support. Unfortunately, complexity couldn't be avoided entirely. You'll find things like RBAs to create new DCM trees for each Meraki Organization and the "Request Manager" Dynamic Application which is a complex mechanism that schedules and limits API calls to Meraki at a level of efficiency not possible without bespoke logic. Other than those items, you'll find that the Meraki PowerPack relies heavily on stock SL1 features like the following: SL1 allows you to select what DAs align to components when they are modeled, but does not enable different alignment based on device classes. As such, you may see some DAs align to devices that we don't expect to collect data (such as Uplink collections aligning to switches and APs although Meraki does not provide uplink data for those devices). You will also find that device class alignment is straight forward and simple in the Meraki Powerpack. We utilize class identifiers 1 and 2 to provide three levels of classification. If a specific model matches a class identifier, we give it that device class, if the model doesn't match entirely, but it starts with characters that give us an idea as to what kind of device it is (MS for switch, MR for AP, etc), we will give it a generic class for that kind of device. If none of the identifiers match, we will give it a generic Meraki class from the device component tab of the discovery Dynamic Application. Adding new device classes should easy, but you also should never have to add your own due to this three tier approach using basic SL1 features. Starting in Meraki API v115, most customization will be handled in the credential. Some Powerpacks may use changes in the snippet code or even use thresholds as "toggles" for certain features. The goal with the Meraki PowerPack is to allow customization in a sustainable way. In v115, you will find more options to configure what API calls to enable, SSL cert verification, and of course selective discovery all as options in the new "Universal" Credential subtype provided for Meraki. Be kind to the API! Think hard about what you really need to collect and monitor. As we get requests to collect more items from Meraki, we have no choice but to ship these to you in a disabled state. If you turn on every collection in the Meraki PowerPack, and you have more than a few thousands devices in a Meraki Organization, you are likely to hit the API rate limit quickly. Think hard about what you want to achieve and turn on collections selectively. You will find a handy guide in the PowerPack manual that lists out every Dynamic Application, what devices it collects data against, and the alignment and enablement status they default to out-of-the-box. The API rate limit is shared between tools. You may know that Meraki limits API calls per organization, but did you know, according to the Meraki documentation they also limit API rate limit based on source IP regardless of the Organization you're querying? This means that if you are monitoring 10 or more organizations from the same IP address, you will have a lower rate limit per organization as they all share 100 calls per second. If you are an MSP monitoring multiple customer Meraki Orgs, keep this in mind! Also, if you are monitoring the same org from multiple tools, you are sharing the rate limit between them. If you have another monitoring tool, or even another SL1 querying the same Meraki Org, you may be causing the rate limit to go into effect prematurely. If you have any concerns, navigate to the API Analytics page in the Merak Dashboard and you will see all of the various API tools hitting that bucket. Selective Discovery - The Meraki PowerPack allows you to limit discovery to devices and networks with certain tags. Add the tags to your credential and devices without those tags will not be modeled in SL1. As always, I'm happy to chat about Meraki or our other integrations, so don't hesitate to schedule time through your account manager! Do you have any tips or tricks? Share them in the comments!
