mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-25 00:50:15 +08:00
XLCYun
commit
186d09ac06
99
sources/talk/20150806 5 heroes of the Linux world.md
Normal file
99
sources/talk/20150806 5 heroes of the Linux world.md
Normal file
@ -0,0 +1,99 @@
|
||||
5 heroes of the Linux world
|
||||
================================================================================
|
||||
Who are these people, seen and unseen, whose work affects all of us every day?
|
||||
|
||||
|
||||
Image courtesy [Christopher Michel/Flickr][1]
|
||||
|
||||
### High-flying penguins ###
|
||||
|
||||
Linux and open source is driven by passionate people who write best-of-breed software and then release the code to the public so anyone can use it, without any strings attached. (Well, there is one string attached and that’s licence.)
|
||||
|
||||
Who are these people? These heroes of the Linux world, whose work affects all of us every day. Allow me to introduce you.
|
||||
|
||||
|
||||
Image courtesy Swapnil Bhartiya
|
||||
|
||||
### Klaus Knopper ###
|
||||
|
||||
Klaus Knopper, an Austrian developer who lives in Germany, is the founder of Knoppix and Adriana Linux, which he developed for his blind wife.
|
||||
|
||||
Knoppix holds a very special place in heart of those Linux users who started using Linux before Ubuntu came along. What makes Knoppix so special is that it popularized the concept of Live CD. Unlike Windows or Mac OS X, you could run the entire operating system from the CD without installing anything on the system. It allowed new users to test Linux on their systems without formatting the hard drive. The live feature of Linux alone contributed heavily to its popularity.
|
||||
|
||||
|
||||
Image courtesy [Fórum Internacional Software Live/Flickr][2]
|
||||
|
||||
### Lennart Pottering ###
|
||||
|
||||
Lennart Pottering is yet another genius from Germany. He has written so many core components of a Linux (as well as BSD) system that it’s hard to keep track. Most of his work is towards the successors of aging or broken components of the Linux systems.
|
||||
|
||||
Pottering wrote the modern init system systemd, which shook the Linux world and created a [rift in the Debian community][3].
|
||||
|
||||
While Linus Torvalds has no problems with systemd, and praises it, he is not a huge fan of the way systemd developers (including the co-author Kay Sievers,) respond to bug reports and criticism. At one point Linus said on the LKML (Linux Kernel Mailing List) that he would [never work with Sievers][4].
|
||||
|
||||
Lennart is also the author of Pulseaudio, sound server on Linux and Avahi, zero-configuration networking (zeroconf) implementation.
|
||||
|
||||
|
||||
Image courtesy [Meego Com/Flickr][5]
|
||||
|
||||
### Jim Zemlin ###
|
||||
|
||||
Jim Zemlin isn't a developer, but as founder of The Linux Foundation he is certainly one of the most important figures of the Linux world.
|
||||
|
||||
In 2007, The Linux Foundation was formed as a result of merger between two open source bodies: the Free Standards Group and the Open Source Development Labs. Zemlin was the executive director of the Free Standards Group. Post-merger Zemlin became the executive director of The Linux Foundation and has held that position since.
|
||||
|
||||
Under his leadership, The Linux Foundation has become the central figure in the modern IT world and plays a very critical role for the Linux ecosystem. In order to ensure that key developers like Torvalds and Kroah-Hartman can focus on Linux, the foundation sponsors them as fellows.
|
||||
|
||||
Zemlin also made the foundation a bridge between companies so they can collaborate on Linux while at the same time competing in the market. The foundation also organizes many conferences around the world and [offers many courses for Linux developers][6].
|
||||
|
||||
People may think of Zemlin as Linus Torvalds' boss, but he refers to himself as "Linus Torvalds' janitor."
|
||||
|
||||
|
||||
Image courtesy [Coscup/Flickr][7]
|
||||
|
||||
### Greg Kroah-Hartman ###
|
||||
|
||||
Greg Kroah-Hartman is known as second-in-command of the Linux kernel. The ‘gentle giant’ is the maintainer of the stable branch of the kernel and of staging subsystem, USB, driver core, debugfs, kref, kobject, and the [sysfs][8] kernel subsystems along with many other components of a Linux system.
|
||||
|
||||
He is also credited for device drivers for Linux. One of his jobs is to travel around the globe, meet hardware makers and persuade them to make their drivers available for Linux. The next time you plug some random USB device to your system and it works out of the box, thank Kroah-Hartman. (Don't thank the distro. Some distros try to take credit for the work Kroah-Hartman or the Linux kernel did.)
|
||||
|
||||
Kroah-Hartman previously worked for Novell and then joined the Linux Foundation as a fellow, alongside Linus Torvalds.
|
||||
|
||||
Kroah-Hartman is the total opposite of Linus and never rants (at least publicly). One time there was some ripple was when he stated that [Canonical doesn’t contribute much to the Linux kernel][9].
|
||||
|
||||
On a personal level, Kroah-Hartman is extremely helpful to new developers and users and is easily accessible.
|
||||
|
||||
|
||||
Image courtesy Swapnil Bhartiya
|
||||
|
||||
### Linus Torvalds ###
|
||||
|
||||
No collection of Linux heroes would be complete without Linus Torvalds. He is the author of the Linux kernel, the most used open source technology on the planet and beyond. His software powers everything from space stations to supercomputers, military drones to mobile devices and tiny smartwatches. Linus remains the authority on the Linux kernel and makes the final decision on which patches to merge to the kernel.
|
||||
|
||||
Linux isn't Torvalds' only contribution open source. When he got fed-up with the existing software revision control systems, which his kernel heavily relied on, he wrote his own, called Git. Git enjoys the same reputation as Linux; it is the most used version control system in the world.
|
||||
|
||||
Torvalds is also a passionate scuba diver and when he found no decent dive logs for Linux, he wrote his own and called it SubSurface.
|
||||
|
||||
Torvalds is [well known for his rants][10] and once admitted that his ego is as big as a small planet. But he is also known for admitting his mistakes if he realizes he was wrong.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.itworld.com/article/2955001/linux/5-heros-of-the-linux-world.html
|
||||
|
||||
作者：[Swapnil Bhartiya][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.itworld.com/author/Swapnil-Bhartiya/
|
||||
[1]:https://flic.kr/p/siJ25M
|
||||
[2]:https://flic.kr/p/uTzj54
|
||||
[3]:http://www.itwire.com/business-it-news/open-source/66153-systemd-fallout-two-debian-technical-panel-members-resign
|
||||
[4]:http://www.linuxveda.com/2014/04/04/linus-torvalds-systemd-kay-sievers/
|
||||
[5]:https://flic.kr/p/9Lnhpu
|
||||
[6]:http://www.itworld.com/article/2951968/linux/linux-foundation-offers-cheaper-courses-and-certifications-for-india.html
|
||||
[7]:https://flic.kr/p/hBv8Pp
|
||||
[8]:https://en.wikipedia.org/wiki/Sysfs
|
||||
[9]:https://www.youtube.com/watch?v=CyHAeGBFS8k
|
||||
[10]:http://www.itworld.com/article/2873200/operating-systems/11-technologies-that-tick-off-linus-torvalds.html
|
||||
@ -1,68 +0,0 @@
|
||||
Translating by GOLinux!
|
||||
How to Use LVM on Ubuntu for Easy Partition Resizing and Snapshots
|
||||
================================================================================
|
||||
|
||||
|
||||
Ubuntu’s installer offers an easy “Use LVM” checkbox. The description says it enables Logical Volume Management so you can take snapshots and more easily resize your hard disk partitions — here’s how to do that.
|
||||
|
||||
LVM is a technology that’s similar to [RAID arrays][1] or [Storage Spaces on Windows][2] in some ways. While this technology is particularly useful on servers, it can be used on desktop PCs, too.
|
||||
|
||||
### Should You Use LVM With Your New Ubuntu Installation? ###
|
||||
|
||||
The first question is whether you even want to use LVM with your Ubuntu installation. Ubuntu makes this easy to enable with a quick click, but this option isn’t enabled by default. As the installer says, this allows you to resize partitions, create snapshots, merge multiple disks into a single logical volume, and so on — all while the system is running. Unlike with typical partitions, you don’t have to shut down your system, boot from a live CD or USB drive, and [resize your partitions while they aren’t in use][3].
|
||||
|
||||
To be perfectly honest, the average Ubuntu desktop user probably won’t realize whether they’re using LVM or not. But, if you want to do more advanced things later, LVM can help. LVM is potentially more complex, which could cause problems if you need to recover your data later — especially if you’re not that experienced with it. There shouldn’t be a noticeable performance penalty here — LVM is implemented right down in the Linux kernel.
|
||||
|
||||
|
||||
|
||||
### Logical Volume Management Explained ###
|
||||
|
||||
We’re previously [explained what LVM is][4]. In a nutshell, it provides a layer of abstraction between your physical disks and the partitions presented to your operating system. For example, your computer might have two hard drives inside it, each 1 TB in size. You’d have to have at least two partitions on these disks, and each of these partitions would be 1 TB in size.
|
||||
|
||||
LVM provides a layer of abstraction over this. Instead of the traditional partition on a disk, LVM would treat the disks as two separate “physical volumes” after you initialize them. You could then create “logical volumes” based on these physical volumes. For example, you could combine those two 1 TB disks into a single 2 TB partition. Your operating system would just see a 2 TB volume, and LVM would deal with everything in the background. A group of physical volumes and logical volumes is known as a “volume group.” A typical system will just have a single volume group.
|
||||
|
||||
This layer of abstraction makes it possibly to easily resize partitions, combine multiple disks into a single volume, and even take “snapshots” of a partition’s file system while it’s running, all without unmounting it.
|
||||
|
||||
Note that merging multiple disks into a single volume can be a bad idea if you’re not creating backups. It’s like with RAID 0 — if you combine two 1 TB volumes into a single 2 TB volume, you could lose important data on the volume if just one of your hard disks fails. Backups are crucial if you go this route.
|
||||
|
||||
### Graphical Utilities for Managing Your LVM Volumes ###
|
||||
|
||||
Traditionally, [LVM volumes are managed with Linux terminal commands][5].These will work for you on Ubuntu, but there’s an easier, graphical method anyone can take advantage of. If you’re a Linux user used to using GParted or a similar partition manager, don’t bother — GParted doesn’t have support for LVM disks.
|
||||
|
||||
Instead, you can use the Disks utility included along with Ubuntu for this. This utility is also known as GNOME Disk Utility, or Palimpsest. Launch it by clicking the icon on the dash, searching for Disks, and pressing Enter. Unlike GParted, the Disks utility will display your LVM partitions under “Other Devices,” so you can format them and adjust other options if you need to. This utility will also work from a live CD or USB drive, too.
|
||||
|
||||
|
||||
|
||||
Unfortunately, the Disks utility doesn’t include support for taking advantage of LVM’s most powerful features. There’s no options for managing your volume groups, extending partitions, or taking snapshots. You could do that from the terminal, but you don’t have to. Instead, you can open the Ubuntu Software Center, search for LVM, and install the Logical Volume Management tool. You could also just run the **sudo apt-get install system-config-lvm** command in a terminal window. After it’s installed, you can open the Logical Volume Management utility from the dash.
|
||||
|
||||
This graphical configuration tool was made by Red Hat. It’s a bit dated, but it’s the only graphical way to do this stuff without resorting to terminal commands.
|
||||
|
||||
Let’s say you wanted to add a new physical volume to your volume group. You’d open the tool, select the new disk under Uninitialized Entries, and click the “Initialize Entry” button. You’d then find the new physical volume under Unallocated Volumes, and you could use the “Add to existing Volume Group” button to add it to the “ubuntu-vg” volume group Ubuntu created during the installation process.
|
||||
|
||||
|
||||
|
||||
The volume group view shows you a visual overview of your physical volumes and logical volumes. Here, we have two physical partitions across two separate hard drives. We have a swap partition and a root partition, just as Ubuntu sets up its partitioning scheme by default. Because we’ve added a second physical partition from another drive, there’s now a good chunk of unused space.
|
||||
|
||||
|
||||
|
||||
To expand a logical partition into the physical space, you could select it under Logical View, click Edit Properties, and modify the size to grow the partition. You could also shrink it from here.
|
||||
|
||||
|
||||
|
||||
The other options in system-config-lvm allow you to set up snapshots and mirroring. You probably won’t need these features on a typical desktop, but they’re available graphically here. Remember, you can also [do all of this with terminal commands][6].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.howtogeek.com/211937/how-to-use-lvm-on-ubuntu-for-easy-partition-resizing-and-snapshots/
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.howtogeek.com/162676/how-to-use-multiple-disks-intelligently-an-introduction-to-raid/
|
||||
[2]:http://www.howtogeek.com/109380/how-to-use-windows-8s-storage-spaces-to-mirror-combine-drives/
|
||||
[3]:http://www.howtogeek.com/114503/how-to-resize-your-ubuntu-partitions/
|
||||
[4]:http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/
|
||||
[5]:http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/
|
||||
[6]:http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/
|
||||
@ -1,409 +0,0 @@
|
||||
translation by strugglingyouth
|
||||
How to monitor NGINX - Part 1
|
||||
================================================================================
|
||||
|
||||
|
||||
### What is NGINX? ###
|
||||
|
||||
[NGINX][1] (pronounced “engine X”) is a popular HTTP server and reverse proxy server. As an HTTP server, NGINX serves static content very efficiently and reliably, using relatively little memory. As a [reverse proxy][2], it can be used as a single, controlled point of access for multiple back-end servers or for additional applications such as caching and load balancing. NGINX is available as a free, open-source product or in a more full-featured, commercially distributed version called NGINX Plus.
|
||||
|
||||
NGINX can also be used as a mail proxy and a generic TCP proxy, but this article does not directly address NGINX monitoring for these use cases.
|
||||
|
||||
### Key NGINX metrics ###
|
||||
|
||||
By monitoring NGINX you can catch two categories of issues: resource issues within NGINX itself, and also problems developing elsewhere in your web infrastructure. Some of the metrics most NGINX users will benefit from monitoring include **requests per second**, which provides a high-level view of combined end-user activity; **server error rate**, which indicates how often your servers are failing to process seemingly valid requests; and **request processing time**, which describes how long your servers are taking to process client requests (and which can point to slowdowns or other problems in your environment).
|
||||
|
||||
More generally, there are at least three key categories of metrics to watch:
|
||||
|
||||
- Basic activity metrics
|
||||
- Error metrics
|
||||
- Performance metrics
|
||||
|
||||
Below we’ll break down a few of the most important NGINX metrics in each category, as well as metrics for a fairly common use case that deserves special mention: using NGINX Plus for reverse proxying. We will also describe how you can monitor all of these metrics with your graphing or monitoring tools of choice.
|
||||
|
||||
This article references metric terminology [introduced in our Monitoring 101 series][3], which provides a framework for metric collection and alerting.
|
||||
|
||||
#### Basic activity metrics ####
|
||||
|
||||
Whatever your NGINX use case, you will no doubt want to monitor how many client requests your servers are receiving and how those requests are being processed.
|
||||
|
||||
NGINX Plus can report basic activity metrics exactly like open-source NGINX, but it also provides a secondary module that reports metrics slightly differently. We discuss open-source NGINX first, then the additional reporting capabilities provided by NGINX Plus.
|
||||
|
||||
**NGINX**
|
||||
|
||||
The diagram below shows the lifecycle of a client connection and how the open-source version of NGINX collects metrics during a connection.
|
||||
|
||||
|
||||
|
||||
Accepts, handled, and requests are ever-increasing counters. Active, waiting, reading, and writing grow and shrink with request volume.
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">accepts</td>
|
||||
<td style="text-align: left;">Count of client connections attempted by NGINX</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">handled</td>
|
||||
<td style="text-align: left;">Count of successful client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">active</td>
|
||||
<td style="text-align: left;">Currently active client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">dropped (calculated)</td>
|
||||
<td style="text-align: left;">Count of dropped connections (accepts – handled)</td>
|
||||
<td style="text-align: left;">Work: Errors*</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">requests</td>
|
||||
<td style="text-align: left;">Count of client requests</td>
|
||||
<td style="text-align: left;">Work: Throughput</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="text-align: left;">*<em>Strictly speaking, dropped connections is <a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/#resource-metrics">a metric of resource saturation</a>, but since saturation causes NGINX to stop servicing some work (rather than queuing it up for later), “dropped” is best thought of as <a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/#work-metrics">a work metric</a>.</em></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
The **accepts** counter is incremented when an NGINX worker picks up a request for a connection from the OS, whereas **handled** is incremented when the worker actually gets a connection for the request (by establishing a new connection or reusing an open one). These two counts are usually the same—any divergence indicates that connections are being **dropped**, often because a resource limit, such as NGINX’s [worker_connections][4] limit, has been reached.
|
||||
|
||||
Once NGINX successfully handles a connection, the connection moves to an **active** state, where it remains as client requests are processed:
|
||||
|
||||
Active state
|
||||
|
||||
- **Waiting**: An active connection may also be in a Waiting substate if there is no active request at the moment. New connections can bypass this state and move directly to Reading, most commonly when using “accept filter” or “deferred accept”, in which case NGINX does not receive notice of work until it has enough data to begin working on the response. Connections will also be in the Waiting state after sending a response if the connection is set to keep-alive.
|
||||
- **Reading**: When a request is received, the connection moves out of the waiting state, and the request itself is counted as Reading. In this state NGINX is reading a client request header. Request headers are lightweight, so this is usually a fast operation.
|
||||
- **Writing**: After the request is read, it is counted as Writing, and remains in that state until a response is returned to the client. That means that the request is Writing while NGINX is waiting for results from upstream systems (systems “behind” NGINX), and while NGINX is operating on the response. Requests will often spend the majority of their time in the Writing state.
|
||||
|
||||
Often a connection will only support one request at a time. In this case, the number of Active connections == Waiting connections + Reading requests + Writing requests. However, the newer SPDY and HTTP/2 protocols allow multiple concurrent requests/responses to be multiplexed over a connection, so Active may be less than the sum of Waiting, Reading, and Writing. (As of this writing, NGINX does not support HTTP/2, but expects to add support during 2015.)
|
||||
|
||||
**NGINX Plus**
|
||||
|
||||
As mentioned above, all of open-source NGINX’s metrics are available within NGINX Plus, but Plus can also report additional metrics. The section covers the metrics that are only available from NGINX Plus.
|
||||
|
||||
|
||||
|
||||
Accepted, dropped, and total are ever-increasing counters. Active, idle, and current track the current number of connections or requests in each of those states, so they grow and shrink with request volume.
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">accepted</td>
|
||||
<td style="text-align: left;">Count of client connections attempted by NGINX</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">dropped</td>
|
||||
<td style="text-align: left;">Count of dropped connections</td>
|
||||
<td style="text-align: left;">Work: Errors*</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">active</td>
|
||||
<td style="text-align: left;">Currently active client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">idle</td>
|
||||
<td style="text-align: left;">Client connections with zero current requests</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">total</td>
|
||||
<td style="text-align: left;">Count of client requests</td>
|
||||
<td style="text-align: left;">Work: Throughput</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="text-align: left;">*<em>Strictly speaking, dropped connections is a metric of resource saturation, but since saturation causes NGINX to stop servicing some work (rather than queuing it up for later), “dropped” is best thought of as a work metric.</em></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
The **accepted** counter is incremented when an NGINX Plus worker picks up a request for a connection from the OS. If the worker fails to get a connection for the request (by establishing a new connection or reusing an open one), then the connection is dropped and **dropped** is incremented. Ordinarily connections are dropped because a resource limit, such as NGINX Plus’s [worker_connections][4] limit, has been reached.
|
||||
|
||||
**Active** and **idle** are the same as “active” and “waiting” states in open-source NGINX as described [above][5], with one key exception: in open-source NGINX, “waiting” falls under the “active” umbrella, whereas in NGINX Plus “idle” connections are excluded from the “active” count. **Current** is the same as the combined “reading + writing” states in open-source NGINX.
|
||||
|
||||
**Total** is a cumulative count of client requests. Note that a single client connection can involve multiple requests, so this number may be significantly larger than the cumulative number of connections. In fact, (total / accepted) yields the average number of requests per connection.
|
||||
|
||||
**Metric differences between Open-Source and Plus**
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;">NGINX (open-source)</th>
|
||||
<th style="text-align: left;">NGINX Plus</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">accepts</td>
|
||||
<td style="text-align: left;">accepted</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">dropped must be calculated</td>
|
||||
<td style="text-align: left;">dropped is reported directly</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">reading + writing</td>
|
||||
<td style="text-align: left;">current</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">waiting</td>
|
||||
<td style="text-align: left;">idle</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">active (includes “waiting” states)</td>
|
||||
<td style="text-align: left;">active (excludes “idle” states)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">requests</td>
|
||||
<td style="text-align: left;">total</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Metric to alert on: Dropped connections**
|
||||
|
||||
The number of connections that have been dropped is equal to the difference between accepts and handled (NGINX) or is exposed directly as a standard metric (NGINX Plus). Under normal circumstances, dropped connections should be zero. If your rate of dropped connections per unit time starts to rise, look for possible resource saturation.
|
||||
|
||||
|
||||
|
||||
**Metric to alert on: Requests per second**
|
||||
|
||||
Sampling your request data (**requests** in open-source, or **total** in Plus) with a fixed time interval provides you with the number of requests you’re receiving per unit of time—often minutes or seconds. Monitoring this metric can alert you to spikes in incoming web traffic, whether legitimate or nefarious, or sudden drops, which are usually indicative of problems. A drastic change in requests per second can alert you to problems brewing somewhere in your environment, even if it cannot tell you exactly where those problems lie. Note that all requests are counted the same, regardless of their URLs.
|
||||
|
||||
|
||||
|
||||
**Collecting activity metrics**
|
||||
|
||||
Open-source NGINX exposes these basic server metrics on a simple status page. Because the status information is displayed in a standardized form, virtually any graphing or monitoring tool can be configured to parse the relevant data for analysis, visualization, or alerting. NGINX Plus provides a JSON feed with much richer data. Read the companion post on [NGINX metrics collection][6] for instructions on enabling metrics collection.
|
||||
|
||||
#### Error metrics ####
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
<th style="text-align: left;"><strong>Availability</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">4xx codes</td>
|
||||
<td style="text-align: left;">Count of client errors</td>
|
||||
<td style="text-align: left;">Work: Errors</td>
|
||||
<td style="text-align: left;">NGINX logs, NGINX Plus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">5xx codes</td>
|
||||
<td style="text-align: left;">Count of server errors</td>
|
||||
<td style="text-align: left;">Work: Errors</td>
|
||||
<td style="text-align: left;">NGINX logs, NGINX Plus</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
NGINX error metrics tell you how often your servers are returning errors instead of producing useful work. Client errors are represented by 4xx status codes, server errors with 5xx status codes.
|
||||
|
||||
**Metric to alert on: Server error rate**
|
||||
|
||||
Your server error rate is equal to the number of 5xx errors divided by the total number of [status codes][7] (1xx, 2xx, 3xx, 4xx, 5xx), per unit of time (often one to five minutes). If your error rate starts to climb over time, investigation may be in order. If it spikes suddenly, urgent action may be required, as clients are likely to report errors to the end user.
|
||||
|
||||
|
||||
|
||||
A note on client errors: while it is tempting to monitor 4xx, there is limited information you can derive from that metric since it measures client behavior without offering any insight into particular URLs. In other words, a change in 4xx could be noise, e.g. web scanners blindly looking for vulnerabilities.
|
||||
|
||||
**Collecting error metrics**
|
||||
|
||||
Although open-source NGINX does not make error rates immediately available for monitoring, there are at least two ways to capture that information:
|
||||
|
||||
- Use the expanded status module available with commercially supported NGINX Plus
|
||||
- Configure NGINX’s log module to write response codes in access logs
|
||||
|
||||
Read the companion post on NGINX metrics collection for detailed instructions on both approaches.
|
||||
|
||||
#### Performance metrics ####
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
<th style="text-align: left;"><strong>Availability</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">request time</td>
|
||||
<td style="text-align: left;">Time to process each request, in seconds</td>
|
||||
<td style="text-align: left;">Work: Performance</td>
|
||||
<td style="text-align: left;">NGINX logs</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Metric to alert on: Request processing time**
|
||||
|
||||
The request time metric logged by NGINX records the processing time for each request, from the reading of the first client bytes to fulfilling the request. Long response times can point to problems upstream.
|
||||
|
||||
**Collecting processing time metrics**
|
||||
|
||||
NGINX and NGINX Plus users can capture data on processing time by adding the $request_time variable to the access log format. More details on configuring logs for monitoring are available in our companion post on [NGINX metrics collection][8].
|
||||
|
||||
#### Reverse proxy metrics ####
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
<th style="text-align: left;"><strong>Availability</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">Active connections by upstream server</td>
|
||||
<td style="text-align: left;">Currently active client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
<td style="text-align: left;">NGINX Plus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">5xx codes by upstream server</td>
|
||||
<td style="text-align: left;">Server errors</td>
|
||||
<td style="text-align: left;">Work: Errors</td>
|
||||
<td style="text-align: left;">NGINX Plus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">Available servers per upstream group</td>
|
||||
<td style="text-align: left;">Servers passing health checks</td>
|
||||
<td style="text-align: left;">Resource: Availability</td>
|
||||
<td style="text-align: left;">NGINX Plus</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
One of the most common ways to use NGINX is as a [reverse proxy][9]. The commercially supported NGINX Plus exposes a large number of metrics about backend (or “upstream”) servers, which are relevant to a reverse proxy setup. This section highlights a few of the key upstream metrics that are available to users of NGINX Plus.
|
||||
|
||||
NGINX Plus segments its upstream metrics first by group, and then by individual server. So if, for example, your reverse proxy is distributing requests to five upstream web servers, you can see at a glance whether any of those individual servers is overburdened, and also whether you have enough healthy servers in the upstream group to ensure good response times.
|
||||
|
||||
**Activity metrics**
|
||||
|
||||
The number of **active connections per upstream server** can help you verify that your reverse proxy is properly distributing work across your server group. If you are using NGINX as a load balancer, significant deviations in the number of connections handled by any one server can indicate that the server is struggling to process requests in a timely manner or that the load-balancing method (e.g., [round-robin or IP hashing][10]) you have configured is not optimal for your traffic patterns
|
||||
|
||||
**Error metrics**
|
||||
|
||||
Recall from the error metric section above that 5xx (server error) codes are a valuable metric to monitor, particularly as a share of total response codes. NGINX Plus allows you to easily extract the number of **5xx codes per upstream server**, as well as the total number of responses, to determine that particular server’s error rate.
|
||||
|
||||
**Availability metrics**
|
||||
|
||||
For another view of the health of your web servers, NGINX also makes it simple to monitor the health of your upstream groups via the total number of **servers currently available within each group**. In a large reverse proxy setup, you may not care very much about the current state of any one server, just as long as your pool of available servers is capable of handling the load. But monitoring the total number of servers that are up within each upstream group can provide a very high-level view of the aggregate health of your web servers.
|
||||
|
||||
**Collecting upstream metrics**
|
||||
|
||||
NGINX Plus upstream metrics are exposed on the internal NGINX Plus monitoring dashboard, and are also available via a JSON interface that can serve up metrics into virtually any external monitoring platform. See examples in our companion post on [collecting NGINX metrics][11].
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
In this post we’ve touched on some of the most useful metrics you can monitor to keep tabs on your NGINX servers. If you are just getting started with NGINX, monitoring most or all of the metrics in the list below will provide good visibility into the health and activity levels of your web infrastructure:
|
||||
|
||||
- [Dropped connections][12]
|
||||
- [Requests per second][13]
|
||||
- [Server error rate][14]
|
||||
- [Request processing time][15]
|
||||
|
||||
Eventually you will recognize additional, more specialized metrics that are particularly relevant to your own infrastructure and use cases. Of course, what you monitor will depend on the tools you have and the metrics available to you. See the companion post for [step-by-step instructions on metric collection][16], whether you use NGINX or NGINX Plus.
|
||||
|
||||
At Datadog, we have built integrations with both NGINX and NGINX Plus so that you can begin collecting and monitoring metrics from all your web servers with a minimum of setup. Learn how to monitor NGINX with Datadog [in this post][17], and get started right away with [a free trial of Datadog][18].
|
||||
|
||||
### Acknowledgments ###
|
||||
|
||||
Many thanks to the NGINX team for reviewing this article prior to publication and providing important feedback and clarifications.
|
||||
|
||||
----------
|
||||
|
||||
Source Markdown for this post is available [on GitHub][19]. Questions, corrections, additions, etc.? Please [let us know][20].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.datadoghq.com/blog/how-to-monitor-nginx/
|
||||
|
||||
作者：K Young
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://nginx.org/en/
|
||||
[2]:http://nginx.com/resources/glossary/reverse-proxy-server/
|
||||
[3]:https://www.datadoghq.com/blog/monitoring-101-collecting-data/
|
||||
[4]:http://nginx.org/en/docs/ngx_core_module.html#worker_connections
|
||||
[5]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#active-state
|
||||
[6]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[7]:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
|
||||
[8]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[9]:https://en.wikipedia.org/wiki/Reverse_proxy
|
||||
[10]:http://nginx.com/blog/load-balancing-with-nginx-plus/
|
||||
[11]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[12]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#dropped-connections
|
||||
[13]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#requests-per-second
|
||||
[14]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#server-error-rate
|
||||
[15]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#request-processing-time
|
||||
[16]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[17]:https://www.datadoghq.com/blog/how-to-monitor-nginx-with-datadog/
|
||||
[18]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#sign-up
|
||||
[19]:https://github.com/DataDog/the-monitor/blob/master/nginx/how_to_monitor_nginx.md
|
||||
[20]:https://github.com/DataDog/the-monitor/issues
|
||||
@ -0,0 +1,429 @@
|
||||
Installation Guide for Puppet on Ubuntu 15.04
|
||||
================================================================================
|
||||
Hi everyone, today in this article we'll learn how to install puppet to manage your server infrastructure running ubuntu 15.04. Puppet is an open source software configuration management tool which is developed and maintained by Puppet Labs that allows us to automate the provisioning, configuration and management of a server infrastructure. Whether we're managing just a few servers or thousands of physical and virtual machines to orchestration and reporting, puppet automates tasks that system administrators often do manually which frees up time and mental space so sysadmins can work on improving other aspects of your overall setup. It ensures consistency, reliability and stability of the automated jobs processed. It facilitates closer collaboration between sysadmins and developers, enabling more efficient delivery of cleaner, better-designed code. Puppet is available in two solutions configuration management and data center automation. They are **puppet open source and puppet enterprise**. Puppet open source is a flexible, customizable solution available under the Apache 2.0 license, designed to help system administrators automate the many repetitive tasks they regularly perform. Whereas puppet enterprise edition is a proven commercial solution for diverse enterprise IT environments which lets us get all the benefits of open source puppet, plus puppet apps, commercial-only enhancements, supported modules and integrations, and the assurance of a fully supported platform. Puppet uses SSL certificates to authenticate communication between master and agent nodes.
|
||||
|
||||
In this tutorial, we will cover how to install open source puppet in an agent and master setup running ubuntu 15.04 linux distribution. Here, Puppet master is a server from where all the configurations will be controlled and managed and all our remaining servers will be puppet agent nodes, which is configured according to the configuration of puppet master server. Here are some easy steps to install and configure puppet to manage our server infrastructure running Ubuntu 15.04.
|
||||
|
||||
### 1. Setting up Hosts ###
|
||||
|
||||
In this tutorial, we'll use two machines, one as puppet master server and another as puppet node agent both running ubuntu 15.04 "Vivid Vervet" in both the machines. Here is the infrastructure of the server that we're gonna use for this tutorial.
|
||||
|
||||
puppet master server with IP 44.55.88.6 and hostname : puppetmaster
|
||||
puppet node agent with IP 45.55.86.39 and hostname : puppetnode
|
||||
|
||||
Now we'll add the entry of the machines to /etc/hosts on both machines node agent and master server.
|
||||
|
||||
# nano /etc/hosts
|
||||
|
||||
45.55.88.6 puppetmaster.example.com puppetmaster
|
||||
45.55.86.39 puppetnode.example.com puppetnode
|
||||
|
||||
Please note that the Puppet Master server must be reachable on port 8140. So, we'll need to open port 8140 in it.
|
||||
|
||||
### 2. Updating Time with NTP ###
|
||||
|
||||
As puppet nodes needs to maintain accurate system time to avoid problems when it issues agent certificates. Certificates can appear to be expired if there is time difference, the time of the both the master and the node agent must be synced with each other. To sync the time, we'll update the time with NTP. To do so, here's the command below that we need to run on both master and node agent.
|
||||
|
||||
# ntpdate pool.ntp.org
|
||||
|
||||
17 Jun 00:17:08 ntpdate[882]: adjust time server 66.175.209.17 offset -0.001938 sec
|
||||
|
||||
Now, we'll update our local repository index and install ntp as follows.
|
||||
|
||||
# apt-get update && sudo apt-get -y install ntp ; service ntp restart
|
||||
|
||||
### 3. Puppet Master Package Installation ###
|
||||
|
||||
There are many ways to install open source puppet. In this tutorial, we'll download and install a debian binary package named as **puppetlabs-release** packaged by the Puppet Labs which will add the source of the **puppetmaster-passenger** package. The puppetmaster-passenger includes the puppet master with apache web server. So, we'll now download the Puppet Labs package.
|
||||
|
||||
# cd /tmp/
|
||||
# wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
|
||||
|
||||
--2015-06-17 00:19:26-- https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
|
||||
Resolving apt.puppetlabs.com (apt.puppetlabs.com)... 192.155.89.90, 2600:3c03::f03c:91ff:fedb:6b1d
|
||||
Connecting to apt.puppetlabs.com (apt.puppetlabs.com)|192.155.89.90|:443... connected.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: 7384 (7.2K) [application/x-debian-package]
|
||||
Saving to: ‘puppetlabs-release-trusty.deb’
|
||||
|
||||
puppetlabs-release-tr 100%[===========================>] 7.21K --.-KB/s in 0.06s
|
||||
|
||||
2015-06-17 00:19:26 (130 KB/s) - ‘puppetlabs-release-trusty.deb’ saved [7384/7384]
|
||||
|
||||
After the download has been completed, we'll wanna install the package.
|
||||
|
||||
# dpkg -i puppetlabs-release-trusty.deb
|
||||
|
||||
Selecting previously unselected package puppetlabs-release.
|
||||
(Reading database ... 85899 files and directories currently installed.)
|
||||
Preparing to unpack puppetlabs-release-trusty.deb ...
|
||||
Unpacking puppetlabs-release (1.0-11) ...
|
||||
Setting up puppetlabs-release (1.0-11) ...
|
||||
|
||||
Then, we'll update the local respository index with the server using apt package manager.
|
||||
|
||||
# apt-get update
|
||||
|
||||
Then, we'll install the puppetmaster-passenger package by running the below command.
|
||||
|
||||
# apt-get install puppetmaster-passenger
|
||||
|
||||
**Note**: While installing we may get an error **Warning: Setting templatedir is deprecated. See http://links.puppetlabs.com/env-settings-deprecations (at /usr/lib/ruby/vendor_ruby/puppet/settings.rb:1139:in `issue_deprecation_warning')** but we no need to worry, we'll just simply ignore this as it says that the templatedir is deprecated so, we'll simply disbale that setting in the configuration. :)
|
||||
|
||||
To check whether puppetmaster has been installed successfully in our Master server not not, we'll gonna try to check its version.
|
||||
|
||||
# puppet --version
|
||||
|
||||
3.8.1
|
||||
|
||||
We have successfully installed puppet master package in our puppet master box. As we are using passenger with apache, the puppet master process is controlled by apache server, that means it runs when apache is running.
|
||||
|
||||
Before continuing, we'll need to stop the Puppet master by stopping the apache2 service.
|
||||
|
||||
# systemctl stop apache2
|
||||
|
||||
### 4. Master version lock with Apt ###
|
||||
|
||||
As We have puppet version as 3.8.1, we need to lock the puppet version update as this will mess up the configurations while updating the puppet. So, we'll use apt's locking feature for that. To do so, we'll need to create a new file **/etc/apt/preferences.d/00-puppet.pref** using our favorite text editor.
|
||||
|
||||
# nano /etc/apt/preferences.d/00-puppet.pref
|
||||
|
||||
Then, we'll gonna add the entries in the newly created file as:
|
||||
|
||||
# /etc/apt/preferences.d/00-puppet.pref
|
||||
Package: puppet puppet-common puppetmaster-passenger
|
||||
Pin: version 3.8*
|
||||
Pin-Priority: 501
|
||||
|
||||
Now, it will not update the puppet while running updates in the system.
|
||||
|
||||
### 5. Configuring Puppet Config ###
|
||||
|
||||
Puppet master acts as a certificate authority and must generate its own certificates which is used to sign agent certificate requests. First of all, we'll need to remove any existing SSL certificates that were created during the installation of package. The default location of puppet's SSL certificates is /var/lib/puppet/ssl. So, we'll remove the entire ssl directory using rm command.
|
||||
|
||||
# rm -rf /var/lib/puppet/ssl
|
||||
|
||||
Then, we'll configure the certificate. While creating the puppet master's certificate, we need to include every DNS name at which agent nodes can contact the master at. So, we'll edit the master's puppet.conf using our favorite text editor.
|
||||
|
||||
# nano /etc/puppet/puppet.conf
|
||||
|
||||
The output seems as shown below.
|
||||
|
||||
[main]
|
||||
logdir=/var/log/puppet
|
||||
vardir=/var/lib/puppet
|
||||
ssldir=/var/lib/puppet/ssl
|
||||
rundir=/var/run/puppet
|
||||
factpath=$vardir/lib/facter
|
||||
templatedir=$confdir/templates
|
||||
|
||||
[master]
|
||||
# These are needed when the puppetmaster is run by passenger
|
||||
# and can safely be removed if webrick is used.
|
||||
ssl_client_header = SSL_CLIENT_S_DN
|
||||
ssl_client_verify_header = SSL_CLIENT_VERIFY
|
||||
|
||||
Here, we'll need to comment the templatedir line to disable the setting as it has been already depreciated. After that, we'll add the following line at the end of the file under [main].
|
||||
|
||||
server = puppetmaster
|
||||
environment = production
|
||||
runinterval = 1h
|
||||
strict_variables = true
|
||||
certname = puppetmaster
|
||||
dns_alt_names = puppetmaster, puppetmaster.example.com
|
||||
|
||||
This configuration file has many options which might be useful in order to setup own configuration. A full description of the file is available at Puppet Labs [Main Config File (puppet.conf)][1].
|
||||
|
||||
After editing the file, we'll wanna save that and exit.
|
||||
|
||||
Now, we'll gonna generate a new CA certificates by running the following command.
|
||||
|
||||
# puppet master --verbose --no-daemonize
|
||||
|
||||
Info: Creating a new SSL key for ca
|
||||
Info: Creating a new SSL certificate request for ca
|
||||
Info: Certificate Request fingerprint (SHA256): F6:2F:69:89:BA:A5:5E:FF:7F:94:15:6B:A7:C4:20:CE:23:C7:E3:C9:63:53:E0:F2:76:D7:2E:E0:BF:BD:A6:78
|
||||
...
|
||||
Notice: puppetmaster has a waiting certificate request
|
||||
Notice: Signed certificate request for puppetmaster
|
||||
Notice: Removing file Puppet::SSL::CertificateRequest puppetmaster at '/var/lib/puppet/ssl/ca/requests/puppetmaster.pem'
|
||||
Notice: Removing file Puppet::SSL::CertificateRequest puppetmaster at '/var/lib/puppet/ssl/certificate_requests/puppetmaster.pem'
|
||||
Notice: Starting Puppet master version 3.8.1
|
||||
^CNotice: Caught INT; storing stop
|
||||
Notice: Processing stop
|
||||
|
||||
Now, the certificate is being generated. Once we see **Notice: Starting Puppet master version 3.8.1**, the certificate setup is complete. Then we'll press CTRL-C to return to the shell.
|
||||
|
||||
If we wanna look at the cert information of the certificate that was just created, we can get the list by running in the following command.
|
||||
|
||||
# puppet cert list -all
|
||||
|
||||
+ "puppetmaster" (SHA256) 33:28:97:86:A1:C3:2F:73:10:D1:FB:42:DA:D5:42:69:71:84:F0:E2:8A:01:B9:58:38:90:E4:7D:B7:25:23:EC (alt names: "DNS:puppetmaster", "DNS:puppetmaster.example.com")
|
||||
|
||||
### 6. Creating a Puppet Manifest ###
|
||||
|
||||
The default location of the main manifest is /etc/puppet/manifests/site.pp. The main manifest file contains the definition of configuration that is used to execute in the puppet node agent. Now, we'll create the manifest file by running the following command.
|
||||
|
||||
# nano /etc/puppet/manifests/site.pp
|
||||
|
||||
Then, we'll add the following lines of configuration in the file that we just opened.
|
||||
|
||||
# execute 'apt-get update'
|
||||
exec { 'apt-update': # exec resource named 'apt-update'
|
||||
command => '/usr/bin/apt-get update' # command this resource will run
|
||||
}
|
||||
|
||||
# install apache2 package
|
||||
package { 'apache2':
|
||||
require => Exec['apt-update'], # require 'apt-update' before installing
|
||||
ensure => installed,
|
||||
}
|
||||
|
||||
# ensure apache2 service is running
|
||||
service { 'apache2':
|
||||
ensure => running,
|
||||
}
|
||||
|
||||
The above lines of configuration are responsible for the deployment of the installation of apache web server across the node agent.
|
||||
|
||||
### 7. Starting Master Service ###
|
||||
|
||||
We are now ready to start the puppet master. We can start it by running the apache2 service.
|
||||
|
||||
# systemctl start apache2
|
||||
|
||||
Here, our puppet master is running, but it isn't managing any agent nodes yet. Now, we'll gonna add the puppet node agents to the master.
|
||||
|
||||
**Note**: If you get an error **Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xe" for details.** then it must be that there is some problem with the apache server. So, we can see the log what exactly has happened by running **apachectl start** under root or sudo mode. Here, while performing this tutorial, we got a misconfiguration of the certificates under **/etc/apache2/sites-enabled/puppetmaster.conf** file. We replaced **SSLCertificateFile /var/lib/puppet/ssl/certs/server.pem with SSLCertificateFile /var/lib/puppet/ssl/certs/puppetmaster.pem** and commented **SSLCertificateKeyFile** line. Then we'll need to rerun the above command to run apache server.
|
||||
|
||||
### 8. Puppet Agent Package Installation ###
|
||||
|
||||
Now, as we have our puppet master ready and it needs an agent to manage, we'll need to install puppet agent into the nodes. We'll need to install puppet agent in every nodes in our infrastructure we want puppet master to manage. We'll need to make sure that we have added our node agents in the DNS. Now, we'll gonna install the latest puppet agent in our agent node ie. puppetnode.example.com .
|
||||
|
||||
We'll run the following command to download the Puppet Labs package in our puppet agent nodes.
|
||||
|
||||
# cd /tmp/
|
||||
# wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb\
|
||||
|
||||
--2015-06-17 00:54:42-- https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
|
||||
Resolving apt.puppetlabs.com (apt.puppetlabs.com)... 192.155.89.90, 2600:3c03::f03c:91ff:fedb:6b1d
|
||||
Connecting to apt.puppetlabs.com (apt.puppetlabs.com)|192.155.89.90|:443... connected.
|
||||
HTTP request sent, awaiting response... 200 OK
|
||||
Length: 7384 (7.2K) [application/x-debian-package]
|
||||
Saving to: ‘puppetlabs-release-trusty.deb’
|
||||
|
||||
puppetlabs-release-tr 100%[===========================>] 7.21K --.-KB/s in 0.04s
|
||||
|
||||
2015-06-17 00:54:42 (162 KB/s) - ‘puppetlabs-release-trusty.deb’ saved [7384/7384]
|
||||
|
||||
Then, as we're running ubuntu 15.04, we'll use debian package manager to install it.
|
||||
|
||||
# dpkg -i puppetlabs-release-trusty.deb
|
||||
|
||||
Now, we'll gonna update the repository index using apt-get.
|
||||
|
||||
# apt-get update
|
||||
|
||||
Finally, we'll gonna install the puppet agent directly from the remote repository.
|
||||
|
||||
# apt-get install puppet
|
||||
|
||||
Puppet agent is always disabled by default, so we'll need to enable it. To do so we'll need to edit /etc/default/puppet file using a text editor.
|
||||
|
||||
# nano /etc/default/puppet
|
||||
|
||||
Then, we'll need to change value of **START** to "yes" as shown below.
|
||||
|
||||
START=yes
|
||||
|
||||
Then, we'll need to save and exit the file.
|
||||
|
||||
### 9. Agent Version Lock with Apt ###
|
||||
|
||||
As We have puppet version as 3.8.1, we need to lock the puppet version update as this will mess up the configurations while updating the puppet. So, we'll use apt's locking feature for that. To do so, we'll need to create a file /etc/apt/preferences.d/00-puppet.pref using our favorite text editor.
|
||||
|
||||
# nano /etc/apt/preferences.d/00-puppet.pref
|
||||
|
||||
Then, we'll gonna add the entries in the newly created file as:
|
||||
|
||||
# /etc/apt/preferences.d/00-puppet.pref
|
||||
Package: puppet puppet-common
|
||||
Pin: version 3.8*
|
||||
Pin-Priority: 501
|
||||
|
||||
Now, it will not update the Puppet while running updates in the system.
|
||||
|
||||
### 10. Configuring Puppet Node Agent ###
|
||||
|
||||
Next, We must make a few configuration changes before running the agent. To do so, we'll need to edit the agent's puppet.conf
|
||||
|
||||
# nano /etc/puppet/puppet.conf
|
||||
|
||||
It will look exactly like the Puppet master's initial configuration file.
|
||||
|
||||
This time also we'll comment the **templatedir** line. Then we'll gonna delete the [master] section, and all of the lines below it.
|
||||
|
||||
Assuming that the puppet master is reachable at "puppet-master", the agent should be able to connect to the master. If not we'll need to use its fully qualified domain name ie. puppetmaster.example.com .
|
||||
|
||||
[agent]
|
||||
server = puppetmaster.example.com
|
||||
certname = puppetnode.example.com
|
||||
|
||||
After adding this, it will look alike this.
|
||||
|
||||
[main]
|
||||
logdir=/var/log/puppet
|
||||
vardir=/var/lib/puppet
|
||||
ssldir=/var/lib/puppet/ssl
|
||||
rundir=/var/run/puppet
|
||||
factpath=$vardir/lib/facter
|
||||
#templatedir=$confdir/templates
|
||||
|
||||
[agent]
|
||||
server = puppetmaster.example.com
|
||||
certname = puppetnode.example.com
|
||||
|
||||
After done with that, we'll gonna save and exit it.
|
||||
|
||||
Next, we'll wanna start our latest puppet agent in our Ubuntu 15.04 nodes. To start our puppet agent, we'll need to run the following command.
|
||||
|
||||
# systemctl start puppet
|
||||
|
||||
If everything went as expected and configured properly, we should not see any output displayed by running the above command. When we run an agent for the first time, it generates an SSL certificate and sends a request to the puppet master then if the master signs the agent's certificate, it will be able to communicate with the agent node.
|
||||
|
||||
**Note**: If you are adding your first node, it is recommended that you attempt to sign the certificate on the puppet master before adding your other agents. Once you have verified that everything works properly, then you can go back and add the remaining agent nodes further.
|
||||
|
||||
### 11. Signing certificate Requests on Master ###
|
||||
|
||||
While puppet agent runs for the first time, it generates an SSL certificate and sends a request for signing to the master server. Before the master will be able to communicate and control the agent node, it must sign that specific agent node's certificate.
|
||||
|
||||
To get the list of the certificate requests, we'll run the following command in the puppet master server.
|
||||
|
||||
# puppet cert list
|
||||
|
||||
"puppetnode.example.com" (SHA256) 31:A1:7E:23:6B:CD:7B:7D:83:98:33:8B:21:01:A6:C4:01:D5:53:3D:A0:0E:77:9A:77:AE:8F:05:4A:9A:50:B2
|
||||
|
||||
As we just setup our first agent node, we will see one request. It will look something like the following, with the agent node's Domain name as the hostname.
|
||||
|
||||
Note that there is no + in front of it which indicates that it has not been signed yet.
|
||||
|
||||
Now, we'll go for signing a certification request. In order to sign a certification request, we should simply run **puppet cert sign** with the **hostname** as shown below.
|
||||
|
||||
# puppet cert sign puppetnode.example.com
|
||||
|
||||
Notice: Signed certificate request for puppetnode.example.com
|
||||
Notice: Removing file Puppet::SSL::CertificateRequest puppetnode.example.com at '/var/lib/puppet/ssl/ca/requests/puppetnode.example.com.pem'
|
||||
|
||||
The Puppet master can now communicate and control the node that the signed certificate belongs to.
|
||||
|
||||
If we want to sign all of the current requests, we can use the -all option as shown below.
|
||||
|
||||
# puppet cert sign --all
|
||||
|
||||
### Removing a Puppet Certificate ###
|
||||
|
||||
If we wanna remove a host from it or wanna rebuild a host then add it back to it. In this case, we will want to revoke the host's certificate from the puppet master. To do this, we will want to use the clean action as follows.
|
||||
|
||||
# puppet cert clean hostname
|
||||
|
||||
Notice: Revoked certificate with serial 5
|
||||
Notice: Removing file Puppet::SSL::Certificate puppetnode.example.com at '/var/lib/puppet/ssl/ca/signed/puppetnode.example.com.pem'
|
||||
Notice: Removing file Puppet::SSL::Certificate puppetnode.example.com at '/var/lib/puppet/ssl/certs/puppetnode.example.com.pem'
|
||||
|
||||
If we want to view all of the requests signed and unsigned, run the following command:
|
||||
|
||||
# puppet cert list --all
|
||||
|
||||
+ "puppetmaster" (SHA256) 33:28:97:86:A1:C3:2F:73:10:D1:FB:42:DA:D5:42:69:71:84:F0:E2:8A:01:B9:58:38:90:E4:7D:B7:25:23:EC (alt names: "DNS:puppetmaster", "DNS:puppetmaster.example.com")
|
||||
|
||||
### 12. Deploying a Puppet Manifest ###
|
||||
|
||||
After we configure and complete the puppet manifest, we'll wanna deploy the manifest to the agent nodes server. To apply and load the main manifest we can simply run the following command in the agent node.
|
||||
|
||||
# puppet agent --test
|
||||
|
||||
Info: Retrieving pluginfacts
|
||||
Info: Retrieving plugin
|
||||
Info: Caching catalog for puppetnode.example.com
|
||||
Info: Applying configuration version '1434563858'
|
||||
Notice: /Stage[main]/Main/Exec[apt-update]/returns: executed successfully
|
||||
Notice: Finished catalog run in 10.53 seconds
|
||||
|
||||
This will show us all the processes how the main manifest will affect a single server immediately.
|
||||
|
||||
If we wanna run a puppet manifest that is not related to the main manifest, we can simply use puppet apply followed by the manifest file path. It only applies the manifest to the node that we run the apply from.
|
||||
|
||||
# puppet apply /etc/puppet/manifest/test.pp
|
||||
|
||||
### 13. Configuring Manifest for a Specific Node ###
|
||||
|
||||
If we wanna deploy a manifest only to a specific node then we'll need to configure the manifest as follows.
|
||||
|
||||
We'll need to edit the manifest on the master server using a text editor.
|
||||
|
||||
# nano /etc/puppet/manifest/site.pp
|
||||
|
||||
Now, we'll gonna add the following lines there.
|
||||
|
||||
node 'puppetnode', 'puppetnode1' {
|
||||
# execute 'apt-get update'
|
||||
exec { 'apt-update': # exec resource named 'apt-update'
|
||||
command => '/usr/bin/apt-get update' # command this resource will run
|
||||
}
|
||||
|
||||
# install apache2 package
|
||||
package { 'apache2':
|
||||
require => Exec['apt-update'], # require 'apt-update' before installing
|
||||
ensure => installed,
|
||||
}
|
||||
|
||||
# ensure apache2 service is running
|
||||
service { 'apache2':
|
||||
ensure => running,
|
||||
}
|
||||
}
|
||||
|
||||
Here, the above configuration will install and deploy the apache web server only to the two specified nodes having shortname puppetnode and puppetnode1. We can add more nodes that we need to get deployed with the manifest specifically.
|
||||
|
||||
### 14. Configuring Manifest with a Module ###
|
||||
|
||||
Modules are useful for grouping tasks together, they are many available in the Puppet community which anyone can contribute further.
|
||||
|
||||
On the puppet master, we'll gonna install the **puppetlabs-apache** module using the puppet module command.
|
||||
|
||||
# puppet module install puppetlabs-apache
|
||||
|
||||
**Warning**: Please do not use this module on an existing apache setup else it will purge your apache configurations that are not managed by puppet.
|
||||
|
||||
Now we'll gonna edit the main manifest ie **site.pp** using a text editor.
|
||||
|
||||
# nano /etc/puppet/manifest/site.pp
|
||||
|
||||
Now add the following lines to install apache under puppetnode.
|
||||
|
||||
node 'puppet-node' {
|
||||
class { 'apache': } # use apache module
|
||||
apache::vhost { 'example.com': # define vhost resource
|
||||
port => '80',
|
||||
docroot => '/var/www/html'
|
||||
}
|
||||
}
|
||||
|
||||
Then we'll wanna save and exit it. Then, we'll wanna rerun the manifest to deploy the configuration to the agents for our infrastructure.
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
Finally we have successfully installed puppet to manage our Server Infrastructure running Ubuntu 15.04 "Vivid Vervet" linux operating system. We learned how puppet works, configure a manifest configuration, communicate with nodes and deploy the manifest on the agent nodes with secure SSL certification. Controlling, managing and configuring repeated task in several N number of nodes is very easy with puppet open source software configuration management tool. If you have any questions, suggestions, feedback please write them in the comment box below so that we can improve or update our contents. Thank you ! Enjoy :-)
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-how-to/install-puppet-ubuntu-15-04/
|
||||
|
||||
作者：[Arun Pyasi][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://linoxide.com/author/arunp/
|
||||
[1]:https://docs.puppetlabs.com/puppet/latest/reference/config_file_main.html
|
||||
@ -0,0 +1,67 @@
|
||||
Ubuntu上使用LVM轻松调整分区并制作快照
|
||||
================================================================================
|
||||
|
||||
|
||||
Ubuntu的安装器提供了一个轻松“使用LVM”的复选框。说明中说，它启用了逻辑卷管理，因此你可以制作快照，并更容易地调整硬盘分区大小——这里将为大家讲述如何完成这些操作。
|
||||
|
||||
LVM是一种技术，某种程度上和[RAID阵列][1]或[Windows上的存储空间][2]类似。虽然该技术在服务器上更为有用，但是它也可以在桌面端PC上使用。
|
||||
|
||||
### 你应该在新安装Ubuntu时使用LVM吗？ ###
|
||||
|
||||
第一个问题是，你是否想要在安装Ubuntu时使用LVM？如果是，那么Ubuntu让这一切变得很简单，只需要轻点鼠标就可以完成，但是该选项默认是不启用的。正如安装器所说的，它允许你调整分区、创建快照、合并多个磁盘到一个逻辑卷等等——所有这一切都可以在系统运行时完成。不同于传统分区，你不需要关掉你的系统，从Live CD或USB驱动，然后[调整这些不使用的分区][3]。
|
||||
|
||||
完全坦率地说，普通Ubuntu桌面用户可能不会意识到他们是否正在使用LVM。但是，如果你想要在今后做一些更高深的事情，那么LVM就会有所帮助了。LVM可能更复杂，可能会在你今后恢复数据时会导致问题——尤其是在你经验不足时。这里不会有显著的性能损失——LVM是彻底地在Linux内核中实现的。
|
||||
|
||||
|
||||
|
||||
### 逻辑卷管理说明 ###
|
||||
|
||||
前面，我们已经[说明了何谓LVM][4]。概括来讲，它在你的物理磁盘和呈现在你系统中的分区之间提供了一个抽象层。例如，你的计算机可能装有两个硬盘驱动器，它们的大小都是 1 TB。你必须得在这些磁盘上至少分两个区，每个区大小 1 TB。
|
||||
|
||||
LVM就在这些分区上提供了一个抽象层。用于取代磁盘上的传统分区，LVM将在你对这些磁盘初始化后，将它们当作独立的“物理卷”来对待。然后，你就可以基于这些物理卷创建“逻辑卷”。例如，你可以将这两个 1 TB 的磁盘组合成一个 2 TB 的分区，你的系统将只看到一个 2 TB 的卷，而LVM将会在后台处理这一切。一组物理卷以及一组逻辑卷被称之为“卷组”，一个标准的系统只会有一个卷组。
|
||||
|
||||
该抽象层使得调整分区、将多个磁盘组合成单个卷、甚至为一个运行着的分区的文件系统创建“快照”变得十分简单，而完成所有这一切都无需先卸载分区。
|
||||
|
||||
注意，如果你没有创建备份，那么将多个磁盘合并成一个卷将会是个糟糕的想法。它就像RAID 0——如果你将两个 1 TB 的卷组合成一个 2 TB 的卷，只要其中一个硬盘失败，你将丢失该卷上的重要数据。所以，如果你要走这条路，那么备份就及其重要。
|
||||
|
||||
### 管理LVM卷的图形化工具 ###
|
||||
|
||||
通常，[LVM通过Linux终端命令来管理][5]。这在Ubuntu上也行得通，但是有个更简单的图形化方法可供大家采用。如果你是一个Linux用户，对GParted或者与其类似的分区管理器熟悉，算了，别瞎掰了——GParted根本不支持LVM磁盘。
|
||||
|
||||
然而，你可以使用Ubuntu附带的磁盘工具。该工具也被称之为GNOME磁盘工具，或者叫Palimpsest。点击停靠盘上的图标来开启它吧，搜索磁盘然后敲击回车。不像GParted，该磁盘工具将会在“其它设备”下显示LVM分区，因此你可以根据需要格式化这些分区，也可以调整其它选项。该工具在Live CD或USB 驱动下也可以使用。
|
||||
|
||||
|
||||
|
||||
不幸的是，该磁盘工具不支持LVM的大多数强大的特性，没有管理卷组、扩展分区，或者创建快照等选项。对于这些操作，你可以通过终端来实现，但是你没有那个必要。相反，你可以打开Ubuntu软件中心，搜索关键字LVM，然后安装逻辑卷管理工具，你可以在终端窗口中运行**sudo apt-get install system-config-lvm**命令来安装它。安装完之后，你就可以从停靠盘上打开逻辑卷管理工具了。
|
||||
|
||||
这个图形化配置工具是由红帽公司开发的，虽然有点陈旧了，但却是唯一的图形化方式，你可以通过它来完成上述操作，将那些终端命令抛诸脑后了。
|
||||
|
||||
比如说，你想要添加一个新的物理卷到卷组中。你可以打开该工具，选择未初始化条目下的新磁盘，然后点击“初始化条目”按钮。然后，你就可以在未分配卷下找到新的物理卷了，你可以使用“添加到现存卷组”按钮来将它添加到“ubuntu-vg”卷组，这是Ubuntu在安装过程中创建的卷组。
|
||||
|
||||
|
||||
|
||||
卷组视图会列出你所有物理卷和逻辑卷的总览。这里，我们有两个横跨两个独立硬盘驱动器的物理分区，我们有一个交换分区和一个根分区，就像Ubuntu默认设置的分区图表。由于我们从另一个驱动器添加了第二个物理分区，现在那里有大量未使用空间。
|
||||
|
||||
|
||||
|
||||
要扩展逻辑分区到物理空间，你可以在逻辑视图下选择它，点击编辑属性，然后修改大小来扩大分区。你也可以在这里缩减分区。
|
||||
|
||||
|
||||
|
||||
system-config-lvm的其它选项允许你设置快照和镜像。对于传统桌面而言，你或许不需要这些特性，但是在这里也可以通过图形化处理。记住，你也可以[使用终端命令完成这一切][6]。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.howtogeek.com/211937/how-to-use-lvm-on-ubuntu-for-easy-partition-resizing-and-snapshots/
|
||||
|
||||
译者：[GOLinux](https://github.com/GOLinux)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.howtogeek.com/162676/how-to-use-multiple-disks-intelligently-an-introduction-to-raid/
|
||||
[2]:http://www.howtogeek.com/109380/how-to-use-windows-8s-storage-spaces-to-mirror-combine-drives/
|
||||
[3]:http://www.howtogeek.com/114503/how-to-resize-your-ubuntu-partitions/
|
||||
[4]:http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/
|
||||
[5]:http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/
|
||||
[6]:http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/
|
||||
416
translated/tech/20150717 How to monitor NGINX- Part 1.md
Normal file
416
translated/tech/20150717 How to monitor NGINX- Part 1.md
Normal file
@ -0,0 +1,416 @@
|
||||
如何监控 NGINX - 第1部分
|
||||
================================================================================
|
||||
|
||||
|
||||
### NGINX 是什么? ###
|
||||
|
||||
[NGINX][1] (发音为 “engine X”) 是一种流行的 HTTP 和反向代理服务器。作为一个 HTTP 服务器，NGINX 提供静态内容非常高效可靠，使用较少的内存。作为[反向代理][2]，它可以用作一个单一的控制器来为其他应用代理至后端的多个服务器上，如高速缓存和负载平衡。NGINX 是作为一个免费，开源的产品并有更全的功能，商业版的叫 NGINX Plus。
|
||||
|
||||
NGINX 也可以用作邮件代理和通用的 TCP 代理，但本文并不直接说明对 NGINX 的这些用例做监控。
|
||||
|
||||
### NGINX 主要指标 ###
|
||||
|
||||
通过监控 NGINX 可以捕捉两类问题：NGINX 本身的资源问题，也有很多问题会出现在你的基础网络设施处。大多数 NGINX 用户受益于以下指标的监控，包括**requests per second**，它提供了一个所有用户活动的高级视图；**server error rate** ，这表明你的服务器已经多长没有处理看似有效的请求;还有**request processing time**，这说明你的服务器处理客户端请求的总共时长（并且可以看出性能降低时或当前环境的其他问题）。
|
||||
|
||||
更一般地，至少有三个主要的指标类别来监视：
|
||||
|
||||
- 基本活动指标
|
||||
- 错误指标
|
||||
- 性能指标
|
||||
|
||||
下面我们将分析在每个类别中最重要的 NGINX 指标，以及用一个相当普遍的案例来说明，值得特别说明的是：使用 NGINX Plus 作反向代理。我们还将介绍如何使用图形工具或可选择的监控工具来监控所有的指标。
|
||||
|
||||
本文引用指标术语[介绍我们的监控在 101 系列][3],，它提供了指标收集和警告框架。
|
||||
|
||||
#### 基本活动指标 ####
|
||||
|
||||
无论你在怎样的情况下使用 NGINX，毫无疑问你要监视服务器接收多少客户端请求和如何处理这些请求。
|
||||
|
||||
NGINX Plus 上像开源 NGINX 一样可以报告基本活动指标，但它也提供了略有不同的辅助模块。我们首先讨论开源的 NGINX，再来说明 NGINX Plus 提供的其他指标的功能。
|
||||
|
||||
**NGINX**
|
||||
|
||||
下图显示了一个客户端连接，以及如何在连接过程中收集指标的活动周期在开源 NGINX 版本上。
|
||||
|
||||
|
||||
|
||||
接受，处理，增加请求的计数器。主动，等待，读，写增加和减少请求量。
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">accepts</td>
|
||||
<td style="text-align: left;">Count of client connections attempted by NGINX</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">handled</td>
|
||||
<td style="text-align: left;">Count of successful client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">active</td>
|
||||
<td style="text-align: left;">Currently active client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">dropped (calculated)</td>
|
||||
<td style="text-align: left;">Count of dropped connections (accepts – handled)</td>
|
||||
<td style="text-align: left;">Work: Errors*</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">requests</td>
|
||||
<td style="text-align: left;">Count of client requests</td>
|
||||
<td style="text-align: left;">Work: Throughput</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="text-align: left;">*<em>Strictly speaking, dropped connections is <a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/#resource-metrics">a metric of resource saturation</a>, but since saturation causes NGINX to stop servicing some work (rather than queuing it up for later), “dropped” is best thought of as <a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/#work-metrics">a work metric</a>.</em></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
NGINX 进程接受 OS 的连接请求时**accepts** 计数器增加，而**handled** 是当实际的请求得到连接时（通过建立一个新的连接或重新使用一个空闲的）。这两个计数器的值通常都是相同的，表明连接正在被**dropped**，往往由于资源限制，如 NGINX 的[worker_connections][4]的限制已经达到。
|
||||
|
||||
一旦 NGINX 成功处理一个连接时，连接会移动到**active**状态，然后保持为客户端请求进行处理：
|
||||
|
||||
Active 状态
|
||||
|
||||
- **Waiting**: 活动的连接也可以是一个 Waiting 子状态，如果有在此刻没有活动请求。新连接绕过这个状态并直接移动到读，最常见的是使用“accept filter” 和 “deferred accept”，在这种情况下，NGINX 不会接收进程的通知，直到它具有足够的数据来开始响应工作。如果连接设置为 keep-alive ，连接在发送响应后将处于等待状态。
|
||||
|
||||
- **Reading**: 当接收到请求时，连接移出等待状态，并且该请求本身也被视为 Reading。在这种状态下NGINX 正在读取客户端请求首部。请求首部是比较少的，因此这通常是一个快速的操作。
|
||||
|
||||
- **Writing**: 请求被读取之后，将其计为 Writing，并保持在该状态，直到响应返回给客户端。这意味着，该请求在 Writing 时， NGINX 同时等待来自负载均衡服务器的结果（系统“背后”的 NGINX），NGINX 也同时响应。请求往往会花费大量的时间在 Writing 状态。
|
||||
|
||||
通常，一个连接在同一时间只接受一个请求。在这种情况下，Active 连接的数目 == Waiting 连接 + Reading 请求 + Writing 请求。然而，较新的 SPDY 和 HTTP/2 协议允许多个并发请求/响应对被复用的连接，所以 Active 可小于 Waiting，Reading，Writing 的总和。 （在撰写本文时，NGINX 不支持 HTTP/2，但预计到2015年期间将会支持。）
|
||||
|
||||
**NGINX Plus**
|
||||
|
||||
正如上面提到的，所有开源 NGINX 的指标在 NGINX Plus 中是可用的，但另外也提供其他的指标。本节仅说明了 NGINX Plus 可用的指标。
|
||||
|
||||
|
||||
|
||||
|
||||
接受，中断，总数是不断增加的。活动，空闲和已建立连接的，当前状态下每一个连接或请求的数量是随着请求量增加和收缩的。
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">accepted</td>
|
||||
<td style="text-align: left;">Count of client connections attempted by NGINX</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">dropped</td>
|
||||
<td style="text-align: left;">Count of dropped connections</td>
|
||||
<td style="text-align: left;">Work: Errors*</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">active</td>
|
||||
<td style="text-align: left;">Currently active client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">idle</td>
|
||||
<td style="text-align: left;">Client connections with zero current requests</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">total</td>
|
||||
<td style="text-align: left;">Count of client requests</td>
|
||||
<td style="text-align: left;">Work: Throughput</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="text-align: left;">*<em>Strictly speaking, dropped connections is a metric of resource saturation, but since saturation causes NGINX to stop servicing some work (rather than queuing it up for later), “dropped” is best thought of as a work metric.</em></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
当 NGINX Plus 进程接受 OS 的连接请求时 **accepted** 计数器递增。如果进程请求连接失败（通过建立一个新的连接或重新使用一个空闲），则该连接断开 **dropped** 计数增加。通常连接被中断是因为资源限制，如 NGINX Plus 的[worker_connections][4]的限制已经达到。
|
||||
|
||||
**Active** 和 **idle** 和开源 NGINX 的“active” 和 “waiting”状态是相同的，[如上所述][5]，有一个不同的地方：在开源 NGINX 上，“waiting”状态包括在“active”中，而在 NGINX Plus 上“idle”的连接被排除在“active” 计数外。**Current** 和开源 NGINX 是一样的也是由“reading + writing” 状态组成。
|
||||
|
||||
|
||||
**Total** 为客户端请求的累积计数。请注意，单个客户端连接可涉及多个请求，所以这个数字可能会比连接的累计次数明显大。事实上，（total / accepted）是每个连接请求的平均数量。
|
||||
|
||||
**开源 和 Plus 之间指标的不同**
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;">NGINX (open-source)</th>
|
||||
<th style="text-align: left;">NGINX Plus</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">accepts</td>
|
||||
<td style="text-align: left;">accepted</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">dropped must be calculated</td>
|
||||
<td style="text-align: left;">dropped is reported directly</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">reading + writing</td>
|
||||
<td style="text-align: left;">current</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">waiting</td>
|
||||
<td style="text-align: left;">idle</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">active (includes “waiting” states)</td>
|
||||
<td style="text-align: left;">active (excludes “idle” states)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">requests</td>
|
||||
<td style="text-align: left;">total</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**提醒指标: 中断连接**
|
||||
|
||||
被中断的连接数目等于接受和处理之差（NGINX），或被公开直接作为指标的标准（NGINX加）。在正常情况下，中断连接数应该是零。如果每秒中中断连接的速度开始上升，寻找资源可能用尽的地方。
|
||||
|
||||
|
||||
|
||||
**提醒指标: 每秒请求数**
|
||||
|
||||
提供你（开源中的**requests**或者 Plus 中**total**）固定时间间隔每秒或每分钟请求的平均数据。监测这个指标可以查看 Web 的输入流量的最大值，无论是合法的还是恶意的，有可能会突然下降，通常可以看出问题。每秒的请求若发生急剧变化可以提醒你出问题了，即使它不能告诉你确切问题的位置所在。请注意，所有的请求都算作是相同的，无论哪个 URLs。
|
||||
|
||||
|
||||
|
||||
**收集活动指标**
|
||||
|
||||
开源的 NGINX 提供了一个简单状态页面来显示基本的服务器指标。该状态信息以标准格式被显示，实际上任何图形或监控工具可以被配置去解析相关的数据为分析，可视化，或提醒而用。NGINX Plus 提供一个 JSON 接口来显示更多的数据。阅读[NGINX 指标收集][6]后来启用指标收集的功能。
|
||||
|
||||
#### 错误指标 ####
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
<th style="text-align: left;"><strong>Availability</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">4xx codes</td>
|
||||
<td style="text-align: left;">Count of client errors</td>
|
||||
<td style="text-align: left;">Work: Errors</td>
|
||||
<td style="text-align: left;">NGINX logs, NGINX Plus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">5xx codes</td>
|
||||
<td style="text-align: left;">Count of server errors</td>
|
||||
<td style="text-align: left;">Work: Errors</td>
|
||||
<td style="text-align: left;">NGINX logs, NGINX Plus</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
NGINX 错误指标告诉你服务器经常返回哪些错误，这也是有用的。客户端错误返回4XX状态码，服务器端错误返回5XX状态码。
|
||||
|
||||
**提醒指标: 服务器错误率**
|
||||
|
||||
服务器错误率等于5xx错误状态代码的总数除以[状态码][7]（1XX，2XX，3XX，4XX，5XX）的总数，每单位时间（通常为一到五分钟）的数目。如果你的错误率随着时间的推移开始攀升，调查可能的原因。如果突然增加，可能需要采取紧急行动，因为客户端可能收到错误信息。
|
||||
|
||||
|
||||
|
||||
客户端收到错误时的注意事项：虽然监控4XX是很有用的，但从该指标中你仅可以捕捉有限的信息，因为它只是衡量客户的行为而不捕捉任何特殊的 URLs。换句话说，在4xx出现时只是相当于一点噪音，例如寻找漏洞的网络扫描仪。
|
||||
|
||||
**收集错误度量**
|
||||
|
||||
虽然开源 NGINX 不会监测错误率，但至少有两种方法可以捕获其信息：
|
||||
|
||||
- 使用商业支持的 NGINX Plus 提供的可扩展状态模块
|
||||
- 配置 NGINX 的日志模块将响应码写入访问日志
|
||||
|
||||
阅读关于 NGINX 指标收集的后两个方法的详细说明。
|
||||
|
||||
#### 性能指标 ####
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
<th style="text-align: left;"><strong>Availability</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">request time</td>
|
||||
<td style="text-align: left;">Time to process each request, in seconds</td>
|
||||
<td style="text-align: left;">Work: Performance</td>
|
||||
<td style="text-align: left;">NGINX logs</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**提醒指标: 请求处理时间**
|
||||
|
||||
请求时间指标记录 NGINX 处理每个请求的时间，从第一个客户端的请求字节读出到完成请求。较长的响应时间可以将问题指向负载均衡服务器。
|
||||
|
||||
**收集处理时间指标**
|
||||
|
||||
NGINX 和 NGINX Plus 用户可以通过添加 $request_time 变量到访问日志格式中来捕捉处理时间数据。关于配置日志监控的更多细节在[NGINX指标收集][8]。
|
||||
|
||||
#### 反向代理指标 ####
|
||||
|
||||
注：表格
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;">
|
||||
<col style="text-align: left;"> </colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th style="text-align: left;"><strong>Name</strong></th>
|
||||
<th style="text-align: left;"><strong>Description</strong></th>
|
||||
<th style="text-align: left;"><strong><a target="_blank" href="https://www.datadoghq.com/blog/monitoring-101-collecting-data/">Metric type</a></strong></th>
|
||||
<th style="text-align: left;"><strong>Availability</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="text-align: left;">Active connections by upstream server</td>
|
||||
<td style="text-align: left;">Currently active client connections</td>
|
||||
<td style="text-align: left;">Resource: Utilization</td>
|
||||
<td style="text-align: left;">NGINX Plus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">5xx codes by upstream server</td>
|
||||
<td style="text-align: left;">Server errors</td>
|
||||
<td style="text-align: left;">Work: Errors</td>
|
||||
<td style="text-align: left;">NGINX Plus</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="text-align: left;">Available servers per upstream group</td>
|
||||
<td style="text-align: left;">Servers passing health checks</td>
|
||||
<td style="text-align: left;">Resource: Availability</td>
|
||||
<td style="text-align: left;">NGINX Plus</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
[反向代理][9]是 NGINX 最常见的使用方法之一。商业支持的 NGINX Plus 显示了大量有关后端（或“负载均衡”）的服务器指标，这是反向代理设置的。本节重点介绍了几个关键的负载均衡服务器的指标为 NGINX Plus 用户。
|
||||
|
||||
NGINX Plus 的负载均衡服务器指标首先是组的，然后是单个服务器的。因此，例如，你的反向代理将请求分配到五个 Web 负载均衡服务器上，你可以一眼看出是否有单个服务器压力过大，也可以看出负载均衡服务器组的健康状况，以确保良好的响应时间。
|
||||
|
||||
**活动指标**
|
||||
|
||||
**active connections per upstream server**的数量可以帮助你确认反向代理是否正确的分配工作到负载均衡服务器上。如果你正在使用 NGINX 作为负载均衡器，任何一台服务器处理的连接数有显著的偏差都可能表明服务器正在努力处理请求或你配置处理请求的负载均衡的方法（例如[round-robin or IP hashing][10]）不是最适合你流量模式的。
|
||||
|
||||
**错误指标**
|
||||
|
||||
错误指标，上面所说的高于5XX（服务器错误）状态码，是监控指标中有价值的一个，尤其是响应码部分。 NGINX Plus 允许你轻松地提取每个负载均衡服务器 **5xx codes per upstream server**的数量，以及响应的总数量，以此来确定该特定服务器的错误率。
|
||||
|
||||
|
||||
**可用性指标**
|
||||
|
||||
对于 web 服务器的运行状况，另一种观点认为，NGINX 也可以很方便监控你的负载均衡服务器组的健康通过**servers currently available within each group**的总量。在一个大的反向代理上，你可能不会非常关心其中一个服务器的当前状态，就像你只要可用的服务器组能够处理当前的负载就行了。但监视负载均衡服务器组内的所有服务器可以提供一个高水平的图像来判断 Web 服务器的健康状况。
|
||||
|
||||
**收集负载均衡服务器的指标**
|
||||
|
||||
NGINX Plus 负载均衡服务器的指标显示在内部 NGINX Plus 的监控仪表盘上，并且也可通过一个JSON 接口来服务于所有外部的监控平台。在这儿看一个例子[收集 NGINX 指标][11]。
|
||||
|
||||
### 结论 ###
|
||||
|
||||
在这篇文章中，我们已经谈到了一些有用的指标，你可以使用表格来监控 NGINX 服务器。如果你是刚开始使用 NGINX，下面提供了良好的网络基础设施的健康和活动的可视化工具来监控大部分或所有的指标：
|
||||
|
||||
- [Dropped connections][12]
|
||||
- [Requests per second][13]
|
||||
- [Server error rate][14]
|
||||
- [Request processing time][15]
|
||||
|
||||
最终，你会学到更多，更专业的衡量指标，尤其是关于你自己基础设施和使用情况的。当然，监控哪一项指标将取决于你可用的工具。参见[一步一步来说明指标收集][16]，不管你使用 NGINX 还是 NGINX Plus。
|
||||
|
||||
|
||||
|
||||
在 Datadog 中，我们已经集成了 NGINX 和 NGINX Plus，这样你就可以以最小的设置来收集和监控所有 Web 服务器的指标。了解如何用 NGINX Datadog来监控 [在本文中][17]，并开始使用 [免费的 Datadog][18]。
|
||||
|
||||
### Acknowledgments ###
|
||||
|
||||
在文章发表之前非常感谢 NGINX 团队审阅这篇，并提供重要的反馈和说明。
|
||||
|
||||
----------
|
||||
|
||||
文章来源在这儿 [on GitHub][19]。问题，更正，补充等？请[告诉我们][20]。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.datadoghq.com/blog/how-to-monitor-nginx/
|
||||
|
||||
作者：K Young
|
||||
译者：[strugglingyouth](https://github.com/strugglingyouth)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://nginx.org/en/
|
||||
[2]:http://nginx.com/resources/glossary/reverse-proxy-server/
|
||||
[3]:https://www.datadoghq.com/blog/monitoring-101-collecting-data/
|
||||
[4]:http://nginx.org/en/docs/ngx_core_module.html#worker_connections
|
||||
[5]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#active-state
|
||||
[6]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[7]:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
|
||||
[8]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[9]:https://en.wikipedia.org/wiki/Reverse_proxy
|
||||
[10]:http://nginx.com/blog/load-balancing-with-nginx-plus/
|
||||
[11]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[12]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#dropped-connections
|
||||
[13]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#requests-per-second
|
||||
[14]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#server-error-rate
|
||||
[15]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#request-processing-time
|
||||
[16]:https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/
|
||||
[17]:https://www.datadoghq.com/blog/how-to-monitor-nginx-with-datadog/
|
||||
[18]:https://www.datadoghq.com/blog/how-to-monitor-nginx/#sign-up
|
||||
[19]:https://github.com/DataDog/the-monitor/blob/master/nginx/how_to_monitor_nginx.md
|
||||
[20]:https://github.com/DataDog/the-monitor/issues
|
||||
Loading…
Reference in New Issue
Block a user