早上起床后，悠然自得地在阳台上晒着太阳看着柴静的《看见》这本书。突然楼上吵架吵的甚是厉害，这已经不是第一次听到楼上吵架了，每次都是伴随着咕咕嘟嘟的物品跌落到地板上声音、妇女歇斯底里的呼喊声、小孩声嘶力竭的哇哇哭闹声、间歇性的愤怒的男性咆哮声。

这一次吵闹的比之前几次都要凶，我感觉不太对劲，打开门，走上楼梯，准备去帮他们和解一下，心想：毕竟是一家人，没必要闹到这个份上。当我走到楼上时，女主站在门外，朝着门内哭喊道“你为什么打我，我出来没有打过你，你为什么打我”，他们的门没关，我看到他们玄关的台面上堆满了书籍，放不下的书籍已经被实实在在的塞在了竖立起来的书层上面，想必也是一定程度上的知识分子，我刚准备去拦架，就听到女主对着门外吼道：“我是在受不了你了，你给我走”，听到这些，我的脚步迈不开了，感觉自己想好的劝解的话不一定能凑效，反而可能让他们觉得不堪的场面，此刻他们需要的是冷静，然后控制住自己的情绪。

我重新回到阳台，继续翻看书籍《看见》，正好看到讲述十几位女性因为无法忍受自己的丈夫而杀害丈夫的故事，调查中的大部分女性都是在无数次沉默忍耐之后才爆发了最后的还击。我从小也经历过父亲喝醉酒，发了疯似的，拿着砍刀要杀人，当时母亲哭泣着抱着我躲在房间的角落里，我至今还清晰的记得那门框旁边残留的被刀砍下的凹痕；母亲的性格是那种凡事都隐忍，不主动把事情摊开来说的那种，我之前还嘲笑母亲懦弱的性格，后来我才明白这是“恐惧留下的阴影”，一个没有当过弱者的人，不会体会到这种恐惧。那些女犯人之所以环击，正是因为恐惧的一层层积累，积累到一定程度后，就会以暴力的方式爆发。

“叮咚，叮咚”，一阵门铃响声打断了我的思绪，我打开门，看到是天猫超市的配送员，他说打我手机没人接，担心我家的东西又丢了，现在都不敢放门口了，听到楼上的吵闹神，他说：“我也是离过婚的人，一个人来到异地杭州，无依无靠”。我不知道该说回答他，脑子中对婚姻这件事有了缕缕疑惑。

楼上的声音渐渐消停了下来，我也看到这篇报道的结尾了，结尾处柴静写到“他人经受的，我必经受”。在最近的几年里，我愈发的明白一个道理，那就是：不要随意地站在自我的立场上使用自己那有限的人生经历去揣测与评判别人的人生，我们不曾经历过的一切都让我们的评论显得格外肤浅。

此时，老婆问我，“我们如果吵架了，你会怎么样？”，我笑了笑。

从事软件编程已经长达8年之后，曾经中间有很长一段时间感觉自己的技术能力没有得到根本性提升，与那些优秀的同龄人相比，技术自卑油然而生，面对日新月息的技术变更和时不我待的岁月流逝，步入中年的我不得不变的焦虑起来。回顾自己的编程生涯，刚毕业的头几年，通过自主学习实现了编程语言的基本掌握，紧接着使用学到的技术完成各种项目，然后日复一日，有时候也会看看技术书籍，但是终究未能突破语言层而知晓技术背后的本质。而后通过长时间的摸索与交流，寻找到了一些解决技术人技术焦虑的方法，这些问题和方法更多的是一种思维方式，一种看问题的视角，希望这些建议能够让我们有所收获和思考。

技术焦虑的起因

技术热情变低

有人说：职业倦怠是做了大量重复劳动缺乏调整，或者努力完成高风险问题最后却以失败告终而导致的。在软件行业，接触了很多人，发现一开始大家对技术都非常热情，当把它编程职业后，时间一长，就索然无味了，但是又不得不从事这个行业，毕竟还要养家糊口。缺乏热情，可能是我们进入了瓶颈期，在大量重复劳动当中，自然提不起什么兴趣。我们可以有两种方法破局：1. 主要要求承担自己感兴趣又没做过的事情。阿里有一句老话，“今天最好的表现是明天最低的要求”，我们要时刻突破自己所在的“舒适区”，让自己跳跃到“学习区”。2. 为自己而工作。为别人工作就很容易消耗的我们的热情，如果我们转变思路，把学习工作转变为为自己工作，就会有所动力。我过观察到的是，那些在专业领域上付出了极大热情的人，往往因为这个工作领域的投入而成就了自己的影响力，难道这不是在为自己工作，为自己打造信用背书，为自己打造个人品牌吗。 more >>

Mybatis的本质：混合型Java对象持久化工具；

前置说明：

需要提前具备SQL、JDBC、RDBMS、XML、OOP等知识；

什么是Mybatis：

核心点：

• 支持了SQL、存储过程、对象/关系映射的持久化框架；
• 消除了几乎所有的JDBC代码和需要手工处理的参数和结果；
• 支持XML和注解两种方式来配置sqlmap、mapper、pojo三者之间的关系。

Mybatis理念：坚信SQL、RDBMS将继续使用30年；： more >>

通常的POJO对象setter方法return 为void

1
2
3

public void setStatus(String status) {
    this.status = status;
}

但是面对对象属性填充时，一堆的set方法让代码看起来很臃肿，部分同学采用类build模式，对setter方法进行改造，改造后就可以使用链式处理简化属性设置；

1
2
3
4

public Employee setName(String name) {
    this.name = name;
    return this;
}

流式编码风格如：

1

new Employee().setName("Xin yuan").setHeight(178);

有人认为这让pojo方法设置变得更加便捷，有其使用之处，但是也有人认为return this打破了Java Bean的规约，破坏了每个函数单一职责的原则，也可能会破坏一些工具库的使用，或组织JVM做一些优化。而且在IDE中getter&setter的自动生成内容中并没有“return this”。综其所述，setter方法“return this”并不建议。

当然还有其它选择方案：

方法一：

采用java内置语法：

1
2
3
4
5
6

new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

方法二：

采用更加复杂的内部类builder模式：

1
2
3
4
5
6
7
8
9
10
11
12

public Employee setName(String name) {
    this.name = name;
    return this;
}

public static class Builder {
    private String name;
      public Builder name(Strig name) {
        this.name = name;
        return this;
    }
}

造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。但是一般POJO 类都比较简单，非复杂对象，所以采用builder模式并不会让代码变得简洁，反而会显得更加臃肿。

方法三：

属性新增withXxx方法：

1
2
3
4
5
6
7
8
9
10
11
12

public Employee setName(String name) {
    this.name = name;
    return this;
}

public Employee withName(String name) {
    setName(name);
    return this;
}
//使用方式
new Employee().withName("Xin yuan").withHeight(178);

结论：

不建议在POJO： Java Bean的setter方法中添加‘return this’，我们遵循Java规范，如果期望简化Java Bean的属性设置，可以采用with或build方法。

参考：

https://en.wikipedia.org/wiki/Plain_old_Java_object

https://stackoverflow.com/questions/1345001/is-it-bad-practice-to-make-a-setter-return-this

定义：AWS Application Discovery Service 收集并呈现数据，以使企业客户能了解其本地环境中服务器的配置、使用和行为。

工作模式：

无代理自动发现

原理：基于 VMware vCenter Server 的环境的数据上报；

弊端：

• 采用VMware 方式在国内并不常用；
• 采集到的数据有限，只是系统层面的静态数据与CPU、MEM的指标数据；

基于代理(Agent)的发现模式：

通过Agent可以采集更加丰富的数据集合，比如系统进程，系统间的网络连接；这里重点了解Agent模式。

采集的数据：

• 静态配置数据：
  • 系统标识信息：主机名、IP地址、MAC地址、操作系统名称、操作系统版本号，cpuType；
  • 运行中的进程数据；
  • 系统间的网络调用（TCP/IP v4 和 v6）；
    • sourceIP、sourceProcess、destinationIp、destinationPort、dstProcess，ipVersion；
• 性能指标数据：
  • 操作系统层面：
    • 参考之前的OS监控采集项；
  • 进程层面：
    • %CPU
    • %MEM
    • %DISK
  • 网络层面：
    • 待补充

数据安全性：

采用SSL协议进行数据传输；
数据存储采用AWS KMS静态加密；

Agent模式下的自动发现

Agent启动时，自动注册到Arsenal中，并频繁对该服务执行 ping 操作以获取配置信息。

数据收集

数据的收集需要自动显示开启；

数据采集状态：

• STARTED – 收集工具已开始收集和发送数据到 Discovery Service。
• START_SCHEDULED – 已计划数据收集开始时间。下次收集工具联系 AWS 时，它将开始将数据发送到 Discovery Service，并且收集状态将更改为 STARTED。
• STOPPED – 收集工具已停止发送数据到 Discovery Service。
• STOP_SCHEDULED – 已计划数据收集停止时间。下次收集工具联系 AWS 时，它将停止向 DiscoveryService 发送数据，并且收集状态将更改为 STOPPED。

组件分类

DiscoveryService识别组件后，通过TAG标签的方式，对资源进行标记；用户也可以同通过控制台进行自定义TAG标记；

进程数据分类方法： 通过采集到的进程数据，可以推测出aws判断进程属于哪一类基础设施应该是通过进程名称与commondLine来判断的。

Agent模式自动发现不足：

• 不能保存资源组件快照或跟踪资源变更；
• 收集的性能数据不是通用的运行状况监控解决方案；

自动发现API

1. Agent相关API
   • Agent的启动、停止数据采集操作；
   • Agent的描述信息；
   • Agent的运行状态；
2. 配置相关API
   • server、application、process、connection 的指标查询、过滤与配置；
3. 标签相关API
   • TAG的增删改查；

其他：

产品链接：https://aws.amazon.com/cn/documentation/application-discovery/

API地址：https://docs.aws.amazon.com/zh_cn/application-discovery/latest/APIReference/discovery-api.pdf#discovery-api-queries

一、监控系统整体概述

系统背景：
在当前项目中，当我们对特定流程注入故障后，如何评估故障的效果以及系统应对故障的表现？传统方式是用户需要登录线上机器或者各种监控系统去查看具体的指标信息，然后通过人工判断，来判断故障的影响范围，产品使用上不够自动化，且没有闭环。我们期望引入监控系统，把之前需要人来做的事情交给系统来做，为故障注入后的影响进行量化分析。

整个监控系统对数据处理的四个步骤：

系统架构图：

组件说明：

API Gateway：agent 与 Server 所有交互都会通过API Gateway，统一由API Gateway进行管控，为整个MK提供一致的数据门面接口，实现之前约定的数据总线的方案。

Data Collector：为数据采集器，接受来自客户端推送上来的监控数据 或 拉去外部监控数据；

Data Transfer： 数据转换器，把采集到的非一致性架构的数据转换为统一的数据模型；

Config： 此模块主要提供一些Agent、Collector、Analyzer需要的一些元数据；

Schedule： 依赖Schedule，主要是期望能把周期性数据拉取采集任务转换为 schedule任务，降低重复编写分布式任务调度的复杂度，其次，借助schedule实现周期任务分发的负载均衡；

Diamond：采用Diamond作为数据采集规则的动态配置中心。

MQ： 把数据采集器采集到的数据转换为统一的消息格式，解耦数据采集与数据分析对数据使用差异性；其次，当数据分析器Data Analyzer集群宕机或处理性能下降时，MQ能起到数据缓存池的作用，一定程度上防止采集上来的数据未能处理而导致的数据丢失。

Data Analyzer： 数据分析器，对收集到的监控数据进行一定程度上的计算转换，并根据关注点规则，进行事件监控处理；

自研监控系统，需要面临一系列的抉择：

二、行业监控系统架构：

OneAPM

CAT

参考：https://tech.meituan.com/CAT_in_Depth_Java_Application_Monitoring.html

三、数据采集方案

数据采集面的的挑战：

• 数据源多种多样
• 数据量大
• 变化快
• 如何保证数据采集的可靠性的性能
• 如何避免重复数据
• 如何保证数据的质量

3.1 采集方案

目前常用的数据采集方式有两种：

1. 主动监控（客户端推模式-Push）；
   • 优势：
     • 实时性好；
     • 对服务端的压力相对较小；
     • 插件化支持用户自定义采集脚本；
     • 监控自动发现；
   • 劣势：
     • 数据聚合与异常处理复杂；
2. 被动监控（服务端拉模式-Pull）；
   • 优势：
     • 数据处理方便；
     • 数据准确性、完备性更好；
     • Edas已经存在根据staragent进行数据拉去的实践方案；
   • 劣势：
     • 集群规模大时，服务器压力大，任务分发易积压，分发线程忙，带来一定数据延迟；
     • 数据拉取时服务隔离难(twitter)；
     • 无法区分服务失效和代理失效(twitter)；

现有监控系统采集方案：

主动监控示意图（Push）：

服务端提供一个接受数据请求的域名地址，客户端把数据推送到服务端，服务端负责数据解析与存储；

被动监控示意图（Pull）：

Agent一般具备的功能:

1. LogFinder: 能够根据请求的时间区间返回区间内的监控数据；
2. LogQuery: 能够根据偏移量定位到日志位置；
3. LogCompression： 支持日志数据压缩；

此部分可以参考LogAgent的实现逻辑。

我们的需求：

• 轻量级；
• 可扩展；
• 支持系统监控（OS）、业务监控（Agent）
• 支持Agent自动注册以及静态数据主动上报；
• 监控项受控开启与关闭，具备开关功能（非常态化挂载）；
• 需要具备数据堆积能力；
• 需要具备多数据源扩展能力；

方案结论：

客户端通过写本地磁盘日志的方式写指标数据，服务端通过 主动拉的方式到客户端上进行拉去数据；

3.2 分布式任务调度

我们采用服务端拉去日志的方式，所以需要一套对多个节点进行周期性调度拉取日志的框架。目前分布式定时调度服务阿里集团内有scheduleX以及开源的Quartz，考虑到服务单独输出减少依赖组件的需求，对Quartz的分布式持久化任务整合工作量评估后， 我们选择了使用quartz的方式。目前spring有对quartz进行整合，简化对quartz的使用。
不仅在监控数据采集上需要调度，在演练定时触发、演练监控定时开启等场景下都需要分布式任务调度服务，所以提供一套通用型的与业务无关的分布式调度服务API很有必要。
基于spring-quartz进行接口封装出统一的分布式调度服务接口服务SchedulerService， 这部分是单独的一个模块。

3.3 数据Metric指标

客户端打印的日志非Metric格式，通过日志数据采集上来的数据需要通过转换器Transfer进行转换为统一的Metric格式；

当前监控系统采集的数据指标分为两类：

• 系统OS监控指标；
• 应用性能指标；

系统监控指标Metric含义：

应用性能监控指标Metric含义：

其中device存储agentId，transaction存储请求名称；

Metric命名规范

key和tag只支持：[a-z][A-Z][0-9][-./], 不能有空格, 大小写敏感, key原则上不包含大写。
格式为xxx.category[.sub_category]*, category和sub_category里面如果有多个单词，用下划线’‘连接， 不要用’.’连接。
需要动态聚合的维度， 放在tag里面， 同时在tagKey也在key中体现。 不需要聚合的维度， 放在key里面。

3.4 数据转换transfer

针对不同类型的类型，采用工厂方法提供自适配的解析器。针对system系统监控，继续拆分为领域适配器，比如针对CPU域、mem域提供不同的处理方式。

1
2
3
4
5
6
7
8
9
10

public interface MetricTransfer extends Transfer {

    /**
     * format  data to metric list
     *
     * @param sourceData
     * @return
     */
    List<MetricObject> format(MetricMeta metricMeta, String sourceData);
}

四、数据分析方案

4.1 分析方案：

现有的监控系统数据分析模块主要分为两类：

• 批处理模型；
• 流处理模型（Spark Streaming、Storm、Flink）；
  

结论：考虑到我们要求部署节点少、拓扑简单以及本期研发周期时间紧，我们采暂且不采用流式处理方案，数据获取到后，直接给到后端进行分析处理；

4.2 监控点分析：

用户可以通过配置监控指标，来对关心的系统指标进行阈值判断，比如选择一批机器，关注CPU利用率超过90%，那么监控系统就需要把这批机器在演练期间CPU利用率超过90%的指标都找出来，并转换为Event事件。这点类似于监控系统中的报警系统模型。

数据分析器中处理监控指标的流程如下：

流程分析：

每一个Data Analyzer模块中都会包含一个Rule Set集合，Rule Set集合存放着生效后的关注点规则，在监控数据到达分析引擎中后，分析引擎通过filter机制，判断是否命中规则，如果命中规则，则根据规则与数据形成一条Event 事件数据，用于描述某次监控指标命中了监控指标阈值。后续复盘时，可以对Event 库中的指标事件进行聚合分析，形成需要的结论报告。

规则注册与更新机制：

关注点规则为内存数据集，当用户在界面是哪个新增了规则或者变更了规则的时候，都需要对内存中维护的这份规则集合进行修改操作。

规则存储：

当前规则为内存存储方式，在系统启动时从数据库中进行load全量有效关注点指标；带来的影响每一台机器都需要在内存中维护一份数据，如果某台机器数据更新失败，会带来数据的一致性问题，后续会考虑这部分数据移动到公共的外部快速存储设备中，比如Redis中。

数据模型：

我们把用户配置的关注点在系统指标上的阈值简称为“告警”，告警条件的判断以及存储流程中，主要涉及的领域模型为：Hosts、Metrics、triggers、functions、items、events、actions；

• hosts： 存储被监控的主机信息；
• metrics：存储监控到的数据指标；
• items： 存储支持的监控项配置信息。
• triggers：存储触发器的相关信息；
• events： 存储事件数据；
• actions：存储当触发器触发时，需要采取的动作（不再本期研发范围内）；

触发器计算模型：

我们的需求是：监控某个关注对象下的某类监控指标下的特定聚合函数值 是否超过(也可能是其它运算符)某个固定阈值；那么我们把需求中拆解出几个对象出来，分别是：监控对象、监控指标、聚合函数、运算符、固定阈值，我们通过这几个对象的组合，可以对我们的意图进行对象化描述，表达式函数格式如下：
{:.()}

计算模型举例：

关注点描述为： 11.23.45.67 这台机器的 最近十分钟 load 指标 大于2 ， 那么 表达式函数为：
{11.23.45.67:system.cpu.load.last(10m)} > 2

触发器中的聚合函数：

• max 最大值
• min 最小值
• avg 平均值

数据模型：

在监控指标分析域中涉及到的领域模型对象为：

• items
• triggers
• events
• actions

数据模型以及关联关系如下：

资源组与触发器为1：n的关系，监控项与触发器为1:1关系，触发器与事件为1:1关系；

五、数据存储方案

5.1 数据分类：

我们把数据类型分为五类：

1. Metric指标数据（分为服务器和容器）
   • 定义：metric描述一个指标在某个时间点的值是多少，可以使用tag来进行元数据标记划分；比如OS的系统监控指标；
2. Event 事件数据（包括：系统、Docker数据采集）
   • 定义：event记录系统在特定时刻下发生的具体信息，比如规则下发、故障启停、MkKit安装与卸载、Metric触发规则配置产生的事件等；
3. Log 运行时日志数据
   • 定义：event数据可以根据业务需求打上tag便于分析时筛选，统计，text中记录事件丰富上下文信
4. Heartbeat 心跳数据
   • 定义：定期执行的状态汇报，比如agent的心跳信息，进程的状态等；
5. Trace 数据
   • 定义：记录故障注入请求trace的信息；

5.2 数据存储方案：

监控数据是时间序列的数据，由于监控的对象数量巨大，所以存储的介质需要支持高的写入吞吐量，良好的扩充性，读取最近的数据速度要快，支持多数据类型，支持多种扫描方式等特点，目前主要的存储方式有SQL和NoSQL两种。通过对比，NoSQL在数据存储吞吐量，扩充性等方面具有优势，SQL在数据类型的支持，扫描多样性具有优势。

总而言之，监控数据更适合采用时序性存储媒介，比如OpenTSDB、HiTSDB等；考虑到种种原因，我们临时使用 Mysql，Mysql 能在一定程度上简化我们架构，让业务跑的更快一些。

不压缩的情况下：100台机器同时采集长达30天，占用空间49G；（单条1kb计算，5秒存储一次）。

5.3 行业常用存储方案

Cassandra
InfluxDB
MongoDB
OpenTSDB
KairosDB
HBase

5.4 监控指标存储规范

遵循metric规范；

一个metric由两部分组成，metric key和metric tag：

1. metric key：它是用英文点号分隔的字符串，用来表征这个指标的含义
2. metric tag：它定义了这个指标的不同切分维度，可以是单个，也可以是多个
   • tag key: 用于描述维度的名称
   • tag value: 用于描述维度的值

Metric的数据格式如下：

• metric key：存储当前指标的key
• metric tag：存储当前指标的tag
• metric value：存储当前指标的值
• timestamp：存储当前的时间戳
• metadata：存储当前指标的一些元信息

在Metric规范下，针对云上的多租户设计，我们增加了两个字段namespace、scope，用来对metric进行分类，一个是从用户角度进行划分，一个是从功能集角度划分，形成 MetricObject 对象属性描述如下：

举例：

1
2
3
4
5
6
7
8
9
10
11

{
    "namespace": "1114805108664848",
    "scope": "system",
    "metric": "sys.memory.total",
    "metricType": "COUNTER",
    "tags": {
        "host": "127.0.0.1"
    },
    "timestamp": 1470298287916,
    "value": 1167126
}

MetricType 指标类型(参考：http://metrics.dropwizard.io/4.0.0/getting-started.html)：

• COUNTER: 用于累加型的数据，反映的是数据随着时间单调递增的关系，如Tomcat接受到的HTTP请求的总次数
• GAUGE: 用于瞬态数据，表示指标在当前时间点的瞬时情况，反映的是数据随着时间上下波动的关系，如系统的load，JVM的内存使用率
• METER：用于对变化速率型指标进行度量，反映的是数据随时间的增长快慢关系，如某个接口的QPS
• HISTOGRAM：用于对分布型数据进行度量，反映的是数据随时间的统计学分布关系

Tags 标签存储方案：

由于生产环境中存储方案当前技术选型为使用Mysql存储Metric数据，Mysql不支持schemaless结构，所以无法做到Tags的key-value的动态扩展，我们使用Mysql的固定列模式，通过提供内置tag来达到相同的目的；Tags中的key为Mysql中的列名称，字段值为tags的value；

内置的tag字段为：

Mysql数据模型如下：

六、监控数据查询方案

6.1 数据查询分类：

用户对时序数据的查询场景多种多样，总的来说时序数据的查询分为两种：

• 原始数据的查询（比如业务监控数据）
• 时序数据聚合运算的查询（比如系统监控数据）

某监控 指标展示计算解析：

监控中用户日志的计算逻辑是由用户自定义的计算方式（因为是业务监控），主要由求行数、对列值求和、对列值求平均、对列值求最大值、对列值求最小值；其大盘数据展示中并未对数据做再次聚合处理，展示的是采集的原始数据（原始数据分为秒级和分钟级），如果需要做计算，是通过前端的聚合函数进行的业务处理。

6.2 数据聚合分类：

在监控数据使用过程中，我们往往会针对单台机器进行分析或者多台(集群)机器进行分析，每一种分析中又会加入时间的概念，比如是采用原始采集的数据点还是进行多个点的合并形成一个新点。所以我们把数据分析计算分为两个维度，一个是‘机器’维度(空间聚合)，一个时间维度(时间聚合)；在Metric模型中我们通过两个方法分别定义，一个是Aggregator，一个是Down sample。

Aggregator：用来描述同一个时间点下，数据集合的聚合方式；比如一个集群的CPU使用率，在某一时刻下集群中所有机器的CPU使用率的平均值；需要注意的是，当随着集群规模越来越大的时候，我们也是需要从这个数据集合中进行采样，然后再做聚合计算。

Down sample：用来描述在多个时间点下，数据聚合的聚合方式；比如一台机器每隔5秒采集一个CPU使用率，最终数据展示时，需要按照1分钟一个点的方式进行展示，那么这个数据集合中在不丢数据的情况下会有12个数据项，我们需要将这12个数据项聚合为一个数据项。

6.3 数据聚合方式：

数据的聚合方式一般可以分为‘预聚合’和‘后聚合’；提前聚合可能引起数据膨胀但可以加速访问请求时的响应速度，访问时聚合虽然降低了一定的存储成本但可能会加慢响应速度。

大部分监控系统一般都支持预聚合(归档)数据处理（比如zabbix的数据归档表trends）；由于一般原始数据采集周期比较小，比如分钟级，那么展示长时间的数据的视图需要扫描过多数据，展示比较慢，如果将数据归档成按小时，和按天的数据，那么展示时间跨度大的数据的效率大大提高；基于Metric的数据预处理，一般采用流式预聚合引擎，对数据进行降精度处理，比如阿里的DBPass产品，会对指标数据事先降时间精度，分为6个精度：1秒、5秒、15秒、1分钟、5分钟、15分钟。

基于Metric规范的时序数据库中，OpenTSDB支持预聚合和后聚合，Aliyun的HiTSDB优先采用后聚合，其通过采用倒排索引+前缀索引来加速数据查询。

6.4 数据计算算法：

在客户端数据采集计算的时候，通常也会遇到数据聚合的需求，主要是基于单机维度的数据聚合，比如我们期望采集固定周期周期范围内的数据，假如每个周期范围内存在多个数据点（D1，D2，D3），我们要怎样计算才能得到一个点的数据呢？

通常会有以下计算方式：

• 随机采样；
• 滑动窗口；
• 滑动时间窗口；
• 指数衰减随机采样（EWMA）；

EWMA的Java实现方式可以参考：EWMA.java
EWMA算法 维护一个固定大小的集合，并认为该集合中的元素的权重不一样，元素的权重随元素距离当前时间的远近而呈现指数型的衰减。主要是解决数据集合中的离散点，让数据曲线跟加平滑。比如Load1、Load5、Load15目前的计算逻辑就采用EWMA算法；

6.5 数据查询API：

待补充

七、扩展阅读：

metric起源：

https://www.youtube.com/watch?v=czes-oa0yik

小米 open-falcon：

http://open-falcon.com/

网易企业级监控：

http://blog.163yun.com/archives/900

salesforce-Argus：
https://github.com/salesforce/argus

使用Metrics监控应用程序的性能：

http://www.cnblogs.com/yangecnu/p/Using-Metrics-to-Profiling-WebService-Performance.html

深入浅出时序数据库之预处理篇：

http://www.infoq.com/cn/articles/pretreatment-in-sequential-databases

论文地址：
https://patents.google.com/patent/US7912749B2/en

论文主体内容：

通过分析中间件网络数据，建立信息模型；从网络数据中判断组件性能阈值、基础设施组件之间的依赖关系以及业务流程与基础设施的映射关系；

建议采用分层（图层）模型；（比如Dynatrace中的5层模型）

架构基线特征

1. 基于对象的；
   • 对象也就是架构实体或者信息模型的组合；
2. 策略驱动的；
3. 安全的；
4. 自我管理的；
5. 自我描述；
   • 自我描述有利于新组件加入后的关系挖掘，而不依赖人工的定义与配置；
6. 能够提供信息透明度；

架构基线是简化系统主要部分的识别和结构化组织的催化剂。

架构发现本质上是对信息的识别和分类过程，识别和分类过程最好与任何特定的知识库，上下文，协议或平台 无关。

模型划分

可以提供元模型来定义用于在业务管理环境中指定模型的语言。元模型可以具有描述动态语义的能力。元模型图层中的一些对象示例包括类，属性，操作，关联，组件等

可以提根据核心模型来定义抽象类的集合，核心模型是分析师确定如何扩展核心模型以创建领域模型的起点。抽象类的一些例子，比如交易、客户等；

按照信息的抽象程度划分：
元模型 > 信息模型 > 核心模型 > 领域模型；

信息模型和核心模型通常更稳定，这两个模型是定义域模型的来源，这些模型也提供了跨不同领域的元素视图，可发现有价值的业务相关数据。

信息过滤

从多个数据源创建有用的信息非常关键。但是，业务相关性需要适当、一致且相关的信息，而不是分散的数据。信息透明度服务可以将离散的实时或历史数据源分离出来，作为有用的信息源。该过程涉及通过使用明确定义的‘聚合’和‘转换规则’以及信息模型作为信息交换的基础来聚合和转换数据源。

模式

软件模块存储在数据库中。库中的各个模块称为模式，而库本身称为模式目录。模式可以根据其规模和抽象进一步分类为

• 架构模式
• 设计模式
• 语言模式

架构模式：表达了软件系统的基本结构组织模式。它提供了一组预定义的子系统，指定了他们的职责，并包括组织它们之间关系的规则和准则。

扩展功能

基础设施的自动发现，可衍生出通过诊断分析进行故障定位或影响分析等功能。可以提供自我修复程序，并且可以通过动态资源管理和嵌入式服务意识来解决基础结构优化问题。比如Dynatrace的故障定位；

扩展产品了解：

dynatrace
amazon-application-discovery

我们在使用spring-quartz的时候，常常会遇到一个场景，那就是任务的调度会随着争取锁的先后顺序而出现不固定机器执行的场景，这在正常业务逻辑中具备了很好的容灾能力，但是在我们排查问题时，却带来了困绕，如果出现问题，我们期望任务调度固定在一台机器上进行执行，方便我们对问题的定位和排查。

这里就探讨如何扩展spring-quartz来实现任务的固定机器执行。

整体思路

要指定机器运行trigger，那首先我们必须清楚spring-quartz cluster模式下，任务的触发时如何进行分布式执行的。
spring-quartz cluster 是借助数据锁来实现并发控制的，需要注意的是分布式环境下需要保证各机器系统时间一致性；

核心处理线程QuartzSchedulerThread决定了扫描那些JOB，以及触发执行和生命周期的维护。
QuartzSchedulerThread中run方法：

1
2
3
4
5
6
7
8
9
10
11
12

//在trigger表中扫描指定SCHED_NAME、状态为WAITING，下次触发时间在30秒内的触发器
triggers = qsRsrcs.getJobStore().acquireNextTriggers(
                                now + idleWaitTime, Math.min(availThreadCount, qsRsrcs.getMaxBatchSize()), qsRsrcs.getBatchTimeWindow());
....                  
//触发器执行
List<TriggerFiredResult> res = qsRsrcs.getJobStore().triggersFired(triggers);                                                          
...
//释放触发器
qsRsrcs.getJobStore().releaseAcquiredTrigger(triggers.get(i));
...
//完成触发器
qsRsrcs.getJobStore().triggeredJobComplete(triggers.get(i), bndle.getJobDetail(), CompletedExecutionInstruction.SET_ALL_JOB_TRIGGERS_ERROR);                          

我们就可以在acquireNextTriggers中做扩展，获取全部或者指定了实例ID的trigger。

延伸思考：acquireNextTriggers获取到trigger列表后，假设机器宕机，这些trigger如何路由到其他机器中正常运行？

扩展实例ID的生成策略

spring-quartz一般配置的org.quartz.scheduler.instanceId：AUTO，采用的是SimpleInstanceIdGenerator ID生成策略。

1
2
3
4
5
6
7
8
9

public class SimpleInstanceIdGenerator implements InstanceIdGenerator {
    public String generateInstanceId() throws SchedulerException {
        try {
            return InetAddress.getLocalHost().getHostName() + System.currentTimeMillis();
        } catch (Exception e) {
            throw new SchedulerException("Couldn't get host name!", e);
        }
    }
}

SimpleInstanceIdGenerator 采用机器主机名称与当前时间戳作为instanceId,我们期望在开发环境使用hostName，在生产环境(Linux)采用IP作为实例ID。

实现InstanceIdGenerator接口，实现自己的ID生成策略，QuartzSchedulerInstanceIdGenerator的实现逻辑为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

public class QuartzSchedulerInstanceIdGenerator implements InstanceIdGenerator {
    private static final Logger log = LoggerFactory.getLogger(QuartzSchedulerInstanceIdGenerator.class);
    private static final String OS_NAME = "os.name";
    private static final String WINDOWS = "Windows";
    private static final String MAC = "Mac OS";

    @Override
    public String generateInstanceId() throws SchedulerException {
        String id;
        try {
            if (isLocalDev()) {
                id = getHostName();
            } else {
                id = IpUtil.getIp();
            }

            if (StringUtils.isBlank(id)) {
                id = InetAddress.getLocalHost().getHostName() + System.currentTimeMillis();
            }
        } catch (Exception e) {
            throw new SchedulerException("Couldn't generate instance id!", e);
        }
        return id;
    }

    private String getHostName() throws SchedulerException {
        try {
            return InetAddress.getLocalHost().getHostName();
        } catch (Exception e) {
            throw new SchedulerException("Couldn't get host name!", e);
        }
    }

    private boolean isLocalDev() {
        if (StringUtils.indexOfIgnoreCase(System.getProperty(OS_NAME), WINDOWS) >= 0) {
            return true;
        }

        if (StringUtils.indexOfIgnoreCase(System.getProperty(OS_NAME), MAC) >= 0) {
            return true;
        }
        return false;
    }
}

在quartz.properties中配置：

1

org.quartz.scheduler.instanceIdGenerator.class=com.xx.ext.QuartzSchedulerInstanceIdGenerator

扩展StdJDBCDelegate

SchedulerFactoryBean 工厂Bean负责加载配置信息，初始化SchedulerFactory和Scheduler实例，jobStore负责job、trigger等的持久化工作，针对不同的数据库类型，可以配置不同的DriverDelegate。Spring中默认使用LocalDataSourceJobStore作为JobStore的处理类。

SchedulerFactory中initSchedulerFactory方法:

1
2
3
4
5
6
7
8
9
10
11
12

     if (this.configLocation != null) {
	if (logger.isInfoEnabled()) {
		logger.info("Loading Quartz config from [" + this.configLocation + "]");
	}
	PropertiesLoaderUtils.fillProperties(mergedProps, this.configLocation);
  }

CollectionUtils.mergePropertiesIntoMap(this.quartzProperties, mergedProps);

if (this.dataSource != null) {
	mergedProps.put(StdSchedulerFactory.PROP_JOB_STORE_CLASS, LocalDataSourceJobStore.class.getName());
}

可以看到SchedulerFactoryBean中设置PROP_JOB_STORE_CLASS属性是在合并用户设置的配置文件之后，也就是PROP_JOB_STORE_CLASS的实现类Spring强制指定为LocalDataSourceJobStore而无法更改，即便是我们在quartz.properties中配置了org.quartz.jobStore.class属性，也会被LocalDataSourceJobStore覆盖掉。

LocalDataSourceJobStore继承自JobStoreSupport，JobStoreSupport默认配置使用StdJDBCDelegate作为与数据库交互的代理处理类；我们可以通过扩展StdJDBCDelegate类，来实现底层数据库交互的扩展。通过配置org.quartz.jobStore.driverDelegateClass属性，指定driverDelegate为我们扩展后的Delegate。

在quartz.properties中配置：

1

org.quartz.jobStore.driverDelegateClass=com.xx.ext.StdJDBCDelegateExt

针对${table_prefix}_quartz_triggers表新增字段INSTANCE_NAME，此字段为InstanceIdGenerator生成的实例ID，此字段会透传到StdJDBCDelegate中的属性instanceId中，因此我们可以扩展StdJDBCDelegate，通过instanceId字段来指定获取的trigger列表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

public class StdJDBCDelegateExt extends StdJDBCDelegate {

    String INSTANCE_NAME_VALUE = "{2}";

    String SELECT_NEXT_TRIGGER_TO_ACQUIRE_EXT = "SELECT "
        + COL_TRIGGER_NAME + ", " + COL_TRIGGER_GROUP + ", "
        + COL_NEXT_FIRE_TIME + ", " + COL_PRIORITY + " FROM "
        + TABLE_PREFIX_SUBST + TABLE_TRIGGERS + " WHERE "
        + COL_SCHEDULER_NAME + " = " + SCHED_NAME_SUBST
        + " AND " + COL_TRIGGER_STATE + " = ? AND " + COL_NEXT_FIRE_TIME + " <= ? "
        + " AND (" + COL_INSTANCE_NAME + " IS NULL OR " + COL_INSTANCE_NAME + " = " + INSTANCE_NAME_VALUE + ")"
        + "AND (" + COL_MISFIRE_INSTRUCTION + " = -1 OR (" + COL_MISFIRE_INSTRUCTION + " != -1 AND "
        + COL_NEXT_FIRE_TIME + " >= ?)) "
        + "ORDER BY " + COL_NEXT_FIRE_TIME + " ASC, " + COL_PRIORITY + " DESC";

    /**
     * 允许设置trigger 指定一台机器进行任务调度执行；
     *
     * @param conn
     * @param noLaterThan
     * @param noEarlierThan
     * @param maxCount
     * @return
     * @throws SQLException
     */
    @Override
    public List<TriggerKey> selectTriggerToAcquire(Connection conn, long noLaterThan, long noEarlierThan, int maxCount)
        throws SQLException {
        PreparedStatement ps = null;
        ResultSet rs = null;
        List<TriggerKey> nextTriggers = new LinkedList<TriggerKey>();
        try {
            ps = conn.prepareStatement(rtp(SELECT_NEXT_TRIGGER_TO_ACQUIRE_EXT, instanceId));

            // Set max rows to retrieve
            if (maxCount < 1) {
                maxCount = 1;
            }
            ps.setMaxRows(maxCount);

            // Try to give jdbc driver a hint to hopefully not pull over more than the few rows we actually need.
            // Note: in some jdbc drivers, such as MySQL, you must set maxRows before fetchSize, or you get exception!
            ps.setFetchSize(maxCount);

            ps.setString(1, STATE_WAITING);
            ps.setBigDecimal(2, new BigDecimal(String.valueOf(noLaterThan)));
            ps.setBigDecimal(3, new BigDecimal(String.valueOf(noEarlierThan)));
            rs = ps.executeQuery();

            while (rs.next() && nextTriggers.size() <= maxCount) {
                nextTriggers.add(triggerKey(
                    rs.getString(COL_TRIGGER_NAME),
                    rs.getString(COL_TRIGGER_GROUP)));
            }

            return nextTriggers;
        } finally {
            closeResultSet(rs);
            closeStatement(ps);
        }
    }

    protected final String rtp(String query, String instanceName) {
        return MessageFormat.format(query,
            new Object[] {tablePrefix, getSchedulerNameLiteral(), "'" + instanceName + "'"});
    }
}

至此，完成了指定trigger在特定instanceId上运行，但是有一个问题，假如我们期望trigger可以在多台instanceId上随机执行的话，该如何实现呢？

在我们程序开发中，进程会需要把一些变量通过property方式进行提取，方便不同环境配置不同的属性，替换变量的方法通常有两种，一种是静态替换，一种是动态替换；所谓静态替换，是在打包编译的时候，把变量替换掉，动态替换，是在程序运行起来时，通过把属性注入到程序的环境变量中，类初始化的时候，再使用环境变量进行替换的一种方法。

静态替换常用工具：autoconfig
动态替换常用工具：spring.property-placeholder

spring动态替换变量实践

简洁配置法：

1
2

<context:property-placeholder location="classpath:xxx.properties" 
ignore-unresolvable="true"/>

等价于：

1
2
3
4
5

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location">
        <value>myConfig.properties</value>
    </property>
</bean>

完整配置属性：

1
2
3
4
5
6
7
8
9
10

<context:property-placeholder   
        location=""  
        file-encoding=""  
        ignore-resource-not-found=""  
        ignore-unresolvable=""  
        properties-ref=""  
        local-override=""  
        system-properties-mode=""  
        order=""  
/> 

ignore-resource-not-found：如果属性文件找不到，是否忽略，默认false，即不忽略，找不到将抛出异常

ignore-unresolvable：是否忽略解析不到的属性，如果不忽略，找不到将抛出异常

order：当配置多个context:property-placeholder/时的查找顺序

不推荐将ignore-resource-not-found和ignore-unresolvable的值设置为ture，默认为false，可以有效避免程序运行异常

使用PropertySource注解配置

Spring3.1添加了@PropertySource注解,方便添加property文件到环境.

properties的注入与使用

• java中使用@Value注解获取

1
2

@Value( "${jdbc.url}" )
private String jdbcUrl;

• 在Spring的xml配置文件中获取

1
2
3

<bean id="dataSource">
  <property name="url" value="${jdbc.url}" />
</bean>

配置多个property-placeholder属性

Spring容器是采用反射扫描的发现机制，通过标签的命名空间实例化实例，当Spring探测到容器中有一个org.springframework.beans.factory.config.PropertyPlaceholderCVonfigurer的Bean就会停止对剩余PropertyPlaceholderConfigurer的扫描，即只能存在一个实例！

所以一遍不建议配置多个property-placeholder对象，但是在必须使用多个的场景下，如何配置呢？

1
2
3

<context:property-placeholder location="xxx.properties" ignore-unresolvable="true"/>

<context:property-placeholder location="xxx.properties" ignore-unresolvable="true"/>

需要设置ignore-unresolvable=”true”，否则后面的property-placeholder不会被加载；

ignore-unresolvable单独使用来看是“是否忽视不存在的配置项”，不仅如此，其还有一个隐含意思：是否还要扫描其他配置项：如果为false，则会忽视后续的property-placeholder，如果需要配置多个property-placeholder则应该设置为true；

context:property-placeholder 工作原理

在 ContextNamespaceHandler 中对于 context中的property-placeholder 标签，会采用PropertyPlaceholderBeanDefinitionParser解析器进行解析；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class ContextNamespaceHandler extends NamespaceHandlerSupport {

	@Override
	public void init() {
		registerBeanDefinitionParser("property-placeholder", new PropertyPlaceholderBeanDefinitionParser());
		registerBeanDefinitionParser("property-override", new PropertyOverrideBeanDefinitionParser());
		registerBeanDefinitionParser("annotation-config", new AnnotationConfigBeanDefinitionParser());
		registerBeanDefinitionParser("component-scan", new ComponentScanBeanDefinitionParser());
		registerBeanDefinitionParser("load-time-weaver", new LoadTimeWeaverBeanDefinitionParser());
		registerBeanDefinitionParser("spring-configured", new SpringConfiguredBeanDefinitionParser());
		registerBeanDefinitionParser("mbean-export", new MBeanExportBeanDefinitionParser());
		registerBeanDefinitionParser("mbean-server", new MBeanServerBeanDefinitionParser());
	}

}

PropertyPlaceholderBeanDefinitionParser解析器会将property-placeholder 标签解析为一个PropertySourcesPlaceholderConfigurer的单例 bean 。

可以看出 PropertySourcesPlaceholderConfigurer 或者 PropertyPlaceholderConfigurer 仅仅是做了一个配置文件的解析工作，真正的注入并不由它们完成，而是托付给了Spring 的Bean初始化流程。
之所以这么做可以生效，是因为这两个类实现了 BeanFactoryPostProcessor 接口，这个接口的优先级高于后续的Spring Bean。

属性元素的注入依赖于 AutowiredAnnotationBeanPostProcessor#postProcessPropertyValues。 通过解析PropertySourcesPlaceholderConfigurer 查询得到元素值。

1
2
3
4
5
6
7
8
9
10

public PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
    InjectionMetadata metadata = this.findAutowiringMetadata(beanName, bean.getClass());

    try {
        metadata.inject(bean, beanName, pvs);
        return pvs;
    } catch (Throwable var7) {
        throw new BeanCreationException(beanName, "Injection of autowired dependencies failed", var7);
    }
}

PropertySourcesPlaceholderConfigurer本质上是一个BeanFactoryPostProcessor。解析XML的流程在BeanFactoryPostProcessor之前， 优先将配置文件的路径以及名字通过Setter传入PropertySourcesPlaceholderConfigurer。

如上BeanFactoryPostProcessor的优先级又优于其余的Bean。因此可以实现在bean初始化之前的注入。

Spring @Value注入流程

1. Spring Context 的初始化开始
2. 读取到context:property-placeholder标签或者PropertySourcesPlaceholderConfigurer
3. 解析并实例化一个PropertySourcesPlaceholderConfigurer。同时向其中注入配置文件路径、名称
4. PropertySourcesPlaceholderConfigurer自身生成多个StringValueResolver备用，Bean准备完毕
5. Spring在初始化非BeanFactoryPostProcessor的Bean的时候，AutowiredAnnotationBeanPostProcessor 负责找到Bean内有@Value注解的Field或者Method
6. 通过PropertySourcesPlaceholderConfigurer寻找合适的StringValueResolver并解析得到val值。注入给@Value的Field或Method。(Method优先)2
7. Spring的其他流程。

参考：
http://blog.csdn.net/qyp199312/article/details/54313784