项目经验

项目经验

要点

1. Kubernetes

   生产应用
2. 云主机弹性伸缩
3. 日志收集平台

   ELK

4. 监控平台 从

   zabbix

   到

   prometheus

5. 代码发布平台

   Jenkins

6. 堡垒机

   jumpserver

7. 打点服务应用

   prometheus

<a id = "ks">

Kubernetes

生产应用 </a>

关键点 :

• 服务弹性伸缩,

  deployment

  利用

  Horizontal Pod Autoscaling

  实现对

  pod

  的弹性伸缩
• 对内对外提供服务, 利用

  ingress

  和

  service

  实现
• 权限管理, 利用

  namespace

  和

  rdac

  实现

• helm

  软件包管理工具

• node

  节点的弹性伸缩, 利用对云主机的弹性伸缩实现

监控

• kube-prometheus

日志收集

节点上运行一个

agent

来收集日志,但

DaemonSet

模式下

• 阿里云日志服务

• FELK

pod

中包含一个

sidecar

容器来收集应用日志

• 在每个

  pod

  中添加一个

  fluentd

  或

  filebeat

  容器收集日志传输到外部

  ELK

  中

直接在应用程序中将日志信息推送到采集后端

代码发布

• jenkins shell

  （目前比较low）
• 可用

  drone

  或

  jenkins-pipeline

  。
• 自己写一个。已经有大概思路。

<a id = "ecs"> 云主机弹性伸缩。</a>

对主机的弹性伸缩服务，这个是云服务商提供的服务。\
弹性伸缩主要是根据设置的伸缩规则，在业务需求增长时自动为您增加

ECS

实例以保证计算能力，在业务需求下降时自动减少

ECS

实例以节约成本。\
产品主要通过在

SLB

后面挂载

ECS

。实现对cpu或内存使用率的监控，当内存或cpu超过一定的阈值，利用之前定义的伸缩策略，利用之前制作好到镜像进行伸缩

ECS

。\
带来下面问题

问题

新发布代码无法在老镜像中。如果弹性伸缩的话，新增的

ECS

中的代码就和线上代码不一致了。

解决

个人觉得比

low

，这样也使发布比较重。但在

Kubernetes

中就不存在这样的问题了。

在发布代码后，调用云服务商的

API

，给新

ECS

打镜像、修改项目的弹性伸缩策略、把新镜像id替换老镜像id。

<a id = "elk"> 日志收集 </a>

elk+kafka

• a.

  filebeat

  收集

  nginx

  的日志并把日志发给

  logstash

• b.

  logstash

  对日志进行字段拆分并写到

  elasticicsearch

  。如果利用到

  kafka

  ，就在写到

  elasticicsearch

  之前，先写到

  kafka

  ，之后

  elasticicsearch

  从

  kafka

  中获取数据。
• c. 利用

  kibana

  进行展示。
• d. 在

  kibana

  根据不同的业务，提前配置好对

  request_time

  、

  upstream_time

  、

  status_code

  等等的

  dashboard

  , 方便定位问题。
• e. 告警： 写好脚本，定期检查不同业务的

  request_time

  、

  upstream_time

  、

  status
  b60
  _code

  。如果超时或

  status_code

  为

  5XX

  就钉钉告警

程序部分日志收集和告警

要求：

网关

nginx

服务产生

request_id

,这个请求后面的一系列请求都带上这个

request_id

写日志.
目地
方便定位问题。

当

nginx

中出现

5xx

等错误时，根据这个请求的

request_id

，可以找到程序中对应的一系列请求，从而快速定位具体问题在哪里。
资源：
考虑到资源问题，目前仅仅收集

warn

/

error

/

fatal

三个等级的程序日志，导入到

elk

中。根据

request_id

快速定位程序问题。

告警：

定时任务，统计最近1分钟，如果某个项目出现10个

error

或者出现过

fatal

就告警。
每天统计项目出现的

warn

次数。发邮件。
项目

warn

较多的（

500

条

warn

），额外会钉钉发告警，让开发处理一下

<a id = "prometheus"> 监控 </a>

从

mysql+zabbix+grafana+微信/钉钉

prometheus+grafana+alertmanager + 钉钉

主要监控点

• cpu

  使用率
• 内存使用量/使用率
• 服务器负载
• 磁盘容量/

  io

• 网络流量

• tcp

  连接数
• 来源

  IP

  连接数
• 访问

  IP

  连接数

对服务的监控：''

• redis

  :

  cpu

  ，内存使用量、

  hit

  、

  miss

  、

  get

  、

  set

  、

  ops

  ...

• elasticsearch

  :

  cpu

  、

  jvm

  、内存、

  gc

  、

  indics

  、健康状态、

  ops

  ...

• mongodb

  :

  cpu

  、

  mem

  、

  ops

  ...

之所以迁移到

prometheus

1. prometheus

   对资源的要求非常低。就一个二进制问题，运行起来就可以了。
2. 当

   zabbix

   监控超过100台服务器之后，查看监控的时候就明显慢了。

3. prometheus

   添加告警更加清晰方便。

<a id = "jenkins">

jenkins

代码发布 </a>

对开发要求：

规定所有开发，所有编译过程，都写一个 `makefile` 。我这边仅仅需要 `make
49d2
build` 即可

大致流程：

1. 先从

   git

   仓库获取根据对应的

   tag

   或

   branch

   获取代码。
2. 利用

   jenkins

   的

   shell

   功能，进行

   make build

3. 获取

   build

   后的代码，

   rsync

   到服务器。
4. 重启

   supervisor

   服务。
5. 健康检查；

   sleep 3s

   ，查看端口和进程是否正常。同时请求健康检查接口，查看服务是否正常。
6. 到这里这个发布完成。但同时会触发下面步骤。后台运行。

   利用

   api

   对新发布的项目中的某一个

   ecs

   进行打镜像. 一般10分钟左右
   • 修改弹性伸缩策略的的镜像

     ID

     为a步骤产生的镜像

     ID

     。
   • 发钉钉和邮件提醒。主要包括项目名称、修改前后的镜像名称。

<a id = "jumpserver"> 堡垒机

jumpserver

</a>

目的：

• 目前还没有把所有的程序日志收集，偶尔开发到服务器查看相应的debug日志。
• 开发需要到服务器，就带来权限管理问题了。用它主要就是为了解决这个问题。

优点：

• 不同的开发，给不同的访问服务器的权限
• 资源统一管理。
• 操作审计等等

  <a id = "point"> 打点服务，定位资源使用情况 </a>

  prometheus+pushgateway+grafana+alertmanager+钉钉

  目的

  经常会遇到如下问题， 某个服务、资源的

  cpu

  或者内存飙高。为了清楚了解。这些资源为飙高，是什么服务导致，我们就加入了打点服务。

  方案：

• 程序在调用其依赖的资源时，往时序数据库打一个点。

• prometheus

  作为时序数据库。

• pushgateway

  作为

  prometheus

  时序数据库的网关。

• grafana

  做展示

• alertmanager

  + 钉钉，实现告警

作者: lvnian