Distributed Tracing in Grafana -- Jaeger & Tempo
前言 在近几个月对某产品后台微服务的SLI建设过程中,逐渐意识到这类监控的最佳方式还是通过jaeger/opentracing这类链式tracing才能以最佳的监控数据结构提供全链路的数据监控 并且最近也看到了Tempo — 来自Grafana Lab的tracing backend,可以更好的处理大数据量的tracing以及更好地兼容在Grafana上的展示 于是写一篇文章来小小整理一下Jaeger和Tempo的内容 需要了解的词 tracing 追踪数据流的工具,下面会详细介绍 Grafana 基于Golang实现的完整可视化面板平台,同时也提供告警等功能 OpenTracing 由Tracing通用API规范、框架和库组成,可以在任何应用程序中支持Distributed Tracing Tracing是什么 尽管我们十分熟悉我们编写的系统,但在线上环境中,它对于我们来说依旧是黑盒;可能你会说我们有丰富的日志,但当系统日渐庞大,业务逻辑逐渐繁杂之后,再丰富的日志对于我们的运维排查来说也是杯水车薪,并且日志采集,日志埋点,和日志存储都带来不小的成本,复杂的日志反 ...
Run minecraft on mac pro m1
Run minecraft on mac pro m1 前言 由于MC自带的必要动态链接库LWJGL的架构是X86,不兼容mac pro m1处理器的arm64架构,原生的MC是无法在m1上启动的;同时由于Apple强推了Metal API,在部分mod / 光影 / 材质包上会有损失部分Feature的情况 经典放送: 基本设置 见arm64 minecraft wrapper 完成配置后可正常启动Minecraft mod支持情况 部分图形渲染相关mod会出现无法渲染文字 / 图像的情况 光影支持情况 m1下仅支持部分光影(部分光影会因为Metal API产生Error) 欣赏经典: 经过测试已支持的光影: https://github.com/MoustacheOff/AppleSilicon-Minecraft-Shaders 推荐使用 注意下载v1.20版本的 Slidur's Shaders,高版本的在m1上有性能问题
小刮刮Scrapy
前言 从大二开始接触python,到现在已经是第三个年头了;随着入职腾讯,进入云原生行业后,python已经不再是我的主要开发语言,我转而收养了golang小地鼠成为了一名gopher 但python依然是我的工具人好伙伴(日常生活中一旦有自动化的念头也会直接想到python),并且作为数据工作者,对于python的数据处理能力还是挺依赖的,golang的生态也没有好到能面面俱到 鄙人大二时课设写过一个小小的b站爬虫(基于bs4, re和selenium等简单写的),最后也只是草草爬了几十万的用户数据以及几百万的视频数据,做了做没有什么意义的词频分析,而scrapy作为我一定会忘记的爬虫必会知识,还是有必要写一篇小笔记record一下的 需要了解的词 网络爬虫:泛指获取网页信息,提取有用信息的行为 selenium: web自动化测试工具集,但在爬虫工程中也经常使用,模拟人的点击操作驱动浏览器来获取网页信息 Scrapy是什么 Scrapy是一个为了爬取网站数据,提取结构性数据而编写的应用框架。 可以应用在包括数据挖掘,信息处理或存储历史数据等一系列的程序中。其最初是为了 页 ...
面试官初体验
前言 近期作为后台开发面试官整理的一些简单面试题(仅供参考仅供参考仅供参考 基础题 Golang Golang中函数调用是传值还是传引用 golang中所有函数参数传递都是传值,slice、map和chan看上去像传引用只是因为他们内部有指针或本身就是指针而已;slice结构体里有一个指向底层数组array的指针,所以slice在作为函数参数传递进去的时候,虽然和map以及chan一样可以修改其中的值,但是内部slice若使用append之类的方法修改了大小,则这部分长度信息的变化不会反馈到外层slice中,甚至会因为底层数组扩容(cap扩充)导致内外slice指向了不同的底层数组;而map和chan因为本质上就是指针,故所有函数内的变动都会反馈到外面,除非在函数内部改变了这些指针指向的内存(这也是map和chan的copy的实现方法) Golang中make和new的区别? make 只能用来分配及初始化类型为 slice、map、chan的数据,new可以分配任意类型的数据 new 分配返回的是指针,即类型 *Type。make 返回引用,即 Type new 分配 ...
Whosbug项目日志2
背景信息 团队规模 whosbug经手了多个团队的近20人,历史团队中:大家分别负责插件和数据流转的设计实现和优化、责任归属算法的设计实现与优化、antlr语法AST分析的多语言适配实现以及项目协同的管理;当前主要由kevineluo和kevinmatthe负责维护以及开源相关的规划,同时开源团队也有其它8位同学一起协作共建 业务内容 提供DevOps流程中的CI流水线插件,为线上项目提供发生错误时实时归属责任人的能力 项目诉求 关键痛点 在很多大型项目中,一个重要缺陷往往会在不同的人手中流转很多次,这会导致很多不必要的时间成本和人力成本,甚至在一些情况下会引发新的问题(如修复人在对模块不熟悉的情况下进行了不恰当的bugfix) 项目目标 whosbug致力于解决责任人归属这一问题的一个微服务,精确的定位到每一个crash / bug的责任人,缩短缺陷修复流程;同时也能在语法树这一层级为项目提供部分统计信息 项目现状 初版尝试在自动化测试产品(NewMonkey)、移动性能监控(QAPM)场景中接入了whosbug;近期也进行了一些更新,解决了下面提到的一些问题,不久后 ...
Keyman算法设计哲学
前言 whosbug项目中,最重要的无非是两个部分: 对接入项目的AST静态语法解析 责任人归属算法 whosbug初版发布后我们进行了一系列的测试,发现了老算法在一些场景下的局限性(如对没有第三方库调用的处理、多语言下的泛用性不足等问题) 于是在参考了部分论文后,我们结合实际落地场景设计了新的责任人归属算法 —— Keyman,本文我们就详细介绍下算法设计 主要设计思想 函数唯一标识 为了清晰一个函数在语法树中的精确位置,首先我们需要每个函数的唯一标识,这里我们的标识为: 并且包 / 类也视作一个函数,将包/类内的代码非函数内代码归入这个包 / 类的函数 获取可能和这次错误相关的函数 Init: 获取预设的迭代次数NUMBER_OF_ITERATION,新建相关方法集methods,以错误堆栈中涉及的所有方法为初值 不断地从methods内的每个函数/方法找到与其相连且未在methods内的方法,加入methods中,也同时得到该方法与直接错误方法的距离。如此全面进行NUMBER_OF_ITERATION次 1234567891011NUMBER_OF_ ...
TraceSim算法深入浅出
前言 现有研究使用的stack trace距离度量主要有以下两种: information retrieval techniques(基于信息检索技术) string matching methods(基于字符串匹配技术) Rebucket就是string matching methods的一种,这篇论文主要提出了TraceSim这一结合了两种方法的堆栈相似度度量方法 需要了解的词 Levenshtein Distance Calculation: 基于string matching methods的一种堆栈间距离的度量算法(本文中的Levenshtein Distance Calculation是其改进版本,下面会展开讲) TF-IDF: 基于information retrieval techniques的一种堆栈间距离的度量算法,其中TF代表单帧的重要程度,IDF代表单帧的罕见程度 TraceSim a novel approach to this problem which combines TF-IDF, Levenshtein distance, and m ...
Service Mesh在接入层流量管理的应用
service mesh是什么 A service mesh, like the open source project Istio, is a way to control how different parts of an application share data with one another. Unlike other systems for managing this communication, a service mesh is a dedicated infrastructure layer built right into an app. This visible infrastructure layer can document how well (or not) different parts of an app interact, so it becomes easier to optimize communication and avoid downtime as an app grows. Each part of an app, called a ...
Redis分布式锁的基本实现
前言 随着分布式系统的普遍运用,分布式锁的重要性也得到了体现 在单机系统中,我们可以运用普通的锁/信号量机制来实现对公共资源的有序访问;但在分布式系统中显然就不行了 因此业界常用的解决方案通常是借助于一个第三方组件,利用它自身的排他性来达到多进程的互斥;如: 基于 DB 的唯一索引 基于 ZK 的临时有序节点 基于 Redis 的 NX EX 参数 本文就主要以Redis分布式锁展开 需要了解的几个词 锁机制:锁是在执行多线程时用于强行限制资源访问的同步机制,即用于在并发控制中保证对互斥要求的满足(Wiki百科) 死锁:死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。 此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程 ZK:即ZooKeeper,ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等 Redis分布式锁的基本原理 既然是选用了 Redis, ...
从Redis事务到Redis pipeline
前言 相信对关系性数据库有使用经验的,都对事务操作很熟悉,为了确保连续多个操作的原子性,我们常用的数据库都会有事务的支持,Redis 也不例外;但它又和关系型数据库支持的事务不太一样 需要了解的几个词 事务:数据库事务通常包含了一个序列的对数据库的读/写操作。包含有以下两个目的: 为数据库操作序列提供了一个从失败中恢复到正常状态的方法,同时提供了数据库即使在异常状态下仍能保持一致性的方法 当多个应用程序在并发访问数据库时,可以在这些应用程序之间提供一个隔离方法,以防止彼此的操作互相干扰 ACID:关系性数据库事务具有的四个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability) 悲观锁(Pessimistic Lock):顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁 乐观锁(Optimistic Lock) ...