Knowledge Base
Knowlegebase articles
Welcome to SysOrb knowledge base. Her you will find detailed explanation on questions regarding SysOrb. The list is under continues development and new articles will be added. You can follow the links below or enter a "key word" to search all of the articles.
- Agent crashes
- Automatic rescan of all nodes in a domain
- Bandwidth consumption estimate
- Basic database tuning
- Can I customize the reports in SysOrb?
- Disabling specific checks
- Does SysOrb support SNMP traps?
- Explanation of the score keeper strategy.
- How does HTTP Netcheck work in SysOrb?
- How to automatically update alert group on all nodes to “As domain”
- How to backup SysOrb database
- How to change time interval value of agent_checkin_delay
- How to move the SysOrb server to a new server
- How to quickly set downtime on an agent
- I cannot get all of the "performance counters/cache" entries to appear in SysOrb what should I do?
- Migrating MIB information from one SysOrb installation to another
- Migrating the configuration of a Windows SysOrb server from 32 to 64 bits
- No empty blocks in meta database.
- Script to get a list of nodes which have no AlertGroup
- SysOrb agent is not checking in to the Sysorb server
- SysOrb agent stops checking in from a windows server with very long system uptime
- SysOrb server shuts down unexpectedly
- System uptime no longer updates on windows
- Unable to monitor hardware (fans, disks, temperatures etc.) on Windows
- Upgrading SysOrb on Windows
- Uploading a SysOrb database to Evalesco
- What does KiB and MiB mean?
- What is IPMI ?
- Windows agent late for check-in every hour
How to quickly set downtime on an agent
When in a hurry or performing emergency administrative actions, it can be rather inconvenient to have to locate a given server in the SysOrb web interface and configure downtime there, in order to prevent false alarms being sent to users in the alert group.
SysOrb versions prior to 3.6 only allowed web based configuration of so-called "unexpected downtime" (the downtime setting used when temporarily disabling alerting from a server for a relatively short amount of time). When performing administrative actions on the server console or on a remote shell, it can be cumbersome to have to also start up the web interface and locate the given server there in order to configure downtime. If downtime is not configured, alerts may be dispatched due to checks spuriously failing because of the administrative actions that are being performed.
If you, for example, need to re-start the web server service or daemon, you risk sending out alerts to other administrators of the server, if you do not configure downtime on the server prior to restarting the service or daemon. Given that the restart often takes just a few seconds, and locating the server (even when using the web interface search feature) might take a minute, it is tempting to just do the re-start and hope SysOrb doesn't notice the missing web service in the few seconds it is away.
In SysOrb 3.6, downtime can now be set directly from the agent. It is no longer necessary to use the web interface to configure "unexpected downtime" on a server.
On a Windows system you can use the "Set Agent in Downtime" option in the Start Menu. A single click on this option will set 30 minutes of downtime on the node (including SNMP checks, NetChecks and AgentChecks).
On Windows, UNIX and Linux systems you can use a simple command line argument to the agent executable. On the command line run
soagent --down
This too, will set downtime on the node (including SNMP, NetChecks and AgentChecks) for 30 minutes.
If you want another interval you can specify an integer number of minutes with the down option; for example:
soagent --down=90
which will set one and a half hour of downtime.
One significant side effect of this functionality is, that you can now also set downtime easily from your own scripts. If, for example, you have software upgrade scripts or system configuration scripts that re-start services, you can now let these scripts set a few minutes of downtime on the node before they restart services. And there is no longer any excuse for administrators for not setting downtime before restarting services.
