要不要也来分享分享一下啊
运维监控

运维监控

Elastic 中文社区运维监控实战 (2) - 总体方案

经验分享medcl 发表了文章 • 0 个评论 • 6775 次浏览 • 2018-02-01 21:18 • 来自相关话题

接上一篇:Elastic 中文社区运维监控实战 (1) - 序

本文为系列文章第二篇,主要介绍如何把 Elastic 中文社区的网站服务器监控起来,对有同样想了解如何使用 Elastic Stack 来做运维监控的同学,可以作为一个很好的参考和入门资料,学习门槛定义为入门级。

本节内容

在深入到具体的监控指标收集的细节之前,今天先主要介绍一下 Elastic 中文社区的总体方案。这样我们在动手之前会有一个总体的思路和对所用工具有一个大致的了解。

技术选型

工欲善其事必先利其器

前面已经提到我们要对服务器进行各项性能指标的监控以及日志的监控。

看起来很复杂,因为有很多信息需要收集。 好在我们有 Elastic Stack,使用它们来作为我们的监控工具,整个工作就变得简单了,我们结合我们社区监控的这个场景,具体来看的话,需要的工具主要是如下几个:

Elasticsearch 是一个分布式的 RESTful 风格的搜索和数据分析引擎。简单易用,用户众多,性能优良,久经考验,支持单节点部署到虚拟机,并可随着业务增长无缝伸缩扩容至上千个节点规模的集群,PB 级别数据也不在话下。

日志数据和指标监控数据都能放,通过集中式存储所有的这些时序型数据,可以快速方便的对这些数据进行分析和关联,实在是排障运维和性能调优的不二选择,你如果还不知道 Elasticsearch,那我只能说你真的是 out 了。

Elastic Beats 家族的一员,Go 语言编写,轻量级,无依赖,这样就可以很方便的完成收集端的部署,所以如果你的场景和我一样, 可以优先使用 Filebeat 代替 Logstash 来收集日志,当然如果有日志的进一步加工,可以让 Filebeat 把数据发送给 Logstash,然后 Logstash 处理完之后再发送给 Elasticsearch。

Filebeat 使用很灵活,可以指定你的日志路径来进行收集,还可以对数据进行预过滤,对于一些常见的监控需求,Filebeat 以模块的方式替你打包好了一切,如:日志路径配置、解析规则、机器学习的任务,甚至还自带 Dashboard,简单几个操作,就可以完成从数据收集到最终可视化分析的所有工作。

我们这次需要监控的服务器都是一些常规的指标,而 Metricbeat 刚好都支持这些指标的收集,你说这不巧了不是。

Metricbeat 同样也是 Elastic Beats 家族的一员,同样也是开源的。定位是一个轻量级的监控指标采集器,采用 Go 语言编写,同样提供的是一个很小的无依赖的二进制文件包,能够收集服务器(Linux、Windows、Mac)本身的运行指标,如: CPU 使用率、内存、文件系统、磁盘 IO 和网络 IO 统计数据等,还能获取服务器上面的各项服务的运行指标,常见的如: Apache、NGINX、MongoDB、MySQL、PostgreSQL、Prometheus、Redis 等都有直接支持,并且内置了 Elasticsearch 索引和 mapping 设置,以及 Ingest pipeline 设置,还提前预置了不少 Kibana 的 Dashboard,开箱即用、即分析。

和 Elasticsearch 工作的最佳拍档,结合 Elasticsearch 的实时分析能力,可以非常方便的对各种数据进行搜索和分析,你可以灵活的自定义的各种图形展现和 Dashboard,不用编写一行代码,即可进行数据分析,除了分析,还整合了 Elastic Stack 的各个产品的管理功能,作为 Elastic Stack 的图形交互终端。

除了上面这些工具,后续我们还可以考虑使用 Auditbeat 来收集服务器的安全行为日志,使用 Heartbeat 来监控各个服务的端口是否正常,我们先完成基本的监控之后,再慢慢将这些加上。

可以看到,我们没有用到 Logstash,是的,这个规模的监控,可以不考虑 Logstash,这样我们可以做到架构简单和足够的轻量级。

上面列的这些软件都是 Elastic 家族的产品,并且都是开源的,所有的源码都在:https://github.com/elastic/

部署方案

在收集数据之前,我们需要明确我们数据放在哪里,毫无疑问,所有的数据都将放在 Elasticsearch 里面,不过 Elasticsearch 不能部署在 Elastic 中文社区的这台服务器上面,一个是资源的限制,另外一个是基于安全的考虑,如果 Elastic 社区的服务器挂了,数据不光收不到,连什么时候挂的都不知道。所以我们需要把 Elasticsearch 服务搭建在别的地方,有多种选择:

  • 使用 Elastic Cloud,很方便就能开通,缺点国内访问速度慢,暂时还没开放机器学习的功能。
  • 使用阿里云的 Elasticsearch,Elastic 官方合作伙伴,国内唯一包含 X-Pack 的完整功能的 Elasticsearch 云服务,国内访问速度快。
  • 自己搭建的 Elasticsearch 集群。

使用阿里云的 Elasticsearch 无疑很方便,不过我家里刚好有一台服务器,型号 HP Gen8,16GB 内存,上面运行了 SmartOS,跑几个 zone 很轻松,每天用来备份社区的数据库,再来起一个 Elasticsearch 服务也很方便,通过路由器将内网 IP 映射出去,让社区服务器将监控数据发送到这台服务器上面来,安全上面,需要保证这台服务器不被黑客攻击,需要做一些必要的访问控制,可以使用 X-Pack 的身份验证,结合 IP 白名单功能,只允许内网和 Elastic 中文社区服务器的 IP 访问。

我们将之命名为:Ops Center,方便后面招呼。

可以看到,Elastic 社区服务器除了启动 Filebeat 和 Metricbeat 之外,不需要额外做什么服务器本身的设置。

这里画一个简单的部署拓扑图,方便理解:

deploy2.png

今天主要写到这里,后面将具体介绍它们的安装部署过程。

es有没有自动部署 平滑启停的第三方运维工具,类似kibana kopf这种的由图形化可以管理的?

Elasticsearchkennywu76 回复了问题 • 4 人关注 • 1 个回复 • 3538 次浏览 • 2018-01-29 11:42 • 来自相关话题

Elastic 中文社区运维监控实战 (1) - 序

经验分享medcl 发表了文章 • 1 个评论 • 6789 次浏览 • 2018-01-25 21:47 • 来自相关话题

本文为系列文章第一篇,主要介绍如何把 Elastic 中文社区的网站服务器监控起来,对有同样想了解如何使用 Elastic Stack 来做运维监控的同学,可以作为一个很好的参考和入门资料,学习门槛定义为入门级。

首先,我们要监控的网站,也就是大家现在正在访问的 Elastic 官方中文社区,网址:elasticsearch.cn,这个网站基于开源的 WeCenter 搭建,开发语言是 PHP,后端数据库是 MySQL,目前只有一台服务器,由 ConvertLab 友情无偿赞助,大写的赞!再次感谢!

服务器部署环境是 Ubuntu 16.04.2,部署了以下服务及软件:

  • Nginx - Http 反向代理,不要介绍了吧
  • PHP-FPM - 一个常用的 PHP FastCGI 管理
  • Elasticsearch - Elasticsearch 服务,用于社区的垂直搜索服务 Elastic 情报局 服务
  • GOPA - 可以说是为社区而写的,一个轻量级的爬虫,用于爬取 Elatic 周边相关相关资料,创建索引存放到 Elasticsearch 里面,提供垂直搜索服务,代码地址
  • Grok Debugger - 一个 Java 的 Grok pattern 调试服务,方便大家调试 Grok 日志解析规则,访问地址:grok.elasticsearch.cn

服务器上所有的财产就这些了,一个平淡无奇的网站,基本上所有的东西都能公开访问到,这个网站的目的就是为所有 Elastic 爱好者服务的,供大家交流和沟通的专属平台,所以请各位黑客大侠不要再扫描和攻击啦,画一个简单的拓扑图如下所示:

topology.png

作为一个合格的网管,除了重启服务器之外,还必须要保证网站的正常运行,所以了解网站的运行情况就变成了一个需要解决的首要问题,我们可以先把任务具体列一下:

  • 网站是否正常访问,各项服务有没有挂
  • 网站访问情况如何,用户访问速度如何
  • 网站访客统计分析,访客相关数据分析
  • 服务器的各项指标,详细指标监控分析
  • 服务器的各项服务,日志集中分析处理
  • 服务器是否很安全,有没有黑客来造访
  • 数据是否安全备份,有没有定期测试过

实在编不下去了(话说对的还蛮齐),说人话就是监控起服务器的各项指标和收集服务的日志,然后出几个分析的 Dashboard,监控报警整起来。

我们这次需要用到的工具主要就是 Elastic Stack 啦,Elastic Stack 包括 Elasticsearch、Logstash、Beats 和 Kibana,版本都用最新的 6.x,再结合我们实际的数据和实际的需求,在后面的文章里面,我会具体介绍它们是什么以及如何使用。

今天先写到这里,明天写监控指标的收集,此系列文章暂且定为需要 100 期完成。(开个玩笑,哈哈)。

es有没有自动部署 平滑启停的第三方运维工具,类似kibana kopf这种的由图形化可以管理的?

回复

Elasticsearchkennywu76 回复了问题 • 4 人关注 • 1 个回复 • 3538 次浏览 • 2018-01-29 11:42 • 来自相关话题

Elastic 中文社区运维监控实战 (2) - 总体方案

经验分享medcl 发表了文章 • 0 个评论 • 6775 次浏览 • 2018-02-01 21:18 • 来自相关话题

接上一篇:Elastic 中文社区运维监控实战 (1) - 序

本文为系列文章第二篇,主要介绍如何把 Elastic 中文社区的网站服务器监控起来,对有同样想了解如何使用 Elastic Stack 来做运维监控的同学,可以作为一个很好的参考和入门资料,学习门槛定义为入门级。

本节内容

在深入到具体的监控指标收集的细节之前,今天先主要介绍一下 Elastic 中文社区的总体方案。这样我们在动手之前会有一个总体的思路和对所用工具有一个大致的了解。

技术选型

工欲善其事必先利其器

前面已经提到我们要对服务器进行各项性能指标的监控以及日志的监控。

看起来很复杂,因为有很多信息需要收集。 好在我们有 Elastic Stack,使用它们来作为我们的监控工具,整个工作就变得简单了,我们结合我们社区监控的这个场景,具体来看的话,需要的工具主要是如下几个:

Elasticsearch 是一个分布式的 RESTful 风格的搜索和数据分析引擎。简单易用,用户众多,性能优良,久经考验,支持单节点部署到虚拟机,并可随着业务增长无缝伸缩扩容至上千个节点规模的集群,PB 级别数据也不在话下。

日志数据和指标监控数据都能放,通过集中式存储所有的这些时序型数据,可以快速方便的对这些数据进行分析和关联,实在是排障运维和性能调优的不二选择,你如果还不知道 Elasticsearch,那我只能说你真的是 out 了。

Elastic Beats 家族的一员,Go 语言编写,轻量级,无依赖,这样就可以很方便的完成收集端的部署,所以如果你的场景和我一样, 可以优先使用 Filebeat 代替 Logstash 来收集日志,当然如果有日志的进一步加工,可以让 Filebeat 把数据发送给 Logstash,然后 Logstash 处理完之后再发送给 Elasticsearch。

Filebeat 使用很灵活,可以指定你的日志路径来进行收集,还可以对数据进行预过滤,对于一些常见的监控需求,Filebeat 以模块的方式替你打包好了一切,如:日志路径配置、解析规则、机器学习的任务,甚至还自带 Dashboard,简单几个操作,就可以完成从数据收集到最终可视化分析的所有工作。

我们这次需要监控的服务器都是一些常规的指标,而 Metricbeat 刚好都支持这些指标的收集,你说这不巧了不是。

Metricbeat 同样也是 Elastic Beats 家族的一员,同样也是开源的。定位是一个轻量级的监控指标采集器,采用 Go 语言编写,同样提供的是一个很小的无依赖的二进制文件包,能够收集服务器(Linux、Windows、Mac)本身的运行指标,如: CPU 使用率、内存、文件系统、磁盘 IO 和网络 IO 统计数据等,还能获取服务器上面的各项服务的运行指标,常见的如: Apache、NGINX、MongoDB、MySQL、PostgreSQL、Prometheus、Redis 等都有直接支持,并且内置了 Elasticsearch 索引和 mapping 设置,以及 Ingest pipeline 设置,还提前预置了不少 Kibana 的 Dashboard,开箱即用、即分析。

和 Elasticsearch 工作的最佳拍档,结合 Elasticsearch 的实时分析能力,可以非常方便的对各种数据进行搜索和分析,你可以灵活的自定义的各种图形展现和 Dashboard,不用编写一行代码,即可进行数据分析,除了分析,还整合了 Elastic Stack 的各个产品的管理功能,作为 Elastic Stack 的图形交互终端。

除了上面这些工具,后续我们还可以考虑使用 Auditbeat 来收集服务器的安全行为日志,使用 Heartbeat 来监控各个服务的端口是否正常,我们先完成基本的监控之后,再慢慢将这些加上。

可以看到,我们没有用到 Logstash,是的,这个规模的监控,可以不考虑 Logstash,这样我们可以做到架构简单和足够的轻量级。

上面列的这些软件都是 Elastic 家族的产品,并且都是开源的,所有的源码都在:https://github.com/elastic/

部署方案

在收集数据之前,我们需要明确我们数据放在哪里,毫无疑问,所有的数据都将放在 Elasticsearch 里面,不过 Elasticsearch 不能部署在 Elastic 中文社区的这台服务器上面,一个是资源的限制,另外一个是基于安全的考虑,如果 Elastic 社区的服务器挂了,数据不光收不到,连什么时候挂的都不知道。所以我们需要把 Elasticsearch 服务搭建在别的地方,有多种选择:

  • 使用 Elastic Cloud,很方便就能开通,缺点国内访问速度慢,暂时还没开放机器学习的功能。
  • 使用阿里云的 Elasticsearch,Elastic 官方合作伙伴,国内唯一包含 X-Pack 的完整功能的 Elasticsearch 云服务,国内访问速度快。
  • 自己搭建的 Elasticsearch 集群。

使用阿里云的 Elasticsearch 无疑很方便,不过我家里刚好有一台服务器,型号 HP Gen8,16GB 内存,上面运行了 SmartOS,跑几个 zone 很轻松,每天用来备份社区的数据库,再来起一个 Elasticsearch 服务也很方便,通过路由器将内网 IP 映射出去,让社区服务器将监控数据发送到这台服务器上面来,安全上面,需要保证这台服务器不被黑客攻击,需要做一些必要的访问控制,可以使用 X-Pack 的身份验证,结合 IP 白名单功能,只允许内网和 Elastic 中文社区服务器的 IP 访问。

我们将之命名为:Ops Center,方便后面招呼。

可以看到,Elastic 社区服务器除了启动 Filebeat 和 Metricbeat 之外,不需要额外做什么服务器本身的设置。

这里画一个简单的部署拓扑图,方便理解:

deploy2.png

今天主要写到这里,后面将具体介绍它们的安装部署过程。

Elastic 中文社区运维监控实战 (1) - 序

经验分享medcl 发表了文章 • 1 个评论 • 6789 次浏览 • 2018-01-25 21:47 • 来自相关话题

本文为系列文章第一篇,主要介绍如何把 Elastic 中文社区的网站服务器监控起来,对有同样想了解如何使用 Elastic Stack 来做运维监控的同学,可以作为一个很好的参考和入门资料,学习门槛定义为入门级。

首先,我们要监控的网站,也就是大家现在正在访问的 Elastic 官方中文社区,网址:elasticsearch.cn,这个网站基于开源的 WeCenter 搭建,开发语言是 PHP,后端数据库是 MySQL,目前只有一台服务器,由 ConvertLab 友情无偿赞助,大写的赞!再次感谢!

服务器部署环境是 Ubuntu 16.04.2,部署了以下服务及软件:

  • Nginx - Http 反向代理,不要介绍了吧
  • PHP-FPM - 一个常用的 PHP FastCGI 管理
  • Elasticsearch - Elasticsearch 服务,用于社区的垂直搜索服务 Elastic 情报局 服务
  • GOPA - 可以说是为社区而写的,一个轻量级的爬虫,用于爬取 Elatic 周边相关相关资料,创建索引存放到 Elasticsearch 里面,提供垂直搜索服务,代码地址
  • Grok Debugger - 一个 Java 的 Grok pattern 调试服务,方便大家调试 Grok 日志解析规则,访问地址:grok.elasticsearch.cn

服务器上所有的财产就这些了,一个平淡无奇的网站,基本上所有的东西都能公开访问到,这个网站的目的就是为所有 Elastic 爱好者服务的,供大家交流和沟通的专属平台,所以请各位黑客大侠不要再扫描和攻击啦,画一个简单的拓扑图如下所示:

topology.png

作为一个合格的网管,除了重启服务器之外,还必须要保证网站的正常运行,所以了解网站的运行情况就变成了一个需要解决的首要问题,我们可以先把任务具体列一下:

  • 网站是否正常访问,各项服务有没有挂
  • 网站访问情况如何,用户访问速度如何
  • 网站访客统计分析,访客相关数据分析
  • 服务器的各项指标,详细指标监控分析
  • 服务器的各项服务,日志集中分析处理
  • 服务器是否很安全,有没有黑客来造访
  • 数据是否安全备份,有没有定期测试过

实在编不下去了(话说对的还蛮齐),说人话就是监控起服务器的各项指标和收集服务的日志,然后出几个分析的 Dashboard,监控报警整起来。

我们这次需要用到的工具主要就是 Elastic Stack 啦,Elastic Stack 包括 Elasticsearch、Logstash、Beats 和 Kibana,版本都用最新的 6.x,再结合我们实际的数据和实际的需求,在后面的文章里面,我会具体介绍它们是什么以及如何使用。

今天先写到这里,明天写监控指标的收集,此系列文章暂且定为需要 100 期完成。(开个玩笑,哈哈)。