微服务业务监控和行为分析怎么做?试试日志埋点

file

一、说明

互联网公司一般都会有专门的数据团队对公司的一些业务指标负责;为了拿到这些基本的业务指标,一般也要工程团队去配合做一些数据采集工作,于是埋点诞生了。  

埋点的方式有很多种,本文主要介绍 日志埋点 这种方式以及实现思路和案例。

日志埋点 就是通过程序打印 log 日志的方式进行业务/行为数据的记录

 

二、总体架构

file

通过 日志埋点 来实现业务监控和行为分析主要需要以下4个步骤

  1. 数据生成(埋点)
  2. 数据收集
  3. 数据解析(结构化)
  4. 数据落盘
  5. 数据使用(展示/分析)

 

三、方案说明

3.1. 数据生成

日志数据的生成直接使用 Logback 等日志框架就可以了,可以自己封装公共方法、aop、注解等方式来生成指定的埋点日志

但是为了便于后面的数据解析,日志数据需要规范先行

  1. 所有的埋点日志必需约定好统一的格式,例如:{时间}|{来源}|{对象id}|{类型}|{对象属性(以&分割)}

按上面的格式生成的日志为: 2019-11-07 10:32:01|api-gateway|1|request-statistics|ip=171.221.203.106&browser=CHROME&operatingSystem=WINDOWS_10

  1. 避免埋点的日志文件和系统本身输出的日志混淆 file

埋点的日志输出的目录、文件等需要和应用本身的日志分离,通过 Logback 的配置就能实现

 

埋点案例

file

生成日志

file

网关埋点用户请求

 

3.2. 数据收集

关于日志数据的收集可选择的中间件比较多,除了图中的 FileBeat 之外还有 FlumeFluentdrsyslog 等;需要每台服务器都部署一个收集中间件。

每台服务器部署一个就行了,就算一台服务器中启了多个微服务也是可以一齐收集

PS:日志收集后面的 消息队列 并不是必需的可以去掉,但是增加 消息队列 后有以下两个优点

  1. 削峰填谷:减轻后面日志解析的压力
  2. 数据共享:日志数据除了提供给日志系统之外,可以增加消费端的同时提供给其他地方使用,如流计算等

 

3.3. 数据解析

使用 Logstash 的grok表达式解析日志数据并结构化,以上面的日志数据为例

2019-11-07 10:32:01|api-gateway|1|request-statistics|ip=171.221.203.106&browser=CHROME&operatingSystem=WINDOWS_10

结构化后的日志数据为:

{
	timestamp: '2019-11-07 10:32:01',
	appName: 'api-gateway',
	resouceid: '1',
	type: 'request-statistics',
	ip: '171.221.203.106',
	browser: 'CHROME',
	operatingSystem: 'WINDOWS_10'
}

 

3.4. 数据落盘

通过 Logstash 能自动创建 Elasticsearch 索引并以天为单位分片 file

可以通过索引模板来指定每个字段的类型和分词器等属性

 

3.5. 数据使用

日志数据落盘到 Elasticsearch 后,就可以通过聚合查询等方式实时显示监控数据或者分析日志数据

监控案例

file

聚合查询逻辑可参考 https://gitee.com/zlt2000/microservices-platform

 

四、总结

日志埋点 只是其中一种埋点手段而已,优点是系统无入侵且灵活;日志收集、解析、落盘等都可以灵活搭配选择不同的中间件,并且不需要修改源系统的代码;并且可以方便对接其他分析平台(例如: 大数据平台)

PS:业务监控是否可以不做日志埋点,直接查询业务的数据库呢?(不建议这样做)

  1. 使用日志埋点能实现监控数据与业务数据分离,监控平台不会影响或增加业务数据库的压力
  2. 使用日志埋点能方便实现实时业务数据预警

举个栗子:日志收集后面添加流计算中间件,计算某个时间窗口内优惠卷日志的数量或者金额大于某个阀值,则发出预警

 

进QQ群(779809018)免费领取学习资源,疑难问题解答。同时欢迎大家关注我的微信公众号:代码帮 ,免费领取学习资源和学习每天不定时推送的技术性文章。

本公众号将秉持活到老学到老学习无休止的交流分享开源精神,汇聚于互联网和个人学习工作的精华干货知识,一切来于互联网,反馈回互联网。
目前研究领域:大数据、机器学习、深度学习、人工智能、数据挖掘、数据分析。 语言涉及:Java、Scala、Python、Shell、Linux等 。同时还涉及平常所使用的手机、电脑和互联网上的使用技巧、问题和实用软件破解。 只要你一直关注和呆在群里,每天必须有收获,讨论和答疑QQ群:大数据和人工智能总群(779809018)微信公众号(代码帮)每天分享最新IT、大数据和人工智能新技术。

<think>嗯,用户让我设计一个监控架构,覆盖微服务、虚拟机应用Redis。首先,我得弄清楚用户的具体需求是什么。可能他们有一个混合环境,既有基于微服务的应用,也有传统的虚拟机部署的服务,还有Redis作为缓存或数据库。他们需要全面的监控方案,确保各个部分都能被有效监控,及时发现问题。 首先,我应该考虑监控的层次结构。通常监控可以分为基础设施、服务、应用性能、日志告警这几个层面。基础设施方面,虚拟机需要监控CPU、内存、磁盘、网络等。微服务可能需要更细粒度的监控,比如每个服务的响应时间、错误率、吞吐量。Redis作为关键组件,需要关注内存使用、命中率、慢查询等。 然后,工具选型。基础设施监控可能用Prometheus或者Zabbix。Prometheus现在比较流行,尤其适合云原生环境,而Zabbix可能在传统环境中更常见。微服务方面,Prometheus结合Grafana可以很好地展示指标,同时可能需要APM工具如SkyWalking或Pinpoint来追踪调用链。对于日志,ELK或者Loki是常用方案,特别是LokiGrafana搭配使用更轻量。Redis的监控可以用Prometheus的exporter,或者Redis自带的监控工具。 接下来,架构设计需要考虑数据采集、存储、展示告警。每个服务都需要有对应的exporter或agent来收集数据。比如Node Exporter用于虚拟机,Redis Exporter专门收集Redis指标微服务通过暴露Prometheus端点或集成APM agent。存储的话,Prometheus本身有TSDB,但长期存储可能需要Thanos或Cortex。日志存储用Elasticsearch或Loki。展示层用Grafana统一展示,这样比较方便。告警部分,Prometheus Alertmanager可以处理告警,同时需要集成通知渠道,比如邮件、Slack、钉钉等。 还要考虑高可用可扩展性。Prometheus可能需要分片或者联邦架构来应对大规模数据。日志系统也需要分布式部署,避免单点故障。另外,安全性方面,数据传输是否需要加密,访问控制如何做,比如GrafanaPrometheus的权限管理。 用户可能没有明确提到的点,比如监控的实时性、历史数据分析、自动化响应等。比如,是否需要在监控到异常时自动扩容或重启服务?不过这可能属于更高级的自动化运维范畴,暂时先设计监控告警部分。 可能还需要考虑部署维护的成本。如果用户资源有限,可能需要选择更轻量级的工具,比如Loki代替ELK,因为ELK的Elasticsearch比较吃资源。另外,是否需要容器化部署这些监控组件,比如用Docker或Kubernetes,这取决于现有环境。 最后,给出一个具体的架构示例,分层次说明各个组件的作用,以及它们如何协同工作。同时,可能需要验证这个架构是否覆盖了所有用户提到的服务类型,并确保没有遗漏。例如,微服务的链路追踪是否被包含,Redis的慢查询是否有监控,虚拟机的基础指标是否采集全面。此外,告警的阈值设置是否合理,是否需要根据实际业务调整。</think>以下是一个覆盖微服务、虚拟机应用Redis的监控架构设计方案,旨在实现全方位可观测性(Metrics、Logs、Traces)告警联动: --- ### **1. 架构核心分层** #### **1.1 数据采集层** - **基础设施监控** - **目标**: 采集虚拟机/物理机的CPU、内存、磁盘、网络等基础指标。 - **微服务监控** - **APM工具**: SkyWalking / Prometheus + Grafana(结合Service Mesh如Istio) - **数据**: 服务调用链(Traces)、接口响应时间、错误率、吞吐量(QPS)。 - **集成**: 在代码中埋点或通过Sidecar自动采集(如Istio Envoy)。 - **Redis监控** - **工具**: Prometheus Redis Exporter / Redis内置`INFO`命令 - **关键指标**: 内存使用率、命中率、连接数、慢查询、主从同步状态。 - **日志采集** - **工具**: Filebeat / Fluentd - **目标**: 收集虚拟机日志、容器日志(如Docker)、应用日志,统一推送至中央存储。 #### **1.2 数据存储层** - **时序数据库**: Prometheus TSDB(短期存储) + Thanos/Cortex(长期存储集群化) - **用途**: 存储所有指标数据(Metrics)。 - **日志存储**: Elasticsearch / Grafana Loki - **用途**: 集中存储日志,支持全文检索模式匹配。 - **链路追踪存储**: Elasticsearch / Jaeger - **用途**: 存储微服务调用链(Traces),用于故障根因分析。 #### **1.3 可视化告警层** - **可视化工具**: Grafana - **统一看板**: 整合Prometheus、Loki、Jaeger数据,创建业务、服务、基础设施三层视图。 - **典型面板**: - 业务层:全局请求成功率、核心交易耗时。 - 服务层:微服务依赖拓扑、Redis内存碎片率。 - **工具**: Prometheus Alertmanager + 自定义脚本 - **告警规则**: - 基础阈值告警(如Redis内存 > 90%)。 - 智能动态基线(如微服务响应时间同比突增200%)。 - **通知渠道**: 邮件、企业微信、钉钉、PagerDuty。 --- ### **2. 关键技术组件联动** 1. **微服务异常定位流程** - **触发告警**: Prometheus检测到某服务错误率超标 → Alertmanager推送告警。 - **日志关联**: 通过Grafana跳转到Loki,过滤该服务时间段的ERROR日志。 - **链路追踪**: 在Jaeger中查询同一时段慢请求的完整调用链,定位故障服务节点。 2. **Redis性能优化场景** - **监控发现**: Prometheus检测到命中率下降 → 联动日志发现大量`KEYS *`慢查询。 - **自动处理**: 通过脚本触发Redis大Key分析工具(如`rdb-cli`)生成报告。 --- ### **3. 高可用扩展设计** - **采集侧** - Prometheus联邦架构:分片采集不同区域的微服务指标。 - Filebeat负载均衡:多实例部署避免日志丢失。 - **存储侧** - Elasticsearch集群:分片副本机制保障日志高可用。 - Thanos多副本:实现指标数据的跨数据中心冗余。 - **安全加固** - 传输加密:PrometheusExporter间使用mTLS。 - 权限控制:Grafana对接LDAP/SSO,按团队划分数据访问权限。 --- ### **4. 部署示例** ```text +-------------------+ +-------------------+ | 微服务集群 | | 虚拟机/Redis | | (K8s/Spring Cloud)| | (VMware/物理机) | +-------------------+ +-------------------+ | 埋点/Sidecar | Node Exporter | Prometheus Exporter | Redis Exporter v v +-----+ +-------------------+ | Prometheus <-------+ 日志采集(Filebeat) | | (联邦分片) | +-------------------+ +-------------------+ | | v v +-----------+ +-------------------+ | Elastic | | Thanos(Cortex) | | Search | | (长期存储) | +-----------+ +-------------------+ ^ | | v | +-----+ +-----------+ | Grafana |<---------+ Loki | | (统一可视化) | | (日志存储) | +-------------------+ +-----------+ | ^ v | +-------------------+ | Alertmanager | | (告警路由) | +-------------------+ ``` --- ### **5. 演进方向** - **AIOps集成**: 基于历史数据训练异常检测模型(如Prophet算法),替代静态阈值。 - **自动化修复**: 联动K8s或Ansible实现自愈(如Redis内存溢出时自动扩容)。 - **成本优化**: 按日志等级设置保留策略(如DEBUG日志保留1天,ERROR保留30天)。 通过此架构,可实现从基础设施到业务逻辑的全链路监控,快速响应故障并优化系统性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值