Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new(plugin_api): add plugin metrics support #1828

Merged
merged 3 commits into from May 16, 2024

Conversation

mrgian
Copy link
Contributor

@mrgian mrgian commented May 3, 2024

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
Adds metrics support to the plugin API.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

new(plugin_api): add plugin metrics support

@FedeDP
Copy link
Contributor

FedeDP commented May 7, 2024

/milestone 0.17.0

@poiana poiana added this to the 0.17.0 milestone May 7, 2024
userspace/libsinsp/plugin.cpp Show resolved Hide resolved
userspace/libsinsp/plugin.cpp Outdated Show resolved Hide resolved
userspace/plugin/plugin_types.h Show resolved Hide resolved
userspace/plugin/plugin_types.h Outdated Show resolved Hide resolved
@incertum
Copy link
Contributor

incertum commented May 9, 2024

New proposal @mrgian: A bummer that the plugin system is so restrictive, but let's focus on this PR.

Why don't we just define a vanilla struct for the plugin metrics and then return that struct via the sinsp_plugin::get_metrics() call and then create the actual metrics within the libsinsp metrics collector.

That way we don't need any of the redefinitions and it would be very similar approach to how we retrieve the libsinsp state metrics, for instance checkout the sinsp_stats_v2 struct and handling of it in the metrics libs collector.

@mrgian
Copy link
Contributor Author

mrgian commented May 9, 2024

@incertum Keep in mind that the main point of this feature is to let plugins define their own custom metrics.
sinsp_stats_v2 consists of a fixed set of metrics.
If we do the same with plugins, how they will be able to define a new custom metric?

@incertum
Copy link
Contributor

incertum commented May 9, 2024

@incertum Keep in mind that the main point of this feature is to let plugins define their own custom metrics. sinsp_stats_v2 consists of a fixed set of metrics. If we do the same with plugins, how they will be able to define a new custom metric?

Oh I somehow thought we wanted just some fixed wrapper metrics like event counts, drops etc since that is what we exposed in Falco before.

Anyways given the plugin system is how it is, seems that we need to keep re-defining things. Just like I called out that it is not a nice approach to needing to redefine the event types when writing a plugin for the syscalls source ...
Wondering is this really the only way it can be cc @jasondellaluce? Is there no chance to have a plugin system that integrates more easily with libs back and forth?

incertum
incertum previously approved these changes May 14, 2024
Copy link
Contributor

@incertum incertum left a comment

Choose a reason for hiding this comment

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

/approve

@poiana
Copy link
Contributor

poiana commented May 14, 2024

LGTM label has been added.

Git tree hash: f1cb57941205278b29711a490fde0ac29f8dfa59

@FedeDP
Copy link
Contributor

FedeDP commented May 15, 2024

Windows CI is failing plus there is now a conflict :) Care to take a look? Thanks!

@poiana poiana requested a review from incertum May 15, 2024 08:06
@mrgian
Copy link
Contributor Author

mrgian commented May 15, 2024

@FedeDP Can you re-run the CI? The Windows build should be ok now (I hope). Thanks :)

@FedeDP
Copy link
Contributor

FedeDP commented May 15, 2024

/cc @jasondellaluce

@mrgian mrgian force-pushed the plugin-api-metrics-finalized branch from 09a4324 to 846da48 Compare May 15, 2024 09:35
Signed-off-by: Gianmatteo Palmieri <mail@gian.im>
Signed-off-by: Gianmatteo Palmieri <mail@gian.im>
Signed-off-by: Gianmatteo Palmieri <mail@gian.im>
@mrgian mrgian force-pushed the plugin-api-metrics-finalized branch from 846da48 to 2ccdd8e Compare May 15, 2024 12:36
@@ -890,3 +891,39 @@ TEST(sinsp_plugin, plugin_set_config)

libsinsp_logger()->remove_callback_log();
}

#ifdef __linux__
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this linux only?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

libs_metrics_collector is currently compiled on linux only (see https://github.com/falcosecurity/libs/blob/master/userspace/libsinsp/metrics_collector.h#L82)

I think the reason behind is that we had linux-only metrics.
However, with this PR that's not the case anymore, so we should definitely enable metrics in other platforms too.
I'm working on that, but maybe it's better to open another PR when I'm done :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Out of simplicity as macOS and Windows were / are not a primary metrics use case. In more detail it's because of how we compute CPU usage etc, which is Linux specific.

I believe there is no harm to refine what actually only needs to be linux. @mrgian does this help?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hey @incertum Thank you!
I believe we just need to rearrange #ifdef __linux__ directives.
The only hiccup I had is in https://github.com/falcosecurity/libs/blob/master/userspace/libsinsp/metrics_collector.cpp#L35-L56
That uses designated initialization (explicit array indexes) which is not supported by MSVC.
However I don't think removing these explicit indexes is a big problem, the comment on top should be enough for contributors to understand that metrics_unit_name_mappings_prometheus and metrics_metric_type_name_mappings_prometheus need to stay in sync with the enums in metrics_v2.h.

Copy link
Contributor

Choose a reason for hiding this comment

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

Out of scope, but have we ever thought about using a client library for prometheus, like: https://github.com/jupp0r/prometheus-cpp ? @incertum

Copy link
Contributor

Choose a reason for hiding this comment

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

@FedeDP see the previous discussions; that was the whole point of not adding another lib as we have a more unique use case with all of our different metrics spanning multiple areas of the code base, plus that lib seems not very suitable and supported enough IMO.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks Melissa! I probably lost that part :)

Copy link
Contributor

Choose a reason for hiding this comment

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

@mrgian mind elaborating However I don't think removing these explicit indexes is a big problem,?

Copy link
Contributor Author

@mrgian mrgian May 16, 2024

Choose a reason for hiding this comment

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

mrgian@cddf7b7
👆 @incertum This is what I've done to make libs_metrics_collector compile on Windows.
Notice how I had to remove designation initializers from metrics_unit_name_mappings_prometheus, it allows to compile with MSVC and the code behavior stays the same.
However we now have to make sure metrics_unit_name_mappings_prometheus has the same ordering as the values in metrics_v2_value_unit in metrics_v2.h. This comment should be enough to make contributors aware of this.
The same applies for metrics_metric_type_name_mappings_prometheus.

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe ok for now since we don't have much time left for the next release.

Copy link
Contributor

@incertum incertum left a comment

Choose a reason for hiding this comment

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

/approve

@poiana poiana added the lgtm label May 16, 2024
@poiana
Copy link
Contributor

poiana commented May 16, 2024

LGTM label has been added.

Git tree hash: 677159adc1a667b27f25cfc8d61164a9366f085e

Copy link
Contributor

@FedeDP FedeDP left a comment

Choose a reason for hiding this comment

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

/approve

@poiana
Copy link
Contributor

poiana commented May 16, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: FedeDP, incertum, mrgian

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@poiana poiana merged commit 0c3e799 into falcosecurity:master May 16, 2024
39 of 40 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants