In previous posts, we looked at various issues related to monitoring, collecting, and saving metrics and different methods and tools for getting around them. In today’s article, we’ll be discussing yet another tool that simplifies these processes: Netdata.
Unlike other analytical tools, Netdata is designed for gathering and visualizing metrics in real time (and when necessary, a backend can be incorporated for gathering and saving collected metrics).
Last year marked a milestone in the world of Internet technology: the confirmation and standardization of HTTP/2. Popular web servers like Apache and Nginx already support HTTP/2, as do the latest versions of most browsers.
Data shows that by the middle of 2015, very few web sites and services had switched to HTTP/2, only 0.4%. The latest statistics (September 2016) show a significant increase: from 0.4 to 10%. It wouldn’t be that wild a prediction to say more and more sites are going to be making the switch and at a faster rate.
Today we’d like to continue our blog series on containerization. As our first two articles (1 and 2) were dedicated to theory, this post will focus on one tool and its features: LXD.
LXD (short for Linux Container Daemon) was created by Stéphane Graber, who works for Canonical. His name is well known in the professional community as he is also one of the authors of another popular container solution: LXC. Naturally, LXD is built on LXC, which makes it easier to work with containers and adds a wide range of new abilities.
In our previous article, we explored problems tracing and profiling the Linux kernel.
Today, we’d like to revisit these issues and talk about an interesting kernel tracer, LTTng, which was developed by Canadian programmer and researcher Mathieu Desnoyers. With this tool, we can receive information on events that occur in both the kernel and user spaces.
There are a number of tools for analyzing events at the kernel level: SystemTap, ktap, Sysdig, LTTNG, etc., and you can find plenty of detailed articles and materials about these on the web.
You’ll find much less information on Linux’s native mechanism for tracing system events and retrieving/analyzing troubleshooting information. That would be ftrace, the first tracing tool added to the kernel, and this is what we’ll be looking at today. Read more
Today we’ll be continuing our post series on containerization mechanisms. In our last article on containerization, we talked about isolating processes using the namespaces mechanism. For containerization though, isolating resources isn’t enough. If we launch an application in an isolated environment, we should be sure it has been allocated enough resources and not use an inordinate amount, interrupting the rest of the system. For this task, the Linux kernel has a special mechanism, cgroups (short for control groups), which we will talk about today.
Any individual or company looking to utilize a data center’s services needs a guaranteed level of quality. There has to be some assurance that their equipment will not fail and that their data will always be available (or that in the worst case scenario, their project will quickly be restored).
When it comes to data centers, the most commonly recognized guarantee is certification. Certification asserts that the center complies with a predetermined list of standards. Although issues of standardization have gained particular interest over the past few years, the number of relevant publications on the topic remains low.
In this article, we’ll be looking at the primary regulatory documents for data center certification.
Linux container solutions have gained quite a bit of popularity over the last few years. A lot of people have written or spoken about how containers can be used and what for, but little attention has been paid to the mechanisms behind containerization.
All containerization tools, like Docker, LXC, or systemd-nspawn, are built on two Linux kernel subsystems: namespaces and cgroups. In this article, we’ll be taking an in-depth look at namespaces.
Containerization has become an increasingly relevant topic. There are already thousands, if not tens of thousands, of articles and posts written about popular solutions like LXC and Docker.
In today’s article, we’d like to discuss systemd-nspawn, a systemd component for creating isolated environments. Systemd is already a standard in the world of Linux and in light of this, it wouldn’t be unfounded to suggest that the potential for systemd-nspawn will significantly expand in the near future. For this reason, we think now would be a good time to better acquaint ourselves with this tool.