What is AppDynamics and what are its top alternatives?
AppDynamics is a performance monitoring and management tool that provides real-time insights into application performance and user experience. Its key features include application performance monitoring, code-level visibility, end-user monitoring, business transaction monitoring, and analytics. However, some limitations of AppDynamics include the complexity of setting up and configuring the tool, high pricing for small businesses, and potential performance overhead.
- Dynatrace: Dynatrace is a full-stack monitoring tool that offers AI-powered observability, automatic discovery of services, and root cause analysis. Pros include automatic topology discovery and dependency mapping, while cons include high pricing for small businesses.
- New Relic: New Relic is a cloud-based observability platform that provides full-stack monitoring, synthetic monitoring, and real user monitoring. Pros include ease of use and a wide range of integrations, while cons include complex pricing structure.
- Datadog: Datadog is a monitoring and analytics platform that offers infrastructure monitoring, application performance monitoring, and log management. Pros include customizable dashboards and powerful analytics, while cons include limited support for on-premises environments.
- SolarWinds AppOptics: SolarWinds AppOptics is a SaaS-based application performance monitoring tool that provides detailed insights into application performance and infrastructure monitoring. Pros include unified infrastructure and application monitoring, while cons include potential learning curve for beginners.
- Splunk: Splunk is a data analytics tool that offers log monitoring, infrastructure monitoring, and application performance monitoring capabilities. Pros include powerful search and analysis capabilities, while cons include high pricing and complexity.
- Riverbed SteelCentral: Riverbed SteelCentral is a network performance monitoring and diagnostics solution that provides end-to-end visibility into network and application performance. Pros include deep packet inspection capabilities, while cons include limited support for cloud environments.
- Instana: Instana is an AI-powered application performance monitoring tool that provides automatic monitoring and analysis of microservices and containerized applications. Pros include automatic distributed tracing and continuous monitoring, while cons include limited support for legacy systems.
- Stackify Retrace: Stackify Retrace is an APM tool that offers code-level performance insights, error tracking, and log management. Pros include easy setup and integration, while cons include limited support for complex enterprise environments.
- Raygun: Raygun is an error and crash reporting tool that provides real-time insights into application errors and performance bottlenecks. Pros include easy integration and detailed error diagnostics, while cons include limited monitoring capabilities compared to full-stack APM tools.
- Opsview: Opsview is an IT infrastructure monitoring tool that offers network monitoring, server monitoring, and cloud monitoring capabilities. Pros include comprehensive monitoring and alerting features, while cons include complexity in configuring advanced monitoring settings.
Top Alternatives to AppDynamics
- Datadog
Datadog is the leading service for cloud-scale monitoring. It is used by IT, operations, and development teams who build and operate applications that run on dynamic or hybrid cloud infrastructure. Start monitoring in minutes with Datadog! ...
- New Relic
The world’s best software and DevOps teams rely on New Relic to move faster, make better decisions and create best-in-class digital experiences. If you run software, you need to run New Relic. More than 50% of the Fortune 100 do too. ...
- Nagios
Nagios is a host/service/network monitoring program written in C and released under the GNU General Public License. ...
- Splunk
It provides the leading platform for Operational Intelligence. Customers use it to search, monitor, analyze and visualize machine data. ...
- ELK
It is the acronym for three open source projects: Elasticsearch, Logstash, and Kibana. Elasticsearch is a search and analytics engine. Logstash is a server‑side data processing pipeline that ingests data from multiple sources simultaneously, transforms it, and then sends it to a "stash" like Elasticsearch. Kibana lets users visualize data with charts and graphs in Elasticsearch. ...
- Grafana
Grafana is a general purpose dashboard and graph composer. It's focused on providing rich ways to visualize time series metrics, mainly though graphs but supports other ways to visualize data through a pluggable panel architecture. It currently has rich support for for Graphite, InfluxDB and OpenTSDB. But supports other data sources via plugins. ...
- Azure Application Insights
It is an extensible Application Performance Management service for developers and DevOps professionals. Use it to monitor your live applications. It will automatically detect performance anomalies, and includes powerful analytics tools. ...
- Jaeger
Jaeger, a Distributed Tracing System
AppDynamics alternatives & related posts
Datadog
- Monitoring for many apps (databases, web servers, etc)139
- Easy setup107
- Powerful ui87
- Powerful integrations84
- Great value70
- Great visualization54
- Events + metrics = clarity46
- Notifications41
- Custom metrics41
- Flexibility39
- Free & paid plans19
- Great customer support16
- Makes my life easier15
- Adapts automatically as i scale up10
- Easy setup and plugins9
- Super easy and powerful8
- In-context collaboration7
- AWS support7
- Rich in features6
- Docker support5
- Cute logo4
- Source control and bug tracking4
- Monitor almost everything4
- Cost4
- Full visibility of applications4
- Simple, powerful, great for infra4
- Easy to Analyze4
- Best than others4
- Automation tools4
- Best in the field3
- Free setup3
- Good for Startups3
- Expensive3
- APM2
- Expensive19
- No errors exception tracking4
- External Network Goes Down You Wont Be Logging2
- Complicated1
related Datadog posts
We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. Behind the scenes the Config API is built with Go , GRPC and Envoy.
At Segment, we build new services in Go by default. The language is simple so new team members quickly ramp up on a codebase. The tool chain is fast so developers get immediate feedback when they break code, tests or integrations with other systems. The runtime is fast so it performs great at scale.
For the newest round of APIs we adopted the GRPC service #framework.
The Protocol Buffer service definition language makes it easy to design type-safe and consistent APIs, thanks to ecosystem tools like the Google API Design Guide for API standards, uber/prototool
for formatting and linting .protos and lyft/protoc-gen-validate
for defining field validations, and grpc-gateway
for defining REST mapping.
With a well designed .proto, its easy to generate a Go server interface and a TypeScript client, providing type-safe RPC between languages.
For the API gateway and RPC we adopted the Envoy service proxy.
The internet-facing segmentapis.com
endpoint is an Envoy front proxy that rate-limits and authenticates every request. It then transcodes a #REST / #JSON request to an upstream GRPC request. The upstream GRPC servers are running an Envoy sidecar configured for Datadog stats.
The result is API #security , #reliability and consistent #observability through Envoy configuration, not code.
We experimented with Swagger service definitions, but the spec is sprawling and the generated clients and server stubs leave a lot to be desired. GRPC and .proto and the Go implementation feels better designed and implemented. Thanks to the GRPC tooling and ecosystem you can generate Swagger from .protos, but it’s effectively impossible to go the other way.
Our primary source of monitoring and alerting is Datadog. We’ve got prebuilt dashboards for every scenario and integration with PagerDuty to manage routing any alerts. We’ve definitely scaled past the point where managing dashboards is easy, but we haven’t had time to invest in using features like Anomaly Detection. We’ve started using Honeycomb for some targeted debugging of complex production issues and we are liking what we’ve seen. We capture any unhandled exceptions with Rollbar and, if we realize one will keep happening, we quickly convert the metrics to point back to Datadog, to keep Rollbar as clean as possible.
We use Segment to consolidate all of our trackers, the most important of which goes to Amplitude to analyze user patterns. However, if we need a more consolidated view, we push all of our data to our own data warehouse running PostgreSQL; this is available for analytics and dashboard creation through Looker.
New Relic
- Easy setup415
- Really powerful344
- Awesome visualization244
- Ease of use194
- Great ui151
- Free tier107
- Great tool for insights80
- Heroku Integration66
- Market leader55
- Peace of mind49
- Push notifications21
- Email notifications20
- Heroku Add-on17
- Error Detection and Alerting16
- Multiple language support13
- Server Resources Monitoring11
- SQL Analysis11
- Transaction Tracing9
- Azure Add-on8
- Apdex Scores8
- Detailed reports7
- Analysis of CPU, Disk, Memory, and Network7
- Application Response Times6
- Performance of External Services6
- Application Availability Monitoring and Alerting6
- Error Analysis6
- JVM Performance Analyzer (Java)5
- Most Time Consuming Transactions5
- Top Database Operations4
- Easy to use4
- Browser Transaction Tracing4
- Application Map3
- Weekly Performance Email3
- Custom Dashboards3
- Pagoda Box integration3
- App Speed Index2
- Easy to setup2
- Background Jobs Transaction Analysis2
- Time Comparisons1
- Access to Performance Data API1
- Super Expensive1
- Team Collaboration Tools1
- Metric Data Retention1
- Metric Data Resolution1
- Worst Transactions by User Dissatisfaction1
- Real User Monitoring Overview1
- Real User Monitoring Analysis and Breakdown1
- Free1
- Best of the best, what more can you ask for1
- Best monitoring on the market1
- Rails integration1
- Incident Detection and Alerting1
- Cost0
- Exceptions0
- Price0
- Proce0
- Pricing model doesn't suit microservices20
- UI isn't great10
- Expensive7
- Visualizations aren't very helpful7
- Hard to understand why things in your app are breaking5
related New Relic posts
I've used more and more of New Relic Insights here in my work at Kong. New Relic Insights is a "time series event database as a service" with a super-easy API for inserting custom events, and a flexible query language for building visualization widgets and dashboards.
I'm a big fan of New Relic Insights when I have data I know I need to analyze, but perhaps I'm not exactly sure how I want to analyze it in the future. For example, at Kong we recently wanted to get some understanding of our open source community's activity on our GitHub repos. I was able to quickly configure GitHub to send webhooks to Zapier , which in turn posted the JSON to New Relic Insights.
Insights is schema-less and configuration-less - just start posting JSON key value pairs, then start querying your data.
Within minutes, data was flowing from GitHub to Insights, and I was building widgets on my Insights dashboard to help my colleagues visualize the activity of our open source community.
#GitHubAnalytics #OpenSourceCommunityAnalytics #CommunityAnalytics #RepoAnalytics
Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.
I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.
For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.
Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.
Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.
Future improvements / technology decisions included:
Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic
As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.
One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.
Nagios
- It just works53
- The standard28
- Customizable12
- The Most flexible monitoring system8
- Huge stack of free checks/plugins to choose from1
related Nagios posts
Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:
By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.
To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...
(GitHub : https://github.com/m3db/m3)
I am new to DevOps and looking for training in DevOps. Some institutes are offering Nagios while some Prometheus in their syllabus. Please suggest which one is being used in the industry and which one should I learn.
- API for searching logs, running reports3
- Alert system based on custom query results3
- Dashboarding on any log contents2
- Custom log parsing as well as automatic parsing2
- Ability to style search results into reports2
- Query engine supports joining, aggregation, stats, etc2
- Splunk language supports string, date manip, math, etc2
- Rich GUI for searching live logs2
- Query any log as key-value pairs1
- Granular scheduling and time window support1
- Splunk query language rich so lots to learn1
related Splunk posts
I am designing a Django application for my organization which will be used as an internal tool. The infra team said that I will not be having SSH access to the production server and I will have to log all my backend application messages to Splunk. I have no knowledge of Splunk so the following are the approaches I am considering: Approach 1: Create an hourly cron job that uploads the server log file to some Splunk storage for later analysis. - Is this possible? Approach 2: Is it possible just to stream the logs to some splunk endpoint? (If yes, I feel network usage and communication overhead will be a pain-point for my application)
Is there any better or standard approach? Thanks in advance.
I use Kibana because it ships with the ELK stack. I don't find it as powerful as Splunk however it is light years above grepping through log files. We previously used Grafana but found it to be annoying to maintain a separate tool outside of the ELK stack. We were able to get everything we needed from Kibana.
ELK
- Open source13
- Can run locally3
- Good for startups with monetary limitations3
- External Network Goes Down You Aren't Without Logging1
- Easy to setup1
- Json log supprt0
- Live logging0
- Elastic Search is a resource hog5
- Logstash configuration is a pain3
- Bad for startups with personal limitations1
related ELK posts
Docker Docker Compose Portainer ELK Elasticsearch Kibana Logstash nginx
- Beautiful89
- Graphs are interactive68
- Free57
- Easy56
- Nicer than the Graphite web interface34
- Many integrations26
- Can build dashboards18
- Easy to specify time window10
- Can collaborate on dashboards10
- Dashboards contain number tiles9
- Open Source5
- Integration with InfluxDB5
- Click and drag to zoom in5
- Authentification and users management4
- Threshold limits in graphs4
- Alerts3
- It is open to cloud watch and many database3
- Simple and native support to Prometheus3
- Great community support2
- You can use this for development to check memcache2
- You can visualize real time data to put alerts2
- Grapsh as code0
- Plugin visualizationa0
- No interactive query builder1
related Grafana posts
Grafana and Prometheus together, running on Kubernetes , is a powerful combination. These tools are cloud-native and offer a large community and easy integrations. At PayIt we're using exporting Java application metrics using a Dropwizard metrics exporter, and our Node.js services now use the prom-client npm library to serve metrics.
Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:
By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.
To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...
(GitHub : https://github.com/m3db/m3)
Azure Application Insights
- Focus in detect performance anomalies and issues5
- Integrated with Azure3
- Live Metrics1
- User flow1
- Availability tests (Heart Beat check)1
- Difficult to surface information2
- Custom instrumentation via code only1
- UI is clunky and gets in the way1
related Azure Application Insights posts
- Easy to install6
- Open Source6
- Feature Rich UI5
- CNCF Project4
related Jaeger posts
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark