监控

开发自己的监控系统一、email篇 开发自己的监控系统二、web篇 移动篇（android） 关键字：java、android、json、php 互联网已经进入大数据时代，如果没有给自己的产品开发手机端的应用程序，出门都不好意思跟别人打招呼了~~ 为了随时随地掌握服务器的运行状态，当然，也为了装ability，下面就来为我们的监控系统开发一个手机端（android）的应用。 原理： 首先编写一个web接口，读取数据库服务器数据，返回json对象数组。android应用程序解析json数据，通过listvie控件显示。 以下是web接口，php编写，pdo方式连接数据库，使用json_encode将字符串转换为json对象格式，代码如下： <?php $dbms='mysql'; //数据库类型 oracle 用ODI,对于开发者来说，使用不同的数据库，只要改这个，不用记住那么多的函数了 $host='localhost'; //数据库主机名 $dbName='monitor'; //使用的数据库 $user='user1'; //数据库连接用户名 $pass='Root123'; //对应的密码 $dsn="$dbms:host=$host;dbname=$dbName"; try { $dbh=new PDO($dsn,$user,$pass);//初始化一个PDO对象

前言： 随着维护服务器量的增多，越来越觉得监控的重要性。监控，就是运维人员的眼睛，没有了监控，你不知道磁盘是否满了，网络流量是否超标，甚至服务器是否宕机。监控的重要性不言而喻。市面上的监控软件也很多，如商业版的ipmontor、opmanager，免费开源的nagios、cacti等。每个监控软件都有各自优缺点和应用场景，这里不去探讨。本文要探讨的是从一个初学者的角度去打造属于自己的监控系统。共分为三部分： email篇 、 web篇 和 移动篇（android） 。好了，不废话了，下面开始。 email篇： 关键字：shell、email 原理： 定时执行监控脚本，提取服务器运行状态，如系统负载、磁盘空间或是相关服务是否运行等，只要有一项异常，即马上发送邮件警报。下面是脚本内容（由于只是个事例，所以只设定了两个监控项目，大家根据自己的需求增减监控项目）。 #!/bin/bash #Server status monitor #by caishzh 2013 #初始化变量及设置阀值 DIR="/root/tool" NOW=$(date "+%F %T") >${DIR}/messages.txt #先清空messages.txt里的内容 ADMIN="xxx@qq.com" #邮箱地址，用于接收警报邮件 HOSTNAME="Server1" IP=$(ifconfig eth0

运维，哎，多么沉重的话题，初创公司的运维，哎，还能愉快的聊天吗？ 初创公司的运维，如今其实兼技术支持、系统管理员（SA）、网管、网络工程师、研发工程师、架构师，干着这些看似不相干甚至矛盾的工作。 他们的具体工作？ 在办公室中安装系统、帮同事排除机器故障 在机房插网线、搬机器、拆服务器箱子 天天盯着N个监控屏幕、8小时一动不动盯着流量图 在 BOSS、开发工程师、网络/系统工程师、DBA 中间跑来跑去进行沟通 在夜半三更收到服务器监控系统的警报，起床赶到机房，节假日陪女朋友收到报警也得赶到机房（当然更多的是没女朋友） 。。。。。。初创公司有那种整天斗地主，麻将下棋的吗？（还缺人吗，会打麻将的那种） 上面这些是有一定规模的公司运维的工作，当然初创公司同样的工作也是要运维来做的，而且不乏一人当多人用，即使是这样，当出现下面这些问题或需求时，怎么淡定呢？ 系统升级，如升级成 centos7 换成了 systemd，不少运维脚本都得重写 业务上加了中间件，需要迅速监控上 研发，运营，QA，产品经理都找你要业务数据，用户数据，测试数据等 监控的数据要高度可视化，BOSS 一眼也能看懂 业务层面的数据也需要一同监控，运营需要的用户信息也想可视化。。。。 于是找个大的 Zabbix／Nagios 框架，不停的写脚本，进行后期维护，图表不好看，那再接上 Graphite，这些如果熟悉还好

郑昀 基于李丹和刘奎的文档 创建于2014/12/5 关键词： 监控 、dashboard、PHP、graphite、statsd、whisper、carbon、grafana、influxdb、Python 本文档适用人员：研发和运维员工 提纲： 监控平台要做到什么程度？为什么要自己做？ 几个通用技术问题 绘图所依赖的数据如何收集？如何加工？如何存储？ 图形如何绘制，各种指标如何叠加？ 拓扑关系如何绘制？ 技术选型哲学 最终选了statsd+graphite 数据的采集 数据存储的粒度 天机的技术选型 一，监控平台要做到什么程度？为什么要自己做？ 运维监控满满都是着各种开源系统以及它们的 Dashboard： Zabbix Nagios Centreon Logstash Ganglia+Cacti 以及各种业务指标趋势的 Dashboard。 我们认为，监控不能只是各种数据的采集和罗列，不仅仅是弄若干个报表并进一步配置成仪表盘， 而是有一定智能，仿照我们日常的排查问题思路，建立一定规则，自动检查，深度检查，友情提示 。 随手举一个例子： 规则：模仿我们发现问题后先检查数据库主从同步是否有问题的习惯 天机系统发现成单金额或验证券数或短信发送条数环比大幅下降后，启动检查规则， 自动逐一检查各种从库的主从同步情况。 如果发现主从延迟超过阈值，则天机 DashBoard

过去的一年中，关于 Docker 的话题从未断过，而如今，从尝试 Docker 到最终决定使用 Docker 的转化率依然在逐步升高，关于 Docker 的讨论更是有增无减。另一方面，大家的注意力也渐渐从 “Docker 是什么”转移到“实践 Docker”与“监控 Docker”上。 本文转自刘斌博文 「如何选择 Docker 监控方案 」 ，文中刘斌从技术的角度深入解释了 Docker 监控 的数据采集原理，介绍了现有开源的监控方案，以及能够对 Docker 进行监控功能的主流 SaaS 服务工具。 上一篇文章中介绍了 Docker 监控目的及技术基础，本篇文章将介绍，Docker 监控方案的实现。 Docker 监控方案的实现 自己动手 + 开源软件 SaaS 评价标准 功能 信息详细程度 查询的灵活程度 报警 + API 灵活性 定制 成本 学习、开发 维护 运维 部署复杂程度 高可用 需要考虑的基本要素如上所示，不多述。 自己动手 灵活性强 成本高 这里的成本包括开发成本，开发成本可能包括招人和培训，开发时间和填坑时间。开发完了还需要维护成本，而且随着Docker的升级，可能还需要对metric的采集实现进行升级，以及各种bugfix。 自己动手打造监控方案 采集 存储 展示 报警（动作） StatsD 是 Flickr 公司首先提出来的，后来由 Esty

一个关于Kafka的监控测试框架 原文请查阅 链接 。 Apache Kafka 已经成为了一个面向大规模流数据的，标准的消息系统。在Linkedin这样的公司， 它被用作各类数据管道的主力，支持一系列关键服务。它已经成为确保企业基础架构健壮、容错和高性能的核心组件。 在过去， Kafka 网站高可用工程师 （SRE）必须依赖Kafka服务器的报告来度量、监控一个Kafka集群 （例如，访问流量，离线分区计数，under-replicated分区计数，等等）。如果任何一个指标不可用，或者任何指标的值是异常的， 都有可能是某些方面出错了，SRE则 需要介入问题排查。然而，从一个Kafka集群获得这些指标并不像听起来那么容易—无论集群是否可用， 一个很低的流入流出值并不没有必要告诉我们，也不能为最终用户提供一个基于可用性经验的、细粒度的参考结果 （比如说，在这个事件中描述道：只是一个分区的子集异常了）。随着我们的集群增长得愈加庞大，为越来越多的重要业务提供服务， 可靠、精确地度量Kafka集群可用性的能力，也就变得越来越重要。 为了监控可用性，有必要主干的稳定性，从功能上或性能方面尽可能早的捕获可回溯的信息。 Apache Kafka 在虚拟机中包含一系列单元测试和系统测试方法，用于检测错误。 到目前为止，我们仍然能发现一些偶发错误

当我们在javaWEB项目中使用到druid来作为我们的连接池的时候，一定不会忘了添加监控功能。下面我们就来看一下，在一个简单的web项目中(尚未使用任何框架)我们是如果来配置我们的web.xml来完成我们的监控配置 首先是过滤器filter的配置,在web.xml中添加如下配置 <filter> <filter-name>DruidWebStatFilter</filter-name> <filter-class>com.alibaba.druid.support.http.WebStatFilter</filter-class> <init-param> <param-name>exclusions</param-name> <param-value>*.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*</param-value> </init-param> </filter> <filter-mapping> <filter-name>DruidWebStatFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> 过滤器中的配置，是用来定义我们的监控选项，在以上的监控配置中，我们定义了一个简单的监控，并采用了大量的默认配置，如果你想使用更丰富的监控配置

开发自己的监控系统一、email篇 开发自己的监控系统三、移动篇（android） web篇： 关键字：shell mysql python web.py 在上一篇中，我们介绍了如何使用shell脚本监控系统状态，并在出现异常时通过email发送警报。但email报警有一个弊端，无法实时了解服务器的运行状态。为了满足这一需求，就要开发一个web程序，通过网页的方式来显示所有服务器的实时运行状态。 原理： 定时执行监控脚本提取服务器运行相关信息，如系统负载、磁盘空间等，将这些信息入到mysql数据库中。开发一个web程序，当用户通过浏览器访问web监控页面，web程序读取mysql数据库中服务器的数据，以网页的形式展现给用户。 下面我们通过一个实例来详细讲解。共用到3台服务器，一台监控服务器serverM（60.11.232.17），用于存放我们web程序和mysql数据库，还有两台被监控服务器，server1（199.83.55.39）和server2（59.66.7.124）. 首先在监控服务器serverM上创建一个数据库monitor： mysql -p create database monitor 在monitor数据库中创建一个servers表，用于存放监控数据： use monitor create table servers ( id int not null

##Druid 简介与用途 首先说明，这里所说的 Druid 并不是阿里巴巴的数据库连接池项目，而是 Eric Tschetter 创立的一个开源的分布式实时处理系统，希望为烧钱的大数据处理，提供一种更廉价的选择。为了解决查询延迟问题，使用 Hadoop 来实现交互式查询分析很难满足实时分析的需要。而 Druid 提供了以交互方式访问数据的能力，并权衡了查询的灵活性而采取了特殊的存储格式。 作为一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，Druid 能够快速处理大规模的数据，并实现快速查询和分析。即使发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid 仍能够保持 100% 正常运行。 目前 Druid 应用最多场景是广告分析，包括互联网广告系统监控、度量和网络监控。并且 eBay 也已经计划将 Druid 用于生产环境中。 而时刻关注新技术的 OneAPM 也试图对 Druid 的指标进行展示。 ##使用 Cloud Insight SDK 监控 Druid Cloud Insight 根据 StatsD 进行了修改，形成了 Cloud Insight SDK，可以方便用户上传自定义指标至 Cloud Insight，目前支持的数据类型有，Counters 和 Gauges, 语言仅支持 Python。 使用 SDK 前先确保自己安装了 Cloud

如果说 15 年你还没有将 DevOps 真正应用起来，16 年再不实践也未免太落伍了。在上篇文章中我们了解到 15 年十佳 DevOps 博客文章的第 6-10 名，有没有哪一篇抓住了您的眼球，让您有所收获呢？接下来让我们来看一看排名前五的文章，究竟是不是妙笔生花，鞭辟入里！ 本文是「 年度十佳 DevOps 博客文章（前篇） 」的后半部分，译自 Hasan Yasar 的文章 the Top 10 Devops Posts of 2015 . 2015 年 8 月， DevOps 博客 推出了自己的平台。DevOps 博客针对越来越多采用 DevOps 的企业（自 2011 年来占比高达 26%），提供各种指南、实用建议和教程。根据 近期研究 ，这些企业变更代码的速度比传统企业快 30 倍。尽管 DevOps 的优势显而易见，很多企业仍然不敢欣然采用，因为这不仅需要转变观念，还要改变文化和技术要求，后者对孤立的竖井式企业而言，是极大的挑战。考虑到这些障碍，CERT 研究人员的文章主要集中介绍 Amazon 和 Netflix 的 DevOps 成功案例，以及 Fabric 、 Ansible 和 Docker 等流行 DevOps 技术的教程。本文则介绍了 2015 年 10 篇最受欢迎的 DevOps 文章中的第 1-5 名（倒序）。 5.DevOps 案例分析