Want to learn how to cover all the #observability basics in your #DevOps role?

From #kubernetes to #VMs, #ePBF to #OTEL: check out the article from #Coroot co-founder Peter Zaitsev to learn how #FOSS can propel you from guessing to knowing the root cause of service issues: https://t.ly/VX3t4

#SRE #tech #IT #observability #coroot #aws #databases

Happy #WorldPenguinDay to all fellow fans of #Linux, #opensource, and #ePBF-powered innovation - worldwide! 🐧💚🌍

#freesoftware #tux #penguins #penguinday #coroot #linuxkernel #tech #softwarelibre #ubuntu #manjaro #mint #arch #debian

https://github.com/grafana/beyla is cool. The documentation misses some parts, so I havd to dig into GitHub issues, but overall is a great tool.

I spinned up a container next to a microservice and got metrics and traces, which made me happy because I didn't have to do that mundane observability instrumentation stuff. I find it a great tool when you have very little observability and want to quicky go from 0 to 1. However, to go from 1 to 100 you still have to bring some manual instrumentation, unfortunately.

#observability #epbf

GitHub - grafana/beyla: eBPF-based autoinstrumentation of web applications and network metrics

eBPF-based autoinstrumentation of web applications and network metrics - grafana/beyla

GitHub

ePBF for Windows, https://github.com/microsoft/ebpf-for-windows.

> eBPF is a well-known technology for providing programmability and agility, especially for extending an OS kernel, for use cases such as DoS protection and observability. This project is a [WIP] that allows existing eBPF toolchains and APIs familiar in the Linux ecosystem to be used on top of Windows. That is, this project takes existing eBPF projects as submodules and adds the layer in between to make them run on top of Windows.

#windows #epbf

GitHub - microsoft/ebpf-for-windows: eBPF implementation that runs on top of Windows

eBPF implementation that runs on top of Windows. Contribute to microsoft/ebpf-for-windows development by creating an account on GitHub.

GitHub

I updated the benchmarks for #epbf overhead in ebpf_exporter.

Overhead for an empty probe for getpid() syscall that immediately returns:

* 15ns for a tracepoint (tp_btf) 🚀
* 24ns for an fentry đŸŽïž
* 137ns for kprobe 🐌

@train I know it is useful for ~3 things.
1. Defining quirks for ALSA
2. Defining quirks for Hid/++
3. Exposing highly semantic interfaces to userspace.

For these former two, #ePBF brings benefits by allowing userspace to quickly iterate over necessary fixes. Also there is a good chance you can then backport fixes easily to LTS.
For the latter exposing interfaces via ioctl or sysfs is cumbersome in highly semantic scenarios. Here #eBPF could make sense as long as latency, etc. is not a concern.