Recent Content
Got a Game-Changing SL1 Story? Here's Why You Should Apply for the 2025 Innovators Awards
1 MIN READ Nominations close August 20 — Apply or nominate someone here. We're ready to shine a spotlight on the bold thinkers and change-makers in our ScienceLogic community. The Innovators Awards celebrate customers and partners who push boundaries, solve tough challenges, and deliver real results using SL1. Whether you’re leading an automation initiative, building something brilliant with PowerFlow or turning chaos into clarity across your IT ecosystem—we want to hear from you. Here are 3 quick reasons to apply (or nominate a colleague) before August 20: Get the recognition your work deserves Innovation doesn’t always shout—it solves, improves, transforms. The Innovators Awards give your team the credit and visibility it’s earned, across the Nexus Community and beyond. Inspire others across the ScienceLogic ecosystem Your journey could help another customer spark their own transformation. Past winners have become the go-to examples of SL1 innovation—and your story could be next. Be featured and celebrated Winners receive exclusive recognition at Nexus Live 2025, plus promotion through customer blogs, newsletter and in social. Today is your day to be celebrated. How to Apply The process is easy—and open to all customers and partners with an active SL1 deployment and a great story to share. Apply here by August 20. Let’s all celebrate the best of our community. Apply or nominate someone today.Meet our Newest Blogger- Michael Leonberger
1 MIN READ With three decades of progressive leadership in technology and service delivery, Michael brings a unique combination of technical expertise and customer-focused innovation to every engagement. His diverse background spanning MSPs and Federal agencies—with deep expertise in Security, Systems, Networking, and Observability—provided the perfect foundation for his transformative 21-year journey with ScienceLogic. This experience uniquely positioned him to understand both the technical complexities and operational challenges that organizations face in today's rapidly evolving technology landscape. At ScienceLogic, Michael has partnered with hundreds of clients to drive deployment efficiencies, architect custom solutions, and establish industry best practices. His collaborative approach and deep technical insight have consistently delivered measurable results across diverse environments and use cases. Beyond client delivery, Michael and his team are the architects behind innovative service offerings including the Optimization Access Service (OAS) program and the Operational Insights PowerPack(s)—solutions that have redefined how organizations approach IT optimization and operational visibility. Keep an eye out for some great posts and videos from Michael and team. mleonbergerShine Bright Nexus Community: Innovators Awards Applications Are Open for 2025!
2 MIN READ You’ve done something remarkable with ScienceLogic SL1—and now it’s your time to shine. We're thrilled to officially launch the 2025 ScienceLogic Innovators Awards, and we're calling on all problem-solvers, big thinkers, and pioneers in our customer community to share how you're using SL1 in unique and game-changing ways. Whether you're automating what no one else thought possible, eliminating operational noise, or delivering jaw-dropping results that made your CIO do a double take—we want to hear your story. This isn't just an award. It’s your opportunity to take the stage (literally). Winners will be celebrated live at Nexus Live this October, featured on-stage in front of their peers, industry leaders, and the broader ScienceLogic community. You’ll join a group of recognized innovators who are pushing the boundaries of what’s possible with AIOps, ITOps, and beyond. Why You Should Apply Because your story deserves to be told—and recognized. Because your team should feel proud of what they’ve accomplished. Because your work might just inspire someone else’s next big breakthrough. What We’re Looking For We’re not looking for “perfect.” We’re looking for bold ideas. Real transformation. Smart applications of SL1 that drive results. If that sounds like you, now’s the time to step up and share it. Winners will receive: An official ScienceLogic Innovators Award A feature in our In the Know newsletter and across our digital channels A spotlight within the Nexus Community An opportunity to tell your story in a ScienceLogic webinar or blog A media kit to share the good news with your social networks And of course, on-stage recognition at Nexus Live 2025 Think You’ve Got a Winning Story? We believe you do. The deadline to apply is August 20, 2025, and the process is simple. Just bring your best story of results-based innovation to the table. Apply now to share your impact and get the recognition your work deserves. The stage is set. Will you be on it?Register Now for the Nexus Live Conference October 7-9, 2025 | Reston, VA
1 MIN READ Your Peers. Your Community. Your Event. Nexus Live 2025 is an immersive learning experience, and a one-of-a-kind connection that brings the ScienceLogic community together for three days to share knowledge, network, and meet industry thought leaders. At Nexus Live (formerly Symposium), you can ideate how to empower IT to solve your most challenging concerns. From Proactive Observability and AI-Driven Operations solutions to Intelligent Automations, our conversations will be meaningful and relevant to you! The age of the IT champion has arrived—and their greatest ally is agentic AI. Be a part of the Nexus Live magic. Register NowIntegrating Okta Authentication with ScienceLogic PowerFlow
4 MIN READ Enabling SSO Authentication for PowerFlow ScienceLogic PowerFlow supports external authentication via Dex, which bridges OpenID Connect (OIDC) Identity Providers (IdPs) like Okta to PowerFlow. This guide outlines configuring Okta as an OIDC IdP, enabling user and group-based login. Important: All third-party IdP related configurations should be performed by the organization’s Identity and Access Management (IAM) team and must comply with corporate security policies. SaaS Deployments: This article applies to on-premises instances of PowerFlow. For SaaS-hosted PowerFlow, submit a request via the ScienceLogic Support Portal with your Dex connector config. Overview This guide walks through the following: Setting up Okta as an OIDC IdP Making Okta’s /default server accessible to Dex Optionally including group claims Configuring the Dex connector Supporting group/non-group logins Testing and Validation Summary Prerequisites Before beginning, ensure the following are available: Access to Okta admin console (e.g. <org>.okta.com) A DNS name or IP for Dex callback endpoint (e.g. https://<IP>:5556/dex/callback) Admin Okta account Step 1: Register a Web App in Okta Start by creating a new OIDC app integration in Okta: Navigate to Applications → Create App Integration Choose: Sign-in method: OIDC – OpenID Connect Type: Web App Configure the application: App Integration Name: PowerFlow Grant type: Authorization Code (Default) Sign-in redirect URI: https://<IP>:5556/dex/callback Sign-out redirect URI https://<IP>:5556/logged-out.html Controlled access: Skip group assignment for now Click on Save and note the Client ID and Client Secret - Required to configure the Dex connector Step 2: Assign Users or Groups Click Assignments within the newly created application. Assign to individuals or pre-created groups Step 3: Allow Access to Okta’s /default Authorization Server Okta’s authorization server (/oauth2/default) requires policy rules to allow access by external clients like Dex and to enable Groups scope to be transmitted in the token. To configure access: Go to Security → API → Authorization Servers → default → Access Policies Add/Edit a policy rule: Name: Allow Dex Assign to: All clients or specific client Grant Types: Implicit and Authorization Code Scopes: Ensure openid, email, profile, and optionally groups are allowed Save and activate the rule Step 4: Include Group Claims in ID Tokens (Optional) If group-based access is desired, a custom claim must be added: Go to Security → API → Authorization Servers → default → Claims Click Add Claim: Name: groups Token: ID Token Enable Always include in token Value type: Groups Filter: .* (to include all groups, or restrict as needed) Include in: Any scope or groups Save the claim This ensures group data is included in tokens Dex uses to perform identity mapping. Step 5: Configure the Dex Connector Edit '/etc/iservices/isconfig.yml' and append the following: DEX_CONNECTORS: - type: oidc id: okta name: Okta config: issuer: https://[instance].okta.com/oauth2/default clientID: [your-client-id] clientSecret: [your-client-secret] redirectURI: https://[powerflow-ip-or-host]:5556/dex/callback basicAuthUnsupported: true insecureSkipEmailVerified: true insecureEnableGroups: true userNameKey: email scopes: - openid - profile - email - groups Note: Omit groups in scope if not using group-based access. PowerFlow will authenticate user's based on the user’s email address. Explanation of Key Fields: issuer: Must match the exact Okta authorization server URL redirectURI: Should match what is registered in the Okta app scopes: Include groups only if using group-based claims userNameKey: Determines how the username is derived (e.g., email) Apply Configuration 1. Redeploy the Docker Stack: # Remove stack docker stack rm iservices # Wait for shutdown docker service ls # Redeploy docker stack deploy -c /opt/iservices/scripts/docker-compose.yml iservices --resolve-image never # Verify docker service ls 3. Monitor Dex Logs: # docker service logs -f iservices_dexserver Step 6: PowerFlow User and Groups Configuration In PowerFlow UI: Go to Admin Panel → Add User Group: Match Okta group name (e.g, Operator) or email where group-based access is not configured in IdP Assign permissions Click Create User Group Step 7: Testing and Validation 1. Verify Authentication: Access the PowerFlow login page and initiate OIDC login. Confirm redirection to Okta and successful login. 2. Monitor Dex Logs: # docker service logs -f iservices_dexserver Check for success: login successful: connector "OKTA", username="jane.doe@domain.com", email="jane.doe@domain.com", groups=["Operator"] Step 9: Troubleshooting Issue Solution Groups Scope not exposed Check policy rule under default server includes appropriate grant types and scopes Redirect URI mismatch Check Dex’s redirectURI exactly matches Okta app’s redirect URI Refer to Step 7.2 above for details on reviewing the Dex logs. Summary Integrating Okta (or another OIDC IdP) with PowerFlow via Dex enhances security, simplifies access, and supports both user and group‑based login. By following the outlined the above steps ensuring proper authentication setup —organizations can integrate SSO effectively while maintaining secure access controls. For assistance, contact ScienceLogic Support. For further details related to PowerFlow authentication and DEX connectors, refer to the official ScienceLogic documentation.ScienceLogic's PowerFlow Training: Explore Built-In Integration and Custom Automation Capabilities
1 MIN READ PowerFlow is ScienceLogic’s integration platform designed to seamlessly extract, transform, and load data between SL1 and third-party tools. Whether you're implementing built-in integrations or creating custom automations, PowerFlow empowers you to streamline workflows, integrate systems, and enhance IT operations. Find the Right Training for Your Needs Explore training options based on your role and objectives: PowerFlow: ScienceLogic's Bi-Directional Task Execution Platform (1 hour) Discover PowerFlow’s core functionality in this introductory learning path, covering key features, configuration, navigation, and troubleshooting. PowerFlow Integrations: ServiceNow (4 hours) Master PowerFlow’s integration with ServiceNow. This comprehensive learning path includes all content from the introductory PowerFlow course, then dives deeper into implementing SL1 and ServiceNow integration use cases. PowerFlow: Software Development Kit (SDK) (1 hour) For advanced users, this training course shows how to use the PowerFlow Software Development Kit (SDK) to build custom SyncPacks for automation, system integration, and workflow enhancements. Access Training Anytime, Anywhere ScienceLogic University is ScienceLogic's on-demand learning portal. Log in or create an account here to access these PowerFlow training options and other essential topics.Six Years of Trust—and It’s All Thanks to You
1 MIN READ We’re thrilled to share some exciting news: ScienceLogic SL1 has been named a TrustRadius Top Rated product for the sixth year in a row! 🎉 This recognition means the world to us—not just because it’s based entirely on customer feedback, but because it reflects something deeper: your trust. Trust in our platform, our people, and our partnership. “Customer success is our north star. Being recognized by TrustRadius for the sixth year in a row shows that we’re not just delivering technology—we’re helping our customers achieve real, measurable outcomes.” — Wendy Wooley, VP of Customer Experience This year, SL1 earned Top Rated honors in eight key categories that matter most to modern IT teams: AIOps Observability Event Monitoring System Monitoring Network Monitoring IT Infrastructure Monitoring IT Operations Analytics Application Performance Management (APM) Your feedback is our compass—it guides how we innovate, where we focus, and how we continue to evolve SL1 to meet your needs. So thank you for sharing your stories, your challenges, and your wins. We’re honored to be on this journey with you. Here’s to what we’ve built together—and what’s next.Optimising PowerFlow Integrations: Isolating Incident and CMDB Workloads
3 MIN READ In complex IT environments, integrations like incident management and Configuration Management Database (CMDB) synchronisation are pivotal. ScienceLogic's PowerFlow platform offers robust capabilities to handle these integrations. However, to ensure optimal performance and prevent resource contention, it's crucial to configure dedicated steprunners and queues for different workloads. This article discusses on-premises instances of PowerFlow. If you are using a SaaS-hosted instance of PowerFlow, please submit a service request via the Support Portal outlining your requirements. The relevant team will then review your request and discuss the necessary changes to be made on your SaaS instance of PowerFlow. Understanding the Challenge Incident management and CMDB synchronisation have distinct characteristics: Incident Management: Typically involves lightweight, high-frequency tasks that require rapid processing to maintain real-time responsiveness. CMDB Synchronisation: Often deals with bulk data operations, such as syncing large volumes of configuration items, which are resource-intensive and time-consuming. Running both integrations on the same steprunner can lead to performance issues. For instance, a heavy CMDB sync might consume significant resources, delaying the processing of critical incident tasks. Implementing Dedicated Steprunners and Queues To address this, PowerFlow allows the configuration of steprunners to listen to specific queues. By assigning separate queues for incident and CMDB tasks, you can isolate their processing and allocate resources appropriately. Example Configuration Here's how you might define dedicated steprunners in your docker-compose.override.yml: Incident Steprunner: steprunner-incident: image: sciencelogic/is-worker:latest hostname: "incident-{{.Task.ID}}" deploy: resources: limits: memory: 2G replicas: 10 environment: user_queues: 'incident_queue' worker_threads: 4 CMDB Steprunner: steprunner-cmdb: image: sciencelogic/is-worker:latest hostname: "cmdb-{{.Task.ID}}" deploy: resources: limits: memory: 4G replicas: 5 environment: user_queues: 'cmdb_queue' worker_threads: 2 In this setup: user_queues: Assigns each steprunner to a specific queue (incident_queue or cmdb_queue), ensuring isolation of workloads. worker_threads: Defines how many concurrent tasks each steprunner container can process. Higher for incidents because incident syncs are typically lightweight and frequent. Lower for CMDB to reduce memory contention since CMDB data is often bulkier and more complex. deploy.resources.limits.memory: Caps how much memory each steprunner container can use. This helps prevent individual steprunners from consuming excessive memory, which is especially important when running many containers on shared infrastructure. Example: 2G for incidents (moderate), 4G for CMDB (higher due to heavier payloads). deploy.replicas: Specifies how many containers to run for each steprunner service. More replicas for incidents to handle high throughput. Fewer for CMDB, since each task may take longer and use more resources. Benefits of Isolation Performance Optimisation: Ensures that resource-heavy CMDB tasks don't impede the processing of time-sensitive incident tasks. Scalability: Allows independent scaling of steprunners based on the workload demands of each integration. Resource Management: Facilitates fine-tuned allocation of system resources, reducing the risk of bottlenecks and failures. Monitoring and Adjustments Regular monitoring is essential to maintain optimal performance: Queue Lengths: Persistent growth in queue lengths may indicate the need for additional steprunners or increased thread counts. Resource Utilisation: Monitor CPU and memory usage to prevent over utilisation. Error Rates: High error rates might necessitate adjustments in configurations or error-handling mechanisms. Final Thoughts By strategically configuring dedicated steprunners and queues for incident and CMDB integrations, you can enhance the efficiency, reliability, and scalability of your PowerFlow environment. This approach ensures that each integration operates within its optimal parameters, delivering better performance and resource utilisation.
How to Generate a PowerPack Version Report in SL1 to Track Updates and Changes
3 MIN READ To successfully merge your custom changes into a new PowerPack version, you’ll need to understand how to identify the differences between versions. This process involves: Comparing the original PowerPack version (used to create your custom version) to your customized version – to identify custom changes. Comparing the original PowerPack version to the new ScienceLogic-released version – to identify new features and updates. After understanding these deltas, you can determine whether: The new version already includes features that cover your customizations, or You need to merge and reapply custom changes onto the new version. Let’s walk through the process using an example and then detail the steps to generate and compare PowerPack reports in SL1. Example Scenario Suppose your team customized PowerPack version 112 and named it 112.1. ScienceLogic has since released version 115. To upgrade your custom PowerPack to a new branch (say, 115.1), you’ll need to: ✅ Compare 112 vs 112.1 to identify what was customized. ✅ Compare 112 vs 115 to identify what’s new from ScienceLogic. ✅ Review release notes for versions 113, 114, and 115 to spot added features or fixes. ✅ Decide which customizations are still needed and merge them into 115.1. Step 1: Generate PowerPack Information Reports SL1 provides a built-in report to list the contents of a PowerPack version. Here’s how to generate it: 1️⃣ Ensure the PowerPack version you wish to report on is installed in your SL1 stack. ⚠️ Important: Do this in a non-production or test environment, as installing older versions may affect data or configurations. 2️⃣ Navigate to the Reports section in SL1. Go to Reports (Navigation Bar). Under Run Report > EM7 Administration, select Power-Pack Information. Choose the specific PowerPack version to report on. Select the Excel format as the output and click Generate. 3️⃣ Save the generated Excel file. 🔁 Repeat this process for each version you wish to compare (e.g., original, customized, and new versions). Step 2: Compare PowerPack Versions Using Excel Now that you have the reports: 1️⃣ Open both Excel files (e.g., 112.xlsx and 112.1.xlsx) in Excel. 2️⃣ If the Developer tab isn’t visible: Click File > Options > Customize Ribbon. Under Main Tabs, enable Developer and click OK. 3️⃣ Under the Developer tab, click COM Add-ins. Check the Inquire add-in and enable it. 4️⃣ You should now see an Inquire tab. Select Compare Files. Choose the two files you want to compare. A Spreadsheet Compare window will open showing the differences. 💡Pro Tip: 🔹 Ignore differences in fields like ID and Edit Date – these are environment-specific and reflect the PowerPack installation date. 🔹 To reduce confusion, consider hiding or removing these columns in Excel before performing the comparison. 🔍 Instead, focus on meaningful differences, such as: Additional or removed objects, including: Dynamic Apps Summary Dynamic Apps Details Event Policies Device Classes Reports Dashboard Widgets Dashboards SL1 Dashboards ScienceLogic Libraries Actions Credentials Changes to version numbers or descriptions for these objects, indicating feature updates or enhancements. This focused comparison helps ensure you’re identifying functional changes rather than irrelevant metadata. Final Thoughts By systematically generating and comparing PowerPack reports: You can clearly identify what customizations were made and what changes the new version introduces. This helps you confidently plan your PowerPack upgrade path and minimize risks. ✅ Review release notes for intermediate versions to avoid duplicating enhancements already included by ScienceLogic. ✅ Always perform this analysis in a non-production environment first. With this approach, you’ll be able to efficiently track PowerPack updates and changes while maintaining your critical customizations.Best Practices for Device Discovery in SL1
1 MIN READ Effective device discovery is a foundational step in building a robust monitoring environment in ScienceLogic SL1. This guide focuses on best practices when performing manual or guided discoveries via the SL1 user interface. For a full overview of the discovery process, refer to the official documentation: 👉 SL1 Discovery Process Documentation Key Best Practices 1. DNS Configuration When discovering devices by hostname, ensure that DNS is properly configured and functional on the collector. Improper DNS settings can prevent successful device resolution and discovery. 2. Use CIDR Notation Thoughtfully If you're using CIDR notation to define the discovery range: Stick with smaller ranges, such as /24, to limit the scope. Large CIDR blocks can overwhelm the discovery process and slow down the collector. 3. Avoid Overloading the Collector Attempting to discover too many devices in one session can lead to performance degradation. A general rule of thumb (on a medium sized collector): SNMP: Up to 1,000 devices SSH (Linux): Around 500 devices PowerShell (Windows): Around 100 devices 💡 Tip: For large-scale discovery, distribute the workload across multiple collectors or collector groups. 4. Preview Discovery Results Before running a full discovery session, run it with "Model Devices" deselected. This allows you to see what will be discovered without impacting device modelling or performance. 5. Test Credentials First Always use the Credential Tester tool to validate new credentials before launching a discovery session. This ensures that: The collector can communicate with the target devices The credentials are correctly configured and accepted Helpful Resources 🔐 Creating SL1 Credentials 🛠️ Using the Credential Tester ❗ Troubleshooting Discovery Issues
