最近组里又来了一个需求：当告警发生时，将告警信息通过企业微信发送给开发的相关负责人，方便尽快排除故障。实际使用Alertmanager来完成这项工作，下面介绍具体的实现方法。详细配置告警通道配置监控最重要的是在故障发生时，能将告警信息发送出来，让正确的人第一时间获悉故障的详情，只有这样才能尽快排除故障。企业微信很多公司都有使用，而且Alertmanager支持将企业微信作为告警通道。按照企业微信的官方文档来配置告警通道，如果觉得麻烦，可以在浏览器上搜索“alertmanager企业微信”关键字，就有很多配置例子展示。我们需要得到下面五个键值对：wechat_api_url:'https://q

公司项目是用consul进行注册的，在发布微服务的时候，总是会导致调用方出现一定几率的调用失败。一开始百思不得其解，后来咨询了资深的同事才知道：原来是服务下线的时候没有优雅停机，没有去consul将自己下线再停机，导致调用方拿到了旧的调用地址，导致调用失败！ 看来优雅停机还是一个蛮重要的知识点，可不能忽略，今天就让我们来盘盘它吧！一、什么是优雅停机？在Linux世界里，一切都是资源。当我们启动一个JVM的时候，我们就加载了许多的资源。而当我们关闭JVM的时候，JVM只会释放内存这个资源，而其他资源是不会释放的，例如：网络连接、文件句柄等等。Linux的网络连接数、文件句柄数都是有限的，如果我们

今天给大家分享Centos8操作系统下如何安装supervisor进程管理程序并守护Nginx进程，希望对大家能有所帮助！一、supervisor介绍1、简介Supervisor是基于Python语言开发的一套的进程管理程序，它可以将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时支持自动重启。2、工作原理它主要是通过fork/exec的方式把这些被管理的进程当作supervisor的子进程来启动，这样只要在supervisor的配置文件中，把要管理的进程的可执行文件的路径写进去即可。也实现当子进程挂掉的时候，父进程可以准确获取子进程挂掉的信息的，可以选择是否自己启动和预警

作者简介本文作者佐思、烧鱼、Shirley博，来自于携程CloudContainer团队，主要从事ServiceMesh在携程的落地，负责控制面的可用性及优化建设，以及推进各类基础设施服务的云原生化。该团队负责K8s容器平台的研发和优化工作，专注于推动基础设施云原生架构升级，以及创新产品的研发和落地。一、背景为了支撑业务的高速发展，从17年开始，携程内部逐步推进应用容器化改造与业务上云工作，同期携程技术架构经历了从集中式单体应用到分布式微服务化的演进过程。随着Kubernetes的不断发展和推广，服务网格（ServiceMesh）在近几年也变得很流行。而ServiveMesh之所以越来越受欢迎

在快速迭代的互联网背景下，系统为了实现快速上线，常常会选择最快的开发模式，例如我们常见的mvp版本迭代。大部分的业务系统对于未来业务的发展是不确定的，因此随着时间的推移，往往会遇到各种各样的瓶颈，例如系统性能、无法适配业务逻辑等问题，这时可能就涉及到系统架构的升级。系统升级往往包含最基础的两个部分：接口迁移重构和数据迁移重构，在系统架构升级的过程中，最重要的是需要保证系统稳定性，即用户不感知。因此文本的目的是提供一种可灰度、回滚的设计思路，实现稳定的架构升级。场景在我们系统迭代过程中，往往涉及到重构、数据源切换、接口迁移等场景，为了保障系统平稳上线，因此在接口迁移过程中应该保证可回滚、可灰度。

系统异常了，​​上篇​​是通过在全局异常中通过调用发送邮件的处理器代码进行邮件的发送，总是觉得还不那么优雅。这篇是通过扩展logback的日志插件来处理err级别的日志异常信息来发送邮件的。通过这篇的学习，可以掌握如何扩展logback的日志类，来实现自己不可告人的目的。下面直接上代码。首先自定义一个日志处理处理类  wlcLogLogbackAppender。importch.qos.logback.classic.spi.LoggingEvent;importch.qos.logback.classic.spi.ThrowableProxy;importch.qos.logback.cor

描述在我们的项目中，总是有一些我们不可控制的异常，比如数据库连接不上，redis挂掉，以及一些代码上未可知的异常爆发，不能在项目上线时就可以统计出来，并且修复，所以当我们这些bug抛出异常时，或者在某些可控的严重异常需要推送邮件或者短信或者其他的通讯工具比如钉钉或者飞书等，我们就需要这样的功能，这里提供一个邮件通知方法，当有未知异常或者被定义为严重异常的，就会给运维人员发送一个邮件进行通知，方便计时应对和问题定位。解决方案在springboot中的全局异常捕获处，对不可控异常拿到异常栈信息，进行异常msg的组装和通过freemarker模板进行渲染html文本，然后再把这个异常msg的html

我们知道Prometheus采用的pull模式，但是某些网络场景下面（比如不在一个子网或者防火墙），Prometheus无法直接拉取监控指标数据，这个时候我们可能就需要一种能够主动push的模式了。而 Pushgateway 就是Prometheus生态中来解决这个问题的一个工具。但是Pushgateway也不是万能的，其本身也存在一些弊端：将多个节点数据汇总到pushgateway,如果pushgateway挂了，受影响范围更大Prometheus拉取状态up只针对pushgateway,无法做到对每个目标有效由于Pushgateway可以持久化推送给它的所有监控数据，所以即使你的监控已经下

事故描述老规矩，我们先看下事故过程：某日，从6点32分开始少量用户访问app时会出现首页访问异常，到7点20分首页服务大规模不可用，7点36分问题解决。整体经过事故的整个经过如下：6：58，发现报警，同时发现群里反馈首页出现网络繁忙，考虑到前几日晚上门店列表服务上线发布过，所以考虑回滚代码紧急处理问题。7：07，开始先后联系XXX查看解决问题。7：36，代码回滚完，服务恢复正常。事故根本原因事故代码模拟如下：publicstaticvoidtest()throwsInterruptedException,ExecutionException{Executorexecutor=Executors

​问题：慢查询搜索平台的公共集群，由于业务众多，对业务的es查询语法缺少约束，导致问题频发。业务可能写了一个巨大的查询直接把集群打挂掉，但是我们平台人力投入有限，也不可能一条条去审核业务的es查询语法，只能通过后置的手段去保证整个集群的稳定性，通过slowlog分析等，下图中cpu已经100%了。​昨天刚好手头有一点点时间，就想着能不能针对这些情况，把影响最坏的业务抓出来，进行一些改善，于是昨天花了2小时分析了一下，找到了一些共性的问题，可以通过平台来很好的改善这些情况。首先通过slowlog抓到一些耗时比较长的查询，例如下面这个索引的查询耗时基本都在300ms以上：{"from":0,"si