mspaulding06

Currently I use a variety of techniques for managing content I would like to revisit on the web. I do use bookmarks mostly for often visited websites and I always using syncing if possible with Chrome and other browsers that support it (Brave does now!). I've also discovered some browser plugins that really help with this. OneTab is absolutely indispensable and will store all of your currently open tabs so that you don't have to keep them open. That's great when I've got several tabs open on a single subject that I want to come back to later. I've also started to use Pocket for most blog posts and random things that I want to read some time in the future but can't right now. The nice thing is that it is accessible from all my devices so I can put links into Pocket from my phone and then go to them from my desktop computer.

Then what is it? Please help me understand this research that proves my statement incorrect.

Your reaction to reading is just an emotional response. You need to get over the fact that you don't like to read and do it. Eventually it will come naturally to you. That's one of the things that I learned from a CSCI professor when I was in school. Don't be concerned about your emotional response when you face a large coding problem, or any kind of difficulties. You can do it and you will if you really want it enough.

There's some you can learn from videos and other tutorials, but really you need to read books. You need to read books and you need to write a lot of code. Coding teaches you how to be better at coding, but reading books teaches you what your code actually means. Reading is where you learn the terminology you need to know to really understand what's going on in your code. It also helps you to be a better communicator with other programmers. Programmers who don't read books can't communicate to other programmers what their programs do. Being a good communicator is part of being a good programmer. So yes, read books, lots of them.

It's a major issue for me because of the time investment required to learn the language (functional programming isn't exactly second nature to most programmers) and the need to design the monitoring system from scratch. Instead of an out-of-the-box system you're getting more of a framework which allows you to build one. I actually like Clojure and agree that it is readable as well as fun to learn. But I think with something like Prometheus you do more simple configuration than monitoring system design.

It's true, you can't tell if something is missing if it never reported. I guess it depends on your requirements. In a situation where your workloads are ephemeral you may not care as much if all of your services have reported as long as most have. In the case that something should no longer exist you could write that functionality into your Riemann configuration. As an example, I could write a "dead service" stream processor that is used to inform Riemann that a service should no longer exist. When a "dead service" event is injected into the event stream for a particular service, Riemann will note the dead service and ignore future events from it.

Riemann injects expire events into the event stream when it doesn't hear from a service for a while. Each event has a TTL that it uses to figure this out. Then of course you can alert on the expired events or take other actions.

Yep, I think that is Riemann's greatest advantage. I don't like the fact that with Prometheus I have to set up some sort of service discovery mechanism. Right now we're using Foreman to manage our clusters, so most likely I would have to use the file service discovery type and query the Foreman API to produce a YAML or JSON file to provide a list of static hosts.

I like Riemann and actually read The Art of Monitoring (https://artofmonitoring.com/) which was a great book. There are two big downsides for me on this one. First, you MUST build your monitoring solution from scratch and you MUST learn Clojure (which can be hard to get a whole team to agree to). Second, there's no alerting dashboard, which makes it difficult to see the overall state of the clusters you're dealing with. The only way you know there's a problem if you get an email. Maybe there's a better way to handle that but I wasn't able to find one.

Yeah, containerization is a good point. We've been starting to deploy apps on Docker within the last 6 months. What does Prometheus offer that makes it better for containerization?

Thanks for the comprehensive reply. Briefly I would say that we care about availability more than performance, though both are important. We're running somewhere on the order of 2000 VMs w/ ESX with some bare metal systems running database clusters. We have a separate team that manages the hardware infrastructure and they have their own monitoring and alerting system. I'm mostly concerned about preventing downtime for the application cluster, alerting the right people via the right means (chat, email, pagerduty) when something does go down, and getting some high resolution graphs for analysis.

Yeah, should have made it more clear. Monitoring a linux-based application cluster of a couple thousand machines.

If you want something with good hardware support for Linux Lenovo is always my first choice. I have a Thinkpad x220 that runs Linux flawlessly. I've also got an ASUS UX305CA which isn't too bad either. The brightness controls didn't work out of the box, but I've got it all working now. It's thin and light, comparable to a Macbook Air. I use it as my personal development laptop. Easy to take anywhere since it's only 13 inches, but it has a QHD touchscreen so there is plenty of space to have multiple code windows open at the same time. Battery life isn't too bad either and it's cheap (about $700 USD new).

I personally like https://www.codeeval.com/. It's not competitive really, just solving coding problems. But I find it great especially for learning new languages or refreshing myself on old ones.

Having gaps on your resume isn't a big deal. If you're good at what you do you shouldn't have any problems. I have two 6 month gaps on my resume and it wasn't any problem getting my current job as a DevOps engineer. It can be a smart move taking your time to find the right thing. The last thing you want is to end up working somewhere just so you can have a paycheck.