您现在的位置：首页 --> 查看专题： 监控
mysql group replication官方在监控及优化方面文档较少，为了在教学中方便使用，总结一下。
一切从应用服务监控说起 。
小明所在的一家小型互联网创业公司一直将应用运行在阿里云上。该应用采用通用的分布式 Nginx+App 架构为用户提供电商数据统计的 webservice 服务。应用运行至今除偶发各类 Bug，性能问题以外，情况还算良好。
最近，小明的老板给小明布置了一个任务，希望把应用服务监控起来，以提高应用运行质量。
在前端开发工作中，除了项目开发保质保量上线以外，项目的数据监控也应该配套起来，确保线上的正常运转。如上报 pv 监控项目是否正常运转；测速上报反应项目质量；脚本错误监控作为监控中重要一环，当页面发生报错的时候，通过上报错误信息，能及时发现存在问题，修复优化、减少损失。
本文基于在手Q家校群前端脚本错误量优化的方案，致力于打造极致的脚本错误优化。
作为首篇，主要讲解基础的脚本错误监控和上报方式，以及常会遇到的 Script error. 的产生原因和处理方法。
本文写于2015年，所有PAAS平台相关内容都已经在2015Q3完成，当时使用的docker版本为1.6.2，虽然docker新版本发布很快，但是下面提到的监控相关的内容大致相同。
随着基于 NodeJS 前后端分离方案的推行，前端的开发模式和角色也在发生着悄无声息的变化，而今 NodeJS 的开发俨然已经成为我们日常工作中的一部分，前端工程师与服务端、运维都有了更多的交集，但随着业务和项目的扩张，生产环境 Node 服务也在不断增多，如何对这些服务的运行状态和各项指标了如指掌是当前我们大家共同遇到的挑战。
从一个现场说起，全程解析如何定位性能瓶颈。
现在监控软件非常多，nagios，zbbiax什么数不胜数，不过现在最多的还是nagios和zbbiax、cacti监控工具。 下面我们就来说一下，如果使用nagios来监测dell服务器的硬件，这样你就可以像监控服务那样监控服务器的各种硬件状态了！
想打造 New Relic 那样漂亮的实时监控系统我们只需要 InfluxDB/collectd/Grafana 这三个工具，这三个工具的关系是这样的： 采集数据（collectd）-> 存储数据（InfluxDB) -> 显示数据（Grafana）。 InfluxDB 是 Go 语言开发的一个开源分布式时序数据库，非常适合存储指标、事件、分析等数据，看版本号（v0.8.8）就知道这个项目还很年轻； collectd 就不用介绍了吧，C 语言写的一个系统性能采集工具； Grafana 是纯 Javascript 开发的前端工具，用于访问 InfluxDB，自定义报表、显示图表等。
Linux 平台上的性能工具有很多，眼花缭乱，长期的摸索和经验发现最好用的还是那些久经考验的、简单的小工具。系统性能专家 Brendan D. Gregg 在 LinuxCon NA 2014 大会上更新了他那个有名的关于 Linux 性能方面的 talk (Linux Performance Tools) 和幻灯片。
有时候，进程突然终止服务，可能是没有资源了，也可能是意外，比如说：因为 OOM 被杀；或者由于 BUG 导致崩溃；亦或者误操作等等，此时，我们需要重新启动进程。
实际上，Linux 本身的初始化系统能实现简单的功能，无论是老牌的 SysVinit，还是新潮的 Upstart 或者 Systemd 均可，但它们并不适合处理一些复杂的情况，比如说：CPU 占用超过多少就重启；或者同时管理 100 个 PHP 实现的 Worker 进程等等，如果你有类似的需求，那么可以考虑试试 Monit 和 Supervisor，相信会有不一样的感受。
很显然从名字中我们就可以知道vmstat是一个查看虚拟内存（Virtual Memory）使用状况的工具，但是怎样通过vmstat来发现系统中的瓶颈呢？在回答这个问题前，还是让我们回顾一下Linux中关于虚拟内存相关内容。
上线的稳定性不仅仅依托于代码异常的监控，代码异常监控只能监控到你代码的健康性，而很多时候业务的稳定还需要监控一些业务数据，例如昨天有1000个人点击了关注按钮，今天上线后突然变成了300人点击，除非你很清楚你上线的行为是会导致点击数下降，否则我们就应该重新审查这次上线是否存在问题，必要时还应该回退这次上线。
对Android网络抓包分析，一般是使用tcpdump抓个文件，再到PC用Wireshark打开分析。能不能达到直接使用Wireshark的效果？ 答案是可以的，至少已经非常接近了。实现起来很简单，原理就是将tcpdump的数据重定向到网络端口，再通过管道(pipe)转到wireshark就可以了。
最终的目的是了解SQL Server实例的运行，但每个实例是跑在windows上的，所以主机级别的稳定性也是不可或缺的，这篇文章主要围绕这张图的windows主机节点部分来讲。
曾“夸下海口”说听完讲座后七天就可以打造自己的前端性能监控系统，既然说出去了也不能食言。从前一篇文章前端数据之美相信大家对前端数据有了一定的了解，下面就针对其中的性能数据及其监控进行详细阐述。
工作中，发现鄙厂使用的服务器监控系统，非常牛逼，CPU，内存，UDP，TCP，eth包量，各种监控应有尽有，此外，还有自定义上报。不光上报，还能对上报数据做绘图，异常数字报警，能发短信、邮件、RTX消息、微信消息等等，无所不能！于是乎，不禁对此类系统神往之，要是自己也能有一套就好了。于是，我找到了Zabbix。
常用的监控系统常常包含以下缺点：1）中心化数据存储进而导致单点故障。2）有限的存储空间。3）数据会因为时间问题而变得不准确。4）不易于定制图形。5）不能扩展采集数据点到100亿级别。6）不能扩展metrics到K级别。7）不支持秒级别的数据。而开源监控系统OpenTSDB，它可以解决上面的问题，它用hbase存储所有的时序（无须采样）来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集所有metrics，支持永久存储，可以做容量规划，并很容易的接入到现有的报警系统里。OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的metrics并进行存储、索引以及服务，从而使得这些数据更容易让人理解，如web化，图形化等。
近3天十大热文
-
[68] 如何拿下简短的域名 -
[68] Go Reflect 性能
-
[64] Oracle MTS模式下 进程地址与会话信
-
[61] IOS安全–浅谈关于IOS加固的几种方法
-
[61] 图书馆的世界纪录
-
[60] 【社会化设计】自我（self）部分――欢迎区
-
[59] android 开发入门
-
[54] 视觉调整－设计师 vs. 逻辑
-
[49] 读书笔记-壹百度:百度十年千倍的29条法则
-
[47] 界面设计速成
赞助商广告
