Operations | Monitoring | ITSM | DevOps | Cloud

Coroot

Instrumenting Python GIL with eBPF

Every Python developer has heard about the GIL (Global Interpreter Lock) This lock simplifies memory management and ensures thread safety, but it also limits the performance of multi-threaded, CPU-bound programs because threads can’t run Python code in parallel. Here is a great explanation of why Python requires the GIL by Python’s creator, Guido van Rossum: Guido van Rossum: Will Python ever remove the GIL? | Lex Fridman Podcast Clips.

Discover what your applications are really up to with Coroot

Modern Applications can use a lot of external services, some of those interactions are expected, others not so much. There could be many reasons for those unexpected interactions, ranging from security vulnerabilities and various malware to outdated code and various reporting and statistics software may report to its creator or a third party. These unexpected interactions can be a security risk, and may also raise privacy concerns.

What Developers Should Know about Observability

Peter is a serial entrepreneur and co-founder of Percona, FerretDB, and other tech companies. As a leading expert in open-source strategy and database optimization, Peter has applied his technical knowledge and entrepreneurial drive to contribute as a board member and advisor to several open-source startups. His insights into performance optimization and system reliability play a crucial role in shaping Coroot’s functionality.

Why should you care about DNS Observability?

If you look at typical Application interaction with service point it tends to happen in two stages – first we connect to the Service and when we are interfacing through that established connection. In this description though one thing stays invisible – you can’t simply connect to the Service through the hostname – that host name needs to be resolved into an IP address, and if this name resolution process does not work or does not perform, the application suffers.

Coroot v1.0: Unified Observability for Heterogeneous Infrastructures

In the current cloud-native era, almost every organization has one or more Kubernetes clusters in their production infrastructures. However, only a small percentage of companies, especially enterprise-level ones, can claim that they are fully committed to running everything exclusively on Kubernetes. The most typical scenario is that new stateless services are deployed on Kubernetes, while legacy applications, third-party services, and databases continue to run on dedicated VMs or bare-metal nodes.

It is the time to simplify Observability!

I come from the database world where observability, or monitoring as we used to call it, was always really important to keep databases up and running and operating well. Thousands of data points would be collected and displayed in countless graphs. As an expert DBA, you can see every detail about internal database operations and feel very good about yourself being able to put all this data together and resolve the puzzle.

Coroot v1.0: Revolutionizing Distributed Tracing Analysis

We’re excited to announce Coroot v1.0 – our first stable version. It includes some great improvements, such as a new Distributed Tracing interface that takes troubleshooting to the next level. In this post, we’ll compare existing open-source distributed tracing tools, identify unsolved problems in the troubleshooting process, and see how Coroot can address them with its brand-new distributed tracing feature. These days, software is getting more complicated.