监控

一、新版本的初步认识 —— 版本声明 很多人会误解与CactiEZ V10中文版本混淆，为了区分所以下一个版本将跳过V10，直接发布Cnyunwei-V11 V11里集成的Cacti中文版本还是采用的CactiEZV10中文版本来集成，也就是Cacti中文版本就是CactiEZV10中文版本的前身 CactiEZ中文版貌似N久前就解散了，已经N久没有更新了…… V11里会集成Cacti、nagios、Centreon、Check_MK、Nconf，可选择性安装 Cacti、Nagios、Centreon（中英文自己切换）、Check_MK、Nconf英文版本全部采用与国外官方同步的最新版本，会发布32位和64位两个版本 二、 新版本的初步认识 —— 与前一版本对比更新说明 与之前版本最大的区别是CentOS升级为最新版本6.4，新增Centreon集成，Check_MK与Nconf分开选择安装，各版本的更新升级（英文版本）及Bug修复，以下是具体说明： （1）修复前一版本中的已知Bug （2）修复中文版本中没有导入Nginx的模板问题 （3）修复在monitor插件中不显示Threshold插件报警提示 （4）Cacti增加更多的插件，及集成更多的设备监控模板 （5）新增集成Centreon最新版本 V2.4.3 （6）Nagios升级至最新版本 V3.5 （7）Check

常用优化要点 当nginx用于反向代理时，每个客户端将使用两个连接： 一个用于响应客户端的请求，另一个用于到后端的访问； 如果机器是两核CPU，例如： $ grep ^proces /proc/cpuinfo | wc -l 2 那么，可以从如下配置起步: # One worker per CPU-core. worker_processes 2; events { worker_connections 8096; multi_accept on; use epoll; } worker_rlimit_nofile 40000; http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 15; } 标准的代理配置 下面是一个基本的反向代理配置模板，将所有请求都转发给指定的后端应用。 例如，到 http://your.ip:80/ 的请求都将重定向到 http://127.0.0.1:4433/ 私有服务器 : # One process for each CPU-Core worker_processes 2; # Event handler. events { worker_connections 8096; multi_accept on; use epoll; } http { # Basic

【编者按】本文作者 Dan Kuebrich 是 AppNeta 公司应用性能产品主管，在本文中，作者通过分析两种终端用户监控方式的利弊，结合具体情况为监控的选择提出建议，本文系 OneAPM 工程师编译整理。 终端用户的性能大多是企业判断 Web 应用程序的标准，也就是说应用程序的响应是否能满足企业的标准。研究表明，在用户需求不断增长的同时，页面平均访问量也与日俱增——相对于 2010 来说已经增长了一倍。结合市场的频繁发布和更新，当下优化的步伐永远都无法及时跟上。 因此从终端用户的角度出发，对应用性能进行持续监控已成为关键。随着更多监控方法的涌现，用户又应该如何挑选最好的方法呢？ 真实用户监控 尽管 Web 应用服务器端的性能可以通过数据中心的 HTTP 请求进行观察测量，但整页加载时的 CDN 静态内容下载、页面渲染、执行 JavaScript 等数据却无法很好的监测。现实世界中，真实用户监控通常利用 JavaScript 脚本嵌入到 web 页面，在浏览器上收集终端用户在浏览过程中的性能数据。 这种监控有助于提升对应用性能的业务理解。收集的数据显示了页面加载的全部时间，基于世界各地的不同浏览器。这种监控适用于桌面、移动端和平板电脑的浏览器。 衡量实际数据的最大优势是不需要对重要用例的预定义。在每个用户体验应用时，真实用户监控捕捉所有数据，所以无论用户看到什么页面

不知不觉微软 Azure 已经进入中国市场近两年的时间。那么 Azure 平台的性能究竟如何？资源加载的延迟、虚拟机的稳定性等问题是否切实满足客户期许。这些都是大家对微软 Azure 这个国外的云服务使者非常关注的问题。 市场对 IaaS 云服务商的对比评测报告数不胜数，很难说谁家的评测报告准确可靠。况且国内公网网络稳定情况与国外存在一定的差距。在这样一个相对不稳定的环境下，公有云服务的 SLA 对于客户的最终使用体验很难完全保证。如何能够帮助客户及时了解自己用户的真实体验，采用有效的工具实时监控才是必由之路。 通过这篇培训文章，将教会大家如何在 Azure 上快速搭建一个博客，并使用国内性能监控的领军厂商 OneAPM 的产品，监测 Azure 云服务端到端的性能。 本文为了让大家能够快速上手，我们选择微软的 WINSR2012R2 系统和非常流行、性能强大的 Node.js 技术 栈。整个过程基本是 Windows 环境的一键安装。另外采用 WINSR2012R2 是因为系统集成的 IIS 天生就实现了 NTLM 认证，服务器端不用写任何代码，这对于中小网站的后台权限管理提供了很多便利。我们使用 Node.js 的 Ghost 框架快速搭建博客站点，采用 OneAPM 的 Node.js 探针来监控这个站点前后端的所有服务。下面我们开始吧： 1.部署 Azure Cloud

最近，开发者们越来越理解，为用户提供愉悦的用户体验的重要性，这也是实现业务目标的关键因素。作为高端用户，开发者本身也越来越意识到网站的性能对提升用户体验的重要性。 同样地，开发者也越来越清楚地认识到，用户从移动端访问网站的发展趋势，即移动流量的增长速度领先于传统的台式机/网络通信，而且移动设备的用户已经习惯于原生应用的表现和速度。 因此，开发者们认识到，要满足越来越多的移动端用户的需求，他们要采取一些迎合用户的行动，比如打造出拥有原生应用体验和性能的产品，从而给用户安全感，给他们带来乐趣，从而留住他们。 ##单页应用：打造优秀的网页应用体验 许多公司开始使用一种名为单页应用的新兴的网页设计范例，来打造网页应用的体验，当然这只占所有产品的一部分。针对上面提到的一些问题，通过 SPA 可以完美解决。 首先，单页应用更容易构建 Web 体验，在移动设备浏览器内，更接近地模拟本地应用的体验，无需构建和分发混合本地移动应用。这样避免了通过 App Store，省去等待 App Store 的审批周期，也无需等待客户下载最新版应用。而且，更新应用程序也极其简单，只要更新服务器上的代码就好了，这大大缩短了发布周期，甚至每天都能发布，而不是每两周或更长时间才能更新。 其次，单页应用支持丰富的交互部件，这些部件可能有很多交互状态「菜单、选择、项目点击等」，可能导致服务器端渲染的难度增大。 第三

工具1：“Cacti” Cacti是一个性能广泛的图表和趋势分析工具，可以用来跟踪并几乎可以绘制出任何可监测指标，描绘出图表。从硬盘的利用率到风扇的转速，在一个电脑管理系统中，只要是可以被监测的指标，Cacti都可以监测，并快速的转换成可视化的图表。 工具2：“Nagios” Nagios是一个经典的老牌系统和网络监测工具。运行速度快，可靠，需要针对应用定制。Nagios对于初学者是一个挑战。但是它的极其复杂的配置正好也反应出它的强大，因为它几乎可以适用于任何监控任务。要说缺点的话就是不怎么耐看，但是其强劲的功能和可靠性弥补了这个缺点。 工具3：“Icinga” Icinga 是一个正在重建的Nagios的分支，它提供了一个全面的监控和警报的框架，致力于设计一个像Nagios一样的开放和可扩展性的平台。但是和Nagios拥有不一样的Web界面。Icinga 1 和 Nagios非常的相近，不过Icinga 2就重写了。两个版本都能很好的兼容，而且，Nagios用户可以很轻松的转到Icinga 1平台。 工具4：“NeDi” NeDi可能不如其他的工具一样闻名全世界，但它确是一个跟踪网络接入的一个强大的解决方案。它可以很流畅的运行网络基础设施和设备目录，保持对任何事件的跟踪。并且可以提供任意设备的当前地点，也包括历史地点。NeDi可以被用于定位被偷的，或者是丢失掉的设备

1. Telegraf相关介绍以及实践 2. Influxdb相关介绍以及实践 3. Grafana相关介绍和实践 4.TIG架构组成以及原理介绍 telegraf为数据采集器，通过监控指标的配置将相应的数据采集并存储到influxdb中，进而进行时间序列化，而grafana最终通过influxdb中提供的源数据进行聚合分析和展示。 telegraf的难点在于理解每个plugin的配置以及采集指标的原理和含义；influxdb的难点在于类SQL语言的优化使用；grafana的难点在于对监控需求以及指标的分析和提取，并通过可视化配置将图标展现。 5.监控效果图 注意:原创著作，转载请联系作者！ 来源： oschina 链接： https://my.oschina.net/u/1026229/blog/751325

前言： Influxdb也是有influxdata公司(www.influxdata.com )开发的用于数据存储的时间序列数据库.可用于数据的时间排列。在整个TIG(Telegraf+influxdb+grafana)方案中，influxdb可算作一个中间件，主要负责原始数据的存储，并按照时间序列进行索引构建以提供时间序列查询接口。在整个TIG方案中，应该先构建的就是Influxdb。 Influxdb研究与实践： influxdb介绍： 使用TSM(Time Structured Merge)存储引擎，允许高摄取速度和数据压缩； 使用go编写，无需其他依赖； 简单，高性能写查询httpAPI接口； 支持其他数据获取协议的插件，比如graphite,collected,OpenTSDB； 使用relay构建高可用 https://docs.influxdata.com/influxdb/v1.0/high_availability/relay/ ； 扩展的类sql语言，很容易查询汇总数据； tag的支持，可用让查询变的更加高效和快速； 保留策略有效地自动淘汰过期的数据； 持续所产生的自动计算的数据会使得频繁的查询更加高效； web管理页面的支持 下载安装： github： https://github.com/influxdata/influxdb 源码编译 官网下载：

前言 Docker由于使用了基于namespace和cgroup的技术，因此监控docker容器和监控宿主机在某些性能指标和方式上有一些区别，而传统的监控方式可能无法满足docker容器内部的指标监控，本篇系列文章主要分享使用telegraf+influxdb+grafana去监控docker容器内部资源使用情况。目前主要关注的监控指标为：每个宿主机上的docker容器数量，每个docker容器的内存使用情况，CPU使用情况，网络使用情况以及磁盘使用情况。同时这套方案也能够监控到宿主机的一些基本资源使用情况。 Telegraf简介与实践 简介： 由influxdata公司开发的用于采集系统数据的服务，用纯go编写，通过插件化方式进行采集各种服务(system，docker，redis，nginx，kafka等)监控指标并且上报给相应的中间件，比如influxdb，opentsdb(商城docker监控使用这个)。Telegraf也是整个TICK(telegraf+influxdb+chronograf+kapacitor)生态栈的第一块组件也是最重要的组件。 特点： 纯go编写，不需要依赖其他组件；消耗相关系统资源比较小；plugins支持多种输入输出插件(采集和上报)； 相关连接： github： https://github.com/influxdata/telegraf

#####一.前言 对 APM 用户的一次真实调查分析（上） 中，我们主要聊到了现阶段国外 APM 行业对各个企业的渗透率、大部分使用 APM 工具的企业规模以及 APM 工具在用户心中的地位等问题，有兴趣的朋友可以点击链接观看。 我们本次继续顺着这个话题聊下去。 #####一.APM 工具的传统购买模式 先上个图！ 图 1. APM 工具的主要买家 如上图所示，IT 运维人员仍然是 APM 工具的主要买家(参见图 1 )，一个主要的原因是，IT 基础设施和运维人员是本次调查的主体。然而，无论行业、公司规模(员工，收入)和公司技术采用策略(保守，主流或激进)，结果都是一致的。但是，要注意，随着 DevOps 的兴起，IT 运维人员仍然是主要买家，但是 APM 数据 的消费者可能不再是 IT 运维人员。 至于 APM 产品的购买偏好，如下图 2 所示，60% 受访者认为购买单项工具是最佳选择，这一购买模式或许与目前的经济情况相关。当经济形势不好时，许多企业希望统一购买以节约成本，通过更大的折扣获得更好的价格。同样的，在经济良好时期，或者非紧缩时期，企业更多地关注性能，而不把成本作为主要购买标准。 图2. APM 产品购买偏好 最后，Gartner 想要评估对基于 SaaS 用户的 APM 产品的需求。结果(参见图 3 )表明，现阶段 SaaS 的使用仍然很有限，只有 18%