摘要：了解需求，明确目的，获取（线上）数据加以分析，制定指标 1.1新上线项目1、指标以目的为导向1）容量验证——某软硬件条件下系统最大处理能力，为运维提供容量模型/预估2）稳定性验证3）有特定的预期指标（1~3年未来规划）注：基准性能需提前把控（重点关注在无压力情况下的响应耗时）2、业务模型1）参考历史项目或其他同行业项目2）业务产品综合评估 注：待系统上线后可观察一段时间，按照较为标准的业务模型在验 1.2已上线系统根据历史数据分析获取方式 1）请运维同学协助查看；2）通过现有监控平台等途径获取版本迭代（按照原预期）1.3 性能需求指标序号指标类型指标名称指标要求说明1系统指标
摘要：了解需求，明确目的，获取（线上）数据加以分析，制定指标 1.1新上线项目1、指标以目的为导向1）容量验证——某软硬件条件下系统最大处理能力，为运维提供容量模型/预估2）稳定性验证3）有特定的预期指标（1~3年未来规划）注：基准性能需提前把控（重点关注在无压力情况下的响应耗时）2、业务模型1）参考历史项目或其他同行业项目2）业务产品综合评估 注：待系统上线后可观察一段时间，按照较为标准的业务模型在验 1.2已上线系统根据历史数据分析获取方式 1）请运维同学协助查看；2）通过现有监控平台等途径获取版本迭代（按照原预期）1.3 性能需求指标序号指标类型指标名称指标要求说明1系统指标
前言随着Prometheus监控的组件、数量、指标越来越多，Prometheus对计算性能的要求会越来越高，存储占用也会越来越多。在这种情况下，要优化Prometheus性能,优化存储占用.第一时间想到的可能是各种Prometheus的兼容存储方案,如Thanos或VM、Mimir等。但是实际上虽然集中存储、长期存储、存储降采样及存储压缩可以一定程度解决相关问题，但是治标不治本。真正的本，还是在于指标量（series）过于庞大。治本之法，应该是减少指标量。有2种办法：Prometheus性能调优-解决高基数问题根据实际使用情况，只保留（keep）展示（GrafanaDashboards）和告警
前言随着Prometheus监控的组件、数量、指标越来越多，Prometheus对计算性能的要求会越来越高，存储占用也会越来越多。在这种情况下，要优化Prometheus性能,优化存储占用.第一时间想到的可能是各种Prometheus的兼容存储方案,如Thanos或VM、Mimir等。但是实际上虽然集中存储、长期存储、存储降采样及存储压缩可以一定程度解决相关问题，但是治标不治本。真正的本，还是在于指标量（series）过于庞大。治本之法，应该是减少指标量。有2种办法：Prometheus性能调优-解决高基数问题根据实际使用情况，只保留（keep）展示（GrafanaDashboards）和告警
今天我们来和大家聊一聊一个新话题，一个对于企业业务发展十分关键的东西——指标。指标建设是衡量企业业务效果的主要依据，本文结合自身实践经验和大家分享指标的设计与加工过程，讲述其基础概念和设计加工方法，以及设计加工过程中的注意点，希望对感兴趣的同学有所帮助。一、指标建设的必要性1、什么是指标指标是客观描述某个事物某个特征的可量化的数字度量，如用户最近30天购买次数，某商品最近30天销售额等。指标常从多个维度来描述，如某地区的新增用户数、线上线下的新增用户数，维度让指标更加具象与丰满。2、建设背景大数据时代数字化转型背景下，企业所需要的往往不单单是数据，而是数据背后映射的业务洞察，相比较数据我们更加
今天我们来和大家聊一聊一个新话题，一个对于企业业务发展十分关键的东西——指标。指标建设是衡量企业业务效果的主要依据，本文结合自身实践经验和大家分享指标的设计与加工过程，讲述其基础概念和设计加工方法，以及设计加工过程中的注意点，希望对感兴趣的同学有所帮助。一、指标建设的必要性1、什么是指标指标是客观描述某个事物某个特征的可量化的数字度量，如用户最近30天购买次数，某商品最近30天销售额等。指标常从多个维度来描述，如某地区的新增用户数、线上线下的新增用户数，维度让指标更加具象与丰满。2、建设背景大数据时代数字化转型背景下，企业所需要的往往不单单是数据，而是数据背后映射的业务洞察，相比较数据我们更加
背景概述最近计划着重分析一下线上各api的HTTP响应耗时情况，检查是否有接口平均耗时、99分位耗时等相关指标过大的情况，了解到nginx统计请求耗时有四个指标：request_time、upstream_response_time、upstream_connect_time与upstream_header_time，在查找资料的过程中，发现无论是nginx官方文档还是热心网友们的分享，都并没有让自己感觉特别详细、明白地说清楚了这四个指标详细具体含义的资料，于是自己动手探究了一番nginx源码，尝试从其中找出这4个指标的代码级别具体含义。特别说明：本文代码分析基于nginx1.10.0版本，从
背景概述最近计划着重分析一下线上各api的HTTP响应耗时情况，检查是否有接口平均耗时、99分位耗时等相关指标过大的情况，了解到nginx统计请求耗时有四个指标：request_time、upstream_response_time、upstream_connect_time与upstream_header_time，在查找资料的过程中，发现无论是nginx官方文档还是热心网友们的分享，都并没有让自己感觉特别详细、明白地说清楚了这四个指标详细具体含义的资料，于是自己动手探究了一番nginx源码，尝试从其中找出这4个指标的代码级别具体含义。特别说明：本文代码分析基于nginx1.10.0版本，从
问题背景大一点的公司都会建立一套规章流程来避免低级错误，例如合入代码前必需经过同行评审；上线前必需提测且通过QA验证；全量前必需经过1%、5%、10%、20%、50%的灰度过程。尤其是最后一步，需要严密的监控发版指标来保证新版本的质量，如果与主力版本的指标相比有异常变动，就需要及时停止放量并分析原因。一个版本的重点观察指标，除崩溃率外有小20项，分布在系统的10多个页面，且每个指标均需要指定多达6-10个过滤条件，最常用的包括版本号、端类型(PC/Mac/Android/iOS/…)、用户类型(user/vip/svip)，此外还有一些复杂的下拉列表选项，每次都记不住，需要参考文档才能确定选对
问题背景大一点的公司都会建立一套规章流程来避免低级错误，例如合入代码前必需经过同行评审；上线前必需提测且通过QA验证；全量前必需经过1%、5%、10%、20%、50%的灰度过程。尤其是最后一步，需要严密的监控发版指标来保证新版本的质量，如果与主力版本的指标相比有异常变动，就需要及时停止放量并分析原因。一个版本的重点观察指标，除崩溃率外有小20项，分布在系统的10多个页面，且每个指标均需要指定多达6-10个过滤条件，最常用的包括版本号、端类型(PC/Mac/Android/iOS/…)、用户类型(user/vip/svip)，此外还有一些复杂的下拉列表选项，每次都记不住，需要参考文档才能确定选对
