方法一： 本模块在编译的时候默认是不编译的，如果你是从源码编译安装的nginx，那么需要在编译的时候加上对应的模块 ./configure –with-http_stub_status_module 使用 ./configure –help 能看到更多的模块支持。然后编译安装即可。 如果是直接 apt-get install 安装的 nginx，那么使用命令来查看是否支持 stub_status 这个模块。如下命令： www.it165.net nginx -V 看看是否有 –with-http_stub_status_module 这个模块。 ok，上面的事情告一段落，接下来需要在nginx的配置文件中增加这个配置项。打开nginx的配置文件 nginx.conf，在server段里面增加如下的内容： location /nginx-status { allow 127.0.0.1; //允许的IP deny…
作者｜杨波 编辑｜郭蕾 一、前言 2014 年可以认为是微服务 1.0 的元年，当年有几个标志性事件，一是 Martin Fowler 在其博客上发表了”Microservices”一文，正式提出微服务架构风格；二是 Netflix 微服务架构经过多年大规模生产验证，最终抽象落地形成一整套开源的微服务基础组件，统称 NetflixOSS，Netflix 的成功经验开始被业界认可并推崇；三是 Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系，推出 Spring Cloud 微服务开发技术栈。 一晃三年过去，微服务技术生态又发生了巨大变化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless 等新技术新理念你方唱罢我登场，不知不觉我们又来到了微服务 2.0 时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累，我想总结并提出一些构建微服务 2.0…
1. 标准输入stdin文件描述符为0，标准输出stdout文件描述符为1，标准错误stderr文件描述符为2 2. /dev/null 空设备，相当于垃圾桶 3. 重定向符号：> 3. 2>1 与 2>&1 的区别 2>1, 把标准错误stderr重定向到文件1中 2>&1,把标准错误stderr重定向到标准输出stdout 4. 举例: 假设有脚本test.sh，内容如下，t是一个不存在的命令，执行脚本进行下面测试。 # cat test.sh t date 标准输出重定向到log，错误信息输出到终端上，如下： # ./test.sh > log ./test.sh: line…
目前线上服务使用了k8s进行部署，一个服务配置了多个副本，然后日志是挂载到宿主机器的目录的，所以当服务部署到三台机器时，这时要查看业务日志，就必须依次登录三台服务器来看日志。显然，这非常地不方便。团队想把日志收集到一个地方统一查看。于是开始尝试各种方案。 尝试 1. elasticsearch + fluentd + in_tail(input) + fluent-plugin-elasticsearch(output) + kibana 刚开始就测试使用网络上推荐的日志收集方案，elasticsearch + fluentd + kibana,部署完成后，经过使用，并不能很方便地对日志进行检索，因为日志格式非常多，不方便对日志进行格式化，所以收集过来的日志并不是结构化的。另一个原因是elasticsearch占用的CPU很高，这个不知道什么原因，可能给的资源不够或配置不当。不过更主要是团队成员希望最好是直接把日志收集到一台服务器，然后能够使用linux的工具，如grep,awk,less来查询日志，所以最终放弃此方案。 2. rsyslog + fluentd + in_tail(input) + fluent-plugin-remote_syslog(output) 然后开始尝试使用fluentd来收集日志并发送到rsyslog, rsyslog使用fluentd发送过来的tag来命令文件名，但由于syslog协议的限制，tag最大为32个字符，最终无奈放弃此方案。 3. fluentd-agent(input: in_tail,…
最近为了做一些数据分析，把我自己服务器上所有应用的日志都通过 fluentd 转存到 mongodb 了，第一次用 fluentd，记录一些笔记。 因为是初学，绝大部分内容来源于官方文档2，等实际线上使用一段时间后再来更新一些心得。 一、Install fluent 比较烦的一点是，从 gem 安装和从 rpm、yum 安装的名字不一样，连配置文件的路径都不一样，需要记住的是： 从 gem 安装的，配置文件和执行程序都叫做 fluent； 从 rpm 安装的，配置文件和执行程序都叫做 td-agent。 1、安装 fluentd 详细可参见官方文档。 以 CentOS 为例： # 安装…
Note: This is an RHCSA 7 exam objective and an RHCE 7 exam objective. Presentation NTP (Network Time Protocol) is a protocol to keep servers time synchronized: one or several…
更新时间：2018-01-24 13:13:08 阿里云日志服务是针对日志类数据的一站式服务，用户只需要将精力集中在分析上，过程中数据采集、对接各种存储计算、数据索引和查询等琐碎工作等都可以交给日志服务完成。2017年9月日志服务升级日志实时分析功能（LogSearch/Analytics），可以使用查询+SQL92语法对日志进行实时分析。 在结果分析可视化上，除了使用自带Dashboard外，还支持DataV、Grafana、Tableua、QuickBI等对接方式。本文主要通过Grafana示例演示如何通过日志服务对Nginx日志进行分析与可视化。 在线成果演示请查看线上Demo。配置视频： 流程架构 日志从收集到分析的流程架构如下。 配置流程 日志数据采集。详细步骤请参考5分钟快速入门。 索引设置与控制台查询配置。详细步骤请参考索引设置与可视化或最佳实践网站日志分析案例。 安装Grafana插件，将实时查询SQL转化为视图。 本文档演示步骤3。 在做完1、2步骤后，在查询页面可以看到原始日志。 配置步骤 安装Grafana Grafana的详细安装步骤请参见Grafana官方文档。 以Ubuntu为例，安装命令为： wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.5.2_amd64.deb sudo apt-get install -y adduser libfontconfig sudo dpkg -i grafana_4.5.2_amd64.deb 如您需要使用饼状图，则需安装Pie…
转载本文需注明出处：EAii企业架构创新研究院（微信号：eaworld），违者必究。 前言 随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器、虚拟机、物理机不一而足。 面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机的应用日志、系统服务日志如何采用同一套方案快速、完整的收集和检索？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？本文主要从以下几个方面来分享下笔者在日志监控方面的一些经验。目录 一、DevOps浪潮下带来的监控挑战 二、统一监控平台架构解析 三、日志监控的技术栈 四、日志监控经典方案ELK 五、微服务+容器云背景下的日志监控实践Journald+fluentd+elasticsearch 六、如何选择适合自己的日志监控方案？ 一、DevOps浪潮下带来的监控挑战 现在Devops、云计算、微服务、容器等理念正在逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器，监控面临的压力越来越大。挑战主要有： 监控源的多样化挑战 业务、应用、网络设备、存储设备、物理机、虚拟机、容器、数据库、各种系统软件等等，需要监控的对象越来越多，指标也多种多样，如何以一个统一的视角，监控到所有的数据？ 海量数据的分析处理挑战 设备越来越多，应用越来越多，要监控的数据自然也排山倒海般袭来，怎样的监控系统才能应对大数据的采集、存储和实时分析展现呢？ 软硬件数据资源的管理分析挑战 数据是采集到了，采集全了，那么如何对他们进行分析呢？应用、系统软件和运行环境、网络、存储设备的关联关系是否能准确体现呢，某个点发生了故障、问题影响的链路是否能快速找到并进行处理呢？监控离不开和软硬件资源管理的结合。 面对这些挑战，是否感觉压力山大呢？一个监控平台，拥有哪些能力才能满足如此大的挑战呢？ 一个好的统一监控平台，应当具备如图所示的能力： 高度抽象模型，扩展监控指标：正如之前所说，监控源、指标的多样化，要求我们必须要进行监控模型的高度抽象，并且针对于指标可以动态扩展，这样才能保证监控平台的健壮性和可扩展性。 多种监控视图：监控数据自然不能只是简单的表格展现，饼图、柱状图、折线图、仪表盘等等，监控的数据需要结合实际情况选择最佳的图标展现。 强大的数据加工能力：海量的数据必须要有足够强大的数据加工、分析处理能力才能得到直观的结果 多种数据采集技术：数据源的不同决定了采集的技术也是有区别的。 多种报警机制：短信、邮件、企业内部通讯工具等等，结合不同场景选择不同的报警机制。 全路径问题跟踪：一个请求有可能牵扯到数个系统、数十个接口的调用，出了问题有可能是其中任何一个环节，也有可能是应用所处运行环境、网络、存储的问题，所以问题的定位离不开全路径的跟踪。 二、统一监控平台架构解析 统一监控平台由七大角色构成：监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。 监控源从层次上来分，大致可以分为三层，业务应用层、中间件层、基础设施层。业务应用层主要包括应用软件、企业消息总线等，中间件层包括数据库、缓存、配置中心、等各种系统软件，基础设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。 数据采集…
转载本文需注明出处：EAWorld，违者必究。 前言 随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器、虚拟机、物理机不一而足。面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机、网络设备、中间件的指标数据如何采用同一套方案快速、完整的收集和分析告警？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？ 上篇文章《建设DevOps统一运维监控平台，先从日志监控说起》主要从日志监控的方面进行了分享，本篇文章则是重点在系统监控层面进行分享。 目录： 一、统一监控平台架构解析 二、系统监控的技术栈 三、开源系统监控软件 Zabbix VS Nagios VS Open-Falcon 四、基于k8s容器云背景下的系统监控实践：cAdvisor+Heapster+Influxdb 五、容器时代的监控利器： Prometheus 一、统一监控平台架构解析 先做一下回顾，统一监控平台由七大角色构成：监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。 监控源： 从层次上来分，大致可以分为三层，业务应用层、中间件层、基础设施层。业务应用层主要包括应用软件、企业消息总线等，中间件层包括数据库、缓存、配置中心、等各种系统软件，基础设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。 数据采集： 数据源如此多样，数据采集的任务自然轻松不了。数据采集从指标上划分可以分为业务指标、应用指标、系统软件监控指标、系统指标。应用监控指标如：可用性、异常、吞吐量、响应时间、当前等待笔数、资源占用率、请求量、日志大小、性能、队列深度、线程数、服务调用次数、访问量、服务可用性等，业务监控指标如大额流水、流水区域、流水明细、请求笔数、响应时间、响应笔数等，系统监控指标如：CPU负载、内存负载、磁盘负载、网络IO、磁盘IO、tcp连接数、进程数等。 从采集方式来说通常可以分为接口采集、客户端agent采集、通过网络协议主动抓取（http、snmp等） 数据存储： 采集到的数据一般都会存储到文件系统（如HDFS）、索引系统（如elasticsearch）、指标库（如influxdb）、消息队列（如kafka，做消息临时存储或者缓冲）、数据库（如mysql） 数据分析： 针对采集到的数据，进行数据的处理。处理分两类：实时处理和批处理。技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等，重点是根据不同的场景需求选择不同的计算方式。 数据展现： 将处理的结果进行图表展现，在多屏时代，跨设备的支持必不可少。 预警：…
更新时间：2018-01-12 16:12:44 滚动发布 滚动发布（rolling update）是最常见的一种发布模式。比如我有10台机器，一台一台的进行部署。每台机器进行部署时，需要保证没有请求会派发到该机器，否则用户就会看到502的错误。所以需要有一个“下线”的操作，把当前机器从负载均衡中摘除，然后在部署完成之后，再把自己挂回到负载均衡中，这个过程称为“上线”。接下来会讲解，配合阿里云SLB如何做上线/下线操作。 基于阿里云SLB的滚动发布 在SLB中进行如下配置： 图中的关键点： 健康检查路径，需要由实例上的web服务器提供，在本例中是/nginx-status 。 健康检查间隔，配置为2S。 健康阈值，配置为2，也就说2次健康检查失败，则认为该后端服务器不可用。同样的，两次连续的健康检查成功，就会认为该后端服务器可用。 按照这个配置，如果/nginx-status这个URL不可用超过4S，则SLB会把该服务器摘除。在这4S内，应用服务仍需要是可用的，因为还会有请求派发过来。可以通过如下方式达到这个效果。 配置nginx 将/nginx-status这个URL派发到一个本地文件，使用如下配置文件： server { location ~ ^/(nginx-status) { root /home/admin/status; } } 并在机器上放置文件：/home/admin/status/nginx-status。当该文件被删除时候，/nginx-status这个请求会返回404，4S之后，该实例就会被从SLB中摘除。这个过程也就是“下线”的过程。 与之对应，touch /home/admin/status/nginx-status这个操作就是上线的过程，也是4S之后生效。 上/下线脚本 所以对应的，应用启停的脚本就是这样样子：…
Vinny Wang