Operations | Monitoring | ITSM | DevOps | Cloud

It seems like every conversation is about inflation lately. Everything is getting more expensive and the news cycle suggests there is little chance of that abating. Inflation and supply chain challenges are having a knock on effect in terms of cloud adoption and network usage. We’ve already seen some of the big providers increase their prices - so what’s to be done? Can technology also offer solutions for stemming the rise of IT costs?

Whether you’re new to Kubernetes or a bona fide wizard, it may seem like getting any meaningful cost data out of it is a miracle. This is because many organizations that migrate to Kubernetes unwittingly step into the Black Box of Kubernetes Spend. In pre-Kubernetes life, teams could allocate costs by tagging resources.

Most sysadmins and developers have at some point used a few of the popular Linux networking commands or their Windows equivalents to answer the common questions of host reachability- that is, whether a host or service is reachable and how fast it responds. One of the simplest, common checks, is to simply ping a host to verify that it’s reachable from where you issue the command, and to see the total time it takes for the host to receive your request.

For DevOps teams looking for insights on how to improve, it’s invaluable to leverage the learnings of others. At the same time, given the wide range of DevOps teams’ expertise, tenure, and organizational dynamics, it’s also clear that one size does not fit all. That’s why efforts like this year’s “Accelerate State of DevOps Report” are so important. We’re proud to be a sponsor of this 2022 edition.

High availability. This is what every monitoring tool needs to ensure that you never compromise on IT infrastructure visibility. On top of high availability, do you really want to enable all available features on your production system? It is important for the monitoring tool to have a low footprint on your CPU consumption and memory usage. Let’s dive deeper into the recommended way of configuring Netdata to ensure high availability and a low resource footprint through data replication.

So you’ve decided to take advantage of Site Reliability Engineering by hiring SREs for your company. Now, you have a second decision to make: Exactly how many SREs to hire. Do you need just one or two SREs? Or should you build a sprawling SRE team, with a dozen or more SREs on hand to support your organization’s reliability needs? The answers to these questions will, of course, vary; every business’s needs are different.

Introducing project context restrictions for GitLab organizations. This feature enables project-based restrictions on contexts for standalone projects that are not tied to a VCS. Standalone projects are available at this time only with a GitLab integration with CircleCI. In this blog post, we hope to explain the value of this feature and how it can be used to further secure your workflows.

One of the biggest mistakes I’ve had to repeatedly help companies fix has been poor partitioning design. I’ve seen many database architectures designed in an attempt to make queries faster. While faster queries can be a product of implementing partitioning correctly for a given design, I’ve often seen query response times get much slower from implementing partitioning incorrectly for the database design.