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.
So far in our series on scaling observability for game launches, we’ve discussed ways to 1) quickly analyze large volumes of telemetry data and, 2) ensure high-quality telemetry data for more effective analysis at lower costs. The best practices in these blogs outline best practices for scaling observability during game launch day – which is necessary to ensure high performance across all infrastructure components – to ensure no lag, no glitches, and no bugs.
HashiCorp Consul began as an open-source project for service discovery. It has evolved to provide other valuable functionality like secure service mesh to help secure microservice architectures based on service identity, but also the ability to achieve repeatable application deployment lifecycles via Network Infrastructure Automation and control access to the service mesh via Consul API Gateway.These features are considered the four core pillars of Consul service networking.
