When Simply Business started, we looked at best practices in tech and software development to incorporate them into the way we operate. But best practices on paper don’t always translate into effective cultural and organization-wide processes for a scale-up.
As we shifted from an Elasticsearch, Logstash, and Kibana (ELK) stack to using New Relic log management across all software engineering teams, we learned three key lessons.
U.K. research shows that one in four people rate insurance as the worst industry for allowing customers to do things digitally. At Simply Business, we believe that insurance should be straightforward, easy to organize, and instant. We make it easy for customers—particularly small companies and sole traders in the UK, Europe, US, and Canada—to purchase insurance instantly and digitally, without having to jump on a call or bring in paperwork.
1. Create pre-filtered saved views
The ELK stack used to be seen as a best-in-breed tech stack for observability. But as we started working closely with other teams, like sales and customer service, we found that it didn’t meet all of our needs. An ELK stack is laden with features, but most go unused even by the bulk of software engineers. It is also incredibly complex for non-technical teams to manage.
In the ELK stack, the data schema takes precedence. You can’t have field name collisions. You can’t write a particular attribute because it has a reserved name. You’ll find that this quickly becomes a problem—someone logs date time as ISO 86001, then as a UNIX timestamp. In an ELK Stack, this means you can't query those logs anymore. That’s just one challenge in enabling teams to use logging capabilities.
Most users need a glorified search box to filter logs to answer key questions around data ingestion or query latency. In New Relic log management, the query syntax is intuitive: it looks like Gmail label syntax. Those who aren’t used to SQL can still make use of it. We have our own custom attributes shared across all applications complete with tags and business-specific labels. From a maintenance perspective, we're not using data partitions or anything fancy. We can query the entire sum of all our logs and just use filters, and it's still fast enough for most of what we need.
There’s just less maintenance with no need to maintain schemas and no need to manage instances—even on a hosted ELK solution.
The dashboard Simply Business uses for its telephony metrics.
2. Use tagging to make accessible dashboards
Our developers work across the company in collaboration with business and customer-facing teams. We send dashboards to a lot of people.
We create dashboards for our consultants that show latency and how long the average person has been waiting on a call. These dashboards can be adapted for business teams and sales managers. Then stakeholders can run with it. They don’t need to know a query language and can filter through the data without support. This is key. Our dashboards can be used across the organization to keep everyone on the same page about our customer experience goals.
Logs in context has been super useful for the teams that have adopted it, becoming an integral part of the workflow. We debug things by going from alerts to logs. An alert tells us something is wrong with a time-bound query for your application logs. We also generate that in our query language because we know what the application is called, what the branch is called, and when the error was thrown. We then pre-populate that query.
3. Avoid best-in-breed when it breeds complexity
We initially thought that offering best-in-breed observability tools in each category would benefit our software developers uniformly. We quickly realized that engineer productivity was impacted, and mental strain increased with every new tool we added. Gaining the competency to use one tool effectively is difficult enough, when three or four are added to a stack it becomes almost impossible. Developers stick to the software they already know, it’s human nature, even if there are better tools out there.
Money was another big concern with so many tools in use. We were on track to spend a million dollars a year on observatory tools alone. For the size of our company, using that much of our budget for observability isn’t sustainable—and we weren’t getting the return on investment we needed to justify it.
We’ve cut down on our tech stack to primarily use New Relic as our single observability tool. This allows us to have all our telemetry data, including logs, traces and metrics in a single place for the first time, and enables us to monitor, debug, and improve our entire stack. Focusing on one tool has saved us money as well as mental energy. All of the data our developers need is accessible directly from New Relic. Developers don’t have to waste time hunting down two-factor authentication codes to log into multiple systems. They also don’t need to be observability experts—the platform takes care of that. When we asked developers what they liked most about migrating to New Relic, it’s that they don't have to deal with five different interfaces and multiple different query languages.
Simply Business uses this dashboard to scope container resource usage via filters.
New Relic vs ELK: Log management showdown
On a final note, here’s a comparative table outlining the key elements to consider when comparing New Relic and ELK for log management capabilities. The right choice for your business will ultimately depend on your specific requirements, budget, in-house expertise, and the level of control you need over your log management infrastructure.
| Aspect | New Relic | ELK Stack |
|---|---|---|
| Components | New Relic Logs, New Relic Infrastructure | Elasticsearch, Logstash, Kibana |
| Log collection | Agents collect logs from various sources | Logstash collects, processes, and ships logs |
| Storage | Cloud-based storage | Self-hosted, scalable storage with Elasticsearch |
| Data parsing | Automatic parsing and categorization of log data | Custom parsing and filtering configurations with Logstash |
| Alerting | Custom alerting based on log events | Custom alerting and notification capabilities |
| Ease of use | User-friendly interface with guided setup | Steeper learning curve, especially for complex configurations |
| Scalability | Scales with New Relic's infrastructure | Scalable, suitable for large-scale log management |
| Cost | Subscription-based pricing model | Open-source, no licensing cost, but requires hardware and maintenance |
| Community support | Strong community support | Active community and extensive online resources |
| Use cases | Well-suited for businesses preferring a managed solution with easy setup | Ideal for businesses with in-house expertise and need for customization |
| Security | Offers security features such as encryption at rest and in transit | Requires careful configuration for securing data and access control |
| Compliance | Complies with industry standards and regulations | Compliance is achievable but requires configuration and monitoring |
| Updates and support | Regular updates and support from New Relic | Updates depend on the user, with support from the community and forums |
다음 단계
- Watch a video where Mikio discusses the three heresies about observability.
- Learn how to shift to effective logging for full-stack observability with Log Management Best Practices.
- Read more about how to get started with log management.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.
