Prometheus 可以使用$value变量将当前告警规则表达式的数值输出到告警信息里。但是有些浮点数值位数相当长,非常不便于阅读,对于强迫症患者来说更是不可接受的。

如何让告警数值变得“人类可读”呢?

阅读全文 »

哨兵的介绍

sentinel,中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件,主要有以下功能:

  • 集群监控:负责监控 redis master 和 slave 进程是否正常工作。
  • 消息通知:如果某个 redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员。
  • 故障转移:如果 master node 挂掉了,会自动转移到 slave node 上。
  • 配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用,本身也是分布式的,作为一个哨兵集群去运行,互相协同工作。

  • 故障转移时,判断一个 master node 是否宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举的问题。
  • 即使部分哨兵节点挂掉了,哨兵集群还是能正常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的,那就很坑爹了。
阅读全文 »

innodb_flush_log_at_trx_commitsync_binlog 两个参数是控制MySQL 磁盘写入策略以及数据安全性的关键参数。本文从参数含义,性能,安全角度阐述两个参数为不同的值时对db 性能,数据的影响.

阅读全文 »

前言

Web 服务器中,高可用 是指服务器可以 正常访问 的时间,衡量的标准是在 多长时间 内可以提供正常服务(99.9%99.99%99.999% 等等)。在 Redis 层面,高可用 的含义要宽泛一些,除了保证提供 正常服务(如 主从分离快速容灾技术 等),还需要考虑 数据容量扩展数据安全 等等。

Redis 中,实现 高可用 的技术主要包括 持久化复制哨兵集群,下面简单说明它们的作用,以及解决了什么样的问题:

  • 持久化:持久化是 最简单的 高可用方法。它的主要作用是 数据备份,即将数据存储在 硬盘,保证数据不会因进程退出而丢失。
  • 主从复制:复制是高可用 Redis 的基础,哨兵集群 都是在 复制基础 上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。
  • 哨兵:在复制的基础上,哨兵实现了 自动化故障恢复。缺陷是 写操作 无法 负载均衡存储能力 受到 单机 的限制。
  • 集群:通过集群,Redis 解决了 写操作 无法 负载均衡 以及 存储能力 受到 单机限制 的问题,实现了较为 完善高可用方案
阅读全文 »

安装

1
2
3
4
5
6
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum install cobbler cobbler-web python-pip httpd pykickstart cman xinetd dhcp -y
pip install --upgrade pip -i https://pypi.tuna.tsinghua.edu.cn/simple requests
pip install Django==1.8.9 -i https://pypi.tuna.tsinghua.edu.cn/simple requests
yum clean all
阅读全文 »

1、删除无用容器时报错

1
2
3
[root@node3 ~]# docker rm ms-product.20190517
ms-product.20190517
Error response from daemon: container c4739fbec54da9ce6e18a14dc90a0f97da0d62a48df6f54c1e9ee94253e71ce8: driver "overlay" failed to remove root filesystem: remove /data/docker/overlay/abb6dcd4eebf472581036d0970829e9f1cecfcaa53b942a4ba29b8da143d9ac9/merged: device or resource busy
阅读全文 »

日志系统

在系统发生故障时,工程师需要登录到服务器上,使用 grep / sed / awk 等 Linux 工具通过关键字去日志里查找我们想要的信息。在一个较大的分布式系统中,至少需要查找几个甚至几十个服务的日志,且这些服务很有可能还是分布在不同的服务器上,另外每个服务还会设置日志滚动策略(如:每天生成一个文件),还有日志压缩归档策略等。一整个排错的流程下来,不仅效率低下,而且容易错过关键的日志信息。所以,如果我们能把这些日志集中管理,并提供集中检索功能,不仅能提高排错的效率,同时还能实时获取整个业务系统的健康状态。

一个日志系统,一般需要具备以下几个特点:

  • 数据收集-能够采集多种来源的日志数据
  • 数据传输-能够稳定的把日志数据传输到中央系统
  • 数据存储-如何存储日志数据
  • 数据分析-提供UI界面,检索日志信息,定位相应的 bug
  • 服务诊断:通过对日志信息进行统计、分析,了解服务运行状态
  • 异常警告-能够提供错误报告,监控机制
阅读全文 »

1. PG介绍

继上次分享的《Ceph介绍及原理架构分享》,这次主要来分享Ceph中的PG各种状态详解,PG是最复杂和难于理解的概念之一,PG的复杂如下:

  • 在架构层次上,PG位于RADOS层的中间。
    a. 往上负责接收和处理来自客户端的请求。
    b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。
  • 是组成存储池的基本单位,存储池中的很多特性,都是直接依托于PG实现的。
  • 面向容灾域的备份策略使得一般而言的PG需要执行跨节点的分布式写,因此数据在不同节点之间的同步、恢复时的数据修复也都是依赖PG完成。
阅读全文 »