monitor | 伪架构师

Kubernetes + Blackbox 实现对 Web 和 DNS 的简单监控

Tue, 19 Sep 2017 23:26:45 +0800

其实都在这里了： https://github.com/prometheus/blackbox_exporter/blob/master/CONFIGURATION.md

Prometheus 带有很多有针对性的 Exporter，能够对 MySQL、Apache 或者 ElasticSearch 等服务器进行监控，另外还有 Blackbox Exporter 用于对 http dns tcp 等零散目标进行简单监控。

DNS 的监控

首先需要运行一个 Blackbox 的 Deployment，并利用 Configmap 来为 Blackbox 提供配置文件：

apiVersion: v1
data:
  config.yml: |
    modules:
      http_2xx:  # http 检测模块
        prober: http
        http:
      http_post_2xx: # http post 模块
        prober: http
        http:
          method: POST
      tcp_connect: # tcp 检测模块
        prober: tcp
      dns:  # dns 检测模块
        prober: dns
        dns:
          transport_protocol: "tcp"
          preferred_ip_protocol: "ip4"
          query_name: "kubernetes.default.svc.cloud.ctrm"  # 利用这个域名来检查 dns 服务器
          query_type: "A"  # 如果是 kube-dns ，一定要加入这个
kind: ConfigMap
metadata:
  name: blackbox
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: blackbox
spec:
  template:
    metadata:
      labels:
        name: blackbox
    spec:
      containers:
      - image: prom/blackbox-exporter:v0.8.1
        name: blackbox
        ports:
        - containerPort: 9115
        volumeMounts:
        - name: config
          mountPath: /etc/blackbox_exporter
        args:
        - --config.file=/etc/blackbox_exporter/config.yml # Configmap 中的配置文件
        - --log.level=error  # 错误级别控制
      volumes:
      - name: config
        configMap:
          name: blackbox
---
apiVersion: v1
kind: Service
metadata:
  name: blackbox
spec:
  selector:
    name: blackbox
  ports:
  - port: 80
    targetPort: 9115

使用 kubectl apply 命令运行起来。

接下来需要在 Prometheus 的配置文件中加入对 BlackBox 的抓取设置：

- job_name: "kubernetes-service-dns"
  metrics_path: /probe # 不是 metrics，是 probe
  params:
    module: [dns] # DNS 模块
  static_configs:
  - targets:
    - kube-dns:53 # 不要省略端口号
  relabel_configs:
  - source_labels: [__address__]
    target_label: __param_target
  - source_labels: [__param_target]
    target_label: instance
  - target_label: __address__
    replacement: blackbox # 服务地址，和上面的 Service 定义保持一致

重启 Prometheus，或者利用 curl Post 更新配置。打开 Prometheus 的 Target 页面，就会看到上面定义的 kubernetes-service-dns 任务了，回到 Graph 页面，可以使用 probe_success{job="kubernetes-service-dns"} 来查看检测历史结果。

HTTP 监控

上面的配置文件中提到有一个 http_2xx 的模块，这里我们可以使用他对 http 服务进行检测。

这里主要是对不受我们控制的外部服务的快速检测。内部的方法就丰富多了。

因为前面已经给 Blackbox 配置了 http_2xx 模块，所以这里只需要在 Prometheus 中加入抓取任务：

- job_name: "business-service-liveness"
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
  - targets:
    - http://192.168.51.129:30001 # 要检查的网址
    - http://192.168.51.129:30004
    - http://192.168.51.129:30003
  relabel_configs:
  - source_labels: [__address__]
    target_label: __param_target
  - source_labels: [__param_target]
    target_label: instance
  - target_label: __address__
    replacement: blackbox-exporter:9115

同样的，重新载入之后，可以使用 probe_success 和 probe_duration_seconds 等来检查历史结果。

自带 metrics 端点的服务

有的服务，例如 prometheus 或者 blackbox，以及 kube-dns、etcd 等，都是自有 /metrics 提供指标输出的，这种服务对 Blackbox + Prometheus 组合是非常方便的。

只要给服务的注解部分加入几个标签：

prometheus.io/host: calico-etcd # 服务名称
prometheus.io/port: "6666" # metrics 端口
prometheus.io/scrape: "true" # 抓取开关

上面是 calico 的 etcd 服务加入的注解，服务中有了上述注解之后，Prometheus 的示例配置中，已经有了针对这一配置的监控方法，直接刷新 Target 页面，就会看到新的监控目标，可以进行使用了。而无需为每个服务分别定制 Target。

https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml

Monitor as Code 的一点尝试

Tue, 23 May 2017 02:53:05 +0800

这篇的真实名字应该是：Grafana 也是有 API 的

在项目的 CI/CD 实践过程中，XX as code 是一个很重要的方法，利用代码的方式，对软件的构建、发布、测试等环节进行表达，一方面极大的提高了自动化程度；另一方面，将这些代码纳入版本管理范围，使其同软件代码同步更新和迭代，更好的体现了系统的整体性，提高了系统的可维护性。

前面的文章中我也多次提到了监控的内容，业务和系统的运行状况可视化是系统运行的重要支撑。甚至监控本身就应该是软件的一部分。得益于各种开源软件的支持，我们可以做一番 Monitor as Code 的尝试。

监控过程本身一般由数据的产生和展示两个部分组成，对于系统数据，例如 Kubernetes 或者主机数据，我们可以使用 Zabbix、Heapster 或者 cAdvisor 以及 Prometheus 进行获取；而业务的数据则需要借助业务应用自身的代码或者数据库来转换为指标数据，注入到 InfluxDB 等时间序列数据库中。本文中暂不介绍数据生成部分的内容。

最终我们继续选择 Grafana 进行数据的展示。这是这一篇里面唯一有用的内容了。

实际操作中，本文过程都应该在 Jenkins Pipeline 中，从版本库拉取代码完成，为叙述方便，使用 Shell 脚本代替。

步骤说明

代码准备
Grafana 准备
创建、更新 Grafana Dashboard

代码准备

代码目录结构大致如下：

codebase
build
- docker
ops
- monitor
- view

code base

一般用于存放业务代码。

build

该目录用于存放构建代码，例如

Jenkins Pipeline code
构建过程中的支持脚本
Dockerfile
Kubernetes yaml

ops

这里用于放置运维相关的一些内容，本文将要使用的代码也在此存放。

实际上，这里除了 Grafana 的内容之外，还可以包含一些其他代码例如

Prometheus Exporter
Zabbix User Script
…

Grafana 准备

首先在 Grafana 的管理菜单中创建一个权限为 Editor 的 API Token：

注意这里生成的 Key 只显示一次

创建或者更新 Grafana Dashboard

生成了 API Token 之后的事情就很简单了，准备一个 Grafana 的 JSON 文件，用 CURL 进行 POST 即可

POST /api/dashboards/db HTTP/1.1
Accept: application/json
Content-Type: application/json
Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk

{
  "dashboard": {
    "id": null,
    "title": "Production Overview",
    "tags": [ "templated" ],
    "timezone": "browser",
    "rows": [
      {
      }
    ],
    "schemaVersion": 6,
    "version": 0
  },
  "overwrite": false
}

“id” 部分为 NULL 代表新建 Dahsboard。如果是从 Grafana 导出的内容，则沿用旧有取值进行更新即可。

可以利用模板+变量的方式来使用 Dashboard 导出文件，用于适应不同环境的部署下，不同的数据源名称，不同的细节调整。

为 Gitlab 和 Jenkins 添加 InfluxDB 支持

Sun, 26 Feb 2017 09:59:19 +0800

概述

量化和监控对现在的开发运维工作的重要性是毋庸置疑的。在大肆鼓吹 DevOps 的今天，一体化的数据采集和可视化展示就尤为重要了。

为了能在同一视图下对 Jenkins 和 Gitlab 的操作进行监控，本来写了一些数据采集的脚本，后发现这两个系统都有实现向 InfluxDB 发送指标数据的能力，虽说结构和数据的细致程度可能不及定制脚本，但懒人方案始终是更快的解决办法。

非常对不起各位的是，下面的内容主要是堆代码了。

环境准备

Docker

为方便部署，这里采用 Docker 作为执行环境，过程中需要下载一些镜像，所以这里可能要配置代理或者其他途径来获得镜像文件并导入。

这里假设宿主机 IP 为 10.211.55.5

网络

因为几个组件之间互相需要访问，因此我们首先用如下命令创建一个虚拟网络：

docker network create devops

InfluxDB

启动

首先启动我们的 InfluxDB，因为 GitLab 只能连接 InfluxDB 的 udp 端口，而官方版本的镜像并未提供这一功能的方便设置，所以这里采用了一个第三方镜像。

这也是 DockerHub 上的常态 —— 嫡出被庶出灭了。

#!/bin/sh
docker run -d --name=influxdb \
--restart=always \
--network=devops \
-v /var/volume/influxdb:/data \
-p 20002:8083 \
-p 20003:8086 \
-p 20004:8089/udp \
-e UDP_PORT=8089 \
-e UDP_DB=gitlab \
appcelerator/influxdb

稍微做一下解释：

使用了上文创建的虚拟网络
镜像为 appcelerator/influxdb
宿主机上的 /var/volume/influxdb 目录被加载到容器的 /data 目录，用于数据存储的持久化。
开放了三个端口：
- 8083：管理界面，可用浏览器访问
- 8086：HTTP API
- 8089：UDP 端口
UDP 端口对应的数据库名为 gitlab

初始化

镜像成功启动之后，就可以使用浏览器打开 http://10.211.55.5:20002，用户名密码缺省为 admin，主机和端口分别为 10.211.55.5 和 20003，这些填写结束后，就可以对 influxdb 进行管理了。

分别为 gitlab 和 jenkins 创建数据库：

CREATE DATABASE "gitlab"
CREATE DATABASE "jenkins"

Gitlab

启动

类似的，我们用如下脚本启动 Gitlab：

#!/bin/sh
docker run -d --name=gitlab \
--restart=always \
--network=devops \
-v /var/volume/gitlab/data:/var/opt/gitlab \
-v /var/volume/gitlab/conf:/etc/gitlab \
-v /var/volume/gitlab/log:/var/log/gitlab \
-p 21001:80 \
gitlab/gitlab-ce

跟前面的 InfluxDB 类似，或者说更加简单，连环境变量也不需要了。映射端口为 21001，加入同一个网络。

配置

浏览器登录页面之后，进入 URL： http://10.211.55.5:21001/admin/application_settings，对 Gitlab 进行设置。

在 Metrics 一节，会看到 InfluxDB 的配置信息，选中 Enable 之后，只需要填写主机和 UDP 端口即可，因为有虚拟网络的配置，这里主机我们直接填写 influxdb，端口就是 8089 了。

变更配置后，利用 docker kill/rm 命令停止 gitlab，并重新启动。

验证

接下来我们可以选择一个项目进行 commit/push 操作，然后进入前面提到的 InfluxDB 控制台。页面右上角的数据库选择 gitlab，在查询输入框中输入 SHOW MEASUREMENTS 并执行，会看到 gitlab 在这一数据库中建立了各个数据表。

继续输入 select * from events，会看到我们刚刚进行的提交记录。

Jenkins

启动

这里用了我自己的 Jenkins 镜像，完成的还是映射端口、挂接存储的任务。

#!/bin/sh
docker run -d --name=jenkins \
--restart=always \
--network=devops \
-v /var/volume/jenkins/data:/data/jenkins \
-v /var/volume/jenkins/maven:/data/maven \
-v /var/volume/jenkins/sonar:/data/sonar \
-v /var/volume/jenkins/kube:/data/kube \
-v /var/volume/jenkins/robot:/data/robot \
-p 21003:8080 \
dustise/jenkins

配置

启动之后访问http://10.211.55.5:21003，对 Jenkins 进行配置。

http://10.211.55.5:21003/pluginManager/available 在这一界面查找 InfluxDB 插件，进行安装启用。

InfluxDB 插件启用之后，就可以在 http://10.211.55.5:21003/configure 找到其配置内容，这里也就是设置一个 InfluxDB 连接到我们之前启动的数据库。

点击 New InfluxDB Target 按钮，在弹出的输入项目中，URL 填写为 http://influxdb:8086，用户名密码同上，数据库为 jenkins。

retentionPolicy 一项可以清空。

exposeExceptions 这一项目表示，向 InfluxDB 汇报数据的任务如果失败，是否标记所属 Build 过程为失败。

验证

首先我们创建一个新的 FreeStyle 项目，内容很简单，执行一个 echo "Hello world"。

在构建后步骤中，可以看到 Post Build Actions 新增了 Publish build data to InfluDB的动作。

添加这一动作之后，选择我们刚才建立的 InfluxDB Target。

Job 创建完成，就可以开始 Build 了。

Build 成功之后，我们可以在 InfluxDB 控制台上，切换到 Jenkins 数据库，执行 SHOW MEASUREMENTS，可以看到 Jenkins 创建的数据表。运行 SELECT * FROM jenkins_data 进行查询，就会看到我们刚才的 Build 数据。

Robot 等插件也会将结果插入 InfluxDB

展示

有了这些数据，我们就可以以项目为单位，利用 Grafana 或者其他可视化工具，对结果进行叠加和展示了。

监控随想，业务和迭代

Thu, 15 Dec 2016 00:56:05 +0800

其实我不知道我在说啥*

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

< Microservices > By Matin fowler

如 Matin 大爷所言，微服务的两个重要特征：面向业务和自动化。随着微服务架构的普及和深入，每一个线上业务都是由为数众多的独立运行的微服务协作完成的。加之容器、云计算等技术的引进使用，自动化工具链也加入战团，这一切情况的叠加，使得一个具体业务的整个生命周期所涉及的 IT 资产数量不断膨胀，并且微服务化带来的快速变更，原有的按照网域、按照应用类型等监控 Screen 的定义方式越来越难跟上业务需求，运维监控这一分支的技术工作成为背锅侠的风险越来越大。

目前见过的几个的监控方式，有几个共同点：

自发：有啥用啥，基于监控软件系统所提供的指标，结合个人经验，形成的主机和监控指标列表，以及建筑其上的 Graph、Screen 等。
独立：基础设施和构建其上的业务系统之间呈割裂状态，监控方面各行其是，甚至是业务和基础设施分别由不同的系统进行监控。忽略了底层到上层的实际联系。
断层：和开发团队不同，现有的很多监控技术的实现，并没有明确的知识管理、版本控制等技术传承手段，一定程度上影响了监控方面整体能力的成长。

对于一个长期存在并演进的项目来说，开发和监控都是这一产品生命周期的必要组成部分，换个角度来看监控，和很多业务系统一样，都是基于一个较大的基础系统之上进行配置和开发。如果从软件开发的方法来看待监控的话，这些问题似乎就不难解决了。

监控系统应该有明确的需求

监控事实上应该作为系统的功能性需求的常备部分，其中需要明确列出需要完成的业务指标和技术指标监控能力，对于不同类型的主机、集群和业务，应该有标准化的指标、图形和 Screen 组合（pattern/template）。

为增强易用性，还应该对监控图形展示、指标组合关系以及递进关系，做出适合展示和系统排错的设计。

例如一个短信系统，其短信队列的长度就是一个关键的业务指标，如果发送队列的长度持续增长，代表业务积压，对应的外部调用量、数据库压力、容器数量、南向接口响应时间等相关指标如果能够同屏呈现，无疑会同时给运营和运维极大助力。

监控系统也有架构

一般来说对于系统的监控是比较直接的，通常都有比较成熟的解决方法：

监控系统自带的指标和模板
软件厂商、开源社区等第三方指标和模板
SNMP 等第三方通用协议的接入

而对于业务的监控就个性得多，也复杂得多了。对业务量的度量经常会使用到侵入式的检测方法，比如直接访问业务数据库，会遇到很多软件开发部署过程中的类似问题：

网络连通性：比如到数据库主机的连通性、到监控 Server、Proxy 的连通性等
系统负载：对监控服务器、数据库、日志等的使用所造成的系统压力
环境依赖：例如 Python 版本和模块、某些 Shell 命令
数据管理：数据的采集频率、转换、存储以及清理

如上所述，一个成熟的对系统的监控工作，其涉猎范围并不小于业务系统本身，不难理解，如此范围的功能叠加，没有适当的设计和实现过程，失控是可以预见的必然趋势，最终结果就是起不到应有的预警和复盘的能力，甚至对业务系统的运行造成干扰。

监控系统的代码管理

这里的代码二字，除了监控中使用的 SQL 和各种语言的脚本之外，还应该有针对监控平台的一些能够代码化的配置内容。

软件开发过程中常用到的分支、合并、Tag 等开发代码管理、甚至配置管理的技巧在这里同样适用。

监控系统的持续改进

上文提到种种，无非是为了说明，监控具有完整的生命周期，对业务系统的重要性自然也是不言而喻；运作健康良好的监控系统，需要有持续的智力投入，和其他业务功能一样，监控系统也是有具体的持续优化和演进的需要。

这里可以参考软件开发中的敏捷方法，来建立初步的监控开发内容。

主动的监控

总而言之，成熟的业务项目需要成熟的监控系统，作为项目中的重要技术组成部分，监控系统同样需要与时俱进、谋定后动。主动跟进架构演进，主动发现问题，业务视角会是监控工作的几个潜在的重要目标。

而随着监控系统的持续改进，数据关系的深入挖掘，监控系统将有助于系统故障的早期发现和预警，事后的复盘和故障的排除，业务的整体展现都会产生极大的帮助。