lement,一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的组件库,提供了配套设计资源,帮助你的开发快速成型。由饿了么公司前端团队开源。
开源版本持续更新至2.3.2版;
一致性 Consistency
与现实生活一致:与现实生活的流程、逻辑保持一致,遵循用户习惯的语言和概念;
在界面中一致:所有的元素和结构需保持一致,比如:设计样式、图标和文本、元素的位置等。
反馈 Feedback
控制反馈:通过界面样式和交互动效让用户可以清晰的感知自己的操作;
页面反馈:操作后,通过页面元素的变化清晰地展现当前状态。
效率 Efficiency
简化流程:设计简洁直观的操作流程;
清晰明确:语言表达清晰且表意明确,让用户快速理解进而作出决策;
帮助用户识别:界面简单直白,让用户快速识别而非回忆,减少用户记忆负担。
可控 Controllability
用户决策:根据场景可给予用户操作建议或安全提示,但不能代替用户进行决策;
结果可控:用户可以自由的进行操作,包括撤销、回退和终止当前操作等。
导航可以解决用户在访问页面时:在哪里,去哪里,怎样去的问题。一般导航会有「侧栏导航」和「顶部导航」2 种类型。
推荐使用 npm 的方式安装,它能更好地和 webpack 打包工具配合使用。
# npm i --save element-angular
或者CDN
目前可以通过 unpkg.com/element-ui 获取到最新版本的资源,在页面上引入 js 和 css 文件即可开始使用。
<!-- 引入样式 -->
<link rel="stylesheet" href="https://unpkg.com/element-ui/lib/theme-chalk/index.css">
<!-- 引入组件库 -->
<script src="https://unpkg.com/element-ui/lib/index.js"></script>
开始前, 你还需要一个主题包, 这里我们推荐使用element-theme-default.
npm install element-theme-default --save
import React from 'react';
import ReactDOM from 'react-dom';
import { Button } from 'element-react';
import 'element-theme-default';
ReactDOM.render(<Button type="primary">Hello</Button>, document.getElementById('app'));
<!DOCTYPE html><html><head> <meta charset="UTF-8"> <!-- import CSS --> <link rel="stylesheet" href="https://unpkg.com/element-ui/lib/theme-chalk/index.css"></head><body> <div id="app"> <el-button @click="visible = true">Button</el-button> <el-dialog :visible.sync="visible" title="Hello world"> <p>Try Element</p> </el-dialog> </div></body> <!-- import Vue before Element --> <script src="https://unpkg.com/vue/dist/vue.js"></script> <!-- import JavaScript --> <script src="https://unpkg.com/element-ui/lib/index.js"></script> <script> new Vue({ el: '#app', data: function() { return { visible: false } } }) </script></html>
清爽图标
说:骑手进店切牛排 来源/看看新闻
新民晚报讯(记者 徐驰)近日,一名身穿“饿了么”制服的外卖小哥引发热议,而“蹿红”的原因,并不是因为他送餐速度快或是送单数量多,而是他在餐厅里做起了菜。这一幕被市民拍下上传至网络后,引发网友热议。为此,“饿了么”回应记者:公司目前正在调查此事。
据了解,当时,该网友在经过古北1699广场内的一家牛排店时,惊讶地发现一名送餐员男子,正在店内忙着切配、装盒。网友随即将这一幕拍下,并指出,这样的行为并不妥当。但该名骑手抬了一下头后,并未搭理,又开始“埋头苦干”。
照片一经传播,立刻引起广大网友热议。不少网友认为,外卖员穿在身上的送餐服长期与外界接触,沾染大量灰尘和汽车尾气,接触食材和餐具,非常不卫生;也有网友认为,餐饮人员从业必须有健康证,而照片里的外卖小哥是否持有健康证,也不得而知。而设施餐厅让外卖员直接进入餐厅做菜,是否存在监管疏漏?事发后,网友随后也向相关部门举报。
图说:骑手配菜挺熟练
记者与“饿了么”方面取得联系。一名客服人员表示,已记录下相关情况,并会将事情反馈给公司相关部门。
其实,新民晚报曾报道过外卖小哥为了加快配送速度,亲自“掌勺”的新闻(详见《外卖界的“清流”还是“泥石流”?嫌弃出菜速度慢 外卖小哥亲自下厨》 http://newsxmwb.xinmin.cn/shanghaitan/2017/09/12/31276199.html )而随后相关企业也表示,在公司的行为规范中,并不允许外卖员私自进入后厨,炒菜、配菜等。
来源/东方IC
去年9月1日,《外卖配送服务规范》正式施行,规定了外卖服务机构须具备法人资质、固定办公场所,要求外卖配送服务队伍要规模化,配送人员使用的配送车、配送箱、头盔等都要符合规定。
饿了么监控系统 EMonitor :是一款服务于饿了么所有技术部门的一站式监控系统,覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近 PB ,每日写入指标数据量百T,每日指标查询量几千万,配置图表个数上万,看板个数上千。
CAT:是基于 Java 开发的实时应用监控平台,为美团点评提供了全面的实时监控告警服务。
本文通过对比分析下两者所做的事情为契机讨论监控系统或许该有的面貌,以及浅谈下监控系统发展的各个阶段。
首先要强调的是这里我们只能拿到 GitHub 上开源版 CAT 的最新版 3.0.0 ,所以是基于此进行对比。接下来说说 CAT 做了哪些事情?
抽象出监控模型
抽象出 Transaction、Event、Heartbeat、Metric 4 种监控模型。
针对 Transaction 和 Event 都固定了两个维度, type 和 name ,并且针对 type 和 name 进行分钟级聚合成报表并展示曲线
采样链路
针对上述 Transaction、Event 的 type 和 name 分别有对应的分钟级的采样链路
自定义的 Metric 打点
目前支持 Counter 和 Timer 类型的打点,支持 tag ,单机内单个 Metric 的 tag 组合数限制 1000 。并且有简单的监控看板,如下图所示:
与其他组件集成
比如和 Mybatis 集成,在客户端开启相关的 sql 执行统计,并将该统计划分到 Transaction 统计看板中的 type=SQL 的一栏下。
告警
可以针对上述的 Transaction、Event 等做一些简单的阈值告警。
饿了么 EMonitor 借鉴了 CAT 的相关思想,同时又进行了改进。
引入 Transaction、Event 的概念
针对 Transaction 和 Event 都固定了两个维度, type 和 name ,不同地方在于聚合用户发过来的数据。
CAT 的架构图如下所示:
CAT 的消费机需要做如下两件事情:
EMonitor 的架构图如下所示:
EMonitor 分两路对数据进行隔离处理:
所以 EMonitor 和 CAT 的一个很大不同点就在于对指标的处理上, EMonitor 交给专业的时序数据库来做,而 CAT 自己做聚合就显得功能非常受限,如下所示:
但是CAT也有自己的优势:
采样链路
目前 CAT 和 EMonitor 都可以通过 type 和 name 来过滤采样链路,不同点在于:
EMonitor 的链路如下所示
自定义的 Metric 打点
EMonitor 支持 Counter、Timer、Histogram、Payload、Gauge 等等多种形式的打点方式,并且支持 tag :
也就是任意 Metric 打点都可以流经 EMonitor 进行处理了并输送到LinDB时序数据库中。至此, EMonitor 就可以将任何监控指标统一在一起了,比如机器监控都可以通过 EMonitor 来保存了,这为一站式监控系统奠定了基础。
自定义 Metric 看板
CAT只有一个简易的 Metric 看板 EMonitor 针对 Metric 开发了一套可以媲美Grafana 的指标看板,相比 Grafana 的优势:
类 SQL 的配置查询指标方式如下所示
看板整体如下所示:
移动端显示如下:
与其他组件集成
目前 EMonitor 已经打通了 IaaS 层、 PaaS 层、应用层的所有链路和指标的监控,再也不用在多个监控系统中切换来切换去了,如下所示:
以打通饿了么分库分表中间件 DAL 为例:
可以根据机房、执行状态、表、操作类型(比如 Insert、Update、Select 等)进行过滤查看:
再以打通饿了么 SOA 服务为例:
告警
可以针对所有的监控指标配置如下告警方式:
日志监控阶段
本阶段实现方式:程序打日志,使用ELK来存储和查询程序的运行日志, ELK 也能简单显示指标曲线。
排障过程:一旦有问题,则去 ELK 中搜索可能的异常日志来进行分析排障。
链路监控阶段
上一个阶段存在的问题: ELK 只是基于一行一行日志进行聚合或者搜索分析,日志之间没有上下文关联。很难知道一次请求耗时较长究竟耗时在哪个阶段。
本阶段实现方式: CAT 横空出世,通过建模抽象出 Transaction、Metric 等监控模型,将链路分析和简单的报表带入了大家的视野。
告警方式:针对报表可以进行阈值监控排障过程:一旦有告警,可以通过点击报表来详细定位到是哪个 type 或 name 有一定问题,顺便找到对应的链路,查看详细的信息。
指标监控阶段
上一阶段存在的问题: CAT 对自定义指标支持的比较弱,也无法实现或者展现更加多样的查询聚合需求。
本阶段的实现方式:支持丰富的 Metric 指标,将链路上的一些报表数据也可以划分到指标中,交给专业的时序数据库来做指标的存储和查询,对接或者自研丰富的指标看板如 Grafana 。
告警方式:针对指标进行更加丰富的告警策略排障过程:一旦有告警,可能需要到各个系统上查看指标看板,粗略定位根因,再结合链路总和分析。
平台打通整合阶段
上一阶段存在的问题:系统监控、中间件和业务监控、部分业务监控、链路监控与指标监控都各搞一套数据收集、预处理、存储、查询、展现、告警流程,各个系统处理数据格式、使用方式不统一。
本阶段的实现方式:打通从系统层面、容器层面、中间件层面、业务层面等等的可能的链路和指标监控,统一数据的处理流程,同时整合发布、变更、告警与监控曲线结合,成为一站式监控平台。
告警方式:可以统一的针对各个层面的监控数据做统一化的告警排障过程:只需要在一个监控系统中就可以查看到所有的监控曲线和链路信息。
目前我们 EMonitor 已完成这个阶段,将公司之前存在已久的 3 套独立的监控系统统一整合成现如今的一套监控系统。
深度分析阶段
上一阶段存在的问题:
总之:之前的阶段都是去做一个监控平台,用户查询什么指标就展示相应的数据,监控平台并不去关心用户所存储数据的内容。现在呢就需要转变思路,监控平台需要主动去帮用户分析里面所存储的数据内容。
本阶段的实现方式:所要做的就是把帮用户分析的过程抽象出来,为用户构建应用大盘和业务大盘,以及为大盘做相关的根因分析。
根因分析:一个大盘有很多的环节,每个环节绑定有很多的指标,每次某个告警出来有可能需要详细的分析下每个环节的指标,比如消费 kafka 的延迟上升,有各种各样的原因都可能导致,每次告警排查都需要将分析流程再全部人为分析排查下,非常累,所以需要将定位根因的过程通过建模抽象下,来进行统一解决。
趋势报表分析:主动帮用户发现一些逐渐恶化的问题点,比如用户发布之后,接口耗时增加,很可能用户没有发现,虽然当前没有问题,但是很有可能在明天的高峰期就会暴露问题,这些都是已经实实在在发生的事故。
要想做主动分析,还深度依赖指标下钻分析,即某个指标调用量下降了,能主动分析出是哪些 tag 维度组合导致的下降,这是上述很多智能分析的基础,这一块也不简单。
告警方式:可以统一的针对各个层面的监控数据做统一化的告警排障过程: NOC 根据业务指标或者业务大盘快速得知是哪些业务或者应用出先了问题,应用的 owner 通过应用大盘的体检得知相关的变动信息,比如是 redis 波动、database 波动、上下游应用的某个方法波动等等,来达到快速定位问题目的,或者通过对大盘执行根因分析来定位到根因。
三者关系如下图所示:
三者的确都不可或缺,相辅相成,但是我想说以下几点:
参考链接:
CAT:http://github.com/dianping/cat
深度剖析开源分布式监控CAT:
http://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html
作者信息:
李刚,网名乒乓狂魔,饿了么监控组研发专家,饿了么内部时序数据库LinDB项目负责人,目前致力于监控的智能分析领域。
本文转载于公众号:架构师社区
*请认真填写需求信息,我们会在24小时内与您取得联系。