grafana

前言 掌门1对1精耕在线教育领域，近几年业务得到了快速发展，但同时也遭遇了“成长的烦恼”。随着微服务数量不断增加，流量进一步暴增，硬件资源有点不堪重负，那么，如何实现更好的限流熔断降级等流量防护措施，这个课题就摆在了掌门人的面前。由于 Spring Cloud 体系已经演进到第二代，第一代的 Hystrix 限流熔断降级组件已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。 如何选择一个更好的限流熔断降级组件？经过对 Alibaba Sentinel 、 Resilience4j 、 Hystrix 等开源组件做了深入的调研和比较，最终选定 Alibaba Sentinel 做微服务体系 Solar 中的限流熔断降级必选组件。 Sentinel 简介 阿里巴巴中间件部门开发的新一代以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性的分布式系统的流量防卫兵。它承接了阿里巴巴近10年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 它具有非常丰富的开源生态： 它和 Hystrix 相比，有如下差异： 摘自官网 Sentinel Roadmap 关于 Sentinel 如何使用，它的技术实现原理怎样等

参考文章： Grafana全面瓦解 grafana-doc 简介 Spring Boot 自带监控功能 Actuator，可以帮助实现对程序内部运行情况监控，比如监控状况、Bean加载情况、环境变量、日志信息、线程信息等。这一节结合 Prometheus 、Grafana 来更加直观的展示这些信息。 实验 说明 服务名 地址 端口 Prometheus 172.16.2.101 9090 Grafana 172.16.2.101 3000 Spring Boot Demo 172.16.2.204 8080 创建项目 创建用于测试的 Spring Boot 项目，主要代码如下。 pom.xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId>

Istio 组件常用端口 端口 协议 使用者 描述 8060 HTTP Citadel GRPC 服务器 8080 HTTP Citadel agent SDS service 监控 9090 HTTP Prometheus Prometheus 9091 HTTP Mixer 策略/遥测 9876 HTTP Citadel, Citadel agent ControlZ 用户界面 9901 GRPC Galley 网格配置协议 15000 TCP Envoy Envoy 管理端口 (commands/diagnostics) 15001 TCP Envoy Envoy 传出 15006 TCP Envoy Envoy 传入 15004 HTTP Mixer, Pilot 策略/遥测 - mTLS 15010 HTTP Pilot Pilot service - XDS pilot - 发现 15011 TCP Pilot Pilot service - mTLS - Proxy - 发现 15014 HTTP Citadel, Citadel agent, Galley, Mixer, Pilot, Sidecar Injector 控制平面监控 15020 HTTP Ingress Gateway Pilot 健康检查 15029 HTTP Kiali Kiali 用户界面

k8s集群上的监控首推prometheus，但如果按照x86架构k8s集群安装prometheus的方法直接在树莓派k8s集群上安装prometheus，适配的工作量比较大，不建议这么做。我推荐github上一个大神的作品 https://github.com/carlosedp/cluster-monitoring ， 经反复验证，在树莓派k8s集群基本可用，这里我简单介绍一下安装过程。 安装准备 树莓派k8s集群：最好3节点，单节点也可以。 root@pi4-master01:~# kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME pi4-master01 Ready master 4d18h v1.15.10 192.168.5.18 <none> Ubuntu 20.04 LTS 5.4.0-1011-raspi docker://18.9.9 pi4-node01 Ready node 4d17h v1.15.10 192.168.5.19 <none> Ubuntu 20.04 LTS 5.4.0-1011-raspi docker://18.9.9 pi4-node02

点击上方“朱小厮的博客”，选择“ 设为星标” 后台回复" 书 "，获取 来源：22j.co/cfHw 监控系统的历史悠久，是一个很成熟的方向，而 Prometheus 作为新生代的开源监控系统，慢慢成为了云原生体系的事实标准，也证明了其设计很受欢迎。本文主要分享在 Prometheus 实践中遇到的一些问题和思考，如果你对 Kubernetes 监控体系或 Prometheus 的设计还不太了解，可以先看下容器监控系列[1]。 几点原则 监控是基础设施，目的是为了解决问题，不要只朝着大而全去做，尤其是不必要的指标采集，浪费人力和存储资源（To B商业产品例外）。 需要处理的告警才发出来，发出来的告警必须得到处理。 简单的架构就是最好的架构，业务系统都挂了，监控也不能挂。Google SRE 里面也说避免使用 Magic 系统，例如机器学习报警阈值、自动修复之类。这一点见仁见智吧，感觉很多公司都在搞智能 AI 运维。 Prometheus 的局限 Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。 Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。 对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos 等方案。

环境简介： 上一篇文章已介绍了整个部署流程，本篇不再叙述，只做些相应插件安装及页面配置。 一、安装zabbix插件 [root@iz2ze846r4r3t1w2vf34luz ~]# grafana-cli plugins install alexanderzobnin-zabbix-app #重启grafana [root@localhost ~]# systemctl restart grafana-server 二、登陆Grafana启用zabbix #启用插件 登录grafana：configuration--->plugins--->Zabbix Plugin Config--->Enable #添加数据源 点击”Configureation”-“Data Sources”-“Add data source”，如下 注意：如果报错，把URL地址变成127.0.0.1，这个问题是个小坑，浪费了作者很长时间。 #开始绘图 #选择图形 #根据需要监控的内容，对应选择数据源、填好组名、host、监控应用集、监控项即可。 #也可导入模板再稍加修改 官方模板下载地址： https://grafana.com/grafana/dashboards 来源： oschina 链接： https://my.oschina.net/u/4302015/blog/4286782

1.下载安装启动node_exporter #创建prometheus目录 mkdir / data / prometheus #进入prometheus目录 cd / data / prometheus #下载node_exporter wget https: / / github . com / prometheus / node_exporter / releases / download / v0 . 18 . 1 / node_exporter - 0 . 18 . 1 . linux - amd64 . tar . gz #解压 tar - zxvf node_exporter - 0 . 18 . 1 . linux - amd64 . tar . gz #进入启动目录 cd node_exporter - 0 . 18 . 1 . linux - amd64 #启动 nohup . / node_exporter>node . logs 2>&1 & #返回上级目录 cd . . 2.下载安装启动prometheus #下载 wget https: / / github . com / prometheus / prometheus / releases / download / v2 . 19 . 2 / prometheus - 2 . 19 . 2 .

0、题记 由于2019年Elastic开发者大会下午分3个会场，使劲浑身解数也只能串了两个分场，所以下面的分享肯定信息不全面。 全面信息后续建议参考Elastic中文社区的PPT。文中可能的细节错误，欢迎大家留言指正。 您的参会干货和认知习得，也欢迎留言讨论交流。 1、感触 从没有见过哪个大会，能干货连连、高潮此起彼伏、全程无尿点； 从没有见过哪个大会，与会者能持续葆有相当高的热情； 从没有见过哪个大会，过道里也站满了人专心听讲，且没有一个人喊累； 从没有见过哪个大会，嘉宾毫无保留的分享技术干货，即便部分内容打了马赛克，但技术细节没有过分阉割； 从没有见过哪个大会，与会讲者老师知无不言、言无不尽； 从没有见过哪个大会，所有人站着吃盒饭，还非常高兴； 从没有见过哪个大会，会后大家围着分享嘉宾问问题，直到主持人打断、直到开始下一场分享； 从没有见过哪个大会，大家走的时候不断回望，非常恋恋不舍，感叹时间过得太快。 ...... 这是Elastic一年一度的盛会，这是Elastic爱好者的朝圣日和狂欢日。 近距离接触，才能体会到开源的强大、分享的强大、社区的强大。 近距离接触，才能明白差距，很多一线大厂已远远走在技术的最前沿，在内核层、源码层、业务层做过大量的创新、优化实战。 ..... 感慨万千，无以言表..... 2、关键词 满满的一天行程下来，以下几个关键词一直在脑海回荡。 的确

每日优鲜监控系统早期情况 系统覆盖不全 每日优鲜早期只有交易平台存在一套内部的业务监控系统，没有推广到全公司级别。大数据团队与自己的业务监控，运维团队有自己的基础监控。除了交易系统其他业务线的业务监控几乎为零，很多时候都是用户告知我们出问题了，而不是我们主动发现出问题了，导致问题发现的时候已经过去很久了。 监控类型不完善 监控内容主要是涉及日志中出现的数据统计，所以对PV、UV、JVM相关监控都没有，尤其对自身业务的监控几乎为零，我们无法实时的知道当前接口的访问量，错误率等信息；除此之外我们依赖的zookeeper、mq、redis、数据库等中间件的监控也基本没有，所以很难做到深入的排查。不过好在有一套pinpoint可以帮助故障和性能定位。但是这并不能代替业务监控。 监控系统选型和实现 选型 要实现一套监控系统，必须要保证数据的收集、存储和可视化，然后在基于此实现一套告警系统，最终实现数据的可视化与问题的触达。 可视化选型 在做监控系统选型的时候，最优先定下来的是可视化，即Grafana这套开源产品，因为其支持多数据源，同时也支持告警规则，除此之外其提供了一套完备的API，我们通过程序调用其API实现了监控数据可视化的自动化流程。 存储选型 第二个定下来的是存储系统，监控的数据基本都带有时序性，所以我们自然而然的朝着时序数据库(TSDB)方向进行选型。最终定下来的存储有两种

简介 在今年2月初， SLS 已经发布针对新冠病毒肺炎疫情国内动态展示分析 APP，目前该能力全面开放给政府、社区、第三方平台和开放者进行广泛应用， 完全免费开放 。还没有关注过的同学可以通过以下链接了解背景： 新冠病毒疫情分析 APP 官方文档 云栖博文、直播 最近，随着新冠病毒肺炎疫情在全球爆发， SLS 又推出了跟踪关注全球范围疫情动态的分析大盘。与国内大盘主要关注国内疫情（数据来源于央视新闻、人民日报、各省市卫健委公告）相比，国际疫情大盘则是跟踪关注全球范围的疫情动态，数据来源是被国际上广泛引用的 约翰·霍普金斯大学开源数据集 。 SLS 阿里云日志服务（SLS）是针对日志类数据的一站式服务，无需开发就能快捷完成海量日志数据的采集、消费、投递以及查询分析等功能，提升运维、运营效率。日志服务主要包括实时采集与消费、数据投递、查询与实时分析等功能，适用于从实时监控到数据仓库的各种开发、运维、运营与安全场景。 作为日志分析中台，日志服务提供了一站式的数据采集、加工、查询分析、AI计算、可视化，并支持互联互通。 亮点 1. 提供规整的疫情数据，并每天定时同步更新 SLS 已经将疫情相关数据进行收集和规整，每天定时更新，并形成可视化平台覆盖全球各个国家/地区、省份/州的疫情信息。你只需要专注在数据的分析和展示，其它繁琐的细节 SLS 都已经处理好。 2. 预定义丰富数据大盘