There is more to Distributed Tracing with Jaeger than just capturing machine data as with metrics, or tailing log files. To start, you should read this primer. In this article, I will walk you through the initial principles you’ll need before executing anything within your codebase. This is going to focus on Node.js, as slight differences and concerns exist for browser applications.
Load balancing is an element of most popular web applications. The reason for this is simple: Load balancers maintain application scalability and sustainability. It’s nearly impossible to imagine a modern application handling continuous traffic or periodic traffic spikes while relying only on a single running server’s capacity. As a result, load balancers have become a critical part of software development.
This post aims to provide a very simple beginner’s guide to Jaeger + OpenTracing instrumentation for Go applications (the terms “application” and “service” is used interchangeably in this document) via a working example. If you are new to instrumentation, I recommend that you first read this post for a practical introduction to instrumentation for Jaeger and OpenTracing. You can also get more info on using logs in Go.
Every journey in distributed tracing starts with instrumenting an application to emit or extract trace data from each service as they execute. There are many ways to instrument, including the use of SDKs and pre-configured frameworks, and many protocols for transmitting the trace data to the analysis tool.
At Logz.io, we are always keeping a close eye on the most widely-used and favorite open source monitoring tools among the developer community. This is why we announced the Early Access for our Infrastructure Monitoring product based on open source grafana at this time last year. After a successful GA and a year of strong adoption among new and existing customers, I’m thrilled to announce a huge milestone for the product: Early Access for Prometheus-as-a-service!
Needless to say, 2020 has been a year to remember. So it goes without saying that re:Invent 2020 will be unforgettable as well, but this time, in a good way. For starters, instead of hopping on a plane and spending four days in Las Vegas, we get three weeks of it from the comfort of our home offices. As usual, the event will be jam-packed with speakers, presentations, hands-on learning sessions. They’ll be helmed by experts in the cloud computing, DevOps, and the open source community.
Logz.io is releasing its AI-powered Exceptions, a revamped version of our Application Insights, fully embedded in your Kibana Discover experience, to boost your troubleshooting experience and help you find bugs in the log haystack.
Have you ever had trouble working with Elasticsearch clusters? You’re not alone. In this post, I will discuss a problem I’ve encountered working with large Elasticsearch clusters and how I solved it. I will share a lot of knowhow on major technical Elasticsearch concepts, some diagrams for illustration, and of course a cool solution! In particular, I will go into Elasticsearch nodes, indices, and shards.
The ever-evolving cloud-native landscape creates constantly changing attack surfaces. As a result, teams implement a whole suite of security tools to identify large varieties of vulnerabilities and attacks, as well as monitor more logs than ever to find malicious activity. But monitoring so much information can cause a barrage of notifications and alerts. Even if you’re identifying real security threats, it can be impossible to know where to start and where to focus.
System Monitor (Sysmon) is Windows’ service for monitoring activity and recording it to the Windows event log. It is the go-to for logging anything on a PC. Sysmon will immediately log events, capturing vital info. The driver for Sysmon will install as a boot-start driver, enabling capture of any and all events from the get-go. Now, you can send Sysmon logs straight to Logz.io Cloud SIEM.
