Operations | Monitoring | ITSM | DevOps | Cloud

Managing IT infrastructure is impossible without proper monitoring solutions and tools. Monitoring requires regular checks on the status, and the best way to gather details would be in the form of reports. Advanced IT monitoring solutions provide an automatic diagnosis of performance and availability issues across your IT network; manual interventions help optimize the process. Manual interventions make sure you don’t miss out on any warning signs before reaching the critical points.

Almost every time I teach a class on DevOps, one of the questions that comes up is: How do we do code reviews in this automated process? There are actually a number of answers to this question. Let’s walk through a few.

In this article, we are going to look at the architecture of Apache ActiveMQ and how to monitor critical metrics of ActiveMQ using Hosted Prometheus and Hosted Grafana. If you would like to follow the steps in this blog, make sure to sign up for the MetricFire free trial. You can use Graphite and Grafana directly from our platform. MetricFire is a Hosted Graphite, Grafana and Prometheus service, where we do the setup and management of these open-source tools so you don’t have to.

The rapid pace of updates and upgrades to operating systems, software frameworks, libraries, programming language versions – a boon to the future of fast-paced software development, has also come to slightly bite us in the back because of having to manage these very many dependencies with their different versions across different environments.

For many software engineers and developers, using standard libraries or built-in objects is just not enough. To save time and increase efficiency, most developers build on work done by others. Whatever the coding problem, there is likely another programmer who has already created a solution for it. There is usually no need to repeat the problem-solving process. This principle is known as Do not Repeat Yourself or DRY.

An on-call schedule tells you and everyone in the team who will be the first responder when an issue happens in production. The on-call team member is responsible for investigating the issue, either fixing the issue herself or adding other people who can help fix it. Having an on-call schedule is important for building reliable systems because making someone responsible for production issues makes sure that they're not ignored.

Adding alerts across your monitoring tools is taking a proactive approach to reliability. But if there are too many alerts, then it can become counterproductive because team members will start ignoring alerts or remove the alerting altogether. Which is why you need a systematic approach to adding alerts and dealing with them.

DevOps has great potential; when it’s done right, it offers organizations improved collaboration, quick innovation, better quality, and shorter delivery cycles. But the reality is that some businesses don’t carry the DevOps process through to the data layer.

If you shudder thinking about compilation for different platforms, I know the feeling. One of the Java promises, the WORA (Write Once, Run Anywhere) principle, while revolutionizing platform independence, it stopped short of one more step – to be able to deploy anywhere. Personally, I think that WORADA sounds awesome, but I guess before Docker it didn’t occur to people that eliminating “works on my machine” is as simple as shipping your machine.