Tip: If you already have a list of the SNMP capable devices by hostname or IP address, Zenoss Core can import them via the zenbatchload command.
In its simplest form, zebatchload will process a text file that lists one device per line. Here’s a sample list of devices that I will call deviceList.txt:
device01
router02
web03
Since zenbatchload is a Zenoss Core daemon, we need to run it as the zenoss user. Here are the commands:
su – zenoss
<enter zenoss user’s password>
zenbatchload deviceList.txt
The zenbatchload import utility will not update devices that are already in the device inventory.
Tip: Editing organizers: You can change the name or description of an organizer by selecting the organizer and then clicking on Edit. You can find the Edit option by clicking on the Actions menu button (which looks like a sprocket) at the bottom of the Infrastructure sidebar. See the following screenshot:
Moving organizers: You can nest organizers by dragging and dropping one organizer into another one to create a hierarchy. You can only nest similar organizers, which means that you cannot move a system into a group or a group into a location.
Tip: If you see an event that indicates zeneventlog is unable to connect to Windows, that’s an indication Zenoss Core is not able to authenticate to the Windows server. Check the Configuration Properties (zProperties) of the device to ensure you have the correct username and password set.
The following screenshot shows the WMI specific zProperties:
Remember, the zWinUser and zWinPassword properties must be an administrator on the Windows server you’re monitoring. It’s possible that each of your Windows servers could require a different username and password.
The zWinUser property can be either a local or a domain account. If you use a domain account, specify the domain for the zWinuser value (for example, mojoactiveadministrator).
Tip: It’s possible that Zenoss Core isn’t collecting any data from the Windows Servers via WMI, but there are no events reported. You can check the following zProperties at the device or class level:
Tip: Acknowledging an event signals to other team members and to Zenoss Core that you are aware of the event and, presumably, taking action. Acknowledging the event is good communication among your team, but Zenoss Core can also escalate event severities or alerts based on an event status.
A common way to escalate an event or an alert is by the event count. For example, we can instruct Zenoss Core to escalate the event severity from Error to Critical if the event hasn’t been acknowledged after a specified number of monitoring cycles. Or if we’re dealing with alerts, Zenoss Core can be configured to alert the next person on call, in the event you fall asleep on the roof at 3 in the morning and don’t realize the database server has been down for 15 minutes.
To acknowledge an event:
A check mark will appear next to the event. See the following screenshot:
In the screenshot all the events are acknowledged, except the first one.
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…