监控

生产环境最佳实践 1.linux 系统： 1】关闭文件系统/分区的atime 选项 Vi /etc/fstab 在对应的分区项后面添加noatime ,nodiratime LABEL=/1 / ext3 defaults 1 1 LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2 2】设置文件句柄4k+，目前该配置已经集成到启动脚本中。 Vi /etc/security/limit.conf * soft nproc 65536 * hard nproc 65536 * soft nofile 65536 * hard nofile 65536 3】不要使用large vm page （不要使用大内存页选项） Linux 大内存页参考：http://linuxgazette.net/155/krishnakumar.html 4】用dmesg 查看主机的信息。 2.linux 文件系统的选择： Mongodb 采用预分配的大文件来存储数据,我们推荐 1】ext4 2】xfs 3.内核版本： 网络上对2.6.33-31 以及2.6.32 的表现持怀疑度， 而强力推荐2.6.36 4.线程堆栈的尺寸 默认的线程堆栈尺寸为10m ，调整为1m ，已经集成在启动脚本中。 项目过程中的总结与建议 1.大小写问题 mongodb

本文主要完成如下一个任务： 对一个已有的Web应用工程，添加 JavaMelody 工具，从而去监控和查看Web应用的运行情况，比如： Http请求的执行时间 、 SQL语句的执行时间 、 PDF报表的生成 。 JavaMelody 简介 从Java Melody的 WIKI 页面上可以看到： The goal of JavaMelody is to monitor Java or Java EE applications in QA and production environments. It is not a tool to simulate requests from users, it is a tool to measure and calculate statistics on real operation of an application depending on the usage of the application by users. JavaMelody的目标是监控QA环境或者生产环境Java或者Java EE应用。 JavaMelody 不是一个模拟用户请求的工具；它是一个用于对应用上的真实操作进行衡量和和计算统计的工具，这些真实的操作取决于用户在应用上的使用情况。 JavaMelody 能够监测Java或Java EE应用程序服务器，并以图表的方式显示

常用优化要点 nginx使用的是固定数量的workers, 每个worker都处理进入的请求。最佳实践是每个CPU内核配置一个worker. 如何知道您的系统有几个CPU？ $ grep ^processor /proc/cpuinfo | wc -l 对于一个四核处理器，配置文件类似： # One worker per CPU-core. worker_processes 4; 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; # Your content here .. } 这里我们提高了 worker_connections 设置，定义了每个worker进程能处理多少连接。 服务器的最大连接数量是： worker_processes * worker_connections (= 32384 本例中) 这里启用了 multi_accept，该配置项使 nginx能尽快接收尽可能多的请求，减少客户端的连接初始化时间。 最后，本例中使用了 epoll 的事件模型，这也是最佳实践建议。 压缩 很多用户会启用

OneAPM 作为应用性能领域的新兴领军企业，近期发布了重量级新产品—— Cloud Insight 数据管理平台，用它能够监控所有基础组件，并通过 tag 标签对数据进行管理。 近日，Cloud Insight (Ci) 探针仪表盘功能重磅上线，默认安装了探针，配置平台服务就会自动生成相应的仪表盘，而且仪表盘将包含所有数据。此外，本文也将重点介绍 Redis 的几项监控指标以及一些值得注意的部分，希望给使用 Redis 的读者带来一些帮助。 仪表盘 任意时间段数据查询 默认只能显示最近一小时的数据，而现在在仪表盘上可以选取固定时间段查看数据，7天内，15天之内，还可以自定义具体时间段，当然默认显示的是30分钟内的数据。 数据筛选 随着现在业务的复杂，一个应用肯定会在多台服务器上部署，那就需要同时监控多台服务器，那如果只需要看某一台服务器的某项指标，仪表盘就派上用场啦！通常仪表盘数据是多个服务器数据的集合，如果想看单个服务器数据，可以根据主机名进行筛选。此外，里面还有多条筛选条件，例如 device url tag 等， Docker 可以选择 image 等。稍后我们会上线自定义仪表盘，通过 tag 标签轻松实现对数据的聚合、过滤、检索。 监控 Redis 指标 Cloud Insight 将监控 Redis 的以下指标 1 aof.last_rewrite_time

OneAlert 是北京 蓝海讯通 科技有限公司旗下产品，中国首个 SaaS 模式的云告警平台，可集成 Zabbix ， Nagios ， Solarwinds ，AWS CloudWatch ， 阿里云 ，监控宝，腾讯云等国内外主流监控/支撑系统，实现一个平台上集中处理所有IT事件，提升IT可靠性，极大提高团队的协作能力、优化协作流程。 去年 OneAlert 结合真实用户的需求和国内外前沿经验，程序员们日夜兼程对平台做了一次又一次的优化，增加了许多用户真实需要的功能。本篇将详解 OneAlert 周报，让运维工程师们在向上级汇报工作时有更多直观的数据可以说！ ####周报内容： ######1. 统计时间 告警统计时间一般为上周开始 00:00:00，到上周末 23:59:59。 ######2. 告警汇总 ######3. 配额汇总 ######4. Top统计：告警内容 ######5. Top统计：告警对象 国内 ITOM 管理平台 OneAPM 致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，通过一个探针就能够完成日志分析、安全防护、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多优秀文章，请访问 OneAPM 官方技术博客 本文转自 OneAPM 官方博客 来源： oschina 链接： https://my.oschina.net/u

背景 随着互联网的发展，各种网络攻击手段也层出不穷，不管是大型企业还是中小企业，随时都有被攻击的危险，因此很多公司都会采取各种手段来维护自己服务器安全，其中比较常见的是采用内网环境，只设置一台代理服务器，其他服务器都走代理，这样即使遭受攻击对内网环境的服务器影响还是很小的。那这种情况下怎么监控服务器，数据库的性能，有人说有开源软件啊，例如 zabbix nagios 等，但别忘了，使用这2种 监控软件从配置监控开始，到后期一天天的维护，这可是都需要专人来看管的。 那么问题来了，内网环境的 数据库监控 有没有简单，安全，直观的解决方法？ 答案是肯定的，本文就针对内网环境如何部署 Cloud Insight 监控，并且直观展示服务器数据库的各项指标，那话不多说，开始操作，本文对2种代理方式分别进行配置。 环境变量里面设置 http_proxy 如果你服务器的环境变量里面设置了 http_proxy，那可以直接修改探针的配置文件，首先单独下载探针包，在本地进行安装，探针包里包含 Python 所需要的环境变量： CentOS 环境 wget http://yum.oneapm.com/x86_64/oneapm-ci-agent-4.2.0-1.x86_64.rpm rpm -Uvh oneapm-ci-agent-4.2.0-1.x86_64.rpm Ubuntu 环境 wget

现在 SaaS 的发展势头已经无法抵挡，只要持有企业信用卡，任何人都可以顺利部署 SaaS 工具，并借助 API，在短短几分钟内连接其他重要应用。并且开发者掌握了许多自动化快捷处理方式——比如说 Application Insight 应用部署和 Mobile Insight 移动应用测试——这极大地节省了推出新应用程序的时间。然而，很多管理应用程序和基础设施的旧方法以及无法跟上 SaaS 发展的步伐。 因此，企业转而采用各种专业监管工具——比如 Nagios 、 Zabbix 、 Solarwinds 和 AWS CloudWatch —— 旨在获取对堆栈不同层次的深刻认识。遗憾的是，这些工具难以实现交互的工作方式。各种监管工具的告警便层出不穷，数量之大，几乎让你分不清信号和噪音。 ##### 如何在噪音中准确寻获信号？ 对于运维团队来说，只是单纯的获取告警其实是远远不够的，因为我们得到了太多的告警。事实上，源源不断的告警只会培养运维团队无视告警的能力（无法否认这是事实！）。当噪音很大时，你容易将不常见的信号也当成噪音。这可不是好事。 因此，运维团队需要智能的整体解决方案和可操作数据的解决方案，这样不仅能自动处理超出人工可处理范围的任务，还能在收到可操作告警后知道该如何处理。 为实现以上功能，结合告警平台的已上线的功能，以国外的 BigPanda 和国内的 OneAlert 为例

插播一条近期新闻：云应用数据监控创企 Datadog 获 9450 万美元融资。 1月13日，云应用数据监控创企 Datadog 宣布获得9450万美元融资，本轮融资由 Iconic Capital 领投，Amplify Partners、Contour Ventures、Index Ventures 和 OpenView Venture Partners 参投。 ##云服务吞噬世界 我们可以发现一个现象，以国外的 Datadog 为例，云监控市场正在崛起，15 年开始尤为明显。 而这一切都是由于，一场云革命正在影响科技领域。通过惠普和 IBM 这种公司的运营策略也可以清楚的发现这一点。确实，传统的技术提供商正在拥抱云计算。他们将业务从建立和运行内部部署的基础设施，转变为提供基于云的服务。 前两年我们说，Software is eating the world——软件正在蚕食世界，现在我们可以说，Cloud service is eating the world——云服务正在吞噬世界。在云服务日益成熟，企业纷纷拥抱云计算的同时，另一股力量也在悄悄壮大。在互联网快速发展的同时，我们不仅要跑得快，还要跑的稳，国内外不少企业开始使用云服务监控，越是大型互联网企业，用的越早，比如 Facebook，比如 Netflix。 Facebook 用了 Datadog 来做运维监控，Netflix

项目首页：https://github.com/alibaba/TProfiler 工具介绍 TProfiler是一个可以在生产环境长期使用的性能分析工具.它同时支持剖析和采样两种方式,记录方法执行的时间和次数,生成方法热点 对象创建热点 线程状态分析等数据,为查找系统性能瓶颈提供数据支持. TProfiler在JVM启动时把时间采集程序注入到字节码中,整个过程无需修改应用源码.运行时会把数据写到日志文件,一般情况下每小时输出的日志小于50M. 业界同类开源产品都不是针对大型Web应用设计的,对性能消耗较大不能长期使用,TProfiler解决了这个问题.目前TProfiler已应用于淘宝的核心Java前端系统. 部署后低峰期对应用响应时间影响20% 高峰期对吞吐量大约有30%的降低(高峰期可以远程关闭此工具) 同类对比 与同类开源工具jip对比 项目 TProfiler JIP 交互控制 支持远程开关和状态查看 支持远程开关等多种操作 过滤包和类名 支持包和类的过滤 支持包和类的过滤 低消耗 响应时间延长20% QPS降低30%(详细对比看上图) 同等条件下资源消耗较多,使JVM不断的FullGC;Profile时会阻塞其他线程 无本地代码 未使用JVMTI,纯Java开发 未使用JVMTI,纯Java开发 易用性 只有一个jar包,使用简单 模块多,配置使用相对复杂 日志文件

前不久，我们讨论了运维不容错过的 4个关键指标 ，其中平均解决时间（MTTR）被认为是衡量业务的最佳标准，随后也分析了「 告警等级 」对MTTR的重要性。 ###正确看待 MTTR MTTR 为从故障发生到故障修复所经历的时间。总故障时间是关于告警事件数量与各告警事件时长的函数。经过仔细地探讨这两项因素及其优先级，结合具体情况，总结以下策略用来缩短MTTR： #### 1）加快工作速度 = 然并卵 如果想通过加快工作速度降低 MTTR，理论上是完美的，但是骨感的现实根本不按我们的剧本走！为了对 MTTR 进行持续的、可衡量的改进，应该对故障事件进行深入的调查，分析事件的复杂程度及重要程度，然后从人与系统的协作上，实现对流程进行优化。 #### 2）检验告警响应时间 一旦事件发生，「MTTR」时钟便开始计时。通过调整通知流程，或许就能速战速决。下图为常见故障处理过程： 还不够直观？数据来说话。 OneAlert 一个月的告警数据显示：平均响应时间为 2.8 分钟；平均解决时间为 27 分钟。（不要问我为什么你们的响应时间要好几个小时！） 如果你的响应时间较长，建议检查一下团队值班响应机制，告警是否可有效传达给了正确的人？如果一线排版人员无响应，告警能否自动升级？升级时间阈值是多少？通过设定接近平均响应时间的适当期望值和目标，能确保所有成员尽快对告警作出响应。 #### 3