wireshark抓包

Sling 请求k8s负载均衡器，导致的404错误

背景：

在一次业务开发中，业务中需要请求k8s服务地址。但是业务逻辑中的请求总是提示HTTP 404错误，使用curl 命令又是正确的。

出现问题：

在golang项目中，使用Sling库作为clinet，进行网络请求以获取服务响应结果

GDB（GNU Debugger）

GDB是UNIX/LINUX操作系统下的、基于命令行的、功能强大的程序调试工具。 可以查看程序在执行过程中的内部

gdb 官方文档

Python-gdb

通过python来运行gdb命令，其本质是利用python语言的灵活性和便利。GDB提供了一套python API，方便用户使用python脚本编写更复杂的GDB脚本 gdb python api 官方文档

wireshark抓包

nginx server 以 content-type chunk格式返回的程序异常

背景：

业务需要通过脚本跑一批数据，数据有很多条，每条数据需要进行一次数据库查询、一次OSS下载，最终才能确定该记录的输出

输出举例：
记录A： DB记录1 + OSS记录1
记录B： DB记录2 + OSS记录2
...
记录N： DB记录N + OSS记录N

wireshark抓包

SNI问题导致的网关层返回502错误

背景：

最近攻防等原因，运维将测试环境部分域名上了cloudflare（主要是海外）

业务方出现的问题：

在nginx中，这些域名被用做反向代理的upstream，在添加cloudflare之后，访问出现 http 502，具体配置如下

出错的nginx配置

location /proxy/cn/
{
    proxy_pass https://user_cs_cn_backend/;
    proxy_http_version 1.1;
    proxy_set_header Host "api-cs-cn-sandbox.intsig.net";
    proxy_set_header Connection "keep-alive";
    proxy_connect_timeout 5;
    proxy_send_timeout 10;
    proxy_read_timeout 10;
}

wireshark抓包

证书过期问题导致的网关层返回502错误

背景：

新对接的新服务，在nginx上配置为反向代理upstream进行访问

业务方出现的问题：

访问时稳定复现502错误，但是使用curl则正常。nginx配置如下：

出错的nginx配置

location /test
{
    proxy_pass https://middleground_workonly_backend/xxx/xxx;
    proxy_http_version 1.1;
    proxy_set_header Host "xxx-sandbox-workonly.xxx.xxx";
    proxy_set_header Connection "keep-alive";
    proxy_connect_timeout 5;
    proxy_send_timeout 10;
    proxy_read_timeout 10;
}

wireshark抓包

nginx 负载均衡导致的400错误

背景：

因为转换服务比较耗CPU等资源，业务层针对pdf转offcie服务做负载均衡

出现问题：

未做负载均衡前，一切正常；添加负载均衡之后反而失败了

出错的nginx配置

location /aspose_sdk/
{
    client_body_buffer_size 30M;
    client_max_body_size 30M;
    proxy_pass http://aspose_sdk/;
    proxy_set_header Connection "";
    proxy_http_version 1.0;
    proxy_connect_timeout 10;
    proxy_send_timeout 30;
    proxy_read_timeout 300;
}

关于性能测试

• 目标：性能测试是软件开发生命周期中的一个关键阶段，旨在识别潜在的瓶颈，并确保应用程序在预期的用户负载下满足其性能标准

一、性能测试指标

• 响应时间
  • ❌ 平均响应时间（ART）意义不大
  • ✅ 最大响应时间（MRT）
  • ✅ 百分位响应时间：P50、P90、P99
• 吞吐量
  • ✅ 请求速率（RPS）
  • ✅ 网络吞吐量（MB/s）
  • ❌ 事务速率（TPS）
• 容量指标
  • ✅ 最大并发用户数（MCU）
  • ✅ 系统承载峰值

eBPF的原理

使用验证器保证安全性，通过BPF映射实现内核-用户空间通信 所有与用户空间的交互都是通过 eBPF“映射”进行的，这些映射是键值存储。 每个 eBPF 程序都将在一定的有限执行时间内完成，即非图灵完备

bcc

BCC适合使用了其他库的复杂脚本、守护进程

bpftrace

• 优点： bpftrace基于内置Linux技术，不用追赶内核版本改动，稳定性更高 脚本执行速度比systemtap快（使用llvm编译成BPF）

• 缺点： bpftrace语言特性上没有systemtap丰富，不太能进行复杂的探测操作 探针附到函数一定偏移处不方便 无法直接获取函数的局部变量 无法直接获取结构体信息 内核版本要求较高，在较旧的发行版上难以安装

SystemTap

SystemTap Tapset Reference Manual

by SystemTap

Copyright © 2008-2015 Red Hat, Inc. and others

This documentation is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 aspublished by the Free Software Foundation.

动态追踪原理

动态追踪工具在逻辑上比较简单：大多是通过类C语言创建一个脚本，通过编译器翻译成探测代码。通过一个内核地址模块加载探测代码到内核地址空间，然后patch到当前内核的二进制代码中。探针将收集的数据写到中间缓冲（这些buffers往往是lock-free的，所以他们对内核性能有较少影响，且不需要切换上下文到追踪程序）。另一个独立的实体消费者读取这些buffers，然后输出数据。