使用Zabbix LLD实现进程数监控

目的

  • 针对特定进程数量做监控报警

思路

  1. 通过Zabbix LLD自动发现:每台机器都跑了什么服务、每个服务应该跑多少进程
  2. Zabbix Agent 30s将当前机器跑了哪些服务、每个服务进程数上报Zabbix Server
  3. 开发给定配置文件proccessInfo.txt: IP 服务名称 进程数量,此配置作为监控依据
  4. proccessInfo.txt配置文件需在每次变更配置时,自动生成最新

配置流程

  1. LLD自动发现脚本
  2. 数据采集脚本
  3. Agent添加Key
  4. Zabbix Server添加模板组
  5. 创建自动发现规则(监控项、报警触发器)
  6. 添加当前进程数监控项(通过Zabbix Trapper方式,由Agent端)
  7. 定义报警内容

具体步骤

LLD自动发现脚本

Agent添加Key

创建自动发现规则(监控项Trapper方式、报警触发器)

添加当前进程数监控项

定义报警内容

Action中定义(此处略)

将定义好的模板链接到主机或者其他模板即可

最后

使用Zabbix LLD之后,可以设定多久更新一次监控项及监控阀值;当配置文件变更时,无需人为调整阀值和监控项

架构学习之路-高可用高并发系统设计原则

本系列博客主要是学习开涛《亿级流量网站架构核心技术》一书学习笔记及自己的感悟:

架构设计三大定律

墨菲定律
– 任何事没有表面看起来那么简单
– 所有的事都会比预计的时间长
– 可能出错的事情总会出错
– 担心某种事情发生,那么它就更有可能发生

康威定律

  • 系统架构师公司组织架构的反映
  • 按照业务闭环进行系统拆分/组织架构划分,实现闭环、高内聚、低耦合,减少沟通成本
  • 如果沟通出现问题,应该考虑进行系统和组织架构的调整
  • 适合时机进行系统拆分,不要一开始就吧系统、服务拆分拆的非常细,虽然闭环,但是每个人维护的系统多,维护成本高
  • 微服务架构的理论基础 – 康威定律 https://yq.aliyun.com/articles/8611
  • 每个架构师都应该研究下康威定律 http://36kr.com/p/5042735.html

二八定律

  • 80%的结果取决于20%的原因

系统设计遵循的原则

1. 高并发原则

无状态

  • 无状态应用,便于水平扩展
  • 有状态配置可通过配置中心实现无状态
  • 实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等

拆分

  • 系统维度:按照系统功能、业务拆分,如购物车,结算,订单等
  • 功能维度:对系统功能在做细粒度拆分
  • 读写维度:根据读写比例特征拆分;读多,可考虑多级缓存;写多,可考虑分库分表
  • AOP维度: 根据访问特征,按照AOP进行拆分,比如商品详情页可分为CDN、页面渲染系统,CDN就是一个AOP系统
  • 模块维度:对整体代码结构划分Web、Service、DAO

服务化

  • 服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
  • 考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
  • 实践:利用Nginx、HaProxy、LVS等实现负载均衡,ZooKeeper、Consul等实现自动注册和发现服

消息队列

  • 目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等
  • 大流量缓冲: 牺牲强一致性,保证最终一致性(案例:库存扣减,现在Redis中做扣减,记录扣减日志,通过后台进程将扣减日志应用到DB)
  • 数据校对: 解决异步消息机制下消息丢失问题

数据异构

  • 数据异构: 通过消息队列机制接收数据变更,原子化存储
  • 数据闭环: 屏蔽多从数据来源,将数据异构存储,形成闭环

缓存银弹

  • 用户层:
    • DNS缓存
    • 浏览器DNS缓存
    • 操作系统DNS缓存
    • 本地DNS服务商缓存
    • DNS服务器缓存
    • 客户端缓存
    • 浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)
    • App客户缓存(js/css/image…)
  • 代理层:
    • CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)
  • 接入层:
    • Nginx为例:
      • Proxy_cache: 代理缓存,可以存储到/dev/shm或者SSD
      • FastCGI Cache
      • Nginx+Lua+Redis: 业务数据缓存
    • PHP为例:
      • Opcache: 缓存PHP的Opcodes
  • 应用层:
    • 页面静态化
    • 业务数据缓存(Redis/Memcached/本地文件等)
    • 消息队列
  • 数据层:
    • NoSQL: Redis、Memcache、SSDB等
    • MySQL: Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
  • 系统层:
    • CPU : L1/L2/L3 Cache/NUMA
    • 内存
    • 磁盘:磁盘本身缓存、dirty_ratio/dirty_background_ratio、阵列卡本身缓存

并发化

2. 高可用原则

降级

  • 降级开关集中化管理:将开关配置信息推送到各个应用
  • 可降级的多级读服务:如服务调用降级为只读本地缓存
  • 开关前置化:如Nginx+lua(OpenResty)配置降级策略,引流流量;可基于此做灰度策略
  • 业务降级:高并发下,保证核心功能,次要功能可由同步改为异步策略或屏蔽功能

限流

  • 目的: 防止恶意请求攻击或超出系统峰值
  • 实践:
    • 恶意请求流量只访问到Cache
    • 穿透后端应用的流量使用Nginx的limit处理
    • 恶意IP使用Nginx Deny策略或者iptables拒绝

切流量

  • 目的:屏蔽故障机器
  • 实践:
    • DNS: 更改域名解析入口,如DNSPOD可以添加备用IP,正常IP故障时,会自主切换到备用地址;生效实践较慢
    • HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度
    • LVS/HaProxy/Nginx: 摘除故障节点

可回滚

  • 发布版本失败时可随时快速回退到上一个稳定版本
3. 业务设计原则
  • 防重设计
  • 幂等设计
  • 流程定义
  • 状态与状态机
  • 后台系统操作可反馈
  • 后台系统审批化
  • 文档注释
  • 备份
4. 总结

先行规划和设计时有必要的,要对现有问题有方案,对未来有预案;欠下的技术债,迟早都是要还的。