让我稍微透露一下在服务器监控和操作方面使用的一些工具

首先

本投稿为Schoo Advent Calendar 2016的第25天的贴文。

作为一名工程师，近几年来我的主要领域是基础设施，所以我想要在这方面做一些贡献……于是我决定介绍一些我在服务器监控和运维中使用的工具，并开始敲击键盘。

顺便提一下…
虽然之后会介绍一些，但并不是只使用一个服务器，也使用了除了介绍的工具之外的其他工具，请理解这一点。

亚马逊云监控

一般情况下，我们会使用其他工具（如后面提到的Grafana）来搭建监控环境。但对于平时不需要关注的监控项目，由于我们的服务在AWS上构建，我们会使用CloudWatch进行监控。

但是，即使是那些平常不需要特别关注的项目，我们也会考虑在监控的各个方面设置阈值，一旦超过阈值，通过SNS通知Lambda函数来将通知发送到Slack。

因为有时在平时不常见（不需要经常查看）的项目中能够事先检测到异常值，这可能会带来意想不到的障碍。
（但是，实际上，并不经常从CloudWatch收到警报。）

Amazon CloudWatch ( https://aws.amazon.com/jp/cloudwatch/ )

Grafana 可视化工具

我认为最近有越来越多的人开始将其用作前端，并通过可视化各种数值信息，特别是性能监测来进行监控。
作为基础设施负责人，我每天都会多次查看Grafana的界面。

监视系统的配置如下（简化说明）：

根据上面的构成图，我们在运行监视中使用Sensu，并在每台服务器上安装Sensu-Client作为代理程序，以便从这些代理程序将各种指标发送到时序数据库InfluxDB。
然后，我们配置Grafana以可视化存储在InfluxDB中的各种指标。

此外，如果监视服务器发生故障，将无法察觉到任何问题的出现。因此，我们使用多个AZ来构建一个集群。然而，当前的监视服务器也用于各种基础设施相关工具，导致服务器变得杂乱无章。因此，我们计划在不久的将来将监视机制迁移到类似Prometheus的工具上进行重建。（似乎还有一些关于”Prometheus很棒！”的文章也开始出现了…）

• Grafana ( http://grafana.org/ )

 

• InfluxDB ( https://www.influxdata.com/time-series-platform/influxdb/ )

 

• Sensu ( https://sensuapp.org/ )

 

Prometheus (https://prometheus.io/)

监视

为了实现在每个服务器内进行自主运行监控的目标，我们在各种服务器上使用了Monit这个常备工具。

主要的使用方法是监视不时运行会影响服务的守护进程（例如Nginx）。当运行的守护进程由于错误或其他原因突然死亡，或者根据服务器配置和负载情况下可能会由OOM Killer关闭守护进程时，它可以帮助我们在不需要进行任何操作的情况下重新启动守护进程，非常方便。

如果以处理守护进程的方式来写的话，可能会听到类似的声音，比如：“不是有Upstart吗…”
但是，我们选择用Upstart来启动Monit，并将Monit负责管理进程和通知的任务分担给它。

顺便提一下，Schoo也在Docker容器的监控中使用了它。
至于这个（使用Monit监控Docker容器的方法），似乎即使搜索也找不到很多结果，所以就写一下Schoo是如何使用Monit监控容器的一些小提示吧…

我认为自从Monit版本5.2之后，除了pid文件之外，还可以使用MATCHING来使用正则表达式来检查进程名进行监视（参见：文档）。如果想要在容器停止时自动启动，可以使用以下方式在Monit中进行监视设置。

check process container-elasticsearch with matching "elasticsearch"
    start program = "/usr/bin/docker start <container id|container name>"
    stop program  = "/usr/bin/docker stop <container id|container name>"
    if 5 restarts within 5 cycles then timeout

如果按照Docker的一般用法，容器是在一个特定功能上运行的，如果该功能停止，容器也会停止。在上述情况中，如果有一个将elasticsearch作为容器在Docker主机上运行，并由Monit进行监控的例子，以下是使用MATCHING的最低配置示例。

无论在这里还是其他地方，我们已经设置了一个功能，一旦处理执行，将向Slack发送通知（通知重启）。关于如何发送Slack通知，你可以自行搜索并得到很多相关结果，所以我将省略这里的设置方法。（按这个链接参考，你应该能够轻松地设置好通知到Slack的功能。）

Monit ( https://mmonit.com/monit/ )

htop

我正在一些服务器上使用替代命令来运行top命令。
它可以在树形视图中显示父子关系，并且以文本图形的形式显示CPU和内存资源。

由于它是一个方便的工具，所以可能可以在所有服务器上统一更换，但是首先，top系列的命令本身就很重，因此我们没有在那些使用uptime、free和ps命令就足够的服务器上安装。

我们在混合了多种功能的服务器或者运行进程数较多的服务器上进行部署（例如，由于我们公司的机制，批处理服务器会有许多Fork出的进程，因此树状视图的展开和关闭功能非常方便！）。

htop ( https://hisham.hm/htop/ )

Kibana 可视化工具

Kibana是Elastic公司提供的Elasticsearch前端GUI（可视化工具）。为了查看Schoo前端Web服务器的日志，我们在此搭建了td-agent+Elasticsearch+Kibana+Nginx的环境并使用。

我最近重建了这个Kibana（版本为5.0.x），但是它的用户界面的变化让我感到非常惊讶（变得非常丰富多彩！！）。

学校中使用Kibana分析登录日志，可以一并查看处理时间较长的URL和出现错误的URL等，以便确认其数量和状况。

此外，我们有时也会将Web服务器的原始数据（称为Log）可视化处理，为了保证安全性，我们设置了使用oauth2-proxy和Google认证，以限制能够查看Log的用户。请忍耐一下，别提”Plugin里有Shield啊！”这样的点评，因为Shield是收费的w。

这个oauth2-proxy的配置非常简单，虽然有一份内部设置文档可供参考（将内部文档转化为文章还需要额外操作，呵呵），但我希望在其他地方发布一篇独立的文章公开讨论。

• Kibana ( https://www.elastic.co/jp/products/kibana )

 

oauth2-proxy ( https://github.com/bitly/oauth2_proxy )

以下是用中文对“incron”进行的本地化改写的选项：

增强型 cron（incron）

这是一个使用Linux的inotify来启动cron的守护进程。

在学校里，我们使用它来简化处理或脚本等操作。例如，

$ touch /var/run/php-fpm/restart

当我们通过”touch”命令更新文件的时间戳（在这种情况下为/var/run/php-fpm/restart文件），我们可以设置并执行以下命令来重新启动php-fpm守护进程。

/var/run/php-fpm/restart IN_MODIFY,IN_NO_LOOP /sbin/service php-fpm restart 

我们使用incron在需要在服务器端发出命令并且结果不会立即返回（需要数秒甚至更长时间）的情况下，或者在需要故意以异步方式处理时。

由于incron可以通过简单的设置方便地用作异步处理，因此我们经常以相当高的频率使用它进行各种操作。

incron ( http://inotify.aiken.cz/?section=incron&page=about&lang=en )

厨师独行士和ansible

Chef-Solo和Ansible，都是同一目的的工具介绍，但我同时使用两者哈哈。

说到使用不同方式，目前没有明确的规则，实际上是根据工作人员的喜好来决定的状态。
（当然，我们也考虑着制定规则并统一某种方式……）

根据过去的经历，最初我们使用的是Chef（在我的入职之前），但是考虑到我们没有那么多的服务器，维护Chef服务器太麻烦了…所以我入职后将Chef服务器停用，并改用Chef-Solo。

随后，在开发成员不断增加的情况下，开始有人开始使用ansible…… 这就是导致现状的经过吗？

这只是关于运营周围的一点闲谈，不过除此之外，在运营领域也有像Rundeck这样的GUI，可以用于批量执行命令的GUI。
通过使用Rundeck，在主机定义中，可以利用AWS的API来筛选出特定标签的服务器列表，并自动生成以yaml格式呈现的主机信息。

虽然说，由于我是唯一负责基础设施的人，所以只有我一个人使用Rundeck！哈哈。
而且，也只是每几个月才使用一次，如果在本地准备一个能快速打开集群控制台的脚本，也能实现相同的功能，所以也许会将其从环境中删除掉…哈哈。

• Chef ( https://www.chef.io/chef/ )

 

• ansible ( https://www.ansible.com/ )

 

Rundeck ( http://rundeck.org/ )

总结

我试着介绍了一些使用的工具，随着粒度的改变。
关于监控方面，有一些在服务器上运行的代理插件是用Golang编写的，还有一些可以更详细解释的因素，但这部分会在以后有机会时再详细介绍和写。

也许作为 Advent Calendar 的结束文章，内容可能会稍微轻松一些。
此外，尽管我有意识地提到了“阅读”，但由于没有进行严格的校对，可能会难以阅读。
而且，也许最好在文章中涉及与技术相关的其他“事物”，而不仅仅是关于技术的讨论。

然而，在像这样的介绍类文章中，就算是旧旧的帖子也可以成为了解未知事物和技术的“契机”，即使已经知道了也可以作为“实例”来应用，以充实个人的“知识”库。

如果我要说欲望的话，我认为让大家在这篇文章中了解一下叫做Schoo的公司和服务，可以作为一个切入点。

希望能有人在了解Schoo之后，并且通过这次Schoo Advent Calendar 2016的活动，对成为我们的成员充满期望。