UUIDSources

Table of Contents Introduction Why use UUID instead of hostname? How it works Current status Getting it

Introduction

UUID support is being implemented on the branch dpocock/uuid

Currently, Ganglia sources are hosts, and each host is uniquely identified by it's hostname (or by the packet source IP if a hostname is not resolvable)

Why use UUID instead of hostname?

• sometimes IP addresses and hostnames are dynamic (devices on mobile Internet, for example)
• sometimes applications are run on different hosts in a cluster, and it is desirable to use a UUID to represent the running application instance
• a new UUID can be created each time a batch job is run, or each time some other long-running process is executed
• sometimes several hosts appear to have the same IP address when they are all behind a NAT gateway
• not necessary to make any DNS lookup on each incoming packet (performance)

How it works

• extra packet types have been defined
• the new packet types resemble the existing packet types (since 3.1), and only differ in that the 7th bit is set (0x40) in the message format discriminator, and a UUID (128 bits) is appended to the packet
• when gmond receives such a packet, it ignores the IP address, does not lookup the hostname, and uses the UUID (in string format) as both the hostname and the hashmap lookup key
• when looking at the XML from gmond, the UUID appears in the HOST/@NAME attribute, the IP address appears normally

Current status

• gmetric4j can send the new packet type
• gmond can receive but not send this new packet type. gmond also receives the original packet types, so UUID nodes and regular nodes (not sending UUID) can be mixed in the same cluster.
• implemented in Lumicall from v1.7.2 onwards
• the XDR format is NOT final, and could be revised again before this becomes part of a mainstream release

Getting it

• checkout the dpocock/uuid branch from git and build it manually. It is not included in the current release tarball (3.4.0)