gydtep
发表于 2021-6-14 11:53:46
目前，一个比较好的解决方法就是把它前置，所有的功能在某一个页面的某一个位置，以一个具体的按扭呈现出来，并设置一个唯一的参数ID，再用事件和属性进行归类。这样一来，所有的页面和功能只需做一个埋点，所有页面的标记都可以用ID来标记。
gydtep
发表于 2021-6-15 09:57:34
维护工作复杂：除了客户端的SDK和探针外，一套全链路监控方案在服务端有计算组件、存储组件、展示组件，都需要单独进行维护。以Jaeger为例，仅在数据存储方面需要维护一套独立的Elasticsearch集群，需要投入很大的工作量。
gydtep
发表于 2021-6-15 13:02:24
其中，-javaagent后面的路径是探针文件所在的路径，arms.licenseKey可以从ARMS的控制台获得，appName代表应用的名字。在微服务应用中，一个应用可以拥有多个对等的应用实例，这些对等的应用实例接入ARMS的时候，使用同样的应用名，这样ARMS可以把这个应用的多个实例放到一个分组中进行统一管理。
gydtep
发表于 2021-6-15 16:41:39
我们可以重点关注应用应用提供服务和应用依赖服务栏展示的指标曲线，如果在某个时间点发生了突变，可以进行针对性的排查。比如在某一个时间点，一个应用对外服务接口的请求量突然变低，极有可能是其中的一个节点发生了故障，需要特别关注。对于在ARMS展示出来的任何一条以时间维度为横座标的指标曲线，都可以继续选择其中的时间段进行下钻分析，这也是一个非常便捷的功能。
gydtep
发表于 2021-6-16 09:23:02
成为优秀的架构师是大部分初中级工程师的阶段性目标。第三部分剖析架构师的能力模型，让大家对目标所需能力有一个比较清晰的认知。
gydtep
发表于 2021-6-16 12:57:07
将经验输出，接受别人的检验是高层次的总结。这种输出不仅帮助了别人，对自身更是大有裨益。总结的方式有很多，包括组织分享，撰写技术文章等等。当然“日三省吾身”也是不错的总结方式。总之，多多总结，多多分享，善莫大焉！
gydtep
发表于 2021-6-16 16:09:18
“一致性”算得上是计算机领域里面最经典的难题，它是所有分布式系统的基础，从多核多CPU到多线程，从跨机器到跨机房，无所不在，几乎所有的计算机从业人员都在解决这个问题，但是Paxos给出了一个很优雅的解决方案。
gydtep
发表于 2021-6-16 19:36:39
从技术发展的角度来说，技术管理者应该关注自己所能把控的活跃项目的数量，并致力于提高活跃项目的影响力和技术深度。团队人数要与个人管理能力、规划能力和需求把控能力相适应。一份工作让多个人来干，每个人的成长都受限。每个人都做简单重复的工作，对技术成长没有任何好处。团队管理和项目管理需要循序渐进，忌“拔苗助长”。
gydtep
发表于 2021-6-17 11:03:56
避免调研时间过长。如果发现调研进展进入到指数级复杂度，也就是每前进一步需要之前两倍的时间投入，就应该果断的停止调研。
gydtep
发表于 2021-6-17 15:57:08
有效沟通的另外一个重点是“不要跑题”。很多看起来很接近的问题，本质上是完全不同的问题。比如：一个会议的主题是“如何实施一个方案”，有人却可能提出“是否应该实施该方案”。 “如何实施”和“是否应该实施”是完全不同的两个问题，很多看起来相关的问题实际上跑题很远。“跑题”是导致无效沟通的重要原因。
页:
1
2
3
[4]
5
6
7
8
9
10
11
12
13
