The latest News and Information on Log Management, Log Analytics and related technologies.
Earlier this week, I wrote a blog stating our intention to fork Kibana and Elasticsearch. This was a huge decision on our end, one that we did not take lightly. A few days have passed since this announcement and I wanted to share how humbled and excited we are with the responses from companies and individuals who are eager to participate and contribute.
Although AWS Lambda is a blessing from the infrastructure perspective, while using it, we still have to face perhaps the least-wanted part of software development: debugging. In order to fix issues, we need to know what is causing them. In AWS Lambda that can be a curse. But we have a solution that could save you dozens of hours of time. TL;DR: Dashbird offers a shortcut to everything presented in this article.
Let’s say you get an alert that one or more queries is slow. Or that your users complain, whichever comes first 🙂 We’ve all been there… How do you find the root cause for this slowness and then fix it? In this article, I’ll go through my usual thought process: first, I’d try to find which queries are slow. Then, I’d dig deeper: Let’s take a specific example and run through each step.
A couple of days ago, Elastic announced that it will change the licensing of Elasticsearch and Kibana as of the 7.11 release to a proprietary dual license (under the SSPL license) and away from the open-source Apache-2.0 license. This move has caused extensive turmoil and frustration in the open-source community, especially with organizations that rely on Elasticsearch. Let me start with the end in mind.
As the Trump Administration comes to a close, there is no better time than the present to reexamine the Department of Defense Digital Modernization Strategy and its potential sustainment beyond January 2021.