整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

精测电子申请一种探针卡制备方法专利,提高悬臂针密度和装配效率

融界 2024 年 7 月 28 日消息,天眼查知识产权信息显示,武汉精毅通电子技术有限公司,武汉精测电子集团股份有限公司申请一项名为“一种探针卡制备方法“,公开号 CN202410470504.3,申请日期为 2024 年 4 月。

专利摘要显示,本发明公开了一种探针卡制备方法,属于探针卡技术领域。所述制备方法包括:提供基板,并在基板进行第一表面微加工,从而在基板上制备得到薄膜电路层,薄膜电路层中具有多个电路;在薄膜电路层依次进行第二表面微加工、第三表面微加工和第四表面微加工,从而依次制备得到针底座层、针臂层和针尖层;对针底座层、针臂层和针尖层进行分离去除,使得薄膜电路层上仅形成多个悬臂针,并去除基板的外边缘结构,使得薄膜电路层的边缘凸出布置;基于多个电路,通过将薄膜电路层外边缘弯曲后连接 PCB 板。本发明实施例提供的一种探针卡制备方法,不仅可以便捷制备探针卡,还能提高悬臂针的密度,同时提高了装配效率,有效促进探针卡的发展。

本文源自金融界

各位小伙伴们,非常感谢你们对我们eBPF专题系列文章的持续关注和热情支持!在之前的文章中,我们深入探讨了如何手写一个uprobe探测用户态程序。许多热心的小伙伴给我们发私信表达了他们对eBPF技术在数据库领域应用的浓厚兴趣,并希望我们能分享更多的相关案例。为了满足大家的期待,本文将带您深入了解用户态探测的另一种强大工具——USDT探针,以及它在数据库优化和监控中的潜在应用。

本文是我们的eBPF专题系列第五篇纯技术分享文章——如何手码eBPF程序探测MySQL5.6 USDT,来实时识别数据库可疑的连接访问来源(user/host)。

USDT原理介绍

USDT(User Statically-Defined Tracing)是动态追踪系统 DTrace 的一部分,允许在用户态应用程序中定义静态探针。这些探针提供了一个强大的调试和性能分析工具,可以在运行时捕获和分析应用程序的行为,而无需修改应用程序代码或重新编译。

  • 探针定义

开发人员在代码中插入静态探针点。这些探针点通常是一些宏定义,用于标记需要追踪的代码位置。例如,在 MySQL 中可以看到类似于 #define MYSQL_COMMAND_START(arg0, arg1, arg2, arg3) 这样的探针定义。

  • 探针注册

编译应用程序时,这些探针会被注册到探针表中,生成相应的探针元数据。探针在正常运行时是无操作的(noop),不会影响应用程序性能。

  • 探针启用

当需要调试或分析时,调试器或追踪工具(如 DTrace、SystemTap 或 BPF)可以附加到这些探针上,并启用它们。当探针被启用时,它们会执行指定的动作,例如记录日志、捕获堆栈跟踪或收集性能数据。

  • 捕获数据

当应用程序运行并触发探针时,探针会调用附加到它们的追踪程序,执行指定的调试或分析任务。这些任务可以包括打印变量值、收集性能指标等。

  • 数据分析

通过收集的数据,开发人员可以分析应用程序的行为,找出性能瓶颈、调试问题或优化代码。

MySQL5.6 DTrace探针

MySQL5.6源码probes_mysql_nodtrace.h中定义了大量的DTrace探针,我们从中选取了以下两个探测:

#define  MYSQL_COMMAND_START(arg0, arg1, arg2, arg3)
#define  MYSQL_COMMAND_DONE(arg0)

备注:MySQL源码编译指定编译选项DENABLE_DTRACE=1才能开启Dtrace探针。关于使用DTrace跟踪mysqld更多信息可查看该链接文档(https://mysql.net.cn/doc/refman/5.6/en/dba-dtrace-server.html)

MySQL源码调用上述两个Dtrace的位置:

bool dispatch_command(enum enum_server_command command, THD *thd,
          char* packet, uint packet_length)
{
  NET *net= &thd->net;
  bool error= 0;
  DBUG_ENTER("dispatch_command");
  DBUG_PRINT("info",("packet: '%*.s'; command: %d", packet_length, packet, command));

  /* SHOW PROFILE instrumentation, begin */
#if defined(ENABLED_PROFILING)
  thd->profiling.start_new_query();
#endif

  /* DTRACE instrumentation, begin,start探针 */
  MYSQL_COMMAND_START(thd->thread_id, command, &thd->security_ctx->priv_user[0], (char *) thd->security_ctx->host_or_ip);

...  
...
  /* DTRACE instrumentation, end,End探针 */
  if (MYSQL_QUERY_DONE_ENABLED() || MYSQL_COMMAND_DONE_ENABLED())
  {
    int res MY_ATTRIBUTE((unused));
    res= (int) thd->is_error();
    if (command == COM_QUERY)
    {
      MYSQL_QUERY_DONE(res);
    }
    MYSQL_COMMAND_DONE(res);  
  }


  /* SHOW PROFILE instrumentation, end */
#if defined(ENABLED_PROFILING)
  thd->profiling.finish_current_query();
#endif


  DBUG_RETURN(error);
}

start探针中四个参数分别为:

  • thread_id : MySQL内部分配的线程ID,即MySQL的Connection ID
  • command: SQL命令的枚举类型
  • priv_user: 连接的用户名
  • host_or_ip: 连接的客户端IP

end探针中只存在一个res参数,该参数为会话执行SQL的返回状态,非0表示SQL执行异常。

eBPF USDT如何实时识别MySQL异常访问来源?

1)环境准备

准备一台 Linux 机器,安装好g++和bcc

2)基于BCC工具实现探测MySQL5.6的Dtrace探针

接下来我们将基于BCC,利用USDT写一个eBPF程序,实时全量采集MySQL的访问来源(User/Host)。

a)使用BCC对探针进行探测

#!/usr/bin/python
from bcc import BPF,USDT

# BPF program to attach to the command__start USDT probe
bpf_text = """
#include <uapi/linux/ptrace.h>

int trace_command__start(void *ctx) {
    struct {
        unsigned long conn_id;
        int command;
        char user[48];
        char host[48];
    } args;

    bpf_usdt_readarg(1, ctx, &args.conn_id);
    bpf_usdt_readarg(2, ctx, &args.command);
    bpf_usdt_readarg_p(3, ctx, args.user, sizeof(args.user));
    bpf_usdt_readarg_p(4, ctx, args.host, sizeof(args.host));


    bpf_trace_printk("Command start:");
    bpf_trace_printk("Timestamp: %llu",bpf_ktime_get_ns());
    bpf_trace_printk("ConnectionId= %llu",args.conn_id);
    bpf_trace_printk("Command=%ld",args.command);
    bpf_trace_printk("User= %s",args.user);
    bpf_trace_printk("Host= %s",args.host);
    return 0;
}


int trace_command__done(void *ctx){
    bpf_trace_printk("Command done:");
    bpf_trace_printk("Timestamp: %llu",bpf_ktime_get_ns());
    int res = 0;
    bpf_usdt_readarg(1, ctx, &res);
    bpf_trace_printk("Res= %d",res);
    return 0;
}
"""

parser = argparse.ArgumentParser(description="Attach USDT probes to a running process")
parser.add_argument("pid", type=int, help="The PID of the target process")
args = parser.parse_args()
pid = args.pid
usdt = USDT(pid=pid)
usdt.enable_probe(probe = "command__start", fn_name = "trace_command__start")
usdt.enable_probe(probe = "command__done", fn_name = "trace_command__done")
bpf = BPF(text = bpf_text, usdt_contexts = [usdt])
bpf.trace_print()

b)效果演示

pid即为需要探测的mysqld的进程号,指定pid执行python invoke_static.py即可开启探测,当该mysqld有SQL执行时,该探针将触发并得到日志打印。如下示例:

远程执行连接MySQL的命令

打印观测的结果

从上面的演示中我们能看到,客户端和MySQL建立连接,显示当前连接的会话id、访问来源(user/host)、SQL Command、SQL执行开始时间、SQL结束时间、SQL是否正常执行完成(Res)等信息。然后我们针对采集上来的数据就可以做分析了:

  • 如果存在user和host为非业务网段或者非业务账号,说明存在异常来源访问。
  • 如果存SQL执行耗时过长,可能存在可疑账号在抽取数据。

总结

借助eBPF技术的强大能力,我们可以利用MySQL的USDT探针来捕获和深入分析与数据库SQL连接相关的操作活动。通过本文的详细阐述,您对否对eBPF技术在数据库性能监控和优化方面的应用有了更深层次的理解和认识?

您的MySQL异常来源访问识别出来了吗?欢迎加入技术交流群与我们讨论!

DBdoctor推出长久免费版

DBdoctor是一款企业级数据库全方位性能监控与诊断平台,致力于解决一切数据库性能问题。可以对商业数据库、开源数据库、国产数据库进行统一性能诊断。

具备:SQL审核巡检报表监控告警存储诊断审计日志权限管理等免费功能,不限实例个数,可基于长久免费版快速搭建企业级数据库监控诊断平台。

同时拥有:性能洞察、锁分析、根因诊断、索引推荐、SQL发布前性能评估等高阶功能,官网可快速下载,零依赖,一分钟快速一键部署。

如果您想要试用全部功能可添加公众号自助申请专业版license。成为企业用户可获得产品定制、OpenAPI集成、一对一专家等高阶服务。欢迎添加小助手微信了解详细信息!

1️⃣免费下载/在线试用:

https://dbdoctor.hisensecloud.com/col.jsp?id=126

ava Agent 服务器探针

探针,用来收集和发送数据到归集器。 参考官网给出的帮助 Setup java agent,我们需要使用官方提供的探针为我们达到监控的目的,按照实际情况我们需要实现三种部署方式

  • IDEA 部署探针
  • Java 启动方式部署探针(我们是 Spring Boot 应用程序,需要使用 java -jar 的方式启动应用)
  • Docker 启动方式部署探针(需要做到一次构建到处运行的持续集成效果,本章节暂不提供解决方案,到后面的实战环节再实现)

探针文件在 apache-skywalking-apm-incubating/agent 目录下

源码目录


IDEA 部署探针

继续之前的案例项目,创建一个名为 hello-spring-cloud-external-skywalking 的目录,并将 agent 整个目录拷贝进来

image

修改项目的 VM 运行参数,点击菜单栏中的 Run -> EditConfigurations...,此处我们以 nacos-provider 项目为例,修改参数如下

-javaagent:D:\Workspace\Others\hello-spring-cloud-alibaba\hello-spring-cloud-external-skywalking\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=nacos-provider
-Dskywalking.collector.backend_service=localhost:11800

image

  • -javaagent:用于指定探针路径
  • -Dskywalking.agent.service_name:用于重写 agent/config/agent.config 配置文件中的服务名
  • -Dskywalking.collector.backend_service:用于重写 agent/config/agent.config 配置文件中的服务地址

Java 命令行启动方式

java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name=nacos-provider -Dskywalking.collector.backend_service=localhost:11800 -jar yourApp.jar

测试监控

启动 nacos-provider 项目,通过观察日志可以发现,已经成功加载探针 注: 如果无法访问到,请重启skywalking容器

image

访问之前写好的接口 http://localhost:8081/echo/hi 之后再刷新 SkyWalking Web UI,你会发现 Service 与 Endpoint 已经成功检测到了

image

image

至此,表示 SkyWalking 链路追踪配置成功

SkyWalking Trace 监控

SkyWalking 通过业务调用监控进行依赖分析,提供给我们了服务之间的服务调用拓扑关系、以及针对每个 Endpoint 的 Trace 记录。

调用链路监控

点击 Trace 菜单,进入追踪页

image

点击 Trace ID 展开详细信息

image

image

上图展示了一次正常的响应,总响应时间为 185ms 共有一个 Span(基本工作单元,表示一次完整的请求,包含响应,即请求并响应)

Span /echo/{message} 说明如下:

  • Duration:响应时间 185 毫秒
  • component:组件类型为 SpringMVC
  • url:请求地址
  • http.method:请求类型

服务性能指标监控

点击 Service 菜单,进入服务性能指标监控页

image

选择希望监控的服务

image

  • Avg SLA: 服务可用性(主要是通过请求成功与失败次数来计算)
  • CPM: 每分钟调用次数
  • Avg Response Time: 平均响应时间

点击 More Server Details... 还可以查看详细信息

image

image

上图中展示了服务在一定时间范围内的相关数据,包括:

  • 服务可用性指标 SLA
  • 每分钟平均响应数
  • 平均响应时间
  • 服务进程 PID
  • 服务所在物理机的 IP、Host、OS
  • 运行时 CPU 使用率
  • 运行时堆内存使用率
  • 运行时非堆内存使用率
  • GC 情况

附A: 配置文件详解

/config/agent.config

# 当前的应用编码,最终会显示在webui上。
# 建议一个应用的多个实例,使用有相同的application_code。请使用英文
agent.application_code=Your_ApplicationName

# 每三秒采样的Trace数量
# 默认为负数,代表在保证不超过内存Buffer区的前提下,采集所有的Trace
# agent.sample_n_per_3_secs=-1

# 设置需要忽略的请求地址
# 默认配置如下
# agent.ignore_suffix=.jpg,.jpeg,.js,.css,.png,.bmp,.gif,.ico,.mp3,.mp4,.html,.svg

# 探针调试开关,如果设置为true,探针会将所有操作字节码的类输出到/debugging目录下
# skywalking团队可能在调试,需要此文件
# agent.is_open_debugging_class = true

# 对应Collector的config/application.yml配置文件中 agent_server/jetty/port 配置内容
# 例如:
# 单节点配置:SERVERS="127.0.0.1:8080" 
# 集群配置:SERVERS="10.2.45.126:8080,10.2.45.127:7600" 
collector.servers=127.0.0.1:10800

# 日志文件名称前缀
logging.file_name=skywalking-agent.log

# 日志文件最大大小
# 如果超过此大小,则会生成新文件。
# 默认为300M
logging.max_file_size=314572800

# 日志级别,默认为DEBUG。
logging.level=DEBUG


链接:https://www.jianshu.com/p/e81e35dc6406