chore: test to prod#199
Conversation
Moved regex compilations in `ebpftracer/tls.go` to package-level variables. Previously, `regexp.MustCompile` was called every time `getSslLibPathAndVersion` was executed (scanning process maps), which is expensive. This change compiles the regexes once at startup, reducing CPU overhead and allocations. Impact: - Eliminates regex compilation overhead (parsing + compilation) for each call. - Reduces memory allocations during process scanning.
…-15837461305579583930 ⚡ Bolt: Optimize regex compilation in TLS tracer
* fix: fix for unexpected token error * fix: resolve concurrent map access crash in updateDelays and handle systemd services - Fix concurrent map read/write crash in updateDelays by using proper locking: - Get PIDs snapshot under read lock - Make syscalls without holding lock to avoid contention - Update delays under write lock - Fix "unexpected container id" errors for systemd services: - Only resolve pod owner for k8s containers (/k8s/ or /k8s-cronjob/ prefixes) - Use container name as workload for non-k8s containers - Skip systemd services that match IGNORE_CONTROL_PLANE list in calcId Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: reduce l7_events log spam and increase perf buffer - Increase l7_events perf buffer from 64 to 128 pages per CPU to reduce lost samples - Add rate-limited logging for lost samples (aggregate and log every 10s instead of per-event) - Include CPU info in lost samples log for better debugging The duplicate log lines (4x) were caused by per-CPU lost sample records being logged separately. Now they are aggregated and logged periodically. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: prevent duplicate klog output Initialize klog flags properly to prevent duplicate log output. The issue was that klog was outputting to both the custom writer and stderr by default. Setting logtostderr=false, alsologtostderr=false, and stderrthreshold=FATAL ensures only the custom output is used. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: use klog.ErrorS to prevent duplicate log output Replace klog.Errorf with klog.ErrorS for lost samples logging. klog.Errorf logs to ERROR, WARNING, and INFO levels causing 3x duplicates. klog.ErrorS uses structured logging and only logs once at the ERROR level. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * fix: use standard log.Printf to prevent duplicate output Replace klog.ErrorS with log.Printf for lost samples logging. Both klog.Errorf and klog.ErrorS output to multiple severity levels (ERROR, WARNING, INFO) by design, causing 3x duplicates. The standard log package writes once to the configured output (our RateLimitedLogOutput) without duplication. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * fix: protect activeConnections map iteration in Collect Add read lock when iterating over activeConnections map in the Collect function to prevent concurrent map iteration and map write errors during Prometheus metric collection. The race condition occurs when: - Prometheus calls Collect() which iterates over activeConnections - Concurrently, connection events modify activeConnections Error: fatal error: concurrent map iteration and map write at containers/container.go:455 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * fix: add panic recovery to ClickHouse parser Prevent agent crashes when receiving malformed or incomplete ClickHouse protocol packets by adding defer/recover pattern to ParseClickhouse. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Replaced make([]byte) with stack-allocated arrays for IP and port buffers. Used hex.Decode directly into stack buffers. This eliminates heap allocations in the hot path of parsing /proc/net/tcp. Benchmarks: IPv4: 88ns -> 38ns (-57%) IPv6: 160ns -> 67ns (-58%) Allocs: 1 -> 0 (-100%) Co-authored-by: blue4209211 <3078106+blue4209211@users.noreply.github.com>
…nfrastructure - Strict HTTP/2 detection requiring HEADERS frame with HPACK static table match - DNS protocol ordering fix to prevent DNS/HTTP/2 misclassification - HPACK fault tolerance for mid-stream HTTP/2 connection monitoring - HTTP/2 CONTINUATION frame support and per-fd parser isolation - LLM provider detection (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI) - Request/response payload structure analysis for provider identification - OTel GenAI semantic convention metrics (container_llm_*) - DNS cache lookup at L7 request time for hostname resolution - eBPF verifier-safe pointer arithmetic for frame scanning - Various protocol detection, memory optimization, and stability fixes
…nfrastructure (#180) - Strict HTTP/2 detection requiring HEADERS frame with HPACK static table match - DNS protocol ordering fix to prevent DNS/HTTP/2 misclassification - HPACK fault tolerance for mid-stream HTTP/2 connection monitoring - HTTP/2 CONTINUATION frame support and per-fd parser isolation - LLM provider detection (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI) - Request/response payload structure analysis for provider identification - OTel GenAI semantic convention metrics (container_llm_*) - DNS cache lookup at L7 request time for hostname resolution - eBPF verifier-safe pointer arithmetic for frame scanning - Various protocol detection, memory optimization, and stability fixes
Bumps [github.com/opencontainers/selinux](https://github.com/opencontainers/selinux) from 1.11.0 to 1.13.0. - [Release notes](https://github.com/opencontainers/selinux/releases) - [Commits](opencontainers/selinux@v1.11.0...v1.13.0) --- updated-dependencies: - dependency-name: github.com/opencontainers/selinux dependency-version: 1.13.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
…12884711624083843 ⚡ Bolt: Optimize decodeAddr in proc/net to zero allocations
…m/opencontainers/selinux-1.13.0 chore(deps): bump github.com/opencontainers/selinux from 1.11.0 to 1.13.0
…8163120042195743 ⚡ Bolt: Optimize eBPF event parsing by replacing binary.Read
chore: main to test
Summary of ChangesHello @mayankpande88, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request delivers a major upgrade to the L7 tracing capabilities, particularly focusing on Go TLS and HTTP/2 traffic. The core intent is to provide more reliable and detailed monitoring for modern application protocols, with a significant emphasis on capturing and analyzing LLM API interactions, including streaming scenarios. The changes address several challenges in eBPF-based tracing, such as race conditions in event processing and the complexities of Go runtime and HTTP/2 protocol parsing, leading to a more robust and insightful observability solution. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request significantly enhances L7 tracing capabilities, especially for Go applications, gRPC, and LLM observability, by introducing features such as ring buffers for L7 events, advanced eBPF techniques for Go TLS and socket info extraction, and new LLM stream tracking with OTel-compliant metrics. However, two security issues require attention: a memory leak in the HTTP/2 parser management and a potential cardinality explosion in Prometheus metrics due to untrusted input. Additionally, there is a minor suggestion regarding some potentially unused code.
| lastConnectionAttempts map[common.HostPort]time.Time | ||
| activeConnections map[ConnectionKey]*ActiveConnection | ||
| connectionsByPidFd map[PidFd]*ActiveConnection | ||
| googleHTTP2Parsers map[PidFd]*l7.Http2Parser // Per-connection HTTP/2 parsers (keyed by pid:fd for correct HPACK state) |
There was a problem hiding this comment.
The googleHTTP2Parsers map stores an Http2Parser for every HTTP/2 connection (keyed by PID and FD). However, there is no logic to remove entries from this map when a connection is closed. This leads to a memory leak that grows with the number of HTTP/2 connections made by processes in the container. Over time, this can lead to memory exhaustion and crash the agent.
To fix this, ensure that entries are removed from googleHTTP2Parsers in the onConnectionClose method or during the garbage collection process.
| ContainerLLMRequestsTotal.With(prometheus.Labels{ | ||
| "container_id": containerID, | ||
| "gen_ai_operation_name": operation, | ||
| "gen_ai_request_model": model, | ||
| "gen_ai_system": string(provider), | ||
| "server_address": host, | ||
| "http_response_status_code": "200", | ||
| }).Inc() | ||
|
|
||
| if llmResp != nil { | ||
| if llmResp.PromptTokens > 0 { | ||
| ContainerLLMTokenUsageTotal.With(prometheus.Labels{ | ||
| "container_id": containerID, | ||
| "gen_ai_operation_name": operation, | ||
| "gen_ai_request_model": model, | ||
| "gen_ai_system": string(provider), | ||
| "server_address": host, | ||
| "gen_ai_token_type": "input", | ||
| }).Add(float64(llmResp.PromptTokens)) | ||
| } | ||
| if llmResp.CompletionTokens > 0 { | ||
| ContainerLLMTokenUsageTotal.With(prometheus.Labels{ | ||
| "container_id": containerID, | ||
| "gen_ai_operation_name": operation, | ||
| "gen_ai_request_model": model, | ||
| "gen_ai_system": string(provider), | ||
| "server_address": host, | ||
| "gen_ai_token_type": "output", | ||
| }).Add(float64(llmResp.CompletionTokens)) | ||
| } | ||
| } | ||
|
|
||
| ContainerLLMRequestDuration.With(prometheus.Labels{ | ||
| "container_id": containerID, | ||
| "gen_ai_operation_name": operation, | ||
| "gen_ai_request_model": model, | ||
| "gen_ai_system": string(provider), | ||
| "server_address": host, | ||
| }).Observe(duration.Seconds()) |
There was a problem hiding this comment.
The server_address label in LLM metrics is derived from the untrusted Host or :authority header of the HTTP request. An attacker can exploit this to cause a cardinality explosion by sending many requests with unique Host headers to endpoints that match LLM path patterns (e.g., /v1/chat/completions). This can lead to excessive memory consumption by the Prometheus registry and potentially crash the agent or the monitoring system.
Consider validating the host against a whitelist of known LLM providers or limiting the number of unique values for the server_address label to mitigate this risk.
No description provided.