ScienceLogic SL1

SL1 events are forwarded to Netcool which creates tickets in Servicenow. Software was developed for generating events and synchronizing the databases. Ansible playbooks was created to manage Sciencelogic reports and PP deployment

With the correct access, the integrations are really seamless. One of the biggest plusses of ScienceLogic is it's ability to integrate with different systems and especially in an environment with multiple tenants.

Unfortunately I was not part of this integration.

We monitor memory, cpu, swap, ping which are under the standard discovery along with bespoke monitors, the bespoke monitors range from checking for URL sites being down to writing python code in a dynamic app to integrate and interrogate other systems which pull back information and act upon that information, either with an alert passing the alert to pager duty or passing it to Rundeck to fire off an automation to try and fix the issue or fire off a runbook to try and fix the issue along with raising a ticket into the hornbill system for tracking. We have also integrated this into the hornbill's cloud ticketing system. If anyone would like to see a working example of python code that they can use and expand on to help integrate Hornbill ticketing with SL1 I have an example in the hornbills forums that you can create a runbook automation from. https: //community.hornbill.com/topic/22170-im-wanting-to-create-hornbill-tickets-using-linux-os-with-curl-also-by-using-the-python-programming-language-to-access-the-api/#comment-105100 Remove the space in-front of the https above This should Fastrack anyone who is trying to achieve the same. The alerts in science logic do not inherit ticket number information, i.e. an alert is raised as a major, it creates a ticket and receives a ticket number then the Alert changes to a critical state. in essence the major alert and the critical alert are totally individual and the details of the ticket reference will not be passed through, you have to manually fire off a runbook which looks for a previous state and if it exists then pull the ticket value from that and update the new alert with it. This for me was an unexpected find but I did manage to create a work around by directly calling the Database and performing queries on it to obtain the information needed. I did reach out to science logic on this, through the management team and through the support portal, once again I found them very helpful.

OOB pack for integration did not suffice the requirement and hence we need to get help from PS to build custom integration for our stack.

We want SL to play a Manager of Manager and integrated the different monitoring tools and Native tools. Used the API,SNMP trap methods to integrate

Not too difficult

Powerflow

I haven't taken part on it

Integrating other tools with SL is Quite easy compare to other tools in the market.

Any of this integration was smooth. It would be good to have PowerPacks created for them. Cisco-ISE is a wide known product.

In each case, we have integrated SL1 (EM7) for the purposes of workflow automation. For Solutions 360 and SalesForce, it was to generate trouble tickets from SL1 events. For XIO Cloud, it was to ingest XIO Cloud alerts and create SL1 events. All solutions were REST API development efforts with programmatic PUT and GET requests respectively. The ScienceLogic API call for creating events is very simple to implement and we've found the API very flexible to use.

It is pretty easy to have Auvik create events in SL1 based on failed backups or unable to connect to devices

ServiceNow - We currently use SyncServer (starting our migration to Integration Service / PowerFlow soon). We had to take Change Management away from SyncServer and do it for Host Clusters, Application Clusters, Application Endpoint monitoring as well as SyncServers Host monitoring) because of our scale / load.

Epage - We have long done our own paging service. Recipients have long been put into groups which are responsible for CIs. During our initial stand up, we took those groups and instantiated them as on-stack Organizations with members from the same source. (This is a very different view of who has access from the normal ScienceLogic / ServiceNow Company focus, but it fits our culture which continues to prefer our custom-fit solution.)

ART - Our ART integration grants users rights (basic rights, slightly elevated rights or platform admins). The Epage Organizations define what CIs can be seen. (A continuing pain-point in the platform, but we are working with ScienceLogic to introduce a solution that fits our needs and is part of the core platform in coming releases.)