My favored format is somewhat complex in terms of layout, but is compact and easy to read once you get used to it:
IATA code (https://en.wikipedia.org/wiki/IATA_airport_code)
Cluster number (digits)
'r' (for "rack") \______ if meaningful for you
Rack number / (ignore for EC2/GCP)
'm' (for "machine")
Machine number
Alternatives that don't work as well:
* Don't use a fixed-width field anywhere. Google used two-letter cluster names, and when those ran out they discovered that the two-letter assumption had worked its way into every layer of the stack. One of the important core services had `uint16_t cluster` in its wire protocol.
* Don't make up your own cluster names. Don't use names like "northwest" or "east". IATA codes are your friend and you will love them because someone else already decided what they should be and wrote them down.
* Don't use fields without delimiters. Being able to say "read digits until the next non-digit" is incredibly useful when writing ad-hoc parsers in shell scripts, because those parsers won't break when you bring up the first datacenter with more than 99 racks. If you tell people not to write hacky ad-hoc parsers in shell scripts, they will (1) do so anyway and (2) not tell you.
* Don't leave off the cluster number. Yes, you only have one cluster in us-west-2 right now, but maybe in five years you'll need to have more than one because you want to run 30,000 EC2 instances there but all your per-cluster infrastructure software falls over at 20,000 instances. Then you can just turn up "pdx2" instead of trying to explain to Hashicorp engineers why you want to run the world's biggest Consul cluster.
* Do not put the production hostnames under a subdomain of your corporate website. If you are ACME LLC then your hostnames should end with `.acme-prod.com` instead of `.prod.acme.com`. The same is true of corporate IT assets like laptops or workstations (`acme-corp.com` -- NEVER `.corp.acme.com`). Why? Browser cookies.
UN/LOCODE may be more appropriate:
* https://en.wikipedia.org/wiki/UN/LOCODE
* https://unece.org/trade/cefact/unlocode-code-list-country-an...
Has both country code and location with-in that.
Now if I just had a dollar for each time I've fat-fingered sjc002 to scj002 ... :)
We name our datacentres with a two-letter city code and a digit (or some letters and then some digits in your framework!). The city codes aren't from any canonical list, but it turns out there aren't enough to matter. So far, this has served equally well at avoiding arguments about what to call things.
We name machines ${datacentre}-${other_stuff}. That makes it trivial to tell what exact datacentre a machine is in. That's very nice if you have to reason about networking. In your scheme, if you had multiple datacentres near one airport, you would have to know the mapping from cluster to datacentre, right?
However, IATA does provide city codes even if no airport in that city actually uses them. London's is LON, Chicago's is CHI. It's better to just use those.
What do you do if there's no airport?
The purpose is to have a Schelling point that bypasses any tedious weeks-long arguments. Otherwise your Frankfurt datacenter gets named "ceurope" because the London datacenter got "europe" first, or you named the Ohio datacenter "east" and there's a fight about whether to call the new Virginia datacenter "easter".
[0] If you're building a submerged datacenter in the middle of the Atlantic then ... well, do your best.
UN/LOCODE tends to have an abbreviation for most places.
UN/LOCODE may be more appropriate:
* https://en.wikipedia.org/wiki/UN/LOCODE
* https://unece.org/trade/cefact/unlocode-code-list-country-an...
Has both country code and location with-in that.
Is there more to say about this? How do browser cookies conflict with server and PC hostnames?
The actual implementation was something like this:
const char *cluster = "ex";
uint16_t enc_cluster = (((uint16_t)cluster[0]) << 8) & (uint16_t)cluster[1];
This was nearly a decade ago, so things may be different now. You'd have to ask someone who currently works there to tell you what their cluster names look like.
It's easy to claim that "lisaann" and "peternorth" are just randomly invented names, and then watch some corporate drone blushing and struggling when asked to explain why they find those names inappropriate.
No blushing is required.
Fwiw, I believe they're either making this up or they work for a company that's too small to have an HR department.
That's what makes it funny.
The impulse to encode lots of metadata in a device name is reasonable, but less is more. Location, user, application, even OS can all change. What then does it mean for the device name?
And how often do you need to distinguish between a laptop and a desktop, really?
Name things uniquely, and as little beyond that as possible. If the system generates its own unique default (Windows) or manages its human-readable hostname on its own (Mac), use that. Let your device management tools tell you where it is, what model device it is, what OS it runs, etc., not to mention countless other things you’ll never fit in a name.
I used to make exceptions for infrastructure, but with automated network management tools, I don’t even bother with that anymore. All that matters is that a device is represented in a database by a primary key, and I don’t even care what that is.
The best naming convention is not to bother with conventions at all. Let the machines do that work.
Each DC had a different business usage, so knowing that immediately gave you context of what that machine should be doing.
We also would also have the environment (prod or dev) in the name. It just gave you an immediate understanding of the sensitivity of the machine and therefore stopped/warned folks from doing crazy things in prod.
Of course, YMMV, but I've always been a fan of names which give you context. Too much can be annoying but a little goes a long way.
Another requirement is you want the names to be a sparse address space: there should never be confuse-able or mistypable characters which drop you into another computer name - so systems like r0001, r0002, r0010 etc. should be right out.
Finally you also want the name to be human pronounceable: if everything's going well, it'll never be said. When things are not going well though, you want it to be something that can be communicated verbally if you need to - i.e. over the phone, or across an office.
Hence, word-lists are ideal as hostnames. Keep them short to around 2-3 syllables. They must be meaningless (and thus also not imply meaning). Any other information you need should come out of the CMDB. If you need more specific info hanging around, then you DNS and CNAME's to set up aliases for things like trying to SSH into "the machine at these rack coordinates" and keep that information updated from your CMDB.
I started doing that after a hard-to-diagnose problem that resulted from restoring a configuration file that referred to a machine that had been retired, but the name was reused, making it refer to the wrong machine.
I worked on a system that had dozens of small-form-factor linux computers, that served as gateways for a fleet of thousands of bluetooth environmental sensors. Because of the nature of the facility construction, it was considerably easier to provision devices before deployment, then record location and other meta-data later. So the unique ID (a 16-digit hexadecimal number) in the system was completely disconnected from the metadata, but the common name of the device was defined almost entirely from the metadata. That also meant that while the unique ID was immutable and described a unique computer, the common name more described a location and purpose that a computer could be deployed to. Even so, that distinction lived waaay up in the facility management software design, and in practice, the only people even aware that the unique ID existed and was a distinct number from the "name", were the people tasked with provisioning the device for deployment.
Plenty of orgs have multiple people named "Steve", a few even have multiple people named "Stephen A. Ambrose", but no good org has multiple employees with the same employee ID number. And to further that analogy, no good org expects its employees to completely ignore the human name in favor of the employee ID.
That's why I switched to names that have no relationship with the particulars of the machines they are assigned to.
The argument that equipment change location and uses sounds to me like an environment where disposing and creating new hosts is much too hard. The lifetime of a host should be simple and well defined such that no one is tempted to make such changes without decomissioning.
The problem was that you still have to consult a key in order to decipher the hostnames, and since the names were all similar to each other, mistakes were an everyday occurrence.
Since you had to refer to documentation anyway, using more unique names would have reduced error and confusion.
Backups, monitoring, logging, SIEM, etc. are integrated with the CMDB such that events and managed hosts are linked in both directions.
If anything, I’m spoiled on having automated systems making lifecycle terribly easy. I would concede that’s a blind spot in my perspective; many organizations aren’t going to be similarly equipped. If such an organization is managing more than a few dozen devices, however, they may have bigger problems than naming.
I think that points to UUID or an incrementing counter, but the incrementing counter may be harder to ensure uniqueness depending on how names are created (which can change in the future).
When naming "pets", thematic names are nice: Tolkien characters, words-starting-with, deities, elements, plants, animals, etc.
When naming "cattle", schemes that have fairly intricate coded meanings and numerical elements generate things like LDW21-0743 (London, Desktop, Windows, 2021, number 743).
Somewhere between 50 and 100 machines and you need to transition, and it can be surprisingly traumatic.
Then you get to argue about the PTR record ...
If you were going for deities, maybe olympus.<something> for Greek gods. Wherever the pantheon is supposed to be homed. Hinduism would give you more host names than you could (probably) ever use...
The ".home.arpa" domain is explicitly set aside for 'home' non-public networks in https://datatracker.ietf.org/doc/html/rfc8375.
I like that scheme. I find it meaningful to name things in my life after things in my natural environment. Helps me remember that I exist inside it.
If you know a machine (especially a server!) is going to be used for one thing, name it after that thing. If you get a second one, you wipe both and rename them to thing-1 and thing-2.
If you move a machine, you absolutely wipe it!
"I named the new search server "gohan" because the original search server was called "goku" because he's searching for the dragon balls" is cute on the surface, but then you have to explain to everyone that joke and then they have to remember it. No one's going to be confused by "search-new-2021".
Computers were scarce and expensive, virtualization wasn't a thing. Any random machine might turn out to do DHCP, FTP and payroll, just because the software had to go somewhere and that particular machine had the spare resources and was hooked up to the right network.
Am I the only one who finds it a pain in the butt to rename an existing machine? So many things have to be updated when I do that...
Obviously programming in C wasn't your only favorite pastime.
Modern server “cattle” style naming, which I assume you have in mind, is actually explicitly mentioned as a reasonable idea in the RFC text.
tron, finch, wintermute, sparrowhawk, axolotl, rook, moneta, mengpo, odessa, ithaca, turing, lovelace
Honestly, even most home machines are randomly named, I think.
Servers get names that are concatenations of meaningful abbreviations that are meaningless to an outsider, you might be on nycfithro603.
Actually I can't think of any org I've worked for that had random strings for its physical machines. Cloud VMs, yes (though not always).
A while ago I wrote a script that uses GPT to generate some machine names and then check them for collisions with existing ones. So no suffixes needed. I thought I was innovating, hahaha. Very interesting.
but after a decade or so I decided to flip to “side characters from Adventure Time” (currently writing from Huntress Wizard, tethered to Rootbeer Guy)
`ssh foo@the-precise-nature-of-the-catastrophe`
The only problem is that I have a lot of machines, and am running out of names!
I still have 20 or so left on my "future names" list. I'm now into names of knife types in the African continent.
- Jovian moons
- Trees
- Constellations
- U.S. state capitol cities
- Chemical elements
It begun with skydiving location, as the guy in charge of PC administration is a diver, then he switched to pokemon as he figured out it was easier to take the next pokemon in the list.
Considering we are only about 25 people at work, we have a long way to go before running out of names...
Mildly recursively, when I play at trying to name all the elements[1] in fifteen minutes, I think of the sets of things elements are named after. Geographic places (Europium, Londinium, Americium, Californium), laboratories (Berkelium, Lawrencium), people (Einsteinium, Nobelium, Curium, Seaborgium), astronomical things (Helium, Selenium, Plutonium, Uranium, Mercurium), things known in the ancient world (Silver/Argentum, Lead/Plumbum)... although it's never enough for me to get all of them.
I guess it brightened up the all-gray cubicle farm.
My hostname idea was to name network printers after trees (e.g., `pine`, `elm`).
You can also make the hostname work with the FQDN. I once got the hostname `ilove.mit.edu`. I later got them to rename it to `ihavealovehaterelationshipwith.mit.edu`.
Also, at that scale, names are never permanent. You're renaming (or rebuilding) hosts as they change location and usage.
The worst is when you scale up from a small firm where all the hosts are named after movie characters and all services are hard coded to those names. Been there, its rough....
Edited for missing words.
uname -n
localhostI'm dead set against IoT, so naming my computers after fixtures or appliances hasn't caused conflicts.
[0] https://wiki.loadingreadyrun.com/index.php/Installation_Anxi...
RFC 1178: Choosing a Name for Your Computer - https://news.ycombinator.com/item?id=35424550 - April 2023 (3 comments)
RFC 1178: Choosing a name for your computer (1990) - https://news.ycombinator.com/item?id=26054014 - Feb 2021 (121 comments)
Choosing a Name for Your Computer - https://news.ycombinator.com/item?id=26027247 - Feb 2021 (1 comment)
RFC 1178 – Choosing a name for your computer (1990) - https://news.ycombinator.com/item?id=16741009 - April 2018 (173 comments)
Choosing a name for your computer - https://news.ycombinator.com/item?id=5167998 - Feb 2013 (10 comments)
Choosing names for your computers - https://news.ycombinator.com/item?id=1290106 - April 2010 (86 comments)
Choosing a Name for Your Computer - https://news.ycombinator.com/item?id=110017 - Feb 2008 (9 comments)
All my versioning names also follow some popular project's version names e.g. x86 & amd64 internal designations or codenames. Similarly, for smaller versioning tasks I have used Fedora Project's release names. I just do it to learn something along the way as well.
It just gives the different entities I work on a personalized touch.
Some past themes... Characters of the current book series I am reading. Hunger Games, Star Wars, Star Trek, C. S. Lewis Novels, Tolkien Novels, Louis L'Amour Novels
Trees, plants, flowers, etc...
Clouds
Snakes, birds, etc...
The important thing is to be unique, memorable and thwart the 'cattle' people.
1. Usually not a concern.
2. When it is, it's in ipam/dcim. Plus you can usually tell from ip address.
Then data is nested in a hierarchy using hiera, saltstack, or custom merge behavior in cdktf. Since the names are most specific to least specific it's easy to apply configuration for each section, letting the most specific configuration override on merge.
Easiest way to automate some of the annoying bare metal/vm requirements without bringing in or writing additional tools. You rack it, set the hostname in the idrac, then let dhcp and provisioning tools do their thing.
In my own personal home setups I’ve followed the convention of choosing a from a religious pantheon the name of a god whose role most approximated— very loosely— whatever the system is going to be used for. I had a Hephaestus for a while that was a workhorse of a machine where I would work on special projects, etc.
Last year I finally exhausted names from the first show and added a second one to my name list.
Is it more logical to name them things like phone-2023-1 and cloud-server-5 - sure. But the reality is my personal infrastructure is going to max out at like 40 concurrent devices, and that's including stuff like network devices which does get more "practical" names (like office-ap-1, tv-switch-1) since I rarely ssh into them. So may as well have a little fun with naming
Perhaps - for end users/non-admins - it'd be best to point first to a list of "favorite" names??
Here are my favorites of mine, which have all notably performed the function of a unique system name quite admirably:
- Gravel (iPhone 8 Plus)
- Jorts (iPhone 12 Pro Max)
- Hildur (Desktop PC)
- [Kudzu](https://en.wikipedia.org/wiki/Kudzu) (iPad Pro)
- Winterkorn (Wireless OBD2 Scanner)
I see their point, but I’m going to consciously ignore this advice because it makes my life more interesting.
The VMs and containers on my proxmox server are all named after the service and a trailing number. Plex is plex1, file servers are fs#, unifi controller is unifi1, etc. Once having a VM or container became essentially free, it mostly eliminated the need to think up or remember names.
Coming up with a uniform, concise, and easily decipherable scheme is really the best for naming nodes on a network (be it at your home, or in a data center with 10s of thousands of machines (virtual and physical)).
GUID is a bit extreme, but leveraging DDNS, and having a plan is always the best (and not naming things after a finite index like: planets, cartoon characters, mythological objects, or models).
Privately I use fantasy/Science Fiction worlds. One of the first was discworld (it had a very large harddisk), and I stuck with it. I've had beleriand, dagobah, tatooine, and my most recently ferrix. Okay, mostly Star Wars planets, I guess.
More recently, I have been naming them after the cats in Diane Duane's Feline Wizards series (which begins with The Book of Night with Moon); however, having run through Rhiow, Saash, Urruah, and Arhu, I'm going to have to find a new naming scheme for my next one!
It's much more limited in possible combinations than petname, but it's perfect for naming secret projects.
You can install it with `npm install nsaname`.
There were so many arguments between otherwise reasonable people over server names.
Some went for cute, some for mythology, some planetary (which can be quite limiting if you stick with only the home solar system), and finally my favorite - the purpose-based, numerically suffixed.
I lost it and can't for the life of me remember what it was called. Anyone have an idea?
*edit - Monger not Mongrel
endgame, vortex, breakpoint, lucretia, hangar18, shewolf
godzilla and then the entire gallery of mutant rogues.
These seem to adhere to the guidelines. I have been using https://iancoleman.io/bip39/ for a while to name VMs. Generate 15 words, pick a pair that I can visualize, and I'm done.
>Use real words:
>- Unreal words: Zibber, Quibbit, Wuzzo, Brumple, Kwozzle, Gliggern, Drimble, Fopple, Zinkern, Thribble
>- Real words: Pulsar, Fusion, Vector, Quantum, Catalyst, Dynamo, Nexus, Zephyr, Vortex, Phoenix
So I asked it, "Give me a list of 100 silly unreal words that are good computer names."
And it generated a hilarious list of silly unreal words for computer names that obeyed all the other rules too.
>Blibber Flibbit Zoggly Snarfle Quizzix Jibberix Flumble Snootle Jumblex Skrungle Flibberish Squozzle Buzzlequib Zumblequack Skrizzik Glibbergen Squibble Wibbleshack Zibberflap Quabblefudge Kwozzler Skrubble Jibberlump Squibbleton Quacklebum Wuzzlequorp Flibberquill Zibberplush Quozzletuck Grubblefrush Jumblezor Squigglemuff Quabbleblurt Buzzlekringle Skrubblefrimp Blibbertron Glibberspark Wuzzlethrump Flibblecrust Zibberklax Quozzlegruff Flumblezest Jibberclump Squibblethorp Skrungleblast Zumblequax Grubbleflink Flibbersprout Buzzlegrit Quacklepuff Blibberchomp Snootleburst Glibberzilch Squozzleflop Kwozzlespork Skrubblemunch Zumblethrift Quozzlequench Flibblegrit Jibberplank Squibblezorb Quacklethrift Flumblezax Wuzzlesplat Glibberfluff Blibbersketch Zibberfrizzle Squozzleblimp Grubblequark Buzzlekrunch Skrunglefluff Zumblecrunch Quozzlefrump Flibbersquatch Jibberflit Squibblekrush Blibberblitz Wuzzleflank Skrubblespook Zumblekrunk Quackleflunk Grubblesmirk Squozzlefrimp Buzzleplunk Flibblezorp Glibberplush Jibberclank Squibblesmudge Blibbergrit Zibberzorch Wuzzlequench Kwozzlesplurge Skrunglethrift Flumbleblimp Quozzlesmirk Buzzlefluff Grubblethwack Zumblegrit Quackleblurt Squibbleplush
They seemed to have certain patterns to them, so I asked: "Describe in words the linguistic and other techniques you used to come up with that list of silly words."
>Sure, the process of generating a list of silly, unreal words involves several linguistic and creative techniques:
>Phonotactics: Phonotactics is the study of the rules governing the possible phoneme sequences in a language. In creating these words, I adhered to the phonotactic rules of English, ensuring that the combinations of sounds were plausible for English speakers.
https://en.wikipedia.org/wiki/Phonotactics
>Phonaesthetics: This is the study of the inherent pleasantness (euphony) or unpleasantness (cacophony) of the sound of certain words, phrases, and sentences. To come up with silly words, I chose combinations that are typically associated with a humorous or whimsical sound in English.
https://en.wikipedia.org/wiki/Phonaesthetics
>Combining Familiar Sounds: To create these unreal words, I combined familiar sounds and syllables from English in new and unusual ways. This increases the chances that the words will be pronounceable and memorable, while still being novel and silly.
>Consonant-Vowel Structure: Most of the words follow a basic consonant-vowel structure, which is common in English and makes the words easier to pronounce.
>Morpheme Mixing: Morphemes are the smallest meaningful units of language. In English, we can combine morphemes in different ways to create new words. In this case, I combined various nonsensical morphemes to create new, unreal words.
>Influence of Existing Words: Some of the created words might resemble or remind you of existing words in English. This was intentional as these associations can make the words sound more familiar and easier to remember, while still being clearly unreal.
>Humorous Connotations: Many of these words were designed to have humorous or whimsical connotations. This was achieved by choosing sounds and syllable combinations that are often associated with humor, silliness, or absurdity in English.
>Variety: In creating this list, I sought to ensure a wide variety of sounds, syllable counts, and levels of complexity. This increases the overall silliness of the list and ensures that there are words that will appeal to different tastes.
>Remember, though, that creating silly, unreal words is a highly creative process and there are no hard-and-fast rules. The most important thing is to have fun with it and create words that make you smile!
I've never heard of Phonaesthetics or Phonaesthetics (but they sound plausible and pleasant ;) ), so I asked: "To elaborate about Phonaesthetics and Phonaesthetics, give me as many explicit examples of possible of how those techniques apply to the list of computer names you generated above."
>Sure, here's how the principles of phonotactics and phonaesthetics apply to some of the silly, unreal words I created as potential computer names:
>Phonotactics:
>"Brungle": This word adheres to English phonotactic rules, in which a single consonant or consonant cluster ("br") can be followed by a vowel ("u"), and then ending in a consonant or consonant cluster ("ngle").
>"Fribzoot": Again, "fribzoot" starts with a valid English consonant cluster ("fr"), followed by a short vowel ("i"), another consonant cluster ("bz"), a vowel ("oo"), and ends with a consonant ("t").
>"Blupzark": This word adheres to the English phonotactic rules with a valid consonant cluster ("bl") followed by a short vowel ("u"), a consonant ("p"), another consonant cluster ("z"), a vowel ("a"), and ending with a consonant ("rk").
>"Tringwop": Here, "tr" is a common consonant cluster, followed by a short vowel ("i"), a consonant cluster ("ng"), a vowel ("o"), and a final consonant ("p"). Each part of the word is a permissible combination in English.
>Phonaesthetics:
>"Snorkwib": This word has a whimsical sound to it, due to the combination of the "sn" sound at the beginning, often associated with words like "snicker" and "sneak", and the "wib" at the end, which is an uncommon but still pronounceable combination in English.
>"Quibnorf": The use of "qu" at the beginning adds a quirky, whimsical sound, while the ending "-norf" adds to the absurdity, reminding one of words like "dwarf".
>"Glibfraz": The "glib-" prefix may remind us of the word "glib", giving a sense of smooth, quick wit. The "-fraz" suffix has a zany, fun feel to it.
>"Plonkstir": The beginning, "plonk", may bring to mind the English onomatopoeic word 'plonk', giving a playful, silly feel. The ending "-stir" balances it with a more usual word ending.
>Phonotactic rules ensure that the created words are plausible and pronounceable to English speakers, even though they are entirely made up. Phonaesthetics, on the other hand, contributes to the silliness, whimsy, and overall appeal of the words, making them suitable and memorable as computer names.
>Please note that while these linguistic principles can guide the process, the creation of such words also involves a considerable degree of creativity and intuition.
These techniques are also useful for generating memorable nice sounding company and product names, too!
I'm not saying my scheme is perfect, or even very good, but it works for my needs and I've used the following convention for around 30+ years. I've got two schemes, one for small sites/personal installations, and one for big sites.
w for workstations. t for tables. p for printers. c for cameras. a for access points. s for servers. m for mobiles/cellphones. v for vms. i for iot devices. u for "devices we don't know how to designate." x for sensors, e.g water leak sensor, package delivery box sensor.
Obviously if you only have three devices in your entire home, it doesn't really make sense to have a "naming scheme."
For personal installations and small sites (not an exhaustive list):
a-studio-ap6 (access point in studio)
a-catbathroom-ap6pro (access point in cats' bathroom)
a-workshop-ap6 (access point in the workshop)
a-rv-aplr (access point in the rv)
w-lloyd-vr (workstation, household VR/gaming computer)
w-justin-storm (workstation, storm is the CPU case manufacturer)
l-justin-surfacebook2 (my surface laptop)
l-joyce-surfacebook2 (wife's surface laptop)
l-joyce-surfacestudio (wife's surface laptop)
l-justin-mbp2013 (my old macbook)
p-office-hp3600 (office printer)
p-workshop-konica (konica minolta printer in workshop)
p-office-canon (office printer)
v-justin-ubuntu (virtualized linux)
v-justin-arch (virtualized linux)
v-justin-win10 (virtualized linux)
t-lloyd-weather (samsung table for weather)
t-lloyd-ipad00
t-lloyd-ipad01
c-lloyd-frontdoor (camera at front door)
c-lloyd-garagedoor (camera on outside of garage door)
c-lloyd-garageceiling (camera on the garage ceiling)
s-lloyd-main (main home server)
s-lloyd-backup (backup server)
s-lloyd-storage (backup server at the storage locker)
s-lloyd-cloud (our racked server in some midwest datacenter)
s-lloyd-rv (server in the rv)
m-joyce-pixel6 (wife's cellphone)
m-justin-pixelpro7 (cellphone belonging to me)
m-justin-note20 (cellphone belonging to me)
m-justin-iphone13 (cellphone belonging to me)
It helps with identifying mystery devices on the network, and who owns the device. I apply the same principle to naming cats and people. "grey-cat", "black-cat", "fuzzy-black-cat", "pink-human", "mao" (cat), "cat", "cath" (also cat), "orange-cat", "chat" (also cat), "gatto" (cat).
For large sites with dozens or hundreds of servers or multiple sites/data centers:
IATA codes with rack and machine name and absolutely nothing creative, and clear separators between each part. e.g. lax-r01-s17. And then I make sure that any publicly accessible machines sit on their own "prod" domain separate from the company's main domain, e.g. hn-prod.com, or bigcorp-prod.com