Prometheus

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 用户界面

公司简介 完美日记（Perfect Diary）是广州市“独角兽”创新企业——广州逸仙电子商务有限公司旗下首个美妆品牌，创立于2017年，用心为新生代女性开发高品质、精设计、易上手的彩妆及护肤产品，立志于打造有国际影响力的Chinese Beauty Icon。 完美日记上线不到两年即成为天猫彩妆销冠，2019年成为11年来第一个登上天猫双十一彩妆榜首的国货品牌，包揽天猫2019全年彩妆销冠；2020年4月成为首个亮相天猫超级品牌日的国货彩妆品牌，同时勇破彩妆品牌销售纪录。 另外，完美日记已在全国各地开设了数十家线下店，计划至2022年底开店超600家。 截至2020年4月，品牌SKU超过700个，全网用户粉丝数量超过2500万，月曝光量10亿+。 业务痛点 系统开发迭代快，线上问题比较多，定位问题比较耗时。 频繁大促，系统稳定性保障压力很大，第三方接口和一些慢SQL就可能导致严重的线上故障。 压测与系统容量评估的工作非常频繁，需要做常态化的机制来支撑。 系统大促时资源与日常资源相差较大，需要频繁扩缩容。 解决方案 图 1. 解决方案架构图 方案细节： 为了支撑业务快速发展，完美日记采用了阿里云容器服务ACK+Spring Cloud Alibaba配合阿里云中间件PTS+AHAS+链路追踪产品的方案。 系统进行容器化部署，利用阿里云容器服务的快速弹性应对大促时的资源快速扩容。

序 本文主要研究一下dubbo-go的metricsFilter metricsFilter dubbo-go-v1.4.2/filter/filter_impl/metrics_filter.go const ( metricFilterName = "metrics" ) var ( metricFilterInstance filter.Filter ) // must initialized before using the filter and after loading configuration func init() { extension.SetFilter(metricFilterName, newMetricsFilter) } // metricFilter will calculate the invocation's duration and the report to the reporters // If you want to use this filter to collect the metrics, // Adding this into your configuration file, like: // filter: "metrics" // metrics: // reporter: // - "your reporter" #

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)方向进行选型。最终定下来的存储有两种

简介 TensorFLow是深度学习和机器学习最流行的开源框架，它最初是由Google研究团队开发的并致力于解决深度神经网络的机器学习研究，从2015年开源到现在得到了广泛的应用。特别是Tensorboard这一利器，对于数据科学家有效的工作也是非常有效的利器。 Jupyter notebook是强大的数据分析工具，它能够帮助快速开发并且实现机器学习代码的共享，是数据科学团队用来做数据实验和组内合作的利器，也是机器学习初学者入门这一个领域的好起点。 利用Jupyter开发TensorFlow也是许多数据科学家的首选，但是如何能够快速从零搭建一套这样的环境，并且配置GPU的使用，同时支持最新的TensorFlow版本, 对于数据科学家来说既是复杂的，同时也是浪费精力的。 在Kubernetes集群上，您可以快速的部署一套完整Jupyter Notebook环境，进行模型开发。这个方案唯一的问题在于这里的GPU资源是独享，造成较大的浪费。数据科学家使用notebook实验的时候GPU显存需求量并不大，如果可以能够多人共享同一个GPU可以降低模型开发的成本。 而阿里云容器服务团队推出了GPU共享方案，可以在模型开发和模型推理的场景下大大提升GPU资源的利用率，同时也可以保障GPU资源的隔离。 独享GPU的处理办法 首先我们回顾下以前调度GPU的情况 为集群添加一个新的gpu节点

本章节主要涵盖了Alertmanager的工作机制与配置文件的比较详细的知识内容，由浅入深的给大家讲解。 警报一直是整个监控系统中的重要组成部分，Prometheus监控系统中，采集与警报是分离的。警报规则在 Prometheus 定义，警报规则触发以后，才会将信息转发到给独立的组件 Alertmanager ，经过 Alertmanager r对警报的信息处理后，最终通过接收器发送给指定用户，另外在 Alertmanager 中没有通知组的概念，只能自己对软件重新Coding，或者使用第三方插件来实现。 注意，这个通知组不是Alertmanager中的group概念，下面会详细讲 Group ，不要混淆哦。 前面已经介绍过一些关于 Alertmanager 知识点，本章开始针通过安装 Alertmanager 组件，对配置文件做详细说明，同时介绍 Prometheus 的警报规则的定义，最后使用Email、Wechat（Robot）、Dingtalk（webhook）来接受警报通知。 Alertmanager工作机制 在Prometheus生态架构里，警报是由独立的俩部分组成，可以通过上图很清晰的了解到 Prometheus 的警报工作机制。其中 Prometheus 与 Alertmanager 是分离的俩个组件。我们使用Prometheus Server端通过静态或者动态配置

上篇文章（第01期：详解 Prometheus 专栏开篇） 介绍了 Prometheus 的架构，本文开始将介绍 Prometheus 数据采集。本文首先会介绍采集数据的格式和分类，然后会给出一些使用上的建议。 一、采集数据格式及分类 1.1 采集数据的格式x` Prometheus 使用 metric 表示监控度量指标，它由 metric name (度量指标名称)和 labels (标签对)组成： <metric name>{<label name=<label value>, ...} metric name 指明了监控度量指标的一般特征，比如 http_requests_total 代表收到的 http 请求的总数。metric name 必须由字母、数字、下划线或者冒号组成。冒号是保留给 recording rules 使用的，不应该被直接使用。 labels 体现了监控度量指标的维度特征，比如 http_requests_total{method="POST", status="200“} 代表 POST 响应结果为 200 的请求总数。Prometheus 不仅能很容易地通过增加 label 为一个 metric 增加描述维度，而且还很方便的支持数据查询时的过滤和聚合，比如需要获取所有响应为 200 的请求的总数时，只需要指定 http_request_total

最近几年好像大家都开始对微服务着迷，与此同时单体架构也在慢慢淡出人们的视线。 当然，热门的趋势总是来来去去，而且它们所受到的关注往往被媒体夸大了，实际情况并不总是如此。不过，对于微服务来说，人们似乎已经达成共识，认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说，微服务扩展了工程师们几十年来采用的相同原则。 一旦你开始使用微服务架构，也许你需要本文中提到的5个规则，帮助你成功运行它们。 微服务的另一面 关注点分离(SoC)是一项设计原则，规定软件的构建应根据 "关注点 "或总体功能来确定不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，它体现在典型的3层架构中的表现层、业务层和数据层的分离。 微服务采用了这个概念，并将其颠覆。它们将同一个应用程序以这样的方式分离出来，应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱两方面的运维成本较高。除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外，维护该应用程序也带来了新的挑战。 挑战1：似乎很难监控整体 虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论你是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，你现在都有更多的服务需要监控。其中每一个都可能会： 使用不同的技术和/或语言。