Joe_Williams
ProfessorJoined 7 years ago
User Profile
Professor
User Widgets
Contributions
Re: SNMP Traps - Baseline for alerting
Best practice is 100% dependent on your network of course. But, yes, my professional opinion, that I openly give to our clients is Trap based alerting is not best practice. But I would not suggest replacing all Trap based monitoring with stateful SSH-based datasources either. That would require a lot of customization in the platform and SSH-based datasources can weigh heavy on a collector. What should most likely happen in your environment is a full review of your datasources, make sure they are up to date, and a venn diagram of what it is the network team wants to alert on, what is covered by default in the platform, and then what could be utilized to cover something. Then if needed use traps. But also a new perspective on the network side, trap based alerting doesn't allow for metrics. Or easily customization of an alert. If they want to trigger on say a high temp alert in a router, they have to adjust the setting across all of their routers to set the high state alert. If you have proper devops, this isn't to hard of a change, but its a change in the operational environment, vs making a threshold change in LogicMonitor itself. That change doesn't have a chance of impacting operations of the device. Personally, I also treat syslog like traps. For the purposes of network monitoring, I avoid it, and highly suggest everyone does. For the same exact reasons as traps. Syslog tho still has its place in SIEM/SOC related items, Voice and some others. But for pure network monitoring, generally you can get everything you want via polling.9Views1like0CommentsRe: SNMP Traps - Baseline for alerting
I couldn't find it now, but there used to be a blog post I would link to all the time about where LogicMonitor basically said, traps are bad don't use them. I imagine that is why there isn't a baseline. While SNMP has been "on a decline" for years and should eventually be replaced, and slowly is via API based monitoring, traps do need to die. The closest I found was a LM person posting on SpiceWorks. Traps are generally 1 time fires with no checking on their resolution. If you miss the trap, it for some reason didn't make it, you do not have an alert. Also the statement of "traps are a fundamental part of network monitoring" is a falsehood. If you are keeping up on refresh cycles and firmware upgrades, almost all enterprise level network gear these days would either be full on SNMP based polling, or API based polling. Now I am not saying a trap isn't still needed here or there. We encounter this from time to time, but its a very limited basis and we can generally build something better. Like a stateful ssh monitor that logs in, runs a command and returns an output that we can use for a datapoint.21Views2likes2CommentsRe: Connectivity between LogicMonitor collector to LogicMonitor SaaS Platform
From my experience, the Collector is periodically making outbound HTTPS connections to checkin. When it checks in, it looks for things like Collector updates, remote connection requests, Datasource updates, etc. This is how most modern tools like LogicMonitor work with SaaS based items as a persistent tunnel flags a lot of items now adays.20Views2likes0CommentsRe: Provide LogicMonitor explicit URLs for whitelisting to enable outbound connectivity
From my experience in working with this part of LogicMonitor, for basic operations, you can simply tell the client to add your portal address over 443 to the allow list. So far for standard monitoring, this only breaks trying to install a collector via the CDN. This is not counting monitoring of something like Meraki or another cloud management solution from their collector. The reason you would not be able to get a full proper list is because it's a cloud product. Things get moved, HA affects items etc.... Another item to look at is providing to the client, LogicMonitor is SOC2 and ISO 27001 compliant. This usually allows you to position yourself in a better frame of reference with a client's security team. Some of that info can be found here.15Views1like0CommentsRe: Topology Map Icons
So you most likely are setting a location property on the main set of folders. To get around this, you would want to set location on a per device basis. Then you can have a main location dashboard for a more NOC style overview, and separate dashboards based on each team. The separate dashboards would be an easy clone of the main and just change out the defaultResourcegroup variable for the proper folder.9Views0likes0CommentsRe: Can someone explain the CPU 5 minute load average thing to me?
The Linux load average represents the average number of processes either running on the CPU or waiting for resources (CPU or I/O). These averages are given as three numbers: 1-minute, 5-minute, and 15-minute averages. A general rule of thumb is that your load average should not exceed the total number of CPU cores in your system. For example, if your server has 8 cores, a load average of 8 means all cores are fully utilized, and anything higher indicates tasks are queuing. Short bursts above this limit, reflected in the 1-minute average, can be normal depending on workload. However, sustained overloads in the 5- or 15-minute averages may point to performance bottlenecks. To find the number of CPU cores you can use: cat /proc/cpuinfo | grep processor | wc -l Or you can use something like top or htop. Keep in mind that high load averages can also result from I/O bottlenecks, not just CPU saturation.20Views0likes0Comments
Groups
Inner Circle
Welcome to the Customer Showcase, sponsored by “The Inner Circle “. Feel free to peruse this Customer Story Showcase to read more about what our customers are doing out in the world and how LogicMonitor is supporting their journeys.
11 Posts Open Beta
Open Beta Process During this open beta period, we are asking that your team members flip the toggle and explore all the new features and functionality while attempting to complete their workflows in the new UI. Any identified bugs or feedback on critical functionality loss will help us to ensure your success and value in this new offering. *Please note, depending on what’s discovered, users can always toggle back to the current UI and continue with their work. Identified bugs or Feedback can be submitted through the following routes: Bugs: Please submit directly through the “Submit a Support Ticket” option using your instance. The more specific you can be on where you experienced the bug, the better. Functionality Feedback: Please submit through the “Feedback” option in your LogicMonitor instance and include “New UI” in the Subject line to ensure it’s routed appropriately.
72 Posts
