Monitis Archives - DaedTech

Sep
14

Addressing Malware Detection from the Outside In

Category: Language Agnostic Tags: Monitis |

Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, have a look around at the different types of production monitoring that they offer.

I worked as a software engineer for almost the entire decade of the 2000s. While I was earning a living this way, computers were making their way from CS student dorm rooms to Grandma’s den. Like so many other programmers of the time, I thus acquired the role of unofficial tech support for computer illiterate friends and family. I do not miss those days in which malware detection became an involuntary hobby.

Back in 2005, everyone had computers with Windows XP or Windows 98. And every computer with Windows XP or Windows 98 seemed to attract malware like flies to flypaper. So I found myself sitting in front of CRT monitors next to dusty towers, figuring out why nothing worked.

I still kind of remember the playbook. For instance, Lavasoft had a product called Ad Aware. I also seem to recall something called MalwareBytes. I favored these because I could download them for free. At least, I could download them for free assuming the victim’s computer was even capable. With those tools in place, and with a heaping helping of googling from my own laptop, I would painstakingly scan, sweep, remove, tweak, and repeat. Eventually, I won. Usually.

It seems strange to think about now. Ten or twelve years ago, consumers compared brands of antivirus software the way we compare music apps on our phones. Malware detection dominated our computing consciousness, even for casual users. But today? I can’t remember the last time I ran an antivirus scan on my laptops. I suspect you can’t either. So what happened to all of this malware? Did it simply disappear?

The Silencing of Malware

Well, no. Malware didn’t disappear. The criminals and spammers of the world didn’t just one day decide to do something better with their lives. In fact, you might argue that they became more effective.

Most of the pieces of malware from my younger days had lots of bark and little bite. They’d install themselves on your computer and hijack your browser with obnoxious graphics or spew error messages until your machine crashed. Some came from would-be vandals, while others tried unsuccessfully to do things sneakily.

But causing some computer neophyte to say “this doesn’t seem right” and call up a young me to fix things — well, it hardly constitutes successful sneaking. It always seemed, in those days, that malware authors sought mainly to annoy. And malware detection and removal sought to fix the inconvenience.

In more recent years, however, the consumer annoyance factor has mostly disappeared. Why? Because there’s no profit in it. Today’s malware instead aims to help its authors and users make money. It does this by quietly gathering data, sending out spam, gaming search engines, and stealing information. And it does all of this under the radar.

Aug
8

By Erik Dietrich

What is Real User Monitoring?

Category: Language Agnostic Tags: DevOps, E-Commerce, Monitis |

Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, have a look around at their assortment of monitoring solutions.

Perhaps you’ve heard the term “real user monitoring” in passing. Our industry generates no shortage of buzzwords, many of the them vague and context dependent. So you could be forgiven for scratching your head at this term.

Let’s go through it in some detail, in order to provide clarity. But to do that, I’m going to walk you through the evolution of circumstance that created a demand for real user monitoring. You can most easily understand a solution by first understanding the problem that it solves.

A Budding Entrepreneur’s Website

Let’s say that the entrepreneurial bug bites you. You decide to build some kind of software as a service (SaaS) product. Obviously, you need some time to build it and make it production ready, so you pick a target go-live date months from now.

But you know enough about marketing to know that you should start building hype now. So, you put together a WordPress site and start a blog, looking to build a following. Then, excited to get going, you make a series of post.

And then, nothing. I mean, you didn’t expect to hit the top of Hacker News, but you expected… something. No one comments on social media or emails you to congratulate you or anything at all.

Frustrated, you decide to add a commenting plugin and some social media share buttons. This, you reason, will provide a lower friction means of offering feedback. And still, absolutely nothing. Now you begin to wonder if your host provider hasn’t played a cruel trick on you in which it only serves the site when you visit.

The Deafening Lack of Feedback

If perhaps it sounds like I empathize, that’s because I sincerely do. Years and years ago when I started my first blog, I posted into the ether. I had no idea if anyone read those early posts. Of course, I was just having a good time putting my opinions out there and not trying to make a living, so I didn’t worry. But nevertheless, I eventually felt frustrated.

The frustration arises from a lack of feedback. You take some actions and then have no ability to see what affect they have. Sure, you can see the post go live in your browser, but are you reaching anyone? Has a single person read the post? Or have thousands read the post and found it boring? It’s like writing some code, but you’re required to hand it off to someone else to compile, run, and observe. You feel blind.

Aug
2

By Erik Dietrich

Software Monitoring: The Things that Might Interest You

Category: Language Agnostic Tags: DevOps, Monitis, Monitoring |

Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, have a look at the different sorts of production concerns that you can keep an eye on with their offering, some of which I address in this post.

If you have responsibility for software in production, I bet you’d like to know more about it. I don’t mean that you’d like an extra peek into the bowels of the source code or to understand its philosophical place in the universe. Rather, I bet you’d like to know more about how it behaves in the wild.

After all, from this opaque vantage point comes the overwhelming majority of maddening defects. “But it doesn’t do that in our environment,” you cry. “How can we even begin to track down a user report of, ‘sometimes that button doesn’t work right?'”

To combat this situation we have, since programmer time immemorial, turned to the log file. In that file, we find answers. Except, we find them the way an archaeologist finds answers about ancient civilizations. We assemble cryptic, incomplete fragments and try to use them to deduce what happened long after the fact. Better than nothing, but not great.

Because of the incompleteness and the lag, we seek other solutions. With the rise in sophistication of tooling and the growth of the DevOps movement, we close the timing gap via monitoring. Rather than wait for a user to report an error and asking for a log file, we get out in front of the matter. When something flies off the rails, our monitoring tools quickly alert us, and we begin triage immediately.

Common Monitoring Use Cases

Later in this post, I will get imaginative. In writing this, I intend to expose you to some less common monitoring ideas that you might at least contemplate, if not outright implement. But for now, let’s consider some relative blue chip monitoring scenarios. These will transcend even the basic nature of the application and apply equally well to web, mobile, or desktop apps.

Monitis offers a huge variety of monitoring services, as the name implies. You can get your bearings about the full offering here. This means that if you want to do it, you can probably find an offering of theirs to do it, unless you’re really out there. Then you might want to supplement their offering with some customized functionality for your own situation.

But let’s say you’d just signed up for the service and wanted to test drive it. I can think of nothing simpler than “is this thing on?” Wherever it runs, you’d love some information about whether it runs when it should. On top of that, you’d probably also like to know whether it dies unexpectedly and ignobly. When your app crashes embarrassingly, you want to know about it.

Once you’ve buttoned up the real basics, you might start to monitor for somewhat more nuanced situations. Does your code gobble up too many hardware resources, causing poor experience or added expense? Does it interact with services or databases that fail or go offline? In short, does your application wobble into sub-optimal states?

But what if we look beyond those basics? Let’s explore some things you may never have contemplated monitoring about your software.

Jul
30

By Erik Dietrich

Choosing an Acceptance Test Framework

Category: The Life of a Programmer Tags: Acceptance Testing, Monitis, Testing |

Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, take a look at their monitoring solutions.

I can still remember writing my first automated tests in a professional setting. Notice that I didn’t say unit tests, and for good reason. At the time, some 14 years ago, I hadn’t heard of unit tests. Instead, I simply automated the process of manually testing my software.

This may sound somewhat facile, but it actually speaks to core principles in the programming profession. As a relatively inexperienced programmer, I understood the importance of testing my work. I also understood the importance of automating manual, error-prone process. And so, of my own accord, I examined and then automated my previously manual testing efforts.

Don’t get me wrong. By doing this, I reinvented a wheel simply because I did not know of its existence. Folks had created automated unit test frameworks for this exact purpose. Had I known, I could have better spent my time learning and using these things. But, in spite of the waste, I did learn something. I learned that, under the covers, test frameworks just represented yet another instance of automating an important manual process.

What is User Acceptance Testing (UAT)?

I led with a tale about unit tests because testing software components applies to everyone that writes software. I mean, you always test your own software, even if you don’t think you’re doing so. Whenever you compile, you test your code to see if it compiles. Granted, you aren’t executing the most sophisticated, high-value test known to man. But you are performing a test of sorts.

But what if we look beyond our own dev boxes a bit? What if we look at other forms of testing?

For almost any software that we write, other stakeholders will perform other sorts of tests. These stakeholders includes users or user-proxies, who perform an activity known as user acceptance testing (UAT). In its simplest incarnation, this involves users or their proxies using the software and evaluating whether or not they find it acceptable.

This can come in various shapes and sizes. In some cases, actual users perform formalized beta tests, perhaps for pay. In other cases, someone from the QA group might do a quick run-through and give a thumbs-up or thumbs-down. But whatever happens, these tests capture the user’s experience and perspective.

Jul
24

By Erik Dietrich

APIs and the Principle of Least Surprise

Category: Language Agnostic Tags: API, Monitis, Software Design | 6 Comments

Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, have a look at some of the other authors for their blog.

I remember something pretty random about my first job. In my cubicle, I had a large set of metal shelves that held my various and sundry programming texts. And, featured prominently on that shelf, I had an enormous blue binder.

Back then, I spent my days writing drivers and custom Linux kernel modules. I had to because we made use of a real time interface to write very precisely timed machine control code. As you might imagine, a custom Linux kernel in 2005 didn’t exactly come with a high production quality video walking users through the finer points. In fact, it came with only its version of the iconic Linux “man pages” for guidance. These I printed out and put into the aforementioned blue binder.

I cannot begin to tell you how much I studied this blue binder. I pored through it for wisdom and clues, feeling a sense of great satisfaction when I deciphered some cryptic function example. This sort of satisfaction defined a culture, in fact. You wore mastery of a difficult API as a badge of honor. And, on the flip side, failure to master an API represented a failure of yours.

Death of “Manual Culture”

What a difference a decade makes. No longer do we have battleship gray windows applications with dozens of menus and sub-menus, with hundreds of settings and thousands of “advanced settings”. No longer do we consider reading a gigantic blue documentation binder to be a use of time. And, more generally, no longer do we put the onus of navigating a learning curve on the user. Instead, we look to lure users by making things as easy as possible.

Ten years ago, a coarse expression described people’s take on this responsibility. I’ll offer the safe-for-work version: “RTM” or “Read the Manual.” Ten years later, we have seen the death of RTM culture. This applies to APIs and to user experiences in general.

DaedTech