1.数据模型

Prometheus 存储的是时序数据, 即按照相同时序(相同的名字和标签)，以时间维度存储连续的数据的集合。

1.1 时序索引

时序(time series) 是由名字(Metric)，以及一组 key/value 标签定义的，具有相同的名字以及标签属于相同时序。

时序的名字由 ASCII 字符，数字，下划线，以及冒号组成，它必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*, 其名字应该具有语义化，一般表示一个可以度量的指标，例如 http_requests_total, 可以表示 http 请求的总数。

时序的标签可以使 Prometheus 的数据更加丰富，能够区分具体不同的实例，例如 http_requests_total{method=”POST”} 可以表示所有 http 中的 POST 请求。

标签名称由 ASCII 字符，数字，以及下划线组成， 其中 __ 开头属于 Prometheus 保留，标签的值可以是任何 Unicode 字符，支持中文。

1.2 时序样本

按照某个时序以时间维度采集的数据，称之为样本，其值包含：

• 一个 float64 值
• 一个毫秒级的 unix 时间戳

1.3 格式

Prometheus 时序格式与 OpenTSDB 相似：

<metric name>{<label name>=<label value>, …}
其中包含时序名字以及时序的标签。

1.二进制包安装方式部署

我们可以到 Prometheus 二进制下载页面，选择自己需要的系统版本，下面我们将以 centos server 作为演示。

环境准备:

• linux amd64 (centos server)
• prometheus 2.1.0(这个是本次演示版，生产应该使用最新的稳定版)

1.1 下载 Prometheus Server

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

#使用 wget 下载 Prometheus 的安装包

wget https://github.com/prometheus/prometheus/releases/download/v2.1.0/prometheus-2.1.0.linux-amd64.tar.gz

#创建 Prometheus 目录，用于存放所有 Prometheus 相关的运行服务

mkdir /usr/local/prometheus

#使用 tar 解压缩 prometheus-2.1.0.linux-amd64.tar.gz

tar -xvzf prometheus-2.1.0.linux-amd64.tar.gz

#移动解压的目录到规范好的目录

mv prometheus-2.1.0.linux-amd64/*  /usr/local/prometheus

#当解压缩成功后，可以运行 version 检查运行环境是否正常

./prometheus --version

#如果你看到类似输出，表示你已安装成功:

prometheus, version 2.1.0 (branch: HEAD, revision: 85f23d82a045d103ea7f3c89a91fba4a93e6367a)
build user: root@6e784304d3ff
build date: 20180119-12:01:23
go version: go1.9.2

1.前言

一种新工具的出现，都意味着解决某一种或者某一类问题，那Prometheus的出现是解决什么问题呢，让我们从Prometheus和各种监控对比过程中得出答案。

2.Prometheus vs Zabbix

• Zabbix 使用的是 C 和 PHP, Prometheus 使用 Golang, 整体而言 Prometheus 运行速度更快一点。
• Zabbix 属于传统主机监控，主要用于物理主机，交换机，网络等监控，Prometheus 不仅适用主机监控，还适用于 Cloud, SaaS, Openstack，Container 监控。
• Zabbix 在传统主机监控方面，有更丰富的插件。
• Zabbix 可以在 WebGui 中配置很多事情，但是 Prometheus 需要手动修改文件配置。

3.Prometheus vs InfluxDB

• InfluxDB 是一个开源的时序数据库，主要用于存储数据，如果想搭建监控告警系统， 需要依赖其他系统。
• InfluxDB 在存储水平扩展以及高可用方面做的更好, 毕竟核心是数据库。

4.Prometheus vs OpenTSDB

• OpenTSDB 是一个分布式时序数据库，它依赖 Hadoop 和 HBase，能存储更长久数据， 如果你系统已经运行了 Hadoop 和 HBase, 它是个不错的选择。

• 如果想搭建监控告警系统，OpenTSDB 需要依赖其他系统。

1.概念

Prometheus是一个开源的系统监控和报警的工具包，最初由SoundCloud发布。从 2012 年开始编写代码，再到 2015 年 github 上开源以来，已经吸引了 9k+ 关注，以及很多大公司的使用；2016 年 Prometheus 成为继 k8s 后，第二名CNCF成员。作为新一代开源解决方案，很多理念与 Google SRE 运维之道不谋而合。

2.主要功能

• 多维 数据模型（时间序列数据由 metric 名字和 k/v 的 labels 构成）。
• 灵活的查询语句（PromQL）。
• 无依赖存储，支持 local 和 remote 不同模型。
• 通过pull方式采集时间序列，通过http协议传输。
• 支持通过中介网关的push时间序列的方式
• 监控目标，可以采用服务发现或静态配置的方式。
• 支持多种可视化图表及仪表盘。

3.核心组件

• Prometheus Server， 主要用于抓取数据和存储时序数据，另外还提供查询和 Alert Rule 配置管理。
• client libraries，用于对接 Prometheus Server, 可以查询和上报数据。
• push gateway ，用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等。
• 各种汇报数据的 exporters ，例如汇报机器数据的 node_exporter, 汇报 MongoDB 信息的 MongoDB exporter 等等。
• 用于告警通知管理的 alertmanager 。

由于默认情况下容器挂载的是宿主机的硬件配置信息，导致有些应用根据这些信息来决定启动内存等的大小，导致应用内存溢出等问题。

LXCFS简介

社区中常见的做法是利用 lxcfs来提供容器中的资源可见性。lxcfs 是一个开源的FUSE（用户态文件系统）实现来支持LXC容器，它也可以支持Docker容器。

LXCFS通过用户态文件系统，在容器中提供下列 procfs 的文件。

1
2
3
4
5
6

/proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime

LXCFS的示意图如下：

比如，把宿主机的 /var/lib/lxcfs/proc/memoinfo 文件挂载到Docker容器的/proc/meminfo位置后。容器中进程读取相应文件内容时，LXCFS的FUSE实现会从容器对应的Cgroup中读取正确的内存限制。从而使得应用获得正确的资源约束设定。

安装lxcfs ，先安装需要使用的依赖包：

yum install http://mirror.centos.org/centos/7/os/x86_64/Packages/fuse-libs-2.9.2-10.el7.x86_64.rpm

用deamonset方式在每个节点启动一个lxcfs,lxcfs-daemonset.yaml配置如下:

1.打标签

由于nginx要部署到指定节点上，所以需要对node打个label，通过nodeSelector调度到节点上，同时要确保部署节点主机的80、443、18080、10254端口没有被占用。
kubectl label node ss-1-centos221 nginx-ingress=nginx
kubectl label node ss-1-centos221-2 nginx-ingress=nginx

2.准备nginx-ingress-controller部署文件

2.1 nginx-ingress-controller-rbac.yaml ：设置rabc权限

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
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
        - events
    verbs:
        - create
        - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: kube-system
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: kube-system

1.什么是跨域请求

A cross-domain solution (CDS) is a means of information assurance that provides the ability to manually or automatically access or transfer between two or more differing security domains.

解决两个安全域之间的信息传递，这个就叫做CDS——跨域解决方案.

在 HTML 中，<a>, <form>, <img>, <script>, <iframe>, <link>等标签以及 Ajax(异步 JavaScript 和 XML) 都可以指向一个资源地址，而所谓的跨域请求就是指：当前发起请求的域与该请求指向的资源所在的域不一样。
这里的域指的是这样的一个概念：我们认为若协议 + 域名 + 端口号均相同，那么就是同域.

2.跨域请求的安全问题

通常，浏览器会对上面提到的跨域请求作出限制。浏览器之所以要对跨域请求作出限制，是出于安全方面的考虑，因为跨域请求有可能被不法分子利用来发动 CSRF攻击。

CSRF攻击：
CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。

CSRF 攻击的原理大致描述如下：有两个网站，其中A网站是真实受信任的网站，而B网站是危险网站。在用户登陆了受信任的A网站是，本地会存储A网站相关的Cookie，并且浏览器也维护这一个Session会话。这时，如果用户在没有登出A网站的情况下访问危险网站B，那么危险网站B就可以模拟发出一个对A网站的请求（跨域请求）对A网站进行操作，而在A网站的角度来看是并不知道请求是由B网站发出来的（Session和Cookie均为A网站的），这时便成功发动一次CSRF 攻击。

因而 CSRF 攻击可以简单理解为：攻击者盗用了你的身份，以你的名义发送而已请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。

3.同源策略

在客户端编程语言中，如javascript和ActionScript，同源策略是一个很重要的安全理念，它在保证数据的安全性方面有着重要的意义。同源策略规定跨域之间的脚本是隔离的，一个域的脚本不能访问和操作另外一个域的绝大部分属性和方法

概述：
同源策略是 Netscape 提出的一个著名的安全策略
同源策略是浏览器最核心最基础的安全策略
现在所有的可支持 Javascript 的浏览器都会使用这个策略
web构建在同源策略基础之上，浏览器对非同源脚本的限制措施是对同源策略的具体实现

同源策略的含义：
DOM 层面的同源策略：限制了来自不同源的”Document”对象或 JS 脚本，对当前“document”对象的读取或设置某些属性
Cookie和XMLHttprequest层面的同源策略：禁止 Ajax 直接发起跨域HTTP请求（其实可以发送请求，结果被浏览器拦截，不展示），同时 Ajax 请求不能携带与本网站不同源的 Cookie。
同源策略的非绝对性：<script><img><iframe><link><video><audio>等带有src属性的标签可以从不同的域加载和执行资源。
其他插件的同源策略：flash、java applet、silverlight、googlegears等浏览器加载的第三方插件也有各自的同源策略，只是这些同源策略不属于浏览器原生的同源策略，如果有漏洞则可能被黑客利用，从而留下XSS攻击的后患

1.REST概念

REST全称是Representational State Transfer。要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。

• 资源与URI
• 统一资源接口
• 资源的表述
• 资源的链接
• 状态的转移

2.RESTful API概念

在开发的过程中，我们经常会听到前后端分离这个技术名词，顾名思义，就是前台的开发和后台的开发分离开。这个技术方案的实现就是要借助API，API简单说就是开发人员提供编程接口被其他人调用，他们调用之后会返回数据供其使用。API的类型有多种，但是现在比较主流且实用的就是RESTful API。

RESTful API 的总结：
1.每一个URL代表一种资源
2.客户端和服务器之间，传递这种资源的某种表现层
3.客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。具体为：
GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

2.1 RESTful API方法-GET

• 安全且幂等

• 获取表示

• 变更时获取表示（缓存）

• 200（OK） - 表示已在响应中发出

• 204（无内容） - 资源有空表示

• 301（Moved Permanently） - 资源的URI已被更新

• 303（See Other） - 其他（如，负载均衡）

• 304（not modified）- 资源未更改（缓存）

• 400 （bad request）- 指代坏请求（如，参数错误）

• 404 （not found）- 资源不存在

• 406 （not acceptable）- 服务端不支持所需表示

• 500 （internal server error）- 通用错误响应

• 503 （Service Unavailable）- 服务端当前无法处理请求

1.问题

k8s有自己的一套网络管理机制，集群内的容器和容器之间是可以相互通信的。

但是在容器化升级改造的过程中，不可能一步到位的将所有的服务全部迁移到k8s的容器当中来，毕竟新的技术在没有经过实践趟坑时，肯定不能轻易的全面铺开升级。

那么就涉及到集群外的服务访问集群内的服务，集群内容器中的ip都是k8s管理的IP，dubbo服务注册的也是获取的容器内分配的IP。

比如宿主机ip是10.201.7.xx,容器内的ip就是172.66.4.x。群外的和宿主主机同网段的服务通过拿到dubbo的注册的172.66.4.x也根本没法访问容器内的dubbo服务。

2.分析

k8s是通过Service来暴露集群内的服务，假如dubbo服务注册的是Service暴露的端口和宿主的IP那么集群外的服务就可以直接访问集群内容器中的服务了。

该方案主要有两个难点：

1.如何获取Service暴露的端口和宿主机的IP注入到POD环境变量；

2.Dubbo服务如何从环境变量获取IP和端口注册到ZK；

关于难点1：

通过downward-api的方式向Pod内注入NodeIP的env；

通过给Pod注入env的方式将NodePort注入到Pod内；（要求先创建Service）

关于难点2：

Dubbo在启动阶段提供两对系统属性，用于设置外部通信的IP和端口地址。

DUBBO_IP_TO_REGISTRY — 注册到注册中心的IP地址
DUBBO_PORT_TO_REGISTRY — 注册到注册中心的端口
DUBBO_IP_TO_BIND — 监听IP地址
DUBBO_PORT_TO_BIND — 监听端口

1.docker镜像分析

是否还记得第一个接触Docker的时候，你从Docker Hub下拉的那个镜像呢？在那个处女镜像的基础上，你运行了容器生涯的处女容器。镜像的基石作用已经很明显，在Docker的世界里，可以说是：No Image，No Container。

再进一步思考Docker镜像，大家可能很快就会联想到以下几类镜像：

1.系统级镜像:如Ubuntu镜像，CentOS镜像以及Debian容器等；

2.工具栈镜像:如Golang镜像，Flask镜像，Tomcat镜像等；

3.服务级镜像:如MySQL镜像，MongoDB镜像，RabbitMQ镜像等；

4.应用级镜像:如WordPress镜像，DockerRegistry镜像等。

镜像林林总总，想要运行Docker容器，必须要有Docker镜像；想要有Docker镜像，必须要先下载Docker镜像；既然涉及到下载Docker镜像，自然会存在Docker镜像存储。谈到Docker镜像存储，那我们首先来聊聊Docker镜像大小方面的知识。

以下将从三个角度来分析Docker镜像的大小问题：Dockerfile与镜像、联合文件系统以及镜像共享关系。

Dockerfile与镜像
Dockerfile由多条指令构成，随着深入研究Dockerfile与镜像的关系，很快大家就会发现，Dockerfile中的每一条指令都会对应于Docker镜像中的一层。

继续以如下Dockerfile为例：

1
2
3
4

FROM ubuntu:14.04
ADD run.sh /
VOLUME /data
CMD ["./run.sh"]