现象：使用PS收集老年代，平均一小时一次major GC，每次平均停顿160ms。

分析：老年代max 1.2G内存，一小时从500到1.2G。

• 正常就是有很多minorGC存货的对象放在了Survivor中，多次GC后晋升为老年代。
• 大对象太多,minorGC后存活下来，survivor放不下，直接放入老年代了，导致老年代爆炸式增长，频繁FULLGC。

解决方法：

首先判断是什么业务类型，会有这么频繁的大对象。根据调用接口次数判断。

• 提高survivor区内存，让大对象不至于直接进入老年代。

md写作模板

摘要

摘要正文

目录

1. 标题1
2. 标题2
3. 标题3

标题1

小节1.1

正文内容…

小节1.1.1

正文内容…

小节1.2

正文内容…

标题2

正文内容…

小节2.1

• 列表项1
• 列表项2
  • 子列表项2.1
  • 子列表项2.2

小节2.2

1. 有序列表项1
2. 有序列表项2
   1. 有序子列表项2.1

标题3

正文内容…

小节3.1

• 已完成的任务
• 未完成的任务

小节3..2

结论

正文内容…

参考文献

• 参考文献1
• 参考文献2
• 参考文献3

附录

附录内容…

opentelemetry Trace流程源码解析：

trace流程当然是从我们使用sdk开始。

1
2
3
4
5

SdkTracerProvider sdkTracerProvider = openTelemetrySdk.getSdkTracerProvider();
Span startSpan = sdkTracerProvider.get("orderService")
        .spanBuilder("pay")
        .startSpan();
startSpan.end();

从最简单的用法开始，从openTelemetrySdk获取traceProvider，构造span，startSpan再到end。

这就是我们trace中span最简单的流程。

在spanBuilder中只接受了一个spanName，其中sharedState指得是trace中所有span共享的一些状态和配置，比如id生成器，span处理器，span的shutdown状态等。

在最后的构造中其实只构造了一个名字，并没有做过多的事情，毕竟是builder。

下面直接看startSpan方法做了什么。

1.获取当前线程的context，从context中获取parentSpan，生成一个spanId。当startSpan为整个trace第一次调用时，parent是空。

ContextStorage是一个接口，实现也很有趣，一个是final类，一个是枚举。

我们看到StrictContextStorage实现了Storage，不过却用的delegate做模板方法。

例如current使用的delegate方法，在实际代码中,delegate其实就是ThreadLocalContextStorage。

ThreadLocalContextStorage是一个枚举类，有一个枚举叫做INSTANCE。

而current方法就是通过threadlocal存储并获取的。

而threadlocal在目前是没有值的。

所以最开始context就是个null。

我们继续往下，在context null时，会返回一个无效的span：PropagatedSpan.INVALID。

通过这个标记，我们可以得知是root span还是child span，从而生成或者获取traceId。

links是我们在spanbuiler使用addLink方法添加的,放入一个spancontext和一些attributes。

第二段：

从sharedState获取sampler采样器，默认是alwaysOn类型，当然也提供了其他策略，所以这里才使用shouldSample方法放入需要的参数，contxt，linkdatas等判断是否需要采样。

然后创建一个spanContext,spanContext其实也是存放span所需信息。

后续就是保存获取attribute，attribute具体放了什么，是否使用都是由shouldSample方法决定的。

startSpan方法中记录了一个span开始时间：

创建SdkSpan并调用spanProcessor中的onStart方法。

Processor有四种：

不过onStart方法基本空实现

此时我们已经拿到了span，总结一下startSpan做了什么：

从当前线程Context中获取parentContext，parentSpan和parentSpanContext，其中核心逻辑是是否采样的逻辑判断，其中一个SpanContext对应着一个span，会存放对应span的id和traceId。

接下来看看end方法，end方法直接调用internal。

可知span并不是线程安全，存在同时end的情况。

大家使用时注意，后end的线程将无法记录span信息到trace中。

记录时间，再次调用spanProcessor处理。

首先看batch

batch使用了queue存放span，存放失败时会使用counter类型的指标（如果不清楚，可以去看看prometheus四大指标类型）记录失败个数。

存放成功后，如果size大于等于spansNeeded时会发送一个信号。

这里的spansNeeded是一个AtomicInteger，我们知道这是BatchSpanprocessor批量发送的，那必然是收集到一个batch，一起发送的过程，所以spansNeeded其实就代表下一次批量发送还需要多少个span。那么这个信号其实就是通知发送线程开始发送。

下图是发送span的worker线程run方法：

着重讲下worker成员变量：

queue用于存放当前添加的还未export的span。

spansNeeded表示当前还需要多少个span才能export。

signal用于通知worker线程在poll阻塞中苏醒。

flushRequested用于通知外部强制flush是否完成。

batch存在下一次export的span。

worker线程逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public void run() {
  updateNextExportTime();

  while (continueWork) {
  // 先判断是否有flush请求，有就flush，以避免span积压太多，后续的span迟迟无法上报。
    if (flushRequested.get() != null) {
      flush();
    }
    // 从queue中出队maxExportBatchSize-batch.size还能export的span
    JcTools.drain(
        queue, maxExportBatchSize - batch.size(), span -> batch.add(span.toSpanData()));
	 // 当batch达到可导出数量时，导出
    if (batch.size() >= maxExportBatchSize || System.nanoTime() >= nextExportTime) {
      exportCurrentBatch();
      updateNextExportTime();
    }
    // 不管当前batch有没有导出，当queue为空，为避免cpu空转，让线程等待，等待queue中又有足够的span数量时能够一次性batch时，再唤醒线程
    if (queue.isEmpty()) {
      try {
        long pollWaitTime = nextExportTime - System.nanoTime();
        if (pollWaitTime > 0) {
          spansNeeded.set(maxExportBatchSize - batch.size());
          signal.poll(pollWaitTime, TimeUnit.NANOSECONDS);
          // 唤醒后设置为最大值,为什么这样？
          // 从之前添加span的代码可以得知,当queue超过spansNeeded时就会通知线程苏醒，实际环境是addSpan是一个非常频繁的动作，所以在苏醒后，queue并没有那么快就出队，就会导致下一个add时又去通知线程苏醒做不必要的操作。所以不如在此时把spansNeeded设置为最大值,减少没有必要的操作。
          spansNeeded.set(Integer.MAX_VALUE);
        }
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        return;
      }
    }
  }
}

1
2
3

if (queue.size() >= spansNeeded.get()) {
  signal.offer(true);
}

剩下exportCurrentBatch的逻辑比较简单。

opentelemetry默认提供了三个exporter。

loggingSpanExporter就是从日志中把本次span的信息打印出来。

MultiSpanExporter就是多个spanExporter分别处理这些span。

NoopSpanExporter是空实现。

还剩几个问题大家可以自己探索源码：

1.trace中span层级怎么确定的？

2.queue没有上限吗？

3.如果span数量一致没有到need个数，是不是有些span永远无法上报呢？

1.物流项目写什么呢？

几个模块，展示数据需求数量，这个简单写写

2.可观测项目

1.多维度观测数据：主机维度，cpu,内存，连接数。JVM维度，接口维度，观测接口成功率，接口耗时，中间件维度，直观查看目前所有中间件的内存，cpu，连接数。

==整体大盘图，中间件层图，和其他大盘目录图

2.code部分，应用接入可观测SDK,实现自定义打点功能，实现接口粒度业务状态码。

==代码结构画一下。

2.日志结构化：更方便的查询工具，不用再登录各个服务器查询，字段搜索，通过traceID和日志定位问题更快。==查询界面截图。

2.文档沉淀：多少份，输出可观测中kibana查询文档，使用文档，自定义大盘文档。

==文档数量截图。

3.告警多维度告警：主机维度cpu，内存告警，MQ积压告警，数据库连接数超过阈值告警。

==告警设置截图，告警过去触发次数截图。

总结：从0到1完成公司可观测平台，补全了公司基本的观测能力，能够观测到接口粒度的数据，使用趋势图，柱状图显示和颜色直观了解到接口性能并进行优化。

3.未来

参与wms项目

​ 最近工作类型从原来的开发切到了SRE，工作内容有了很大变化。从原来的CRUD变为了稳定性保证人员。

不过在小公司，应该就是运维加24 ON CALL接线员。

​ 由于工作内容的改变，要学习的东西也变得很多很多，在学习和搜集资料方面，GPT可谓是我的第一帮手。

经过这些天的使用，发现现在的AI真的发展到一个令人震惊的情况了。

​ 1.知识的收集：GPT已经无敌，如果不是次数限制，我估计以后都不会再使用百度，google等SEO去搜索问题。

GPT总结内容，比我自己一个一个网站鉴定内容和整合信息快多了。现在GPT强大到已经让我相信，当它都找不到正确的信息时，SEO就更难了。

​ 2.上下文的理解：尤其是claude 3.5 sonnet和chat gpt 4o，这两个的上下文的理解都很不错，这让我少打了很多字，用起来非常顺手。我觉得未来微软把4o整合到PC上使用语音的方式提问，生产力又提升一个档次了。

​ 顺带一提，国产大模型在这块差得太远了。以明星GPT-KIMI为例，KIMI的回答总让我感觉是一个机器模板式的回答，光是答题格式就让你怀疑这个回答的准确性，其次就是内容充斥着很多无用的口水话，而chatgpt4o和claude sonnet的回答都是直奔主题并直接show code，并且KIMI生成速度也不如上述两个大模型。

​ 3.内容质量：这里作为程序员视角，主要分析代码运行是否正确，符合预期。其中4o基本给出了错误代码很少，基本通过Prompt矫正都能得到正确可执行的代码，尤其是在配置各种复杂的环境方面，非常好用。通过这方面，我觉得以后单纯的初级CRUD程序员将会被很快淘汰。以后程序员是否熟练使用GPT应该会变成各大公司里招聘的硬性条件。由于Claude目前使用较少，暂时无法评判其正确性。

​ 4.GPT目前的缺点：现在的GPT应该都已经联网，不过信息的实时性上还是差了很多。例如最近开源软件新发布的功能，由于gpt无法整合到这么新的消息，所以回答并不是最优解。还有一个缺点是，回答重复，无法对症修改答案，明明你的提问只是改了一个软件版本，但是依然会生成之前的一大堆重复的信息，比较浪费时间，尤其是当答案很长时，得优化prompt才能让他意识到。

关于使用生成式大模型的感受

近期，我的工作性质从开发转向了SRE，工作内容发生了显著变化。从之前的CRUD开发，转变为负责系统稳定性保障。不过在小型公司中，这个角色更像是集运维和24小时待命接线员于一身。

随着工作内容的改变，需要学习的知识也急剧增加。在学习和资料搜集方面，GPT成为了我的得力助手。经过一段时间的使用，我发现当前AI的发展已经达到了令人惊叹的程度。

1. 知识收集

GPT在这方面的表现堪称无可匹敌。如果不是受到使用次数的限制，我估计未来几乎不会再使用百度、Google等搜索引擎来查找问题。GPT总结内容的效率远超我自己逐个网站筛选和整合信息。现在GPT的能力已经强大到让我相信，当它都无法找到正确信息时，传统搜索引擎就更加困难了。

2. 上下文理解

特别是Claude 3.5 Sonnet和ChatGPT 4.0，它们在上下文理解方面表现出色，这让我节省了大量输入，使用起来非常顺畅。我认为，未来如果微软能将GPT-4整合到PC上，并支持语音提问，生产力将再次得到显著提升。

值得一提的是，国产大模型在这方面还有很长的路要走。以备受关注的GPT-KIMI为例，其回答常给人一种机械化模板的感觉。不仅答题格式让人对回答的准确性产生怀疑，而且内容中充斥着许多无关紧要的话语。相比之下，ChatGPT 4.0和Claude Sonnet的回答都更加直接切题，并能直接提供代码示例。此外，KIMI的生成速度也不如上述两个大模型。

3. 内容质量

从程序员的角度来看，主要关注代码的正确性和是否符合预期。GPT-4在这方面表现出色，很少给出错误代码，即使有，通过适当的提示也能快速得到正确可执行的代码。特别是在配置复杂环境方面，非常实用。基于这一点，我认为纯粹的初级CRUD程序员可能很快就会被淘汰。未来，熟练使用GPT可能会成为各大公司招聘程序员的硬性要求。由于我对Claude的使用还不够深入，暂时无法全面评判其表现。

4. GPT的当前局限性

• 尽管现在的GPT模型已经可以联网，但在信息实时性方面仍有不足。例如，对于开源软件最新发布的功能，GPT可能无法及时整合这些最新信息，导致回答不够优化。
• 回答有时会出现重复，难以针对性修改。即使提问只是改变了一个软件版本，GPT仍可能生成大量重复的信息，这在答案较长时尤其浪费时间。要解决这个问题，需要优化提示词，让GPT意识到变化。

Nginx 日志统计

日期: 2024-09-11 00:08:31

页面浏览量 (PV): 457

独立访客数 (UV): 84

访客来源地理分布:

• United States: 40.48%
• China: 14.29%
• Switzerland: 1.19%
• United Kingdom: 4.76%
• Bulgaria: 2.38%
• Japan: 2.38%
• Netherlands: 11.90%
• Poland: 3.57%
• Vietnam: 1.19%
• Portugal: 1.19%
• Panama: 1.19%
• Canada: 1.19%
• Argentina: 1.19%
• France: 1.19%
• Hong Kong: 1.19%
• Russia: 1.19%
• Belgium: 2.38%
• Seychelles: 1.19%
• Germany: 1.19%
• India: 2.38%
• Singapore: 1.19%
• Israel: 1.19%