微服务治理之异常日志告警

线上服务出现异常如何及时感知,每天不定时观察线上日志还是等用户反馈错误?

🤔…

这个问题应该有更好的答案…

试试Alertmanager

既然人工监测不是很合适,那就安排一个机器人吧!

怎么做?从日志收集logstash开始,到Alertmanager进行告警信息分组、抑制、静默,再到企业微信群聊机器人@具体的服务owner。

从日志收集开始

图片

因为我们所有服务日志已经是由logstash统一收集了,所以这一步就比较简单了。在logstash输出时添加一个管道,把异常日志往Alertmanager输出一份,配置如下:

output {
  # elasticsearch
  ...
  # 添加异常日志输出
if 'ERROR' == [level] or 'WARN' == [level] {
		http {
      http_method => "post"
      format => "json_batch"
      url => "http://alertmanager/api/v1/alerts"
      mapping => {
        "labels" => {
            "app" => "%{springAppName}"
            "env" => "%{springProfilesActive}"
            "level" =>  "%{level}"
            "logger_name" => "%{logger_name}"
            "traceId" => "%{traceId}"
        }
        "annotations" => {
            "time" => "%{@timestamp}"
            "message" =>  "%{message}"
            "stack_trace" => "%{stack_trace}"
         }
      }
    }
  }
}

根据 alertmanager 的 api 配置好消息的格式,设置app、env、level等字段为标签,方便后续根据标签分组、静默。

日志告警规则管理

为什么要加一个Alertmanager而不是直接让logstash把异常日志发出去?

并不是logstash做不到,而是当logstash直接把异常发出去之后就会发现:

  • 突然收到一堆告警,一模一样的消息发这么多,吓死我了

  • 这个干嘛发给我,是下游服务出问题了已经发给他了还给我发

  • 这个异常无关痛痒,不用再看了,别发了

  • 再发,不看了

先部署Alertmanager

apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: ops
data:
  config.yml: |-
    global:
      # 在没有报警的情况下声明为已解决的时间
      resolve_timeout: 30m
      # 配置邮件发送信息
      smtp_smarthost: 'smtp.example.com:25'
      smtp_from: 'alertmanager@example.com'
      smtp_auth_username: 'alertmanager@example.com'
      smtp_auth_password: '1234'
    # 所有报警信息进入后的根路由,用来设置报警的分发策略
    route:
      # 这里的标签列表是接收到报警信息后的重新分组标签,例如,接收到的报警信息里面有许多具有 app=order、env=pre、level=warn 这样的标签的报警信息将会批量被聚合到一个分组里面
      group_by: ['app', 'env','level']
      # 当一个新的报警分组被创建后,需要等待至少group_wait时间来初始化通知,这种方式可以确保您能有足够的时间为同一分组来获取多个警报,然后一起触发这个报警信息。
      group_wait: 30s

      # 当第一个报警发送后,等待'group_interval'时间来发送新的一组报警信息。
      group_interval: 5m

      # 如果一个报警信息已经发送成功了,等待'repeat_interval'时间来重新发送他们
      repeat_interval: 3h

      # 默认的receiver:如果一个报警没有被一个route匹配,则发送给默认的接收器
      receiver: rocket

      # 上面所有的属性都由所有子路由继承,并且可以在每个子路由上进行覆盖。
      routes:
      - receiver: wecom-robot-rocket
        match:
          app: mall-order
    receivers:
    - name: 'email-rocket'
      email_configs:
      - to: 'rocket@example.com'
        send_resolved: true
    - name: 'wecom-robot-rocket'
      webhook_configs:
      - url: 'http://localhost:8080/api/webhook/send?key=yourWeComRobotKey&mentions=userId,all'
    - name: 'wecom-rocket'
      wechat_configs:
      - corp_id: 'corp_id'
        to_user: 'userId'
        agent_id: 10001
        api_secret: 'secret'
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: alert-pv-volume
  namespace: ops
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data/alert"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager
  namespace: ops
  labels:
    app: alertmanager
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alertmanager
  template:
    metadata:
      labels:
        app: alertmanager
    spec:
      containers:
        - name: alertmanager
          image: prom/alertmanager:v0.24.0
          imagePullPolicy: IfNotPresent    
          args:
          - "--config.file=/etc/alertmanager/config.yml"
          ports:
          - containerPort: 9093
            name: http    
          volumeMounts:
          - mountPath: "/etc/alertmanager"
            name: alertcfg
          - mountPath: "/alertmanager/data"
            name: alert-persistent-storage
        - name: wecom-robot-adapter
          image: wangsj/wecom-robot-adapter:1.2
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
      volumes:
      - name: alertcfg  
        configMap:
          name: alert-config
      - name: alert-persistent-storage
        persistentVolumeClaim:
          claimName: alert-pv-claim
---
apiVersion: v1
kind: Service
metadata:
  name: alertmanager
  namespace: ops
  labels:
    app: alertmanager
spec:
  type: ClusterIP
  ports:
    - port: 9093
  selector:
    app: alertmanager

异常日志告警管理

分组

把同类型的警报进行分组,合并多条警报到一个通知中。在生产环境中,特别是云环境下的业务之间密集耦合时,若出现多台 Instance 故障,可能会导致成千上百条警报触发。在这种情况下使用分组机制, 可以把这些被触发的警报合并为一个警报进行通知,从而避免瞬间突发性的接受大量警报通知,使得管理员无法对问题进行快速定位。


    # 所有报警信息进入后的根路由,用来设置报警的分发策略
    route:
      # 这里的标签列表是接收到报警信息后的重新分组标签,例如,接收到的报警信息里面有许多具有 app=order、env=pre、level=warn 这样的标签的报警信息将会批量被聚合到一个分组里面
      group_by: ['app', 'env','level']
      # 当一个新的报警分组被创建后,需要等待至少group_wait时间来初始化通知,这种方式可以确保您能有足够的时间为同一分组来获取多个警报,然后一起触发这个报警信息。
      group_wait: 30s
      # 当第一个报警发送后,等待'group_interval'时间来发送新的一组报警信息。
      group_interval: 5m
      # 如果一个报警信息已经发送成功了,等待'repeat_interval'时间来重新发送他们
      repeat_interval: 3h
      # 默认的receiver:如果一个报警没有被一个route匹配,则发送给默认的接收器
      receiver: rocket
      # 上面所有的属性都由所有子路由继承,并且可以在每个子路由上进行覆盖。
      routes:
      - receiver: wecom-robot-rocket
        match:
          app: mall-order

抑制

当某条警报已经发送,停止重复发送由此警报引发的其他异常或故障的警报机制。


inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  equal:
  - alertname
  - instance
静默

根据标签快速对警报进行静默处理;对传进来的警报进行匹配检查,如果接收到警报符合静默的配置,Alertmanager 则不会发送警报通知。

图片

企业微信机器人通知

Alertmanager 可以将告警信息推送到邮箱、企业微信、钉钉、WebHook等多种目的地,这里主要是用WebHook方式推送到企业微信群聊。在企业微信群聊中新增机器人,用机器人的key替换下面url中的{企业微信机器人的key},并可设置需要@的用户ID。

    receivers:
    # 邮件通知
    - name: 'rocket-email'
      email_configs:
      - to: 'rocket@example.com'
        send_resolved: true
    # 企业微信通知,直接发给个人或部门,需要企业微信后台配置自建应用
    - name: 'rocket-wecom'
      wechat_configs:
      - corp_id: 'corp_id'
        to_user: 'userId'
        agent_id: 10001
        api_secret: 'secret'
    # 企业微信群聊机器人(推荐,任意企业微信群聊创建机器人后即可)
    - name: 'wecom-robot-rocket'
      webhook_configs:
      - url: 'http://localhost:8080/api/webhook/send?key={企业微信机器人的key}&mentions=userId,all'
    - name: 'wecom-robot-zhangsan'
      webhook_configs:
      - url: 'http://localhost:8080/api/webhook/send?key={企业微信机器人的key}&mentions=zhangsan'

最后

在了解完异常日志告警机器人的工作流程后,希望各位小伙伴在编程开发时重视日志打印的规范,以便机器人可以高效准确地将异常信息推送出来。

<think>首先,用户的问题是关于微服务治理体系的构建:"我想了解如何构建微服务治理体系 请问微服务架构中如何实现服务治理 构建微服务治理方案"。我需要基于提供的引用内容来回答,因为系统指令要求引用相关段落并添加引用标识。 系统指令关键点: - 使用中文回答。 - 回答结构清晰,逐步解决问题。 - 引用相关段落时,在末尾添加引用标识,如 [^1]。 - 生成相关问题。 - 对于数学表达式,使用 $...$ 或 $$...$$,但在这个主题中可能不太相关,因为微服务治理不涉及数学公式。 - 参考站内引用:[^1], [^2], [^3], [^4]。 引用内容总结: - [^1]: 讨论构建微服务架构的系统方法,包括服务建模、技术实现、基础设施管理和研发过程。 - [^2]: 探讨Java中的微服务架构与服务治理机制,包括服务注册与发现、负载均衡、配置管理、熔断与限流、服务监控,并提供代码示例。 - [^3]: 深入探讨服务治理实现方案,如Zookeeper、Nacos、Consul、Eureka,分析特点、工作原理和应用场景。 - [^4]: 关于微服务架构下的服务治理概述,包括AKF拆分原则、反腐层、挎斗模式、APM等关键点。 用户的核心问题是构建微服务治理体系。我需要基于这些引用构建一个清晰的回答结构。 回答结构: 1. **介绍微服务治理的重要性**:简要解释为什么需要服务治理。 2. **关键组件和步骤**:详细说明如何构建治理体系,包括服务发现、负载均衡、容错、监控等。 3. **实现方案**:讨论不同的工具和技术,如Nacos、Consul等。 4. **最佳实践**:包括服务拆分原则、反腐层等。 5. **总结**:强调系统性和可维护性。 在回答中引用相关段落: - 当提到服务建模时,引用 [^1]。 - 当讨论服务治理机制时,引用 [^2]。 - 当分析具体工具时,引用 [^3]。 - 当涉及AKF原则或反腐层时,引用 [^4]。 生成相关问题:在回答末尾,添加§§相关问题§§部分,列出3-4个相关问题。 确保回答真实可靠:基于引用内容,不添加虚构信息。 最终输出格式: - 回答部分:结构清晰,使用中文。 - 相关问题部分:以§§相关问题§§开头。 - 引用标识:在引用的句子末尾添加 [^数字]。 现在,规划回答内容: 1. **引言**:微服务治理是确保微服务架构稳定、高效运行的关键,涉及服务的注册、发现、负载均衡、容错等。 2. **核心组件**: - 服务注册与发现:使用工具如Eureka、Consul实现服务自动注册和发现 [^2][^3]。 - 负载均衡:通过Ribbon或Nginx实现请求分发 [^2]。 - 容错机制:包括熔断(如Hystrix)、限流和降级 [^2]。 - 配置管理:使用Config Server或Nacos进行集中配置 [^2][^3]。 - 监控与追踪:集成APM工具如Zipkin、Prometheus进行性能监控 [^4]。 3. **构建步骤**: - 服务拆分:遵循AKF拆分原则,确保服务独立性和可扩展性 [^4]。 - 实施反腐层:在微服务改造中,添加反腐层来处理遗留系统集成 [^4]。 - 使用挎斗模式:如Service Mesh(Istio)来解耦服务治理逻辑 [^4]。 4. **工具选择**:比较Zookeeper、Nacos、Consul、Eureka,根据场景选择 [^3]。 5. **总结**:构建治理体系需系统方法,结合技术实现和过程管理 [^1]。 相关问题: 1. 如何选择适合的服务治理工具? 2. 微服务治理中的常见挑战有哪些? 3. 如何实现微服务的安全治理? 4. 服务网格(Service Mesh)在治理中的作用是什么?</think>### 构建微服务治理体系的系统方法 在微服务架构中,服务治理是确保系统稳定、高效运行的核心环节。它通过一系列机制管理服务的注册、发现、通信、容错和监控,从而提升系统的可维护性和可扩展性。基于行业最佳实践和参考内容,我将逐步指导您如何构建一个完整的微服务治理体系。整个过程包括关键组件设计、工具选型、实施步骤和优化策略,确保方案可靠且易于落地。 #### 步骤1: 明确服务治理的核心组件 服务治理体系的基础是几个关键组件,这些组件协同工作,确保服务间的通信高效且可靠: - **服务注册与发现**:服务启动时自动注册到注册中心,其他服务通过中心查询和发现目标服务。这解决了动态环境中服务地址变更的问题,提高系统的灵活性。例如,Java生态中常用Eureka或Nacos实现此功能 [^2][^3]。 - **负载均衡**:在多个服务实例间分发请求,避免单点过载,提升系统吞吐量。工具如Ribbon(客户端负载均衡)或Nginx(服务端负载均衡)可集成实现 [^2]。 - **容错机制**:包括熔断(Circuit Breaker)、限流(Rate Limiting)和降级(Fallback),用于在服务故障或高负载时保护系统。Hystrix是常见的熔断实现,防止雪崩效应 [^2]。 - **配置管理**:集中管理服务配置(如数据库连接参数),支持动态更新,无需重启服务。Nacos或Spring Cloud Config是推荐工具 [^2][^3]。 - **监控与追踪**:通过APM(Application Performance Management)工具监控服务性能、日志和链路追踪,快速定位问题。Zipkin或Prometheus可提供实时洞察 [^4]。 这些组件构成了治理体系的基础,确保服务的高可用性和弹性。构建时需从系统设计开始,例如通过服务建模定义边界和接口,避免过度耦合 [^1]。 #### 步骤2: 选择并实施服务治理工具 工具选型需基于业务规模、技术栈和运维复杂度。参考主流方案,以下是常见工具的比较和实施建议: - **Zookeeper**:适合分布式协调,但配置复杂,适用于小规模系统 [^3]。 - **Nacos**:阿里巴巴开源,支持服务发现、配置管理和动态DNS,集成简单且社区活跃,是Java微服务的首选 [^2][^3]。 - **Consul**:提供强一致性和多数据中心支持,适合跨云环境,但学习曲线较高 [^3]。 - **Eureka**:Netflix出品,轻量级服务发现工具,适合Spring Cloud生态,但功能较单一,常需结合其他工具 [^2][^3]。 **实施示例(以Nacos为例)**: 1. 部署Nacos Server:通过Docker快速启动注册中心。 2. 服务注册:在Java服务中添加Nacos客户端依赖,使用注解自动注册。 ```java // Spring Boot示例 @SpringBootApplication @EnableDiscoveryClient // 启用服务发现 public class UserServiceApplication { public static void main(String[] args) { SpringApplication.run(UserServiceApplication.class, args); } } ``` 3. 服务调用:通过Feign或RestTemplate实现负载均衡调用。 4. 配置管理:在Nacos控制台动态修改配置,服务实时生效。 工具选型应结合实际需求:中小型项目用Nacos或Eureka,大型分布式系统选Consul或Service Mesh方案 [^3]。 #### 步骤3: 集成高级治理策略 为提升体系健壮性,需融入架构原则和模式: - **AKF服务拆分原则**:根据扩展性(X轴)、功能(Y轴)和数据(Z轴)拆分服务,确保独立部署和扩展。例如,电商系统可按用户、订单、支付拆分为独立服务 [^4]。 - **反腐层(Anti-Corruption Layer)**:在微服务改造中,添加中间层隔离旧系统,转换数据格式,避免污染新服务。适用于遗留系统迁移,使用API网关实现 [^4]。 - **挎斗模式(Sidecar)**:通过Service Mesh(如Istio)将治理逻辑(如流量控制、安全)从业务代码解耦,部署为独立容器。这简化开发,提升可维护性,尤其适合云原生环境 [^4]。 - **监控与APM**:集成工具如Zipkin进行链路追踪,结合告警系统(如Grafana)实现主动运维 [^4]。 #### 步骤4: 系统化构建与优化 构建治理体系不是一次性任务,而是持续过程: 1. **设计阶段**:通过服务建模定义治理需求,结合基础设施管理(如Kubernetes编排)确保资源高效利用 [^1]。 2. **开发阶段**:采用DevOps实践,自动化测试和部署,参考Java微服务示例实现代码级治理 [^2]。 3. **运维阶段**:建立服务SLA(Service Level Agreement),监控关键指标(如错误率、延迟),定期审计。 4. **优化策略**:从单体架构迁移时,优先实施反腐层;高并发场景下强化熔断和限流;使用挎斗模式降低代码侵入性 [^4]。 #### 总结 构建微服务治理体系需系统方法:从核心组件(注册、负载均衡、容错)入手,选择合适的工具(如Nacos或Consul),并融入AKF拆分、反腐层等高级策略。整个过程强调可观测性和自动化,确保系统高可用、易维护。根据引用内容,成功的治理依赖于技术实现(如服务发现机制)和研发过程(如持续集成)的结合 [^1][^2][^3][^4]。最终,治理体系能显著提升微服务架构的稳定性和扩展性,支持业务快速迭代。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值