Application Performance Monitoring, aka APM, is one of the most common methods used by engineers today to measure the availability, response times and behavior of applications and services. There are a variety of APM solutions in the market but if you’re familiar with the ELK Stack or are a Logz.io user, this article describes using a relatively new open source-based solution — Elastic APM.
Last month, we announced Logz.io Security Analytics — a security app built on top of the ELK Stack, offering out-of-the-box security features such as threat intelligence, correlation, and premade integrations and dashboards. In this article, I’d like to show an example of using both the ELK Stack and Logz.io Security Analytics to secure an AWS environment.
In our last blog post, we learned what the Distributed Denial of Service (DDoS) attack is, and examined the DDoS picture globally. As we walked through some recent and well-known cases, we also surveyed a range of attack types and drilled down to specific examples. In this article, we’ll study the mitigation techniques you’ll need to resist these attacks. You’ll learn: 1. How to avoid becoming a bot; 2. How to prepare your own network for the possibility of an attack and finally; 3.
Addressing compliance requirements for monitoring and logging can be a challenge for any organization no matter how experienced or skilled the people responsible are. Compliance requirements are often not well understood by technical teams and there is not much instruction on how to comply with a compliance program. In this article, we’ll discuss what some of these new compliance programs mean, why they are important, and how you can comply with your logging and monitoring system.
Imagine the following scenario: you’re running a small corporate website, and suddenly, your service becomes unreachable, throwing a 503 (service unavailable) http error at your customers and website visitors. The irritated messages start flooding in to support. Worried, you walk through the usual administrative checks, to make sure it’s not what you think it is. Is the webhost up?
Facing the growing threat of cybercrime, and to answer compliance requirements, more and more organizations are looking at their DevOps and Operations teams to implement security. The term “security”, however, often triggers negative feelings among engineers. The reason for this is that security is associated with siloed, sequential and complicated processes — all roadblocks to fast development and deployment.
We founded Logz.io four years ago with a vision to provide a platform for engineers like us to operate the next generation of applications and infrastructure. As engineers, we experienced firsthand the challenges of running large-scale, open-source tools and the frustration of dealing with slow, proprietary tools which were not designed to support the rapidly changing technology stack we operated.
Boston and Tel Aviv, October 24, 2018 — Logz.io, the leader in AI-powered log analysis, releases the first robust security application built on the open source ELK Stack, bringing powerful and scalable security monitoring and analysis directly into the DevOps workflow.
While there are plenty of articles aiming to instruct newbies on “how to become a DevOps engineer”, none of them answer a simple question – should you become one to start with? For me, it’s been a long and winding journey to becoming what is called a Site Reliability Engineer (SRE). The journey was unplanned, and for each step, I had to figure out what I want my next challenge to be and how to achieve it.
In Elasticsearch parlance, a document is serialized JSON data. In a typical ELK setup, when you ship a log or metric, it is typically sent along to Logstash which groks, mutates, and otherwise handles the data, as defined by the Logstash configuration. The resulting JSON is indexed in Elasticsearch.
