Microservices architecture is the new norm for building products these days. An application made up of hundreds of independent services enables teams to work independently and accelerate development. However, such highly distributed applications are also harder to monitor. When hundreds of services are traversed to satisfy a single request, it becomes difficult to investigate system issues.
Ask any cloud software team using Kubernetes (and most do); this powerful container orchestration technology is transformative, yet often truly challenging. There’s no question that Kubernetes has become the de-facto infrastructure for nearly any organization these days seeking to achieve business agility, developer autonomy and an internal structure that supports both the scale and simplicity required to maintain a full CI/CD and DevOps approach.
The real beauty of this modern, cloud-fueled, DevOps-driven world that we are living in is that it’s so highly composable. In so many ways, we’ve been freed from the limitations and structures of the previous annals of software and technology history to build things the way that we want to, and however we choose to do so.
Open source monitoring and observability tools can be found in production all over the world – whether they’re being used by startups or entire enterprise development teams. DevOps, ITOps, and other technical teams rely on tools like Prometheus, Grafana, OpenSearch, OpenTelemetry, Jaeger, Nagios, Zabbix, Graphite, InfluxDB, and others to monitor and troubleshoot their cloud environment.
Logz.io is one of Logz.io’s biggest customers. To handle the scale our customers demand, we must operate a high scale 24-7 environment with attention to performance and security. To accomplish this, we ingest large volumes of data into our service. As we continue to add new features and build out our new machine learning capabilities, we’ve incorporated new services and capabilities.
It’s Cybersecurity Awareness Month, and in that spirit, we’re offering a number of tips and tricks small security operations center (SOC) teams can use. I started my career working as part of a small SOC team, and working with other security experts here at Logz.io, we’re happy to offer these to small SOC teams who can often use all the help they can get! In the last post, we talked about managing security talent and building processes.
Observability is a hot topic in the IT world these days. It is oftentimes discussed through the lens of the “three pillars of observability”: Logs, Metrics and Traces. Indeed these telemetry signal types help us understand what happened, where it happened and why it happened in our system.
Many developers don’t know what instrumentation really is, and those who do don’t really understand the black magic that takes an application and makes it emit telemetry, especially when automatic instrumentation is involved. On top of that, each programming language has its own tricks. I wanted to unwrap this loaded topic on my podcast, OpenObservability Talks. For this topic I invited Eden Federman, CTO of Keyval, a company focused on making observability simpler.
We all know that observability is a must-have for operating systems in production. But we often neglect our own backyard — our software release process. We noticed we made that mistake here at Logz.io. We were wasting time and energy in handling failures in the CI/CD pipeline, and made our Developer-on-Duty (DoD) shifts tedious. That’s why it’s critical to incorporate your observability practices into your CI/CD pipeline.
Every security operations center (SOC) team is different, and for smaller teams, even small challenges can seem big. I started my career in cybersecurity as part of a smaller team, and eventually grew into a SOC role. During that time, I gained a good deal of knowledge about the dos and don’ts of what a small SOC team needs to do in order to be successful.
