Skip to content

feat: cmk Linux agent data emitted from metrics-cache - #32

Open
racicLuka wants to merge 1 commit into
masterfrom
CMK-36614-linux-agent-emit
Open

feat: cmk Linux agent data emitted from metrics-cache#32
racicLuka wants to merge 1 commit into
masterfrom
CMK-36614-linux-agent-emit

Conversation

@racicLuka

Copy link
Copy Markdown
Contributor

CMK-36614

@racicLuka
racicLuka requested a review from relrod August 13, 2026 18:46
pub metrics: MetricTables,
pub indexes: Indexes,
pub self_health: SelfHealth,
pub system_agent_snapshot: HashMap<String, Bytes>,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd store the actual arced MetricsFetcherIngestion here, for a few reasons:

  1. The main reason for MetricsFetcherIngestion as an abstraction at all is so we can store some metadata (namely the ingestion timestamp) alongside it and ideally eventually emit that in the self-health sections in the future. But if we only store the Bytes we lose that.
  2. We arc the MetricsFetcherIngestion so we can easily clone it as a whole, so we might as well use that. Yes axum::body::Bytes is reference counted and can be cloned cheaply too, but it doesn't really buy us anything and see (1) 😅

})
}

pub fn from_raw(piggyback_hostname: String, raw: Bytes) -> Self {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd match of() here e.g. take &str in the first arg and probably rename to just raw().

@@ -1,3 +1,4 @@
use axum::body::Bytes;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to use Bytes here, but let's use bytes::Bytes directly instead of Axum's re-export of it. (We can add the direct dependency on bytes if it's not there yet).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The String::from_utf8_lossy() on 22 is incompatible with the Bytes we store now (we could potentially change the agent output there by altering non-utf8-compliant bytes which would be non-ideal).

I'd probably change the handler to return Bytes instead of String and change the last line to Ok(out.into()).

(A test here would be nice but is probably a bit difficult to set up, so you can ignore it for now)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants