The 2019 Writing Challenge got off to an amazing start and I’m grateful to everyone who contributed their time, energy, and talent both as the lead writers and commenters. The summary below offers up just a sample of the amazing and insightful ways in which IT pros break down difficult concepts and relate them—not just to five-year-olds, but to folks of any age who need to understand something simply and clearly.

 

Day 1: Monitoring—Leon Adato

I had the privilege of kicking off the challenge this year, and I felt there was no word more appropriate to do so with than “monitoring”

 

Jeremy Mayfield  Dec 1, 2019 8:27 AM

 

Great way to start the month. I was able to understand it. You spoke to my inner child, or maybe just me as I am now...... Being monitored is like when the kids are at Grandma’s house playing in the yard, and she pretends to be doing dishes watching everything out the kitchen window.

 

Rick Schroeder  Dec 2, 2019 2:30 AM

Are there cases when it’s better NOT to know? When might one NOT monitor and thereby provide an improvement?

 

I’m not talking about not over-monitoring, nor about monitoring unactionable items, nor alerting inappropriately.

 

Sometimes standing something on its head can provide new insight, new perspective, that can move one towards success.

 

Being able to monitor doesn’t necessarily mean one should monitor—or does it?

 

When is it “good” to not know the current conditions? Or is there ever a time for that, assuming one has not over-monitored?

 

Mathew Plunkett Dec 2, 2019 8:35 AM

rschroeder asked a question I have been thinking about since THWACKcamp. It started with the question “Am I monitoring elements just because I can or is it providing a useful metric?” The answer is that I was monitoring some elements just because it was available and those were removed. The next step was to ask “Am I monitoring something I shouldn’t?” This question started with looking for monitored elements that were not under contract but evolved into an interesting thought experiment. Are there situations in which we should not be monitoring an element? I have yet to come up with a scenario in which this is the case, but it has helped me to look at monitoring from a different perspective.

 

Day 2: Latency –Thomas LaRock

Tom’s style, and his wry wit, is on full display in this post, where he shows he can explain a technical concept not only to five-year-olds, but to preteens as well.

 

Thomas Iannelli  Dec 2, 2019 12:02 PM

In graduate school we had an exercise in our technical writing class where we took the definition and started replacing words with their definitions. This can make things simpler or it can cause quite a bit of latency in transferring thoughts to your reader.

 

Latency -

  • The delay before a transfer of data begins following an instruction for its transfer.
  • The period of time by which something is late or postponed before a transfer of data begins following an instruction for its transfer.
  • The period of time by which something causes or arranges for something to take place at a time later than that first scheduled before a transfer of data begins following an instruction for its transfer.
  • The period of time by which something causes or arranges for something to take place at a time later than that first arranged or planned to take place at a particular time before a transfer of data begins following an instruction for its transfer.
  • The period of time by which something causes or arranges for something to take place at a time later than that first arranged or planned to take place at a particular time before an act of moving data to another place begins following an instruction for its moving of data to another place.
  • The period of time by which something causes or arranges for something to take place at a time later than that first arranged or planned to take place at a particular time before an act of moving the quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media to another place begins following an instruction for its moving of the quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media to another place.
  • The period of time by which something causes or arranges for something to take place at a time later than that first arranged or planned to take place at a particular time before an act of moving the quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media to another place begins following a code or sequence in a computer program that defines an operation and puts it into effect for its moving of the quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media to another place.

 

.....and so on

 

Juan Bourn Dec 2, 2019 1:39 PM

I think I am going to enjoy these discussions this month. I have a hard time explaining things without using technical terms sometimes. Not because I don’t understand them (i.e., Einstein’s comment), but because I sometimes think only in technical terms. It’s honestly what I understand easiest. For me, latency is usually associated as a negative concept. It’s refreshing to hear it discussed in general terms, as in there’s latency in everything. Like many things in IT, it’s usually only brought to light or talked about if there’s a problem with it. So latency gets a bad rep. But it’s everywhere, in everything.

 

Jake Muszynski  Dec 2, 2019 10:42 AM

Hold on, I will reply to this when I get a chance.

 

Day 3: Metrics–Sascha Giese

One of my fellow Head Geek’s passions is food. Of course he uses this context to explain something simply.

 

Mark Roberts  Dec 4, 2019 9:49 AM

The most important fact in the first line is that to make a dough that will perform well for a pizza base a known amount of flour is necessary. This is the baseline, 1 pizza = 3.5 cups. If you needed to make 25 pizzas you now know how to determine how much flour you need 25 x 3.5 = A LOT OF PIZZA

 

Dale Fanning Dec 4, 2019 11:54 AM

Why metrics are important—those who fail to learn from history are doomed to repeat it. How can you possibly know what you need to be able to do in the future if you don’t know what you’ve done in the past?

 

Ravi Khanchandani  Dec 4, 2019 8:08 AM

Are these my School Grades

Metrics are like your Report cards—giving you grades for the past, present & future (predictive grades).

Compare the present ratings with your past and also maybe the future

Different subjects rated and measured according to the topics in the subjects

 

Day 4: NetFlow—Joe Reves

What is remarkable about the Day 4 entry is not Joe’s mastery of everything having to do with NetFlow, it’s how he encouraged everyone who commented to help contribute to the growing body of work known as “NetFlowetry.”

 

Dale Fanning Dec 5, 2019 9:27 AM

I think the hardest thing to explain about NetFlow is that all it does is tell you who has been talking to who (whom? I always forget), or not, as the case may be, and *not* what was actually said. Sadly when you explain that they don’t understand that it’s still quite useful to know and can help identify where you may need to look more deeply. If it was actual packet capture as something you’d be buried in data in seconds.

 

Farhood Nishat Dec 5, 2019 8:43 AM

They say go with the flow

but how can we get to know what is the current flow

for that we pray to god to lead us towards the correct flow

but when it comes to networks and tech

we use the netflow to get into that flow

cause a flow can be misleading

and we cant just go with the flow

 

George Sutherland Dec 4, 2019 12:23 PM

NetFlow is like watching the tides. The EBB and flow, the high and low.

 

External events such as the moon phases and storms in tides are replaced by application interactions, data transfers, bandwidth contention and so on.

 

Know what is happening is great, but the real skill is creating methods that deal with the anomalies as they occur.

 

Just another example of why our work is never boring!

 

Day 5: Logging–Mario Gomez

Mario is one of our top engineers and every day, he finds himself explaining technically complex ideas to customers of all stripes. This post shows he’s able to do it with humor as well.

 

Mike Ashton-Moore  Dec 6, 2019 10:08 AM

I always loved the Star Trek logging model.

If the plot needed it then the logs had all the excruciating detail needed to answer the question.

But security was so lax (what was Lt Worf doing all this time?)

So if the plot needed it, Lt Worf and his security detail were on vacation and the logs only contained no useful information.

 

However, the common thread was that logs only ever contained what happened, never why.

 

Michael Perkins Dec 5, 2019 5:14 PM

What’s Logging? Paul Bunyan and Babe the Blue Ox, lumberjacks and sawmills, but that’s not important now.

 

What do we do with the heaps of logs generated by all the devices and servers on our networks? So much data. What do we need to log to confirm attribution, show performance, check for anomalies, etc., and what can we let go? How do we balance keeping logs around long enough to be helpful (security and performance analyses) with not allowing them to occupy too much space or make our tools slow to unusability?

 

George Sutherland Dec 5, 2019 3:18 PM

In the land of internal audit

The edict came down to record it

 

Fast or slow good or bad

It was the information that was had

 

Some reason we knew most we did not

We collected in a folder, most times to rot

 

The volume was large, it grew and grew

Sometimes to exclusion of everything new

 

Aggregation was needed and to get some quick wins

Thank heavens we have SolarWinds

 

Day6: Observability—Zack Mutchler (MVP)

THWACK MVP Zack Mutchler delivers a one-two punch for this post—offering an ELI5 appropriate explanation but then diving deep into the details as well, for those who craved a bit more.

 

Holly Baxley Dec 6, 2019 10:36 AM

To me—monitoring and observability can seem like they do the same thing, but they’re not.

 

Monitoring -

“What’s happening?”
Observability -

“Why is this happening?”

“Should this be happening?”

“How can we stop this from happening?”

“How can we make this happen?”

 

The question is this...can we build an intelligent AI that can actually predict behavior and get to the real need behind the behavior, so we can stop chasing rabbits and having our customers say, “It’s what I asked for, but it’s not what I want.”

 

If we can do that—then we’ll have mastered observability.

 

Mike Ashton-Moore  Dec 6, 2019 10:15 AM

so—alerting on what matters, but monitor as much as you’re able—and don’t collect a metric just because it’s easy, collect it because it matters

 

Juan Bourn Dec 6, 2019 9:16 AM

So observability is only tangible from an experience stand point (what is seen by observing its behavior)? Or will there always be metrics (like Disney+ not loading)? If there are always metrics, then are observability and metrics two sides of the same coin?