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.
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.
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.
If your monitoring system doesn't have knowledge of what's supposed to be out there (like via service discovery), how do you know when something is broken/down/missing?
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.
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.
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.
You can alert via a number of mechanisms: email, PagerDuty, Slack et al, etc (I talk about most of those in Chapter 9).
I have never been very keen on alerting dashboards, I find they are rarely actually reviewed and flash red for days or weeks. :) So I only covered metrics/graphing as a console rather than a status console. If you want to add such a console it'd be easy to output Riemann events via an API to such a console.
> you MUST learn Clojure (which can be hard to get a whole team to agree to)
For any sufficiently advanced monitoring system, you're going to have to learn some form of DSL/language to take advantage of it.
I wouldn't consider this to be a major issue, more part of the irreducible complexity of the problem. The Riemann examples I've seen all seemed pretty readable, and routing alerts is not world away from what you'd be doing in say a Prometheus Alertmanager config; just with S-Expressions against YAML.
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.
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?
Mostly, it has great support for service discovery for many major cloud and container platforms (Kubernetes, Marathon, EC2, Azure, Zookeeper, Consul, ...). So it can not only go out and pull metrics data directly from instances as they float around your dynamic cluster scheduler, but also attach identity metadata (as provided by the service discovery) to the time series collected from each instance. For example, you may map EC2 tags or Kubernetes labels into your Prometheus time series labels to give you more useful metrics. There's also a way to plug in your own custom service discovery. Also, Kubernetes exports native Prometheus metrics since quite a while already.
Borg inspired Kubernetes. Borgmon inspired Prometheus. So naturally it works well together with a dynamically scheduled world.
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.
I still don't know anything much about your systems, but I do know this: find out what your hardware team uses and see if it is right for you, too. (Or find out that they are unhappy with it, and perhaps go in together on a new system.)
Benefits: shared expertise. Common language. Propagation of alerts up from hardware and down from services. Better root cause analysis. If you have a good culture, faster resolution time and better understanding.
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.
