Discussion Forums
A place for dialogue and discovery about our products and services
Resource Library
Access our collection of helpful videos, guides, templates, and more
User Groups
Connect with members that have common interests or goals
Node Navigation
Recent Content
SL1 Ibiza 12.3.4 Release Notification
We are pleased to announce that SL1 Ibiza 12.3.4 is now available. The release and documentation can be accessed using the following links: https://support.sciencelogic.com/s/release-file/aBtVL0000000wgj0AA/1234 If you are planning to consume SL1 Ibiza 12.3.4, be advised of the following: The 12.3.4 release is available only as a patch; there is no ISO version. You can upgrade to this release directly from the following releases: SL1 12.3.0 through 12.3.3 SL1 12.2.1.1 through 12.2.6 SL1 12.1.2, if all of your SL1 appliances have been converted to OL8 NOTE: If you are on12.1.2, you should upgrade directly to 12.3.4 without consuming the 12.2.x releases. WARNING: If you are upgrading from a version prior to 12.2.3, then after upgrading SL1, you must also upgrade MariaDB 10.4.x to version 10.6.18. Failure to perform this MariaDB upgrade can cause major functionality issues in SL1. If you are on 12.1.0.2 or 12.1.1, you can upgrade to 12.1.2, convert to OL8, and then upgrade directly to 12.3.4 without consuming the 12.2.x releases. 12.2.x and 12.3.0 STIG-compliant users can upgrade to this release. If you are on an 11.x MUD system, you cannot upgrade directly to this release; you must first follow the approved conversion process from 11.x MUD to12.2.1.1 STIG and then upgrade to 12.3.4 STIG. For more information, see the section on STIG Support. AWS deployments that are using Aurora 3 can upgrade to this release. If you are currently deployed using Aurora 2, you can upgrade to this release but you must perform a post-upgrade Aurora 2 to 3 conversion. SL1 12.3.4 is Department of Defense Information Network (DoDIN)-certified. If you are planning to consume SL1 Ibiza 12.3.4, be advised of the following: The 12.3.4 release is available only as a patch; there is no ISO version. You can upgrade to this release directly from the following releases: SL1 12.3.0 through 12.3.3 SL1 12.2.1.1 through 12.2.6 SL1 12.1.2, if all of your SL1 appliances have been converted to OL8 NOTE: If you are on12.1.2, you should upgrade directly to 12.3.4 without consuming the 12.2.x releases. WARNING: If you are upgrading from a version prior to 12.2.3, then after upgrading SL1, you must also upgrade MariaDB 10.4.x to version 10.6.18. Failure to perform this MariaDB upgrade can cause major functionality issues in SL1. If you are on 12.1.0.2 or 12.1.1, you can upgrade to 12.1.2, convert to OL8, and then upgrade directly to 12.3.4 without consuming the 12.2.x releases. 12.2.x and 12.3.0 STIG-compliant users can upgrade to this release. If you are on an 11.x MUD system, you cannot upgrade directly to this release; you must first follow the approved conversion process from 11.x MUD to12.2.1.1 STIG and then upgrade to 12.3.4 STIG. For more information, see the section on STIG Support. AWS deployments that are using Aurora 3 can upgrade to this release. If you are currently deployed using Aurora 2, you can upgrade to this release but you must perform a post-upgrade Aurora 2 to 3 conversion. SL1 12.3.4 is Department of Defense Information Network (DoDIN)-certified. For more information, see SL1 Ibiza 12.3.4 release notes.SL1 Hollywood 12.2.7 Release Notification
We are pleased to announce that SL1 Hollywood 12.2.7 is now available. The release and documentation can be accessed using the following link: https://support.sciencelogic.com/s/release-file/aBtVL0000000wiL0AQ/1227 If you are planning to consume SL1 Hollywood 12.2.7, be advised of the following: The12.2.7 release is available only as a patch; there is no ISO version. SaaS deployments cannot upgrade to 12.2.7; this release is limited to on-premises deployments only. You can upgrade to 12.2.7 directly from the following SL1 versions: 12.1.2, if all appliances are running on Oracle Linux 8 (OL8) 12.2.1.2 through 12.2.6 On-premises STIG-compliant users can upgrade to 12.2.7. Users who currently use Python 3.9 execution environments for Dynamic Applications and Run Book Automations should not upgrade to 12.2.7. Due to a known issue, Python 3.9 is not supported in this release. Unsupported Upgrade Paths You cannot upgrade to SL1 12.2.7 in the following scenarios: You are on a SaaS deployment of SL1. You have not yet deployed or upgraded to an SL1 version in which all appliances are running on Oracle Linux 8 (OL8). WARNING: All customers who are upgrading from a version of SL1 prior to 12.1.2 must first upgrade to SL1 12.1.2 and then convert to OL8 before upgrading to SL1 12.2.7. All older SL1 systems with OL7 are still operable, but ScienceLogic no longer supports them, and the systems might not be secure. For full details, please see the SL1 Hollywood 12.2.7 release notes: https://docs.sciencelogic.com/release_notes/sciencelogic_12-2-7_release_notes.pdf
Any way to "ignore ssl" in a web content monitor?
Hi All, We're trying to do a quick and dirty web content monitor, very simple, just hit a target website and if you see a 200 it is a 'success'. I created the web content monitor and when SL1 hits the endpoint in the UI we get a timeout error. To make sur eit wasn't something else we ran a "curl -k https://website" from the collector and it worked, however ssl failure without the -k. It doesn't appear that there is an option to turn off ssl verification in the web content screen, but please let me know if I'm mistaken?ScienceLogic Meraki Monitoring Best Practices
6 MIN READ 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!
Trap Threshold in a Event Policy
Hello SL community, I'm trying to create some events based on traps received. Some of the policies require a threshold to match an event. For example, the "tempOfSensor:" string should trigger a Critical event if the value is between 60 and 65. Is there a way to include a range of values in a trap-based alert, using either the result of an OID or a value inside that trap? Something similar to what we can do with a Dynamic Event Source.
Inventory Cisco Stacked Switches
Is there a way to add Cisco Stacked switches to ScienceLogic to allow the ServiceNow CMDB SyncPack to sync the switches that are not master using Sync Devices from SL1 to ServiceNow? I can export the stack switches from the data collected from the Entity Configuration application to get a list of all switches and serial numbers. We would like to have the ability to add stack switches as some type of device to sync using ServiceNow CMDB. Thanks🌟Nexus Member Top Contributors – April 2025 🌟
Celebrating the Champions Who Power Our Community April was an incredible month in the Nexus Community—buzzing with meaningful discussions, powerful insights, and an inspiring level of collaboration. Today, we’re proud to spotlight the standout members whose contributions made the biggest waves. 🙌 Thank You to Our April MVPs To everyone who raised their hand to help, shared knowledge generously, or offered valuable feedback—your presence is what makes Nexus thrive. Your contributions don’t go unnoticed, and your impact is truly appreciated. 💡 Every Contribution Counts Whether you're sharing a tip, asking a thoughtful question, or casting a vote on an idea—you’re helping shape a smarter, more connected community. Your input drives progress, fuels innovation, and supports peers on their journeys. 👏 April’s Standout Contributors 🔥 Most Page Views teppotahkapaa followed by Mani then Jasonkeck-GDIT tied with wimcoelus 💬 Most Replies Issac followed by teppotahkapaa and then but7villa_kd 🗳️ Most Idea Votes Given teppotahkapaa followed by Joel then trothe 🏆 Most Idea Votes Received cplus followed by but7villa_kd then Savage 🚀 Let’s Keep the Momentum Going! We’re building something great—together. Stay engaged, keep sharing your wisdom, and invite others to do the same. If you’re new to the community, now’s the perfect time to jump in. Every voice adds value here. Thank you once again to all who made April a month to remember. Let’s carry that energy into May and beyond! – The Nexus Community TeamA Big Thanks to You—Our Amazing Customers
2 MIN READ At ScienceLogic, our customers and partners aren’t just using our tech—you’re shaping what’s next. You’re the reason we show up every day ready to build, improve, and reimagine IT operations. So this Customer Appreciation Day, we want to pause and just say: thank you. Thanks for trusting us. Thanks for pushing us with your ideas. And thanks for being the reason we’re always reaching for better. 2025: What We’ve Built Together This year’s been all about leveling up—together. We’ve focused on making IT smarter, faster, and more self-sufficient. And your need for agility, speed, and innovation? That’s been our compass. From boosting observability across complex environments to introducing Agentic AI inside SL1, it’s all about helping IT teams move from reactive to proactive—and now, into the world of autonomy. Here are just a few of the things we’re proud to bring to the table: Agentic AI that doesn’t just automate—it thinks and acts on its own, giving your team more time for big-picture work. Next-gen observability tools that go beyond alerts and help you understand the full story—what’s happening, where, why, and what to do about it. More customer-driven product design—because your voice guides what we build, always. Our Progress Starts with You Every product release, every new feature, every late-night brainstorm—it all starts with you. Your feedback, your goals, your challenges. You push us to do more, and we’re better for it. Whether you’ve been with us from the beginning or just joined the ScienceLogic community, we’re so glad you’re here. Your journey shapes ours, and we’re beyond grateful for that. From all of us at ScienceLogic: thank you for being part of this ride. We’re excited to keep building the future with you. Thank you for being the best part of ScienceLogic!Cisco: Hyperflex v106 PowerPack Release Notification
We are pleased to announce that the Cisco: Hyperflex v106 PowerPack has been released. The download for this release can be found on the Support Portal under the PowerPack filename: https://support.sciencelogic.com/s/release-version/aBu0z000000XZg1CAG/cisco-hyperflex Enhancements and Issues Addressed The following enhancements and addressed issues are included in this release: Addressed an issue that caused major events from Cisco: Hyperflex Dynamic Applications that were not aligned to any devices to overwhelm syslogs during discovery. Please refer to the Cisco: Hyperflex v106 PowerPack File Details in the PowerPacks section of the Support Portal for all information pertaining to the Cisco: Hyperflex v106 PowerPack Support Status, Minimum SL1 Version, Solution Information, and Pricing Information. The Cisco: Hyperflex v106 Py3 PowerPack Release File Details also contains links to the Release Notes, Manual, and PowerPack Info Report. Issues Addressed in the Cisco: Hyperflex v106 PowerPack Release can be found in the Release Notes
AP2 Dashboard PowerPacks
Please be advised that ScienceLogic has transitioned all AP2 Dashboard Powerpacks (typically containing “SL1 Dashboards” in the name) to “Community” support status. These Powerpacks will remain accessible for download, however they will no longer receive official updates from ScienceLogic. Our support team will still provide “best effort” troubleshooting/assistance, and ScienceLogic reserves the right to update these products in the future if required. We appreciate your understanding of this change.
How to manage duplicate IP addresses
This is more general question for SL and users, When monitoring for example a clustered firewall, so two separate similar FWs. Then discovery does its things and discovers devices and all their IP addresses. And the worst case is then that there are tens and tens same IP addresses between those devices. OK, for monitoring per se it is not that bad issue, but SL1 itself is then sending events as long as there are same ip address uses in those devices. Can that feature, scan all IPs, be disabled by default? Does the "Port Scan All IPs" in discovery session disable that? If reading that name it is just about if it is scanning open ports for all IPs found. What is the SL recommended way to delete those duplicate IPs. Most of the time in our env it is using pure mysql commands.
