Server Monitoring with Zabbix
You can find several startup script examples within the zabbix-1.8.1/misc/init.d directory. Copy the one for your installation to /etc/init.d, and make any necessary changes. For Ubuntu, I used the scripts located in the debian directory. In both the server and agent configuration files, I needed to change the location of the binary from /home/zabbix/bin to /usr/local/sbin.
The zabbix-1.8.1/frontends/php directory contains the Web-based front end to Zabbix. Copy this directory structure somewhere below Apache's DocumentRoot, and load that URL in your Web browser. You will be greeted with the Zabbix Introduction screen (Figure 1). This wizard-like page steps through your configuration and presents you with a License Agreement. The next screen details any configuration changes that need to be made before continuing, such as PHP memory and execution time settings.
Once past the configuration screen, the main login screen loads. The default account is Admin with the password zabbix. Of course, once you're logged in, change the default password. The front-end layout consists of two rows of options (Figure 2). Click Administration, then Users. Make sure the pull-down menu located on the right side of the screen has Users selected instead of User Groups. Next, click on the admin user. A configuration page for the Admin user is shown (Figure 3). First, change the password. Also, add an e-mail address (click Add next to the Media line), as we're going to configure alerts to be sent via e-mail later in this article.
Three files need to be copied to a new client: the zabbix_agentd client binary to /usr/sbin, the zabbix_agentd.conf configuration file to /etc/zabbix and an init script. Edit the zabbix_agentd.conf configuration file, and change the line that reads Server= to equal the Zabbix server name, and change the Hostname= line to equal the client hostname. Once completed, start up the zabbix agent with the init script.
Back on the Zabbix server Web page, click Configuration→Hosts within the Web front end. Make sure Hosts is selected in the pull-down menu on the right-hand side of your screen, and then click the Create Host button. The Hosts configuration screen appears (Figure 4). You can give your host any name you choose, but I recommend staying with the short hostname (hostname -s) instead of a fully qualified domain if you can. Add it into the Linux servers group, and populate the DNS name with the fully qualified DNS name. I could choose to monitor this host with its IP address, but I'll trust that DNS always will be up to date. The only other change to this page is to click Add under the Linked templates area. Click the radio button next to Template_Linux and choose Select at the bottom of this pop-up window. Back at the Host screen, click Save. All the monitoring Items and Triggers included in the Template_Linux will be added to the client.
The Zabbix monitoring structure starts with Items (checks or collects data), then Triggers (monitors data in Items) and finally, Actions (e-mail, SMS or run scripts).
Items can be considered the “data collectors”. Some items are built in to the agent binary, and others will be custom scripts. After installing Zabbix, you will have a range of templates that contain these Items for common operating systems checks, such as Linux, Solaris, MAC OS X and Windows systems.
Let's look at the template we used with our first client. Using the Global search box at the upper right-hand side, search for “Template_Linux”. The search results should return a page that has links to the Items, Triggers or Graphs for this template (Figure 5). Select the Items link. All these Items will be monitored on any host that has the Template_Linux template applied to it, such as the first host configured above.
Click the Item called Free disk space on /. Here are all the details for this Item (Figure 6). Most fields are self-explanatory, but here are few important ones:
Description: a free form field that describes the check. Note that in the free disk space check there is a $1. Zabbix replaces this with the first field in the key (explained later).
Type: a Zabbix agent type is a check preformed by the agent running on the client at defined intervals. A Zabbix agent check is compiled in the binary, such as checking free disk space, number of free/used inodes or a custom written script. Another type is a Zabbix Trapper. A Zabbix Trapper acts like an SNMP trap. Its value is updated only when the client sends the update by running the binary zabbix_sender. For example, say you have a cron job that takes 30 minutes to finish. Normally, the Zabbix server will timeout waiting for a response from the client running this script. A better way would be to add a line in the cron job script to update the Zabbix server when it's finished using the zabbix_sender program. Another type of check is called Simple checks. This is used for agent-less clients—for example, pinging a host or checking a specific port (e-mail, SSH and so on) with an external host.
Key: this field is the “expression” that Zabbix will check. It can be a built-in key, such as the free disk space item (vfs.fs.size[/,free]) or a custom script that you wrote. The documentation details all the built-in keys and expressions that can be used.
You also can tell Zabbix what type of data is going to be returned: text, characters or numbers and a multiplier for that value. Also, you can specify for how long you want fine-grained graphs (history) and trends. The Applications section is where you can group similar checks. For example, if you were adding another filesystem item, you would add it to the Filesystem application.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds