Unanswered questions

I am looking for advice/help on monitoring Cisco Nexus 9000 Series switches.  The metrics the business is asking to monitor are: Metric   CPU Utilization   Memory Utilization   Device reload Alert   Interface errors (ifInErrors and ifOutErrors) (CRC, FCS)   Interface Discards ( ifInDiscards and ifOutDiscards)   Interface status   Utilization Bandwidth   PSU status   Fans   BGP/OSPF status   SNMP availability   TCAM Utilization monitoring (working to get MIB/OID from Cisco)   MAC Table Exhaustion  

We have been dealing with unknown behavior in our ScienceLogic Environment, and we would like to explain point wise to keep it clean.Application Team has reported us that File system Unavailable events are landing in their SNOW queue in the form of ticket. We have investigated and File System unavailable major events have been triggered. Furthermore, we have navigated into Registry » Hardware » searched with specific server name to find out reported File System have been discovered or not. We have found that those are not discovered and when connected back to the application team. we have got two types of inputs. 1st » multiple File System unavailable event are trigger for user profile for example /home/baljeets [whenever user log into Solaris Server. there profile will be created and once they logoff from the server FS related to their profile will be unmounted and ScienceLogic triggers major] 2nd » backup job will be triggering time to time and once the backup job is complete. same k

The vEdge Container availability check does not currently validate vManage REST API availability. Because of this limitation, the vEdge Container can remain available even when API-dependent vEdge devices, which are child components under the vEdge Container, are impacted. This prevents topology-based event suppression from working as expected and can result in multiple child component availability alerts for a single API-related outage.Proposed Enhancement: -Enhance the vEdge Container availability logic by adding an availability check via the vManage REST API. If the API is unavailable, the vEdge Container should also fail the availability check and move to an unavailable state.Expected Behavior: -When the vManage REST API is unavailable, the vEdge Container should fail its availability check. The vEdge Container should be marked as unavailable before the child vEdge devices generate individual availability alerts. Topology-based event suppression should suppress availability alerts

For powershell devices, when a device is first discovered, the cred used to added into this cred keys table, and then nightly discovery will also use that cred. You can also add a second cred from the properties page. The issue i found is that if you change creds, for whatever reason the cred key table doesn’t get updated. We have created a DA which dynamically aligns DAs using ‘from sl_credentials.constants import CRED_POWERSHELL’ to pull the credentials. because its not updated the DA doesn’t work Is there a way to pull the credential for a powershell device more dynamically, also, i think the nightly discovery also uses the same, so I think that it would also fail?Or is there a process which updates the table? 

We would like to get an update for following disclaimer for on Linux Base Pack v114. Reason being, it has been almost 5 months, and it has not been update on SL Support Portal ** We are currently reviewing a potential performance-related issue that we have identified internally with Linux Base Pack v114. We will provide an update on next steps once our evaluation is complete. **

Hello Team,There is a requirement coming from our client to monitor all the certificates configured on v-centersThe certificate includes Machine SSL, trusted root certificate,Below are the some sample certificates which is required to be monitored.