Skip to content

Conversation

@niklasf
Copy link
Contributor

@niklasf niklasf commented Jan 20, 2026

Summary

#18134 recently added support for named sets, and #18177 fixes the parsing of named counters. This now fully supports named counters for consistency.

feature anonymous named
counter ✔️ via comment on rule (v1.37.0) 🚧 this pr
sets uninteresting (always constant) ✔️ #18134 (unreleased)

Additionally, supporting anonymous counters via comments on the rule feels a bit hacky when there is a dedicated way to name counters. Introduce a new option anonymous_counters to allow turning this off, without changing the default behavior.

cc @skartikey

Checklist

  • No AI generated code was used in this PR

Related issues

based on #18135

@telegraf-tiger telegraf-tiger bot added feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/input 1. Request for new input plugins 2. Issues/PRs that are related to input plugins labels Jan 20, 2026
@niklasf niklasf changed the title feat(inputs.nftables): Consistently support named counters feat(inputs.nftables): Monitor named counters Jan 20, 2026
@niklasf niklasf force-pushed the feat/nftables-consistency branch from 882d1f1 to 1929c4e Compare January 20, 2026 22:29
Copy link
Member

@srebhan srebhan left a comment

Choose a reason for hiding this comment

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

Thanks @niklasf for working on the nftables plugin! Much appreciated. I do have one suggestion on how to configure things...

Comment on lines 12 to 14
## Include anonymous counters, identified by a unique comment on the rule.
## Rules without a comment are ignored.
# anonymous_counters = true
Copy link
Member

Choose a reason for hiding this comment

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

How about making this an include field with potential values

with an empty default?

This will make the whole construct more speaking and allows the user to configure the plugin output in a fine-grained fashion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good.

Regarding the default: I think the best default would be include = [ "counters", "sets" ], but omitting anonymous counters by default would be a breaking change (v1.37.0 monitors them), so I set include = [ "counters", "sets", "anonymous-counters" ].

Copy link
Member

Choose a reason for hiding this comment

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

Well I would omit sets and anonymous-counters in the defaults, i.e.

include = [ "counters"]

as this would represent what is there in v1.37.0.

Copy link
Contributor Author

@niklasf niklasf Jan 27, 2026

Choose a reason for hiding this comment

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

Unfortunately v1.37.0 is essentially include = [ "anonymous-counters" ], which in my opinion now looks like a weird choice, but it's just how this plugin started out. It's at least weird enough that it required that note:

Important

Rules are identified by the associated comment so those comments have to be unique! Rules without comment are ignored.

include = [ "counters" ] or include = [ "sets", "counters" ] would make more sense to me, but I believe for backwards compatibility it must then be
include = [ "counters", "anonymous-counters" ] or include = [ "sets", "counters", "anonymous-counters" ] respectively.

Thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

Well if v1.37.0 is include = [ "anonymous-counters" ] then this should be the default to reproduce v1.37.0 behavior in following releases.

@srebhan srebhan self-assigned this Jan 21, 2026
@srebhan srebhan added the waiting for response waiting for response from contributor label Jan 23, 2026
@niklasf niklasf force-pushed the feat/nftables-consistency branch 2 times, most recently from 19a56cd to a4515c9 Compare January 24, 2026 14:31
Copy link
Member

@srebhan srebhan left a comment

Choose a reason for hiding this comment

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

Thanks @niklasf! Some more comments...

Comment on lines -6 to -9
> [!IMPORTANT]
> Rules are identified by the associated comment so those **comments have to be
> unique**! Rules without comment are ignored.

Copy link
Member

Choose a reason for hiding this comment

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

I think this is still true, isn't it?

Copy link
Contributor Author

@niklasf niklasf Jan 27, 2026

Choose a reason for hiding this comment

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

Depending on what we decide for the defaults, it's either a minor detail for the configuration of anonymous-counters or a very important point. Will restore or improve wording in the sample.conf, depending on that choice.

default:
return fmt.Errorf("unknown include: %s", include)
}
}
Copy link
Member

Choose a reason for hiding this comment

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

How about looping over the includes in gather like (pseudo-code)

	for _, include := range n.Include {
		switch include {
		case "counters":
			if err := n.gatherNamedCounters(acc, nftables); err != nil {
				return fmt.Errorf("gathering named counters failed: %w", err)
			}
		case "sets":
			if err := n.gatherSets(acc, nftables); err != nil {
				return fmt.Errorf("gathering sets failed: %w", err)
			}
		case "anonymous-counters":
			if err := n.gatherAnonymousCounters(acc, nftables); err != nil {
				return fmt.Errorf("gathering anonymous counters failed: %w", err)
			}
		default:
			return fmt.Errorf("unknown include %q", include)
		}
	}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried to fail as early as possible in Init(). Not sure if that matters.

The proposed implementation also implicitly deduplicates include = [ "counters", "counters" ] -- probably irrelevant.

Still prefer your suggestion?

Copy link
Member

Choose a reason for hiding this comment

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

In Init you should check for

  • valid values, i.e. error out on invalid/unknown strings
  • duplicate values, i.e. construct a local map[string]bool and error out if you can already find that string

@niklasf
Copy link
Contributor Author

niklasf commented Jan 27, 2026

@srebhan Thanks for reviewing. I edited the summary to clarify the release status of the various features and asked some questions before my next revision.

@telegraf-tiger telegraf-tiger bot removed the waiting for response waiting for response from contributor label Jan 27, 2026
@srebhan
Copy link
Member

srebhan commented Jan 28, 2026

Thanks @niklasf! Replied to your questions/comments...

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

Labels

feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/input 1. Request for new input plugins 2. Issues/PRs that are related to input plugins

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants