-
Notifications
You must be signed in to change notification settings - Fork 259
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
Added StructuredStats method to returned structured stat data #56
Conversation
ba9e3cf
to
f5321a7
Compare
iptables/iptables.go
Outdated
|
||
structStats := []Stat{} | ||
for _, rawStat := range rawStats { | ||
if len(rawStat) != 10 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that this will ever be 11? In other words, could iptables add new stats?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is likely, but it is possible.
I can omit this check and instead leave it to the parsing (mentioned below) to handle returning an error if the datatypes are mismatched or the number of fields is not within the expected range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved this check into the ParseStat
method, but made it a minimum of 10 stats in a row to allow for forward compatibility.
iptables/iptables.go
Outdated
@@ -72,6 +72,20 @@ type IPTables struct { | |||
mode string // the underlying iptables operating mode, e.g. nf_tables | |||
} | |||
|
|||
// Stat represents a structured statistic entry. | |||
type Stat struct { | |||
Packets string `json:"pkts"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you parse all numbers accordingly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I will make this change.
@@ -263,6 +277,29 @@ func (ipt *IPTables) Stats(table, chain string) ([][]string, error) { | |||
return rows, nil | |||
} | |||
|
|||
// StructuredStats returns statistics as structured data which may be further | |||
// parsed and marshaled. | |||
func (ipt *IPTables) StructuredStats(table, chain string) ([]Stat, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest you add a separate ParseStats
function that just takes a []string
and parses the stats accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I originally was going to do exactly that. The only issue I foresee is that exposing a ParseStats
method that accepts an arbitrary []string
(or [][]string
) may be subject to misuse.
Anyway, two questions I'm looking for your feedback on:
-
I can make a
ParseStat(stat []string) (Stat, error)
and/or aParseStats(stats [][]string) ([]Stat, error)
. Any preference for either or both? -
Would you like me to remove
StructuredStats(table, chain string) ([]Stat, error)
completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, I pushed up a contribution with ParseStat(stat []string) (Stat, error)
and left StructuredStats(table, chain string) ([]Stat, error)
for now pending feedback.
iptables/iptables.go
Outdated
Opt string `json:"opt"` | ||
Input string `json:"in"` | ||
Output string `json:"out"` | ||
Source string `json:"source"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forget - can these be hostnames, or do they have to be IP addresses? If they have to be IP addresses, can you parse them accordingly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method Stats(...)
uses the -n
flag. From the man pages:
--numeric -n numeric output of addresses and ports
This shows the source and destination in CIDR format. Below is some output:
$ iptables --version
iptables v1.4.21
$ iptables -t filter -L INPUT -n -v -x
Chain INPUT (policy ACCEPT 12 packets, 857 bytes)
pkts bytes target prot opt in out source destination
2 128 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3332
$ iptables -t filter -L INPUT -v -x
Chain INPUT (policy ACCEPT 43 packets, 3073 bytes)
pkts bytes target prot opt in out source destination
2 128 ACCEPT tcp -- any any anywhere anywhere tcp dpt:mcs-mailsvr
From this, we know it will be CIDR notation IP addresses.
We can call this struct NumericalStats
to be more accurate. Since it's already granular, I don't think this is necessary.
FYI, I won't have computer access for a few weeks. So apologies in advance for the radio silence. |
…d Stat struct with data types
Hi @squeed, just a friendly request to revisit this if appropriate. Thanks! |
@asilvr sorry, this fell off the stack. Looks good to me! |
This additional method maintains the currently available
Stats
method while adding aStructuredStats
method, which returns structured data instead of a slice of string slices with statistics. This allows the caller to use a defined data structure for accessing fields in a specific statistic.Although a caller could peer into the existing
Stats
method to determine what each field is, providing this abstraction allows for more portability/usability.