feat: Support MSSQL packets

[Orenico10]

This enables instrumentation of requests and queries to Microsoft SQL Server (mssql) from OBI services. Implemented similarly to how MySQL and PostgreSQL instrumentation are implemented.
Resolve #1285

Checklist

• If this enhances / fixes / changes a core feature, I have updated the features documentation

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Copilot / name: Copilot (0c880fe, 2ffaf13, 887da01, dac879f)
• ✅ login: Orenico10 / name: Oren (030bf97, 0a868e5, 0c880fe, 0f8e3c9, 18a86bd, 266e2d6, 2ffaf13, 3327bc2, 375fab2, 39cf71d, 3add9cb, 3c47303, 3c6057f, 3fd2aa8, 4121611, 47a6231, 4a49bfe, 4d537ef, 4daf722, 4ede158, 52f63f1, 636762d, 64f637e, 692947b, 85d0306, 87e8be5, 887da01, 922572b, 94e44c3, a033a37, aa598a4, afbfa36, c9d4dda, cb91f4e, d283e7e, d54fe0d, d7b7fec, dac879f, dd817d6, de76d6f, f519a85, ff02e18)
• ✅ login: Orenico10 / name: Orenico10 (1d879d1, 6d107d6, 6dc1f66, 8d491b9, 9324bbe, da3ca69)

[NimrodAvni78]

This is great, thanks!

would love to see some integration tests for this, im pretty sure there are some open source images for mssql we can use

i think after pushing a new commit tests will also start running

also adding copilot for review

[Copilot]

Pull request overview

Adds Microsoft SQL Server (MSSQL/TDS) support to OBI’s eBPF-based TCP/SQL instrumentation so MSSQL requests can be detected, parsed (including prepared statement flows), and emitted as SQL client spans.

Changes:

• Add kernel-space (eBPF) protocol detection and large-buffer capture support for MSSQL/TDS.
• Add user-space MSSQL SQL detection/parsing (batch + RPC prepare/execute caching) and wire it into the TCP span pipeline.
• Extend configuration/defaults and documentation to expose MSSQL buffer sizing + prepared statement cache sizing.

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
pkg/obi/config_test.go	Updates default-config expectations to include MSSQL prepared statement cache size.
pkg/obi/config.go	Adds MSSQL defaults (buffer size + prepared statement cache size).
pkg/internal/sqlprune/sqlparser.go	Routes SQL command/error parsing to MSSQL-specific parser.
pkg/internal/sqlprune/mssql.go	Implements basic MSSQL/TDS response error parsing + command ID mapping.
pkg/internal/ebpf/generictracer/generictracer.go	Exposes mssql_buffer_size constant to eBPF program.
pkg/ebpf/common/tcp_detect_transform.go	Adds MSSQL protocol-type handler to produce SQL spans (or fallback).
pkg/ebpf/common/sql_detect_transform.go	Adds MSSQL detection to SQL kind heuristics + prepared statement parsing hook.
pkg/ebpf/common/sql_detect_mssql.go	Implements MSSQL/TDS header validation, UCS-2 decoding, RPC parsing, and prepared-stmt handle caching.
pkg/ebpf/common/sql_detect_mssql_test.go	Adds unit tests for MSSQL detection and parsing helpers.
pkg/ebpf/common/common.go	Adds MSSQL protocol enum + parse-context LRU for MSSQL prepared statements.
pkg/config/ebpf_tracer.go	Adds MSSQL prepared statement cache size + MSSQL buffer size config knobs.
pkg/appolly/app/request/span.go	Adds DBMSSQL kind and maps it to OTel db.system semantic convention.
devdocs/features.md	Documents MSSQL support in feature matrix.
bpf/generictracer/protocol_tcp.h	Enables MSSQL large-buffer emission in TCP protocol handler.
bpf/generictracer/protocol_mssql.h	Adds MSSQL/TDS protocol detection + large-buffer emission implementation.
bpf/generictracer/k_tracer.c	Adds MSSQL detection in kernel-side protocol classification pipeline.
bpf/common/large_buffers.h	Adds MSSQL buffer-size constant and scratch buffer.
bpf/common/connection_info.h	Adds MSSQL protocol enum value for kernel/user alignment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Orenico10]

This is great, thanks!

would love to see some integration tests for this, im pretty sure there are some open source images for mssql we can use

i think after pushing a new commit tests will also start running

@NimrodAvni78 I tried searching internal/test/integration/ to see what an integration test in this project looks like, and I'm not sure whether you want to see something like pythonsql (internal/test/integration/components/pythonsql/) or if I should be doing something else entirely.

There is an official image for mssql: mcr.microsoft.com/mssql/server:2022-latest (we can use a newer version if needed), and a native Python library called pymssql that can be used to query the DB.

Would using all of that, and adding a test, similar to how the docker-compose-python-mysql.yml runs, be sufficient?

[rafaelroquetto]

Good stuff! Thank you so much for spearheading this!

If possible, avoid materialising a byte slice and instead use the large buffer API directly - or, I see that some of the functions here are a perfect fit for the large buffer Reader (cursor) API - using those prevents us from having to allocate a big scratch chunk and instead will consume the bytes mostly in-place from the original backing store.

Also, this will conflict with: #1513 - since that PR is already approved, could you wait until that's in and rebase on top of it?

[Orenico10]

Good stuff! Thank you so much for spearheading this!

If possible, avoid materialising a byte slice and instead use the large buffer API directly - or, I see that some of the functions here are a perfect fit for the large buffer Reader (cursor) API - using those prevents us from having to allocate a big scratch chunk and instead will consume the bytes mostly in-place from the original backing store.

Also, this will conflict with: #1513 - since that PR is already approved, could you wait until that's in and rebase on top of it?

@rafaelroquetto Thanks :) Is there a guide for the new large buffer API, or an example I can take a look at and try to adapt my code to work with it? I didn't realize what I already modified in my code to work with largebuf.LargeBuffer is what you meant, I will modify my code to work with it.
In addition to that, could you let me know when #1513 is merged so I can merge main into my branch and resolve the conflicts?

[NimrodAvni78]

@NimrodAvni78 I tried searching internal/test/integration/ to see what an integration test in this project looks like, and I'm not sure whether you want to see something like pythonsql (internal/test/integration/components/pythonsql/) or if I should be doing something else entirely.

There is an official image for mssql: mcr.microsoft.com/mssql/server:2022-latest (we can use a newer version if needed), and a native Python library called pymssql that can be used to query the DB.

Would using all of that, and adding a test, similar to how the docker-compose-python-mysql.yml runs, be sufficient?

yeah something like this, add an example service testing different scenarios (in my head the main ones are plain query, error query and prepared statement), and testing it the same as other protocols like mysql

[Orenico10]

yeah something like this, add an example service testing different scenarios (in my head the main ones are plain query, error query and prepared statement), and testing it the same as other protocols like mysql

Should I wait for #1539 so I don't cause conflicts?

[mmat11]

left a couple nits, lgtm!

[codecov]

Codecov Report

❌ Patch coverage is 51.33531% with 164 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.19%. Comparing base (360521f) to head (d54fe0d).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/ebpf/common/sql_detect_mssql.go	47.59%	99 Missing and 21 partials ⚠️
pkg/internal/sqlprune/mssql.go	50.00%	35 Missing and 6 partials ⚠️
pkg/ebpf/common/sql_detect_transform.go	71.42%	2 Missing ⚠️
pkg/ebpf/common/common.go	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1533      +/-   ##
==========================================
+ Coverage   67.22%   69.19%   +1.97%     
==========================================
  Files         277      279       +2     
  Lines       33258    33594     +336     
==========================================
+ Hits        22358    23246     +888     
+ Misses       9539     9092     -447     
+ Partials     1361     1256     -105     

Flag	Coverage Δ
integration-test	56.26% <41.22%> (+0.77%)	⬆️
integration-test-arm	29.10% <5.04%> (-0.36%)	⬇️
integration-test-vm-x86_64-5.15.152	29.45% <4.96%> (-0.15%)	⬇️
integration-test-vm-x86_64-6.10.6	30.04% <14.50%> (+0.46%)	⬆️
k8s-integration-test	42.45% <4.19%> (-0.63%)	⬇️
oats-test	37.72% <5.34%> (-1.06%)	⬇️
unittests	58.29% <48.85%> (+6.94%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[NimrodAvni78]

Should I wait for #1539 so I don't cause conflicts?

Don't think so, that will only effect mysql test suite

[Orenico10]

I merged origin/main to my branch to deal with the conflicts. it should be good to go :)

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 6 comments.

[github-actions]

CI Supervisor: Pull request checks (attempt 2)

Job	Conclusion	Duration	Verdict
Lint	failure	4m	unrecoverable (lint failure)
Unit test 2 - pkg/statsolly/agent and 57 others	failure	3m	flaky
Action: NOT re-running. Reason: Maximum re-run attempts reached (attempt 2 of 2)

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated no new comments.

[mmat11]

lgtm!

[rafaelroquetto]

This looks great, there's just one major last change we should do - decouple the eom detection from mssql_send_large_buffer, as that's completely orthogonal and does not belong there (unless I am missing something).

Otherwise, some minor feedback:

• missing default for MSSQLPreparedStatementsCacheSize - since the field has validate:"gt=0", OBI will fail validation on startup unless the user explicitly sets it
• mssqlPreparedStatements function is misnamed: it handles SQL_BATCH plain queries, not prepared statements. RPC/prepared-statement handling is in handleMSSQL directly. Name it mssqlExtractBatchSQL or similar.
• improvements to multi-packet test: testPythonSQLMultiPacketResponse only asserts a SELECT span appeared, it doesn't verify the SQL text was correctly reassembled. The whole point of the /largeresult endpoint and bulk_actor table is to force multi-packet reassembly, but the assertion doesn't confirm it worked.
• BPF/Go detection divergence: BPF is_mssql accepts login7/prelogin packets; Go isMSSQL does not. Not a bug (login packets don't carry SQL), but undocumented and will confuse anyone trying to understand why the two functions differ.

(these bullet points were generated with the help of Claude).

The PR looks good overall, I am marking this with "request changes" just to prevent it from accidentally being merged since it's already gotten an approval.

[rafaelroquetto]

I am not sure if this is the best place for this - this seems to be detecting the end of a message, even when large buffers are not enabled for this protocol (i.e. mssql_max_captured_byted == 0). In this scenario, no buffer will ever be sent but yet this function is performing unrelated work for every packet.

Maybe it would be cleaner to have someething like mssql_respnse_complete() instead, to be called from handle_unknown_tcp_connection() alongside the large buffer call, as it is somewhat unrelated.