skywalking

22 日晚， Apache SkyWalking Founder 吴晟在朋友圈中指出，因违反开源协议要求，SkyWalking 只能 暂时 拒绝针对唯品会 Saturn 项目的插件需求 。 Saturn 是 fork 自 ElasticJob，并更改了版权信息，这是一个非常严重的许可证问题。基于 ElasticJob 的原始许可证 Apache 2.0 ，所有文件的 header 都应该保留，即便他们修改了代码。所以，无论你或是任何人想要做这个插件，我们都不能正式接受它作为 Apache SkyWalking 的一部分。如果你认识他们，请联系他们。只有在他们纠正了许可证问题，并且回滚了所有的 header 之后，我们才能支持他们的新版本。 我们联系吴晟了解相关情况，根据他的说法，他在查看 Saturn 源码时，发现项目实际上是 fork 自当当网的 ElasticJob。 ElasticJob 采用的 Apache 2.0 开源许可协议。根据 Apache 2.0 协议的要求，衍生项目需要在源码中有明确标识，说明此项目是 fork 自 ElasticJob ，一般就是在使用到的源码上保留原始附加 版权 信息，方可进行二次分发。 也就是说，Saturn 需要保留原项目文档中的版权 header 说明，声明当当的原始版权。但吴晟发现，Saturn 项目大部分文档中并没有声明版权归

版本：7.0.0 描述 在涉及到数据库的链路跟踪里面，通常希望将执行时间慢的SQL语句统计出来，这样的话能更快的定位问题。 配置 在 config/application.yml 文件中， receiver-trace 模块下配置 slowDBAccessThreshold 。 默认配置收集 mongodb SQL 执行时间大于100 毫秒，其他数据库 SQL 执行时间大于200毫秒。可依据实际情况调整。 receiver-trace: selector: ${SW_RECEIVER_TRACE:default} default: slowDBAccessThreshold: ${SW_SLOW_DB_THRESHOLD:default:200,mongodb:100} # The slow database access thresholds. Unit ms. 验证 收集到的慢 SQL 语句将显示在仪表盘，数据库面板下。 来源： oschina 链接： https://my.oschina.net/u/2344188/blog/4338289

版本：7.0.0 描述 apdex是一个衡量服务器性能的标准。 apdex有三个指标： 满意：请求响应时间小于等于T。 可容忍：请求响应时间大于T，小于等于4T。 失望：请求响应时间大于4T。 T：自定义的一个时间值，比如：500ms。 apdex = （满意数 + 可容忍数/2）/ 总数。 例如：服务A定义T=200ms，在100个采样中，有20个请求小于200ms，有60个请求在200ms到800ms之间，有20个请求大于800ms。计算apdex = (20 + 60/2)/100 = 0.5。 配置 SkyWalking配置apdex在 config/service-apdex-threshold.yml 文件中。默认设置 500ms 。 此配置可以使用配置中心，动态配置。 # default threshold is 500ms default: 500 # example: # the threshold of service "tomcat" is 1s # tomcat: 1000 # the threshold of service "springboot1" is 50ms # springboot1: 50 验证 来源： oschina 链接： https://my.oschina.net/u/2344188/blog/4330692

前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。 上面只是开一个玩笑，但是从某种程度反映了一些实际情况：Service Mesh 是一种设计思想和理念，而不是具体的架构或者实现方式，虽然 Istio+Envoy 的配置似乎已经成了事实标准，当我们环顾四周，却发现理想太丰满，现实太骨感，因为各企业当前切实原因，导致各种形态的 Service Mesh 百花齐放。 蚂蚁金服的 Service Mesh 就属于上面提到的百花齐放中的一员，我们已经渡过探索期，全面进入生产应用。去年的双十一完成了交易支付核心链路，几十万容器规模的生产级验证。但是业界对于 Service Mesh 仍然有很多种不同的声音，一方面是众星捧月式的支持，另一方面是困惑和质疑，包括对价值、架构以及性能的质疑。那么我们对此是什么态度？双十一深度实践之后蚂蚁金服的 Service Mesh 路又在何方？Service Mesh 架构是终点吗？ 本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。 蚂蚁金服 Service Mesh 实践回顾 上图是 2019 年蚂蚁金服双十一的实践架构

题记 今年是我个人从事软件测试工作的第六个年头，职业生涯至今经历了功能-接口-自动化-性能测试岗位的变迁。 18年下半年开始以团队owner的角色进行工作开展，不过当时团队技术体系建设已经步入正轨，对我个人而言，并没有太多沉淀。 19年跳槽后，有幸从零开始主导我司的性能测试体系建设工作，个人之前的很多想法得以落地实现。 这也许是除了薪资之外，对我个人而言获得的最大成就感。。。 导图 演进 基础建设 1、文档建设 前段时间知乎回答了一个问题： 做技术人是不是都反感写文字类的东西，比如需求文档，需求分析等等？ 之前的博客也写过类似的内容： 性能测试从零开始实施指南——文档建设篇 。 我个人认为无论是作为个人学习笔记抑或一个Team的累积沉淀，文档建设的工作必不可少，而且是重中之重。原因如下： 1） 降低“口头说明”带来的风险； 2）文档是很重要的记录和交流介质； 3） 便于事前、事中、事后快速回溯追踪； 4） 降低工作交接、沟通的成本，提高效率； 5）文档是一次梳理思路，review的方式； 6）文档是很重要的工作产出，自我价值诉求的重要手段（KPI）； 当然，现在有很多在线协同文档工具，如confluence、语雀（参考- 工具汇总 ）。我司性能团队文档类目如下： 2、资源管理 这里的资源主要指压测资源，包含如下几项： 1）压测机 2）压测场景 3）压测脚本 4）压测数据

掌门教育自2014年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、AR/VR/MR以及现今最火的5G，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门1对1新的机遇。随着业务规模进一步扩大，流量进一步暴增，微服务体系下，业务服务新增和迭代频率大大加快，运维和业务人员经常需要熬夜人工上线，疲劳状态下容易产生生产事故，运维成本和业务成本也将大大上升。在此背景下，基础架构部推出可以白天安全上线，流量无损的微服务灰度蓝绿发布智能化系统，并通过强有力的各种监控手段来保证流量的精确制导和调拨，提升技术驱动能力。 关于Solar Solar作为掌门1对1下一代基础微服务体系，2019年11月开始筹划，2020年1月4日推出第一版，2020年4月15日发布1.2.0 & 2.2.0里程碑稳定版，兼容Spring Cloud Edgware版、Finchley版、Greenwich版、Hoxton版本。基于三层体系而构建： 基础公共组件。Solar的基础组件，基础公共组件一般呈原子层面的独立存在，组件间也可适当耦合，基本上可达到一个组件被移除，不影响另外一个组件的运行的特征。 基础公共框架。Solar的基础框架，依托Spring Cloud服务体系，以框架形式对外暴露

https://www.jianshu.com/p/2fd56627a3cf https://blog.csdn.net/qq924862077/article/details/89409746 来源： oschina 链接： https://my.oschina.net/u/4386227/blog/4258220

在大型网站系统设计中，随着分布式架构，特别是微服务架构的流行，我们将系统解耦成更小的单元，通过不断的添加新的、小的模块或者重用已经有的模块来构建复杂的系统。随着模块的不断增多，一次请求可能会涉及到十几个甚至几十个服务的协同处理，那么如何准确快速的定位到线上故障和性能瓶颈，便成为我们不得不面对的棘手问题。 <!-- more --> 为解决分布式架构中复杂的服务定位和性能问题，Google在论文 《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 中提出了分布式跟踪系统的设计和构建思路。在这样的背景下， Apache SkyWalking 创建于2015年，参考Dapper论文实现分布式追踪功能，并逐渐进化为一个完整功能的 Application Performance Management 系统，用于追踪、监控和诊断大型分布式系统，尤其是容器和云原生下的微服务系统。 今年初我在尝试使用.NET Core构建分布式追踪系统 Butterfly 时接触到SkyWalking团队，开始和SkyWalking团队合作探索SkyWalking对.NET Core的支持，并于4月发布SkyWalking .NET Core探针的 第一个版本

搭建skywalking 服务端 一. 所需第三方软件 XShell Xftp Visual Studio 2019 .net Core 2.2 SDK JDK8+ Elasticsearch 6.3.2 centos7 docker 二. 实验架构 本次实验采用2台服务器Elasticsearch 放在centos7上，collector和客户端放在一起收集本机web服务器提供的数据。如果对skywalking架构不了解的同学可以先去了解一下。这里就不多做介绍了。 三. 安装运行环境 1. 安装java 根据博客上的命令行在centos7上安装失败了，命令如下 wget --no-check-certificate --no-cookie --header "Cookie: oraclelicense=accept-securebackup-cookie;" http://download.oracle.com/otn-pub/java/jdk/8u171-b11/512cd62ec5174c3487ac17c61aaa89e8/jdk-8u171-linux-x64.rpm 所以在本地上下载的 jdk-8u221-linux-x64.rpm 在用Xftp传到centos上，然后用一下命令安装 rpm -ivh jdk-8u221-linux-x64.rpm