Operations | Monitoring | ITSM | DevOps | Cloud

Ask any DevOps engineer, and they will tell you about all the alerts they enable so they can stay informed about their code. These alerts are the first line of defense in the fight for Perfect Uptime SLA. With every good solution out there, you can find plenty of methods for alerting and monitoring events in the code. Each method has its own reasons and logic for how it works and why it’s the best option. But what can you do when you need to connect two opposing methodologies? You innovate!

We're a small team of engineers right now, but each engineer has experience working at companies who invested heavily in observability. While we can't afford months of time dedicated to our tooling, we want to come as close as possible to what we know is good, while running as little as we can- ideally buying, not building. Even with these constraints, we've been surprised at just how good we've managed to get our setup.

Amazon Elastic Kubernetes Service, or EKS, is a managed Kubernetes service. That means that Amazon Web Services (AWS) handles some of the deployment and management tasks for users. But the fact that EKS is a managed service doesn’t mean that AWS manages all administrative tasks. One key management task that isn’t fully covered as part of EKS is monitoring.

Loki 2.4 is here! It comes with a very long list of cool new features, but there are a couple things I really want to focus on here. Be sure to check out the full release notes and of course the upgrade guide to get all the latest info about upgrading Loki. Also check out our ObservabilityCON 2021 session Why Loki is easier to use and operate than ever before.

The need for relevant and contextual telemetry data to support online services has grown in the last decade as businesses undergo digital transformation. These data are typically the difference between proactively remediating application performance issues or costly service downtime. Distributed tracing is a key capability for improving application performance and reliability, as noted in SRE best practices.

When it comes to comparing all of the best solutions for log management and analysis it can be incredibly difficult to compare key features and pricing per annum side by side to see what solutions you should consider trialling.

At Payoneer, we use Coralogix to collect logs from all our environments from QA to PROD. Each environment has its own account in Coralogix and thus its own limit. Coralogix price modules are calculated per account. We as a company have our budget per account and we know how much we pay per each one. In case you exceed the number of logs assigned per account you will pay for the “extra” logs. You can see the exact calculation in this link.

There’s something wrong with the pricing of observability services. Not just because it costs a lot – it certainly does – but also because it’s almost impossible to discern, in many cases, exactly how the costs are calculated. The service itself, the number of users, the number of sources, the analytics, the retention period, and extended data retention, and the engineers on staff who maintain the whole system are all relevant factors that feed into the final expense.