整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
融界 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探針中四個參數分別為：
end探針中只存在一個res參數，該參數為會話執行SQL的返回狀態，非0表示SQL執行異常。
eBPF USDT如何實時識別MySQL異常訪問來源?
1）環境準備
準備一臺 Linux 機器，安裝好g++和bcc2）基于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）等信息。然后我們針對采集上來的數據就可以做分析了：
總結
借助eBPF技術的強大能力，我們可以利用MySQL的USDT探針來捕獲和深入分析與數據庫SQL連接相關的操作活動。通過本文的詳細闡述，您對否對eBPF技術在數據庫性能監控和優化方面的應用有了更深層次的理解和認識？
您的MySQL異常來源訪問識別出來了嗎？歡迎加入技術交流群與我們討論！
DBdoctor推出長久免費版
DBdoctor是一款企業級數據庫全方位性能監控與診斷平臺，致力于解決一切數據庫性能問題。可以對商業數據庫、開源數據庫、國產數據庫進行統一性能診斷。
具備：SQL審核、巡檢報表、監控告警、存儲診斷、審計日志、權限管理等免費功能，不限實例個數，可基于長久免費版快速搭建企業級數據庫監控診斷平臺。
同時擁有：性能洞察、鎖分析、根因診斷、索引推薦、SQL發布前性能評估等高階功能，官網可快速下載，零依賴，一分鐘快速一鍵部署。
如果您想要試用全部功能可添加公眾號自助申請專業版license。成為企業用戶可獲得產品定制、OpenAPI集成、一對一專家等高階服務。歡迎添加小助手微信了解詳細信息！
1??免費下載/在線試用：
https://dbdoctor.hisensecloud.com/col.jsp?id=126
探針，用來收集和發送數據到歸集器。 參考官網給出的幫助 Setup java agent，我們需要使用官方提供的探針為我們達到監控的目的，按照實際情況我們需要實現三種部署方式
探針文件在 apache-skywalking-apm-incubating/agent 目錄下
源碼目錄
繼續之前的案例項目，創建一個名為 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
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 通過業務調用監控進行依賴分析，提供給我們了服務之間的服務調用拓撲關系、以及針對每個 Endpoint 的 Trace 記錄。
點擊 Trace 菜單，進入追蹤頁
image
點擊 Trace ID 展開詳細信息
image
image
上圖展示了一次正常的響應，總響應時間為 185ms 共有一個 Span（基本工作單元，表示一次完整的請求，包含響應，即請求并響應）
Span /echo/{message} 說明如下：
點擊 Service 菜單，進入服務性能指標監控頁
image
選擇希望監控的服務
image
點擊 More Server Details... 還可以查看詳細信息
image
image
上圖中展示了服務在一定時間范圍內的相關數據，包括：
/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
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
