Load Balancing Equipment

[adelbot]

In the case of events received from Load Balancer.
We receive events for pool (ie VIP ) : up, down, activate, desactivate
We received events for member : up, down, activate, desactivate

How use ECS in this context. What fieldset use ?

source for VIP ?
destination for MEMBER ?

BR
Alain

[webmat]

For the essential part of your question, where to put these states or state transitions, I'd say ECS doesn't cover that specifically, at the moment. So those details would be captured in custom fields. But I do see a need to flesh out how to capture state checks or state transitions better in ECS, eventually.

Now many other parts of these events will be captured in ECS fields we currently have.

• Details about the load balancer monitoring its pool of resources should be captured in observer.*
• Details about the resources/hosts being monitored could probably be captured under host.* (esp for the name of the resource)
• If the log events contain IPs relevant to this check, I agree these could be captured under source.* and destination.*
• If you have some network details like protocols of the various layers, those could be captured under network.*

[adelbot]

In my first instruction : <133>Nov 22 14:38:15 WERV0002 notice mcpd[6021]: 01070727:5: Pool /PART_UO0/pool-prd-wal-10.154.120.51-udp-514-to-13514 member /PART_UO0/node-wal-weya0059-10.154.21.218:13514 monitor status up. [ /Common/mon-gen-udp: up, /Common/mon-gen-icmp: up ] [ was down for 0hr:0min:21sec ] "labels": { "logstash": "weya0060" }, "message": "<133>Nov 22 14:38:15 WERV0002 notice mcpd[6021]: 01070727:5: Pool /PART_UO0/pool-prd-wal-10.154.120.51-udp-514-to-13514 member /PART_UO0/node-wal-weya0059-10.154.21.218:13514 monitor status up. [ /Common/mon-gen-udp: up, /Common/mon-gen-icmp: up ] [ was down for 0hr:0min:21sec ]\n", "bigip": { "ltm": { "source": { "partition": "UO0" }, "pool": "/PART_UO0/pool-prd-wal-10.154.120.51-udp-514-to-13514", "destination": { "original": "/Common/mon-gen-udp: up, /Common/mon-gen-icmp: up ", "state": "down", "partition": "UO0", "labels": { "monitor": "monitor status up" } }, "member": "node-wal-weya0059-10.154.21.218:13514" } }, "source": { "application": { "environment": "prd", "code": "wal" }, "ip": "10.154.120.51", "geo": { "name": "Marcoussis", "city_name": "Marcoussis" }, "port": "514" }, "log": { "facility": { "code": "16", "name": "local0" }, "level": "notice", "priority": "133", "severity": "5" }, "elapsed": "0hr:0min:21sec", "process": { "name": "mcpd", "pid": "6021" }, "@timestamp": "2019-11-22T13:38:15.000Z", "tags": [ "_grokIPV4" ], "@Version": "1", "network": { "protocol": "udp" }, "observer": { "type": "LB", "ip": "10.154.8.48", "geo": { "name": "Marcoussis", "city_name": "Marcoussis" }, "hostname": "WERV0002", "product": "ltm", "vendor": "F5" }, "destination": { "application": { "code": "wal" }, "ip": "10.154.21.218", "geo": { "name": "Marcoussis", "city_name": "Marcoussis" }, "host": { "hostname": "weya0059" }, "port": "13514" } }, "fields": { "@timestamp": [ "2019-11-22T13:38:15.000Z" ] }, "highlight": { "observer.type": [ "@kibana-highlighted-field@LB@/kibana-highlighted-field@" ] }, Is it a good way ?

[webmat]

The safest way to add custom fields to an index following ECS is to avoid nesting fields directly within ECS field sets, and especially avoiding naming custom fields with the name of common concepts. These are two things that pose a high risk of conflict with future versions of ECS.

Here are a few safer ways to add custom fields:

• When it's just a few bits of information, the simplest is to add the fields under labels, e.g. labels.upstream_state and so on.
• If you prefer modeling multiple nested fields, you should add a custom top level field. The safest way to avoid a future conflict there is to nest under a proper name, as ECS tries to avoid those. The proper name could be your company name, a project name or a brand name. acme.load_balancer.upstream_state.
• Another way to pretty much guarantee you won't conflict with ECS is to instead use capitalization in your field names. ECS tries to use lowercase and underscores only, in key names. E.g. destination.UpstreamState

Note that the above are only guidelines. ECS only states how core and extended fields should be. Custom fields are 100% in user's control, as has always been the case with Elasticsearch.

[webmat]

We created meta-issue #938 to add proxy support in ECS. Closing in favor of the meta issue. Stay tuned :-)