DevOps と IT 業務｜リソースセンター

In one of my previous blogs I explained how important it is for a modern observability platform to provide “the observers” full, flexible access to all raw telemetry. Observability’s promise to find unknown unknowns relied directly on the ability of fast, powerful and multidimensional high-cardinality analysis of raw data, to uncover previously unknown patterns that have not yet been visualized as a metric, dashboard panel or an alert or anomaly event.

In this article we look at how to monitor Cassandra database clusters. We start with the basic architecture of a Cassandra cluster, and mention the most important metrics to gather. Next, we advance step-by-step into configuring and setting up a monitoring stack with Jolokia, Telegraf and Sumo Logic collectors and dashboards – everything you need to monitor Cassandra databases.

Many of our customers today leverage Office 365 GCC High, including organizations looking to meet evolving requirements for working with the United States Department of Defense. Sumo Logic enables customers to leverage our out-of-the-box monitoring and analytics capabilities to analyze Office 365 GCC High data to offer security engineers and security analysts stronger situational awareness of internal employee data.

A common scenario for log analytics is that many log events are high value for real time analytics, but there are also events that are low value for analytics, but account for a very large percentage of overall log volume.

The Sumo Logic team is excited to announce that it has been named a Visionary in the Gartner 2021 Magic Quadrant for Security Information Event Management (SIEM). We believe our placement in the Visionary quadrant reflects the value and success our customers have realized by using our cloud-native security platform and the innovative ways in which it solves SIEM and modern security operations use cases.

In this article, we're going to focus on pillar number five: measuring everything. We'll discuss five key metrics for DevOps software pipelines and explain how each of them can help measure software delivery performance.

Platform architects, SREs, developers and DevOps staff for mission-critical modern apps know being notified in real-time when or before critical conditions occur can make a massive difference in end-user digital experiences and in meeting a 99.99% availability objective.

In the beginning, there was the Log – or to be a bit more precise, there were application logs. At least that's how it was in the early days of application development, when raw log data itself was more often than not the point where troubleshooting began.

Since 2010, it has been Sumo Logic’s mission to democratize machine data. Naturally, we tend to focus on the outcomes: reliable and secure applications and systems that are the engines of successful modern businesses. But to drive these outcomes, and before the spotlight-hogging analytics kick in, algorithms require data. And this is where the magic starts! Sensu has been working on championing a monitoring as code approach to building observability pipelines for a decade now.

Application monitoring is a well-established discipline that dates back decades and remains a pillar of software management strategies today. However, as software environments and architectures have evolved, monitoring techniques have needed to evolve along with them. That’s why many teams today rely on distributed tracing to glean insights that they can’t gather from application monitoring alone. Distributed tracing provides a deeper level of visibility into complex distributed environments than application monitoring can achieve.

Telegraf is a server-based agent for collecting all kinds of metrics for further processing. It’s a piece of software that you can install anywhere in your infrastructure and it will read metrics from specified sources – typically application logs, events, or data outputs.

In a recent experiment with my colleagues, I polled them about the following: “What would they do if the lights went out as you worked at night?” Besides identifying the funny and who-you-want-in-case-of-an-emergency responses, most of my colleagues checked to see if the problem might be broader than their own home.

When migrating to Kubernetes and re-architecting your applications into containers, logging is a critical piece to consider. The twelve-factor app methodology has a section dedicated to logging and outlines the importance of not worrying about routing and storage of your logs. As a best practice, applications running in containers should rely 100% on standard output (STDOUT). Unfortunately, getting logs from applications that do not write to STDOUT is non-trivial and has many things to consider.

It’s essential to choose the right tool for the job. I have an old, sturdy screwdriver that I use for lots of odd DIY jobs around my house, like cleaning gutters, opening paint cans, and general maintenance on my lawnmower. However, when I’m performing an upgrade on my computer, a large, rusty screwdriver isn’t the best tool to remove the screws anchoring my motherboard.

If your team falls into the majority of organizations that use NGINX – which remains the world’s most popular Web server – to host websites and Web applications, monitoring NGINX usage, performance, and transactions is critical for maintaining a positive end-user experience.