New Relic News

• 

  Monitor Downtime: New Scheduling and Control Capabilities for New Relic Synthetics
  new relic news and produc new relic synthetics • • sorangutan  

  1
  1
  Posts
  85
  Views

  

  Controlling when your synthetic monitors run is essential to managing your team’s service level agreements (SLAs) and, more broadly, to applying consistent and reliable proactive monitoring. During maintenance and scheduled site downtime windows, for example, you don’t want your synthetic monitors to fail and subsequently skew your uptime results. You need precise control over your synthetic monitors to dictate when you’d like them to run.

  Maintenance windows in New Relic Synthetics, which until recently was in beta testing, were designed to give our customers these very important capabilities. With maintenance windows, users define periods when they can either stop monitors from running at all (e.g. turn off the monitor during scheduled downtime); or continue to run monitors but “mute” the data by excluding it from their results.

  New Relic Synthetics is pleased to announce the general availability of monitor downtime—which integrates these key capabilities for managing and controlling your synthetic monitors directly into the Synthetics UI. Monitor downtime gives you an easier and more intuitive way to pause monitoring and alerting across all of your synthetic monitors, helping you maintain the integrity and accuracy of your monitoring and alerting data, and even of your SLAs.

  New capabilities for New Relic Synthetics

  Why did we change the name from maintenance windows to monitor downtime? Mostly, it’s a matter of being completely clear and transparent about the nature and extent of the new capabilities.

  Within New Relic Synthetics, the periods that we referred to as “maintenance windows” specifically impact Synthetics monitors running during the allocated time windows. The reference to “maintenance windows,” however, implies that it extends across every New Relic product (including New Relic Alerts, New Relic APM, New Relic Browser, New Relic Mobile and New Relic Infrastructure). We updated the name to “monitor downtime” to put the emphasis where it belongs—specifically, on improvements within New Relic Synthetics that make it easier to pause or mute your monitors, and thus protect the accuracy and relevance of your monitoring data.

  A better way to manage your monitors

  You can use monitor downtime to pause synthetic checks. You can view this in relation to your SLAs, or simply control when you want monitors to run actively or to pause. Ultimately, as the user, you get full control over when your monitors run and when monitor data flows into your reporting.

  

  Monitor downtimes give you the ability to dictate pauses in your New Relic Synthetics monitoring data.

  Because monitor downtime is built into the Synthetics UI, using it is much easier than controlling monitors programmatically or manually through the API. You won’t have to pause monitors one by one, for example, but instead can control all four Synthetics monitor types in a simplified format within the UI.

  In addition, the monitor downtime scheduler is based on Apple’s iCal recurring rules, so using it looks and feels a lot like scheduling meetings on a Mac desktop—a familiar and intuitive process for many users.

  This release also includes a more intuitive approach to using timezone selectors. For cases where teams create monitors for locations in other parts of the nation or world, they can easily select the correct timezone for the monitor. If your team is based in Chicago, for example, but you create synthetic monitors for London, Singapore, or Seattle, you can simply select the correct timezone for that region and save the monitor.

  Getting started with monitor downtime

  You will find the Monitor downtime tab under the navigation bar in the Synthetics UI. Once inside the tab, you can specify the name of the monitor and select a frequency (once, daily, weekly, or monthly); select the correct timezone, and specify the exact times and days of the week when the monitor should pause. You can then apply these selections to specific, pre-built synthetic monitors.

  

  Using the monitor downtime tab in the New Relic Synthetics UI is a simple and intuitive process.

  Simple and seamless control

  With monitor downtime, you can now seamlessly coordinate and control when to pause your synthetic monitors, and easily account for  time zone differences when monitoring from several different geographic points of presence. For periods of scheduled maintenance, or when you simply don’t want to be alerted, you can now quickly schedule a time-out within the Synthetics UI. It all adds up to a more efficient and intuitive experience for teams who want more control over their synthetic monitors and alerts.

  
  
  
• 

  App Monitoring in the AWS Cloud: 3 Best Practices for Success with New Relic
  aws events new relic news and produc new relic apm aws reinvent lightning ta • • sorangutan  

  1
  1
  Posts
  62
  Views

  

  The New Relic lightning talks at AWS re:Invent 2018 gave attendees a bevy of best practices for making monitoring a critical part of their AWS cloud journeys. But a truly dialed-in and impactful monitoring strategy can be a tricky task to perfect—especially when you’re dealing with performance issues at crunch time.

  Expert advice on success with New Relic in the AWS cloud

  To help smooth the path, Matt van Zanten—a DevOps engineer at AWS consulting partner and systems integrator Onica, was on hand at one of New Relic’s two re:Invent 2018 booths to deliver a lightning talk: “AWS Best Practices From the Largest Pure AWS SI in North America.” Matt, a veteran consultant who works with e-commerce companies to support their cloud-native applications, told attendees that he and his team use out-of-the box metrics gathered by Amazon CloudWatch to monitor system performance from an outside-in view, alerting on key metrics like CPU, latency, and HTTP 5xx errors. These metrics, Matt said, helped his team track system health and react accordingly.

  But alerts alone, Matt added, don’t tell you why an application is suddenly performing poorly. This is where New Relic truly shines—and Matt delved into three critical best practices for operating natively in the AWS cloud with New Relic at your side:

  1. Detect and solve anomalies with real-time application data.
  2. Uncover transactions and queries that require tuning.
  3. Improve monitoring and alerting from within your applications.

  Detecting and resolving anomalies with real-time application data

  Matt opened his discussion with an anecdote: While working on a consulting project he discovered that his client’s Java application couldn’t handle more than 2,000 user requests at a time. Faced with more than 2,000 concurrent user requests, the app’s database tables deadlocked and the app crashed.

  Matt used New Relic APM to instrument and monitor the troublesome Java app in real time, and found a more nuanced issue: evidence of increased database transaction latency on top of the application’s (expected) latency.

  Once he saw the database transaction latency, Matt attacked the problem by asking two key questions: First, which queries were requested most frequently? Second, which were the slowest to complete? The answers to these questions, Matt said, helped him determine which queries—and which portions of the app’s underlying code—would need to be optimized to fully resolve the latency issues.

  Uncovering transactions and queries that require tuning

  Matt used another story involving a client to illustrate the second of his AWS monitoring best practices. In this case, Matt and his team were finishing testing and maintenance work to prepare a client for a big Black Friday and Cyber Monday push. Just as the team was wrapping up its work, however, the system threw them a curveball: previously stable CPU metrics suddenly began jumping around and increasing. This was a big problem, since backend API CPU usage directly correlated to the app’s overall latency—and app latency, of course, can have huge revenue-killing potential during the busy holiday shopping season.

  

  

  Increasing latency associated with increased backend CPU activity (top image) combined with ordinary site-traffic patterns (bottom image): a major concern for a retailer heading into holiday shopping crunch time.

  After analyzing the relevant CPU and latency metrics, Matt said, the team also looked at request counts to see if increased traffic was causing the problem. CloudWatch’s RequestCount metric typically goes up during the day and down overnight, Matt said, but since that metric showed no changes, he quickly eliminated increased traffic as a reason for the change in CPU utilization.

  After a quick examination of the New Relic metrics, however, Matt’s team found their CPU utilization culprit: Java garbage-collection processes running rampant on the API cluster.

  

  New Relic uncovers the culprit behind the app latency issue—Java garbage-collection processes running amok due to data-caching issues—and points the way to a permanent solution.

  Since the client’s product dataset had grown dramatically during the previous few weeks, Matt surmised that the API servers weren’t able to cache the entire data set in-memory. This change, in turn, caused the Java app to run its garbage collection processes continuously to free up memory and to make room for other data.

  With Black Friday and Cyber Monday fast approaching, Matt said, the team moved quickly to provision a larger Amazon EC2 instance class—giving the containers enough memory to cache the application’s entire product-data set. The team updated its AWS CloudFormation template, tested it, and rolled the changes out to production.

  After the production rollout, the team went back into New Relic to check on the app’s garbage collection performance. The results, Matt said, proved that the team had solved the problem: The application was once again caching its full product-data set, its garbage-collection processes were no longer running rampant, and CPU utilization was back to normal.

  Improving monitoring and alerting from within an application

  Finally, Matt noted, once a team uses New Relic monitoring data to solve a problem, it’s important to continue monitoring the relevant metrics—and to alert the team if the pattern resurfaces.

  Matt cited an example involving irregular latency issues with some transactions on a client’s server. His team used New Relic APM to monitor and analyze the transaction data, and identified a third-party API as the source of the latency issues. The team, Matt said, could then implement code changes to fix the problem. Just as important, the team now knew that it would have to be more vigilant about similar issues in the future. The team addressed the issue by setting an alert that triggers whenever the system shows a consistent and significant change in service latency—combining proactive protection with efficient use of the team’s resources.

  New Relic monitoring—a faster path to success with AWS

  These stories illustrate how critical it can be to protect an AWS cloud investment with monitoring tools that can quickly get your team to the root cause of a performance issue and suggest a practical solution. This is why so many teams turn to New Relic to instrument and monitor their AWS cloud-native apps. The results, in terms of customer experience and revenue impact, speak for themselves.

  
  
  
• 

  The 15 Most Interesting Things Werner Vogels (and Friends) Said at AWS re:Invent 2018
  aws aws reinvent serverless technology industry • • sorangutan  

  1
  1
  Posts
  103
  Views

  

  AWS re:Invent 2014 was one of the high points of Werner Vogels’ life. At the end of the AWS CTO’s keynote at AWS re:Invent 2018, he noted that 2014 was the year that AWS launched AWS Lambda—as well as when world-famous DJ Skrillex headlined the AWS re:Play party. He didn’t say whether or not 2018 would linger in his memory the same way, but he did announce that Skrillex would be returning to rock the house again.

  Leading up to that revelation, Werner spent almost two hours taking care of business: sharing a deep look at how AWS has built reliable, scaleable, and secure cloud systems, and dropping some pretty interesting feature and product announcements along the way. Here are 15 of the most resonant highlights from Werner’s keynote, touching on a range of topics that included databases, Lambda and serverless, development and architecture tools, and more.

  (For a full list of all the product announcements made during Werner’s keynote—which you can watch below—and during the rest of re:Invent check out this official AWS roundup.)

  Considering the database

  1. To open his talk this year, Werner asked Amazon Alexa where she thought he should start. “Why don’t you tell us about your worst day at Amazon?” she suggested. December 12, 2004, Werner replied, was his worst day ever at Amazon. It was the last day of that year for Amazon customers to qualify for Super Saving Shipping and have their packages arrive before Christmas. However, a bug in the logging code took down Amazon’s customer database, and the company was “dead in the water”—for 12 hours! “This failure drives a lot of the development you see today from AWS,” Werner said.

  2. “Things fail. Databases fail,” Werner told the audience. Their,  goal, he said, is to use reliability, scalability, and performance to minimize the impact and reduce the blast radius of those inevitable failures.

  3. Cloud-native databases, Werner stated, are the foundation of innovation. The commercial enterprise databases most widely used until now, he said, were built for the ‘90s—not for how modern systems now operate.

  4. Amazon’s Items and Offers service—which supplies details like color and size about items on shopping pages—manages 100 billion records, with upwards of 5 billion updates per day. Using AWS Databases Migration Service, Amazon moved this data from 24 Oracle databases to Amazon DynamoDB, and the company continues to scale the service at least 30% – 40% per year.

  5. Mai-Lan Tomsen Bukovec, Vice President of Amazon S3 and Amazon S3 Glacier, joined Werner on stage to discuss the architecture of S3, which Werner called “one of the digital wonders of the world.” S3 and Glacier, Mai-Lan said, manage exabytes of storage that hold tens of trillions of objects over millions of drives—supporting everything from data lakes to driverless cars. “In a single region,” Mai-Lan said, “S3 will manage peaks of 60 terabytes per second in a single day.” That’s why every feature or change gets a durability review, she said.

  

  While the S3 team works hard to prevent the loss of a data center or “the long-term impairment of an availability zone,” AWS has never lost a data center. Nevertheless, AWS’ storage class “replicates storage across three availability zones,” Mai-Lan said. And the database for an availability zone (AZ) is not just in another room or on another floor of a data center—it’s located, at the very least, in a separate building and often at a completely different location. That, she said, is true redundancy.

  6. Alexa also asked Werner about his best day of the year. He replied that it was November 1st, which was the day Amazon shut down one of the world’s largest data warehouses running on Oracle and moved it to over to Amazon Redshift (a reply that also teased the release of Amazon Redshift concurrency scaling).

  Teaching guitar to the next Jimi Hendrix—one Lambda function at a time

  7. Ethan Kaplan, chief product officer of Fender Digital, joined Werner to discuss how Fender uses dozens of AWS services to build applications and video tutorials that teach people how to play guitar. Since July, the software division of the iconic guitar maker has used 352 million AWS Lambda requests and is using AWS to store 747 TB of transcoded video. Fender is also using the Amazon SageMaker machine learning service to improve its factory guitar-building processes.

  

  To celebrate, Ethan handed Werner—famously fond of EDM—a brand new, AWS-branded Fender Telecaster. “You give a guitar to a bass player,” Werner said, “and they suddenly start wondering: six strings?”

  Key thoughts on serverless

  8. Why, Werner asked, are so many customers flocking to serverless? He answered this question with four key reasons:

  • There’s no infrastructure to provision.
  • You pay for what you use, and you pay for direct value.
  • It’s very secure and highly available across multiple AZs.
  • It scales automatically.

  9. Enterprises, Werner stated, are driving the adoption of serverless. “Normally, we’d expect that the younger, tech-oriented businesses would be the first ones to try this out,” he said. “But what we’re seeing is that large enterprises are really the ones embracing serverless technologies. With serverless technologies, customers can build their business logic into their applications and not have to worry about maintaining anything else … This truly drives the evolution of serverless.”

  10. It all started, Werner said, with AWS Lambda: “Four years ago,” he explained, “we pioneered the whole serverless movement by providing compute as a serverless environment as well, and we’ve seen enormous investment … and innovation over time.”

  11. Werner described Amazon’s new Firecracker—which offers lightweight virtualization for serverless computing—as innovation at the micro-machine level to bring customers better isolation and efficiency in their serverless environments.

  The right tools for the job you want to do

  12. “You’re very vocal about how you want to see the next generation of development happening,” Werner told the crowd of cloud enthusiasts. “It’s really great to work together with you to really think of what modern development should look like.”

  13. 95% of AWS services and features, Werner said, are based directly on customer feedback. Developers building in AWS, he added, have emphasized the importance of supporting their favorite integrated development environments (IDEs), languages, programming models, and workflows. To that end, Werner make a series of announcements:

  • AWS tool kits for IDEs that focus on serverless development
  • Ruby support for AWS Lambda
  • Custom runtimes (via the new Lambda runtime API) for C++ and Rust, and for partner-supported languages including Cobalt, PHP, Erlang, and Elixir.
  • Lambda Layers for centrally managing code shared across functions.

  Making it easier to be well architected

  

  14. “Are you well architected?” is a key question for the Werner Vogels experience. Unfortunately, the AWS Well-Architected Framework—a set of principles designed for companies to use before building their first cloud-based app—has not scaled the way Werner would have liked it to scale. To give it a boost, he unveiled the AWS Well-Architected Tool, which he hopes companies will use to review their workloads and architectures, and to compare them to the latest AWS best practices.

  Werner Vogels—the Rick Steves of the cloud

  15. Before leaving the stage, Werner unveiled Now Go Build, a long-form video series in which he travels the world visiting startups that do cutting-edge work using some the most interesting software powered by AWS. Episode 1—Jakarta is available now on YouTube.

  
  
  
• 

  AWS re:Invent 2018: Cloud Migration Lightning Talks From New Relic Experts And Partners
  aws aws reinvent events new relic news and produc cloud migration cloud adoption • • sorangutan  

  1
  1
  Posts
  91
  Views

  

  This year at AWS re:Invent, New Relic set out to help forward-thinking software teams that want to leverage Amazon Web Services (AWS) cloud to move fast and innovate more confidently—and become more competitive. The New Relic platform plays a critical role in many of these cloud migration journeys: It helps organizations adopt AWS faster, evolve their software for greater performance by gaining visibility into complex systems, and measure cloud infrastructure and application performance with consistency and precision. All so teams can deliver the amazing digital customer experiences that increasingly determine business success.

  This goal was a common thread connecting many of the lightning talks presented this week at New Relic’s two (yes, two!) packed re:Invent booths. These lighting talks drew big crowds by featuring New Relic product experts, as well as representatives from many of our key customers and partners, sharing best practices and requirements for successful cloud migrations. With a special emphasis, of course, on the central role New Relic plays in every phase of a successful cloud migration journey, from initial planning to post-migration. 

  Instrument your cloud migration in the right place at the right time

  Earlier this year, New Relic introduced the Guide to Planning Your Cloud Adoption, a three-phase (Plan, Migrate, and Run) cloud migration framework. Each phase covers a set of steps, key performance indicators (KPIs), and measurement strategies designed to help firms advance through a cloud migration journey. A lightning talk from New Relic Senior Solutions Consultant Boris Gouchev, entitled “Cloud Adoption Best Practices,” highlighted an issue firms often face as they work through this type of framework: failing to instrument in the right place at the right time.

  All too often, Boris explained, teams ignore monitoring during the Plan phase and downplay it during the Migrate phase. But teams that apply instrumentation only during the Run phase may be making a serious mistake.

  

  Instrumentation should begin as early as possible in your cloud migration journey.

  To illustrate his point, Boris recalled one customer that recently migrated to AWS—and learned a hard lesson about the dangers of not monitoring early enough in the process. As the customer’s team prepared its migration effort, Boris said, it discarded its homegrown, legacy monitoring tool; integrated New Relic and AWS; and began moving its workloads to AWS. The team intended to add monitoring only after completing the migration process.

  Unfortunately, once the team moved its workloads to AWS, they felt they were getting poor performance from the new cloud services they were using. It wasn’t just disappointing—it was terrible.

  Spooked, the team called in an AWS Professional Services architect, who advised them to deploy New Relic immediately on the migrated apps. Ironically, the customer had already purchased New Relic, the team just hadn’t deployed it yet! After deploying New Relic, it quickly became clear that the performance issues involved the customer’s own code and configurations in their apps—and not the AWS services.

  Boris’ story Boris has a happy ending: The team fixed its performance problems and quickly became a happy AWS customer.

  The story prompted Boris and his teammates to look into this problem across the entire New Relic customer base. Given the size of a typical AWS deployment (approximately 750 virtual machines), the group concluded that failing to instrument early enough in a migration could add $5 million or more to a typical $31 million enterprise migration project. As little as 48 hours of instrumentation work earlier in the migration process could have spared the customer three months of avoidable, and expensive, rework.

  Boris and his team estimated that instrumenting at the right time—during the Planning phase—would:

  • Allow firms to decommission data centers up to 25% faster
  • Reduce an organization’s average AWS spend by 8% by getting to the Run phase faster
  • Reduce by 21% the full-time engineering resources dedicated to a typical migration

  Interested in how New Relic and partners can help? Don’t miss the New Relic Cloud Adoption Solution for AWS!

  Focus on critical optimizations

  The cloud offers great benefits in scalability, availability, and cost savings, said New Relic Strategy Consultant Bharath Raj, in his lightning talk “Host for the Most.” Maximizing those benefits, however, typically requires post-migration optimizations of both spend and performance.

  Once an organization begins its cloud migration, Bharath explained, it’s time to refine KPIs to define usage, user experience, scaling, and application optimizations. Once the cloud migration is complete, it’s time to focus on KPIs related to cloud spend and business agility.

  Dashboards built in New Relic Insights can help teams visualize these metrics in highly intuitive ways. For example, Bharath explained, to understand the your infrastructure’s workload, it’s useful to identify trends by monitoring the average CPU usage per IP address, by correlating average utilization rate by instance type, or by tracking CPU usage by container as you scale instances.

  

  New Relic Insights dashboards can help you gain context into the workload of your cloud-based infrastructure.

  To track the agility of your business in the cloud, Bharath suggested that teams monitor the highest memory usage of their instances to see where they may need to re-optimize an instance to account for changes in how it’s used. Similarly, it can be useful to track CPU load by instance type or memory usage over time, using these trends to spot anomalies in your cloud infrastructure.

  

  Use New Relic Insights dashboards to track how agile your business is in the cloud.

  Finally, Bharath said, a good cloud spend and user experience dashboard can capture metrics about your monthly spend, your overall CPU usage over time or by instance type, and your potential for misallocating money on cloud resources.

  

  A cloud spend and user experience dashboard in New Relic Insights can gather critical metrics for post-migration optimizations.

  Supporting a cloud-native evolution

  The post-migration, or Run, phase of a cloud initiative is the point where many organizations think they’ve completed a migration journey—but they may still have a long way to travel.

  During his lightning talk called “Foundational Elements Supporting Cloud Native Evolution,” Lars Cromley, Director of Cloud Advocacy at 2nd Watch, a New Relic partner and AWS Premier Consulting partner, reminded an overflow crowd that being in the cloud is not a strategic advantage in itself. The value of a cloud strategy, Lars said, depends on what an organization does once it’s in the cloud.

  That’s where an organization’s tools, practices, and engineering culture play a critical role in the success of an AWS migration journey. Teams, for example, must learn to work with immutable infrastructure. They must be able, Lars said, to manage applications, services, and software deployments that involve replacing components rather than changing them (a fundamental principle of container-based workflows).

  Lars noted that learning how to replace components rather than fixing them, in turn, has an immediate and positive impact on an organization’s mean time to recovery (MTTR). Being “in the cloud” doesn’t create this source of value; it simply sets the stage for a team with the knowledge and tools to take advantage of it.

  Second, you can’t overlook what will be a greater reliance on tooling, Lars said, particularly for monitoring your infrastructure. “Visualizing the system and keeping a picture of everything in your head becomes harder,” he added. “The tools that support our applications must have greater capabilities—and those systems, too, must evolve.”

  From migration to cloud-native alerting—New Relic gets you there

  Regardless of where you are in your AWS cloud migration—starting from the planning phase, looking for post-migration optimizations, or considering the next phase of your cloud-native evolution—these stories are useful reminders that today’s software teams are increasingly reliant on proven best practices. New Relic is an essential component of that process, delivering the observability and insights required to put these best practices to work and achieve measurable success.

  
  
  
• 

  Improve Your Synthetics Workflows with Containerized Private Minions
  docker containers new relic news and produc new relic synthetics • • sorangutan  

  1
  1
  Posts
  110
  Views

  

  A key benefit in New Relic Synthetics is the ability to test your applications globally from any location, including from behind your firewall, using private minions. Until now, our private minions—which receive and manage jobs from Synthetics for each test location you’ve established—have run on virtual machine appliances in VMware’s VSphere or Oracle’s VirtualBox, which limited user configurability, control, speed, and cloud readiness.

  Today, we’re pleased to announce containerized private minions (CPM), private minions that run in Docker containers. By taking advantage of the benefits of container software—and a few enhancements—you can configure, deploy, upgrade, and auto-remediate Synthetics minions with ease, including running CPMs as a non-root user. The Docker sandbox ensures complete isolation of CPMs, improving security, reliability, and repeatability. You also have the ability to containerize your Synthetics checks and run them from your private data center or even on a local machine (such as your laptop). Containerized private minions raise the bar on security, cloud readiness, ease of use, and flexibility.

  Our containerized private minions are now generally available for use.

  Getting started with containerized private minions

  You don’t have to immediately switch your workloads to CPM. If you’re interested in gradually converting from legacy VM-based private minions to CPM, you can run both concurrently. Start deploying CPMs, and run them alongside your legacy private minions, and then retire the older ones as you get more comfortable with the containerized versions.

  To run containerized private minions, you need a Synthetics Pro and a Private locations subscription. Before getting started, review the system requirements and Docker dependencies. You’ll also need a Private Location Key.

  To create a CPM:

  1. Go to synthetics.newrelic.com  > Private locations. Select the appropriate option:
     • To add a new private location, select Add new, and note the Private Location Key.
     • To add minions to an existing location, select the edit icon for that location, and note the Private Location Key.
  2. From the terminal of the Windows, Linux, or Mac OS machine hosting the container, run:docker pull quay.io/newrelic/synthetics-minion:latest 
  3. Start your CPM.On Linux and Mac OS, run:docker run \
--name [YOUR CONTAINER NAME] \
-e "MINION_PRIVATE_LOCATION_KEY=[YOUR PRIVATE LOCATION KEY]" \
-v /tmp:/tmp:rw \
-v /var/run/docker.sock:/var/run/docker.sock:rw \
-p 8080:8080 -p 8180:8180 \
quay.io/newrelic/synthetics-minion:latest
     On Windows, run:
docker run ^
--name [YOUR CONTAINER NAME] ^
-e "MINION_PRIVATE_LOCATION_KEY=[YOUR PRIVATE LOCATION KEY]" ^
-v /tmp:/tmp:rw ^
-v /var/run/docker.sock:/var/run/docker.sock:rw ^
-p 8080:8080 -p 8180:8180 ^
quay.io/newrelic/synthetics-minion:latest

  You should see a message that your CPM is up and ready to run monitors assigned to that location.

  Note: In these installation examples, we used common defaults for /tmp and /var/run/docker.sock: you should tailor these options to your system, and provide more environment variables to unlock the full potential of CPM.

  (For more about monitoring, securing, and maintaining CPMs, see our CPM documentation.)

  Once your CPMs are deployed and ready to work, it’s fairly easy to start generating useful insights—for example, the page load time comparisons shown below—and to dig deeper when the data indicates a possible issue.

  

  The benefits of running containerized private minions

  With containerized private minions, we’re bringing a much-needed update to how you manage your private Synthetics locations. More specifically:

  CPMs give you better ease of use, flexibility, and control. Setup, configuration, and upgrades of your CPMs are significantly easier than with legacy minions. As illustrated in the “Getting started with containerized private minions” section above, you can deploy CPMs with a few simple commands.

  With CPMs, you’re in control of the host’s settings and configuration. This means, for example, that you could install a container on a compliant server in your data center and be running CPM in minutes. When you’re ready to upgrade, simply log into the host machine and pull the latest image with dockerpull quay.io/newrelic/synthetics-minion:latest and restart the container.

  CPMs are cloud ready. To run legacy private minions in the cloud, you had to convert the virtual appliance into a format supported by your cloud provider. CPMs, on the other hand, can be deployed wherever you’re hosting containers in the cloud, without any additional configuration. This makes it easier to enable synthetic monitoring from any location your cloud provider supports.

  CPMs are orchestration ready. If you use a container orchestration tool, like Kubernetes, you can use it to manage the containers in which CPM runs. For example, in Kubernetes, describe the end state for your CPM containers (for example, you want two sets of CPM running in your North American East database and two sets running in the West database) and then allow Kubernetes to do the heavy lifting of deploying those containers.

  Containers mean increased security for your minions. Legacy private minions contained an entire operating system that had to be maintained and patched. CPMs expose a narrower attack surface. CPMs contain only a micro-image of our application, so you don’t need to worry about patching dependencies.

  CPMs can be run in multiple locations. You can deploy multiple CPMs on one physical host and have them point to different private locations. For example, you can deploy a container with minions for both staging and production environments, and service different geographic locations with those environments.

  CPMs give you customizable timeouts. With CPMs you can use custom timeouts to extend the lifetime of your scripts. You can now run your scripts for up to 15 minutes for more in-depth synthetic transactions. If you have pre-existing synthetic monitors that you run in UI tests, you can easily transfer those monitors to New Relic without constraint. Longer customizable timeouts let you test apps where users may sit idle on a page for longer than 3 minutes (for example, when watching a video), or test “wait, don’t go” messages your app that might show when idle users haven’t “checked out” their carts.

  Containerized private minions—designed with ease of use in mind

  Since you no longer need to run your minions in a VM—which another team may have to supply and provision for you—you’ll find that CPMs are significantly easier to deploy, run, and upgrade. Security is tighter, as containers require fewer dependencies than a VM, and you can configure and control CPMs directly from your laptop. Finally, CPMs are compatible with any cloud provider offering a Docker-based infrastructure, including Kubernetes orchestration. All of these improvements combine to make CPMs a capability that we’re sure many developers will find extremely useful.

  Go to synthetics.newrelic.com to get started now!

  
  
  
• 

  AWS re:Invent Keynote Focuses on AWS Outposts and Helping ‘Builders’
  aws aws reinvent events artificial intelligence blockchain new relic news and produc hybrid cloud machine learning agile • • sorangutan  

  1
  1
  Posts
  71
  Views

  

  Numbers—big numbers—were the order of the day as Amazon Web Services (AWS) CEO Andy Jassy took the stage for his 3-hour keynote address at the company’s signature AWS re:Invent cloud computing conference in Las Vegas yesterday. Even as AWS reported 46% year over year revenue growth, the number of conference attendees swelled to 53,000, reflecting the crucial role that AWS and its cloud offerings play in so many businesses today.

  But while Jassy laid out the standard litany of announcements of new AWS products, features, and capabilities, he placed particular emphasis on dedicating AWS to improving the working lives of “builders”—the engineers, developers, operations specialists, IT managers, and CIOs who increasingly rely on the cloud.

  The needs of the builder, Jassy said, are what drive AWS’ development efforts. In some cases, that means expanding upon what the company already does well (for example, Amazon DynamoDB On-Demand–No Capacity Planning and Pay-Per-Request Pricing), but Jassy also cited devoting more resources to technologies like machine learning (ready for the autonomous Amazon race car? See below!) and (contrary to Jassy’s previous position on the subject), blockchain management.

  As usual, AWS made far too many announcements for us to cover here—you can watch the full keynote presentation below, and a full list of new products and features is available from AWS. But it’s instructive to highlight some of the ways AWS hopes to ease the toil and unleash the innovation potential of builders, especially via a new acknowledgement of the role of the hybrid cloud, better ways to work with multiple cloud services, and the increasing importance of machine learning, AI, and blockchain.

  The hybrid cloud is real

  Enterprises, Jassy said, know the benefits of cloud computing, but they also understand the amount of work required to migrate to the cloud. And the longer they wait, he said, “the deeper the ditch” they need to climb out of. Nevertheless, some enterprises still aren’t ready to shift 100% of their workloads to the cloud. Just as important, they want to use the same APIs, hardware, and tools to manage their cloud infrastructure as well as their on-premise data centers.

  To this end, supported on stage by VMware CEO Pat Gelsinger, Jassy unveiled AWS Outposts, demonstrating a clear understanding that the hybrid cloud (a combination of the public cloud and on-premise data centers) still plays an important role in the lives of many builders.

  With AWS Outposts, enterprises can use actual racks of AWS-designed infrastructure hardware to run services like Amazon EC2. Initially, enterprises will have two ways to use AWS Outposts:

  1. Building off the VMware Cloud for AWS model, AWS says the first variant allows “you to use the same VMware control plane and APIs you use to run your infrastructure.”
  2. The second variant is AWS-specific, allowing you to run on-premise native instances of the same APIs and control plane you use to run your infrastructure in the AWS cloud, but on-premise.

  Either way, Jassy said, AWS will deliver the racks straight to your data center and even install them for you!

  Describing AWS’ expanded relationship with VMware, Jassy said, “We continue to innovate together to let you run hybrid the way you want.”

  Separating the signal from the noise

  AWS re:Invent is all about showcasing how enterprises thrive in the cloud, and showing practitioners how to leverage services and infrastructure to move faster and deliver better experiences for their customers. But when they face 140 services spread across enterprise apps, migration services, security and control, infrastructure offerings, and analytics (just to name a few areas), some builders, Jassy said, don’t want to guess how to make it all work.

  Enterprises often have multiple teams running multiple services in multiple locations, Jassy said, and they may need guidance putting it all together. To satisfy that need for a larger perspective, Jassy announced AWS Control Tower and AWS Security Hub.

  Enterprises can use Control Tower to automate the setup of their multi-account AWS environments or Landing Zone service, and trust that it’s done in a secure and compliant way that follows AWS best practices. As enterprises create new teams and accounts, Control Tower makes it easier to make sure the additions follow the organization’s compliance policies. No more guesswork configuring multiple accounts, Jassy promised.

  With AWS Security Hub, teams get a single place to aggregate and organize all of the security information across their AWS accounts. Security Hub, Jassy said, will work with any AWS security service, as well as with some third-party offerings.

  The machines are learning—even the race cars

  More than 10,000 AWS customers use the platform for machine learning, Jassy said. And AWS has done plenty of work to support them, he added, including adding machine learning algorithms and models to the AWS Marketplace, expanding the scope and power of AWS SageMaker, and releasing Amazon Elastic Inference, which allows you to configure the the GPU power of EC2 and SageMaker instances to reduce by up to 75% the cost of running deep learning inference.

  But when it comes to reinforcement learning, a type of machine learning that relies on feedback from a machine’s trial-and-error interactions in an environment to accomplish a specific goal, Jassy delighted the crowd with the announcement of AWS DeepRacer, Amazon’s first autonomous race car (albeit it at 1/18th scale).

  

  According to Dr. Matthew Wood, General Manager of Deep Learning and AI at AWS, who joined Jassy on stage, AWS DeepRacer was designed to give developers hands-on experience with reinforcement learning. Developers can use virtual cars and tracks in a 3D cloud-based racing simulator to teach the car through trial and error, with feedback from a “reward function.” From there, they’ll be able to deploy the trained models onto the AWS DeepRacer, where they can race in the AWS Deep Racer league, the championships of which will be held at AWS re:Invent 2019, Jassy said.

  With AWS DeepRacer, AWS has abstracted away a significant amount of the complexity involved in such experiments, Wood said. He hopes this will lead to greater interest in reinforcement learning, allowing more organizations to train their software to react to changing environments, and in the process fostering faster and cheaper innovation.

  The car can be pre-ordered directly from Amazon for $249; eventually it will cost $399.

  AWS and blockchain? Don’t call it a bandwagon

  Blockchain is one of the hottest trends in technology, and many companies have created blockchain initiatives to look good to customers and investors. But that’s not why AWS got involved, Jassy said. AWS believes that blockchain technology is the right solution, Jassy said: “We don’t build things for optics.”

  AWS customers say they need, or at least are highly interested in, blockchain technologies to decentralize transaction processing, Jassy explained. Retail and supply-chain organizations, as wells as companies that heavily rely on trade and asset transfers, could use the new Amazon Managed Blockchain (built on Hyperledger Fabric and Ethereum protocols) to speed up sharing and validation transactions that could otherwise take several business days to complete. The new Amazon Quantum Ledger Database (QLDB), meanwhile, is a fast, scalable, fully managed ledger database tracking all changes in a transparent, immutable, and cryptographically verifiable with an immutable, cryptographically chained and verifiable transaction log ‎owned by a central trusted authority.

  Builders want to innovate—help them do it in the cloud

  “Over the last several decades, it’s been a little bit of dreary world for builders,” Jassy said. Builders don’t get jobs so they can do the same thing over and over again. That’s demoralizing, Jassy said. In fact, too many builders have been trained by their employers not to spend their time and energy trying to invent or innovate on the customer experience—because why bother?

  It doesn’t have to be that way, Jassy claimed. Enterprises and companies that have adopted AWS and the cloud have seen changes in how they innovate, he said. Access to huge numbers of powerful, pre-built services and the ability to deploy code in minutes without having to build the infrastructure yourself means that, “you can get from ideas to implementation in several orders of magnitude faster than ever before,” Jassy said. “That’s a very different world. It’s totally changed the culture,” enabling and encouraging builders to think about—and create—exciting new customer experiences.

  To emphasize this point, Dean Del Vecchio, Chief Information Officer & Head of Enterprise Shared Services at Guardian, joined Jassy on stage to explain how the success of the insurers’ efforts in cloud migration, paying down technical debt, and transforming legacy systems for the cloud depended on careful preparation of the $71.5 billion insurance and wealth management company’s teams and culture.

  Before changing any code or infrastructure, Guardian started at ground level—literally. The company spent a year updating its buildings, Del Vecchio said, to prepare teams for working in agile methodologies. The moves sent a clear message—investing in workplace, technologies, and employees was important. Once everything was in place, Guardian migrated 200 applications to the AWS cloud in just 12 months, finally shutting down its last physical data center this month. Creating new possibilities for the staff, Del Vecchio said, was essential to embracing new technologies to improve its customer experience.

  
  
  
• 

  What It Takes to Monitor Serverless Applications in AWS Lambda
  aws lambda new relic news and produc serverless monitoring apm • • sorangutan  

  1
  1
  Posts
  52
  Views

  

  For developers, it has never been easier to build software and deploy it to production. Enabled by cloud platform providers, modern development frameworks, container and orchestration technologies like Docker and Kubernetes, and the emergence of managed services like autoscaled databases, experienced software teams can now build production systems at scale in hours or days instead of months.

  The rise of serverless capabilities

  Some of the most advanced capabilities available from the major cloud computing providers are now completely “serverless,” meaning that they require little to no management overhead to operate. These capabilities aren’t just appropriate for startups; large enterprises are also rapidly adopting these services as the standards within their organizations. These serverless tools range from databases like Amazon DynamoDB and object storage solutions like Google Cloud Storage to managed container hosting services like Amazon Elastic Container Service (ECS) and Functions-as-a-Service offerings such as AWS Lambda. These and other serverless tools abstract away the challenges of provisioning and supporting infrastructure; that becomes the responsibility of the cloud provider, which leaves only application architecture and logic for software development teams to handle. These serverless offerings also scale on demand, and you pay only for what you use.

  The impact of serverless on innovation cycles and software engineering team productivity is clear. The reduction in effort and friction involved in building new applications allows businesses to innovate faster and react to changing demand more quickly. Rapid iteration allows for user experiences to evolve in response to customer feedback; inevitable mistakes can be quickly fixed. Independent development teams can extend existing system components without the need for centralized control. And dynamic scaling means that high-demand (read: high-value) parts of the system can flex to meet growing demand without requiring big infrastructure or architecture changes.

  The evolution from microservices to nanoservices

  This infrastructure flexibility has lead to an evolution from microservices to what are essentially nanoservice architectures. While organizations may maintain a variety of microservices with internal or public facing APIs, each of those microservices may itself be comprised of many other service components, all of which can be modified and scaled independently.Consider this simple but common web API example: An HTTP request is sent to an Amazon API Gateway, which invokes a synchronous Lambda function that does some processing and puts data into a DynamoDB table, returning success or the proper error code after the operation has been completed.

  

  From there, you can evolve this architecture to do more complex things.

  Here’s an example of a common, modern data-ingest-and-aggregation process: Similar to the web request above, the HTTP call is routed to a function that does some processing, but this time it publishes to an Amazon Kinesis stream. A different function has the job of consuming from that stream, doing some data aggregation work, and storing it in an Amazon S3 bucket for later use.

  

  From there, it’s easy to introduce more complexity and deliver more value with even small changes to the system. Those system components can be combined into many different workflows. Development teams can reduce dependencies on each other by building their own extensions on the system. They are free to choose the tools, languages, and services they need to meet their objectives, modifying only the components required to compose the larger application, rather than change large chunks of code. 

  Building software has never been easier—but monitoring it has never been harder

  This approach comes with a cost, however, and that cost is complexity: multiple languages, many services, and myriad paths through the system. So while it has never been easier to build software, understanding your systems and monitoring them has never been more difficult. The benefits of architectures using this approach are clear, yet the tools used to build, monitor, and troubleshoot these composite applications haven’t kept up.

  Modern software developers need complete observability into their serverless applications, with the same depth and breadth they’ve come to expect in their legacy, monolithic apps. Key data for this observability includes:

  1. Metrics to understand system health: Aggregate metrics are essential to understand what’s happening at the highest level. There are many examples of critical metrics, but the 4 Golden Signals from the Google SRE book is a good place to start. It’s critical to understand that metrics at every level help identify that there is a problem, but the details of the problem are also important.
  2. Traces of end-to-end paths: When you discover a problem, whether from an alert, a support ticket, or an observation you make, you need to understand the end-to-end path through your distributed system. Looking at these traces helps you better understand the data flows and identify offending components, even if they are far downstream.
  3. Detailed data for root cause analysis: Once you’ve found the source, you need to find the cause. Rich, code-level, HTTP request details and errors in the context of your metrics and traces enable you to determine what is wrong. You shouldn’t have to download a bunch of logs across multiple functions and services, aggregate them, and start running custom queries to get the answer.
  4. Relationships for context: Serverless, highly iterative systems experience lots of change, and that change frequently comes in unplanned ways. There could be unexpected or unknown upstream or downstream systems causing an issue. When a problem occurs, you need to see the full context around the system.

  Developers building and operating their software need all of this data in one place—using one tool on one platform. They need to see not just their serverless applications in isolation but also how these interact with legacy systems. And the monitoring data needs to scale dynamically, just like their applications—even on their biggest days.

  New Relic AWS Lambda monitoring—now in private beta

  That’s why we are so proud to announce a private beta of our AWS Lambda monitoring solution. Paired with New Relic’s ever-growing list of integrations providing insights into managed service data (see the documentation here), we give our customers a more complete picture of their serverless applications. Our solution is designed to let you monitor, visualize, troubleshoot, and alert on your Lambda functions, all in the New Relic platform you are already using. You can monitor Lambda performance in aggregate, and then drill down into individual Lambda invocations to see traces, errors, view end-to-end traces, and other troubleshooting information.

  Starting with Node.js and Python, our solution includes automatic framework instrumentation specifically designed to run in the Lambda environment, along with new data collection tooling built to gather data and send it to New Relic with negligible overhead. Lambda-specific data is instrumented, including sources of invocation, errors, and tracebacks, as well as services called. That data is written to Amazon CloudWatch logs, where it is extracted via a log stream and sent to the New Relic platform.

  Once collected, we add important metadata and tags for use in later queries, and we define relationships to the rest of the entities in your system. With the data in the New Relic platform, developers have access to the full power of our robust features: alerts, applied intelligence capabilities like anomaly detection, curated UI experiences, custom dashboards, API automation, and ad hoc analytics.

  Early-access customers are already using our solution to monitor their production Lambda systems. As always, our product development process includes validating new solutions with select customers before we scale it to our entire customer base. If you are interested in getting early access and want to contribute feedback, sign up here. Unfortunately, not everyone who signs up will be invited to the private beta, but everyone will receive updates as we hit critical milestones on the way to general availability. We welcome your feedback—in fact, we thrive on it!

  
  
  
• 

  Distributed Tracing Anomaly Detection: A Faster, Easier Way to Troubleshoot Microservices Environments
  new relic news and produc troubleshooting new relic apm anomaly detection distributed tracing • • sorangutan  

  1
  1
  Posts
  43
  Views

  

  As microservices environments continue to grow in size and complexity, they create bigger challenges for DevOps teams working to monitor the health and behavior of their systems. New Relic recently announced the general availability of a new feature that addresses this challenge: anomaly detection for distributed tracing.

  Anomaly detection automatically surfaces the anomalous parts of a trace, which allows customers to find and focus directly on sources of latency. It’s one in a series of New Relic releases devoted to distributed tracing improvements, including condensed trace views, deployment markers, and trace groupings—all of which help DevOps teams understand and troubleshoot microservices environments more quickly.

  The challenges of using trace data to resolve performance bottlenecks

  Distributed tracing helps you understand how requests flow through your microservices environment. This capability makes distributed tracing useful for finding sources of latency and errors within these environments. By tracing a request as it goes from one service to another, and timing the duration of important operations within each service, you get a complete picture of any performance issues or bottlenecks that impact the request within a distributed system.

  However, digging through all of this trace data to find actionable insights can be time-consuming—requiring you to filter down to relevant traces that will actually help you spot the problem. As distributed systems continue to scale and get more complex, this process of finding the relevant traces and spans required to solve a performance problem will just keep getting harder.

  In addition, even after you find a relevant trace, it’s often difficult to understand the flow of the trace—and it can be impossible to tell whether a specific span within the trace was performing normally. To make matters worse, many distributed tracing solutions provide only high-level, service-to-service details. These solutions fail to drill down into the details that indicate what’s actually happening inside the service—yet these highly specific, in-process details are precisely what a developer needs to see when the source of a performance problem lies within the service itself.

  Highlighting performance bottlenecks with applied intelligence

  New Relic has introduced anomaly detection to automatically highlight unusually slow spans within a trace, making it easier for you to find and focus on these anomalous sources of latency. New Relic Applied Intelligence—a set of services that includes artificial intelligence, machine learning, and advanced statistical analysis—plays a key role in this capability by making connections and uncovering actionable insights within even the biggest anomaly detection data sets.

  When New Relic views a trace, it uses anomaly detection to compare the spans within that trace to the spans of other, similar traces. It then highlights spans with longer-than-normal latency times based upon this comparative analysis. For each anomalous span, New Relic displays a summary that shows why it flagged the span as anomalous. New Relic also creates histogram charts showing the duration distribution of similar spans; these also show how the anomalous span compares to its peers over the past six hours. The latter capability is particularly useful for understanding how much of an outlier a particular span represents.

  These capabilities also help teams in microservices environments where they often look at traces that involve their own services, but they may also look at traces involving services that they don’t own and don’t understand deeply. For these teams, it’s often difficult to understand what’s “normal” in a trace. With New Relic’s anomaly detection, these teams now get a fast and highly accurate sense of what’s normal in a given situation versus what’s unusual and needs attention.

  

  Anomalous spans flagged for review with performance benchmarking against similar spans.

  Faster root-cause identification with improved trace navigation and context

  We’ve also released a number of improvements that make it easier to to pinpoint underlying problems using trace data.

  Trace groupings: Reproducing issues often requires identifying patterns: Are traces that originate from a specific service slower than others? Is a specific entry span slower or faster than others? Are errors clustered during a specific time period? Trace grouping allows you to organize traces by errors, root service, root entry span, and service entry span giving you more ways to zero in on traces that are relevant to the problem you’re trying to solve.

  Deployment markers: Deployments and other changes often cause performance problems. In these cases, correlating a difference in trace behavior with a particular deployment to an upstream or downstream service lets you identify the offending service more quickly. Embedded deployment markers provide this context as part of the trace scatter plot—making the process of identifying potential impacts from upstream and downstream changes much more straightforward.

  

  Traces grouped with errors, with deployment marker context.

  Condensed trace views: Complex microservice environments require monitoring that delivers the best of both worlds: the simplicity and clarity of a high-level system overview but also letting users drill deeply into specific transactions and processes to troubleshoot them. Our updated and condensed trace view satisfies both of these requirements. It begins with a high-level view that makes it easy to understand the flow of a given request. From there, however, you can expand different spans to see the detail within a specific service; and you can drill into in-process operations that show exactly how much time was required within the service for tasks such as internal method calls and functions. Going deep into these in-process spans can make it easier to spot potential sources of latency and errors, such as servlet filters in Java applications.

  

  In this example, there are 3 services in this request, starting with WebPortal calling the Fulfillment Service, which then calls the Billing Service …

   

  

  .. and then expand the Fulfillment Service to see more details of its calls …

   

  

  … and even display in-process spans to review the internals of the service for troubleshooting.

  Customize dashboards and target alerts to specific services and spans

  New Relic customers get a curated, out-of-the-box distributed tracing experience automatically when they implement a New Relic APM language agent. At the same time, the underlying trace data is also available in New Relic Insights—where all span and transaction events are available for custom dashboarding. Users can create Insights dashboards, using powerful NRQL queries, that are fully customized for their own teams and systems. These queries also give users the option to create targeted NRQL alerts that notify teams instantly about errors or performances issues in their services.

  

  Create custom dashboards to track key services, system health, and performance.

  A look at troubleshooting issues in complex environments

  During our early-access testing of these new features, we found teams digging up interesting issues in their environments. One customer, for example, identified a periodic rebuild within one of their distributed cache services—an incredibly expensive issue that also caused significant slowdowns to requests during the rebuild periods. In this case, the customer quickly identified the issue by correlating the information they saw in traces during the slowdown periods.

  We also found an interesting example involving a trace on an unfamiliar system with a duration of 65 seconds—a duration that appeared to indicate abnormally slow performance. Normally, we might have assumed that the trace was, indeed, anomalous and we were surprised that anomaly detection was not flagging it. In reality, the trace involved a job that ran twice an hour and consistently required about 65 seconds—what turned out to be completely normal performance profile for the job that it was doing.

  Since we also use New Relic to monitor our own production systems, we’ve been testing this release alongside our customers. One interesting issue that we uncovered involved a New Relic team member using anomaly detection to review slow spans in a set of traces. A pattern started to emerge—involving a set of requests that consistently had the same number of spans and duration. After grouping the traces by ‘Service entry span,’ the team member found that the requests always called the same API and always encountered the same issue: a classic N+1 query problem associated with an old version of our REST API.

  In addition, since we have added custom attributes to these spans, we could see that these requests originated with a specific New Relic customer. We worked with the customer to adopt and integrate a newer, more performant version of the APIs. It was actually a great feeling to uncover such a pattern—one that otherwise might have remained hidden within the hundreds of microservices that we run, and one that allowed us to improve the New Relic experience for a customer!

  Building better observability for distributed systems

  Since our original release of distributed tracing, we have continued to build more useful and intuitive experiences for our customers working in microservices environments. Whether we provide better visibility into an organization’s service topology with Service Maps, or enable customers to drill deep into their services using our latest distributed tracing releases, or deliver innovation in any number of other ways, we continue to invest in making it easier for DevOps teams to find and resolve application performance issues.

  To learn more about distributed tracing with New Relic, check out these resources in the New Relic documentation:

  • Understand and use distributed trace UI
  • Example Insights queries of distributed trace data
  • Span event attributes

  And if you haven’t enabled distributed tracing yet, do it today! We’ll show you how here.

  
  
  
• 

  New Relic Infrastructure: Delivering Value and Efficiency to Your AWS Investment
  aws aws reinvent new relic news and produc aws integrations new relic infrastructure • • sorangutan  

  1
  1
  Posts
  50
  Views

  

  At New Relic, we believe “observability” is a critical part of infrastructure management, so we’re constantly working to make it easier for you to monitor your Amazon Web Services (AWS) hosts and services. Moreover, we understand that your foundational stack in AWS is likely evolving—management and configuration options for AWS offerings are more robust and dynamic than ever before—so our specific goal is make sure that you’re efficiently monitoring—and thus understanding—the impact those changes have on your software architecture and technology running in the cloud. To help illustrate that we’re all in on AWS, we want to highlight some of the latest capabilities from New Relic Infrastructure designed to help you get more value and efficiency out of your AWS investment.

  Your AWS ecosystem is evolving

  New Relic’s unique value becomes apparent the moment you incorporate our monitoring tools with your AWS services. But we offer even more value in a few critical areas based on your evolving workflows, including when:

  • You support multiple AWS accounts.
  • You run AWS across multiple regions.
  • You run multiple AWS services and need to understand how those services and their underlying hosts are performing.

  Multi-account monitoring

  It’s not uncommon for our customers to have different accounts in AWS based on organizational structures, security boundaries, or development-environment workflows. Each account generates its own metrics, perhaps even on a per-region basis, but teams may want to consolidate that multi-account data (for, say, SRE-driven cloud resource management ).

  You can add multiple AWS accounts to New Relic Infrastructure. To do so, simply follow the steps to connect an AWS account for each account you want to associate with New Relic Infrastructure, and you’ll be able to consolidate your data in just one dashboard.

  Multi-region support

  As your Software-as-a-Service (SaaS) organization scales, multi-region support becomes even more critical. Large-scale SaaS operations are likely to distribute environments depending on regional, compliance, and high-availability needs. As you add customers throughout new regions, you need to monitor the entire infrastructure from a central location—that fabled “single pane of glass.” To this end, we’ve made it possible for you to connect AWS accounts from multiple regions to New Relic Infrastructure.

  Multi-service monitoring

  If you’re hosting an application on AWS infrastructure, you’re likely consuming more than one AWS service at a time. Maybe you have some combination of AWS Lambda, Amazon Kinesis, AWS DynamoDB, and the AWS API Gateway working together in your application’s backend. For such architectures, New Relic Infrastructure provides more than 30 AWS integrations (more on them below) through which you can monitor essential AWS services from a single Infrastructure account.

  When you connect multiple AWS integrations to your Infrastructure account, you’ll get one out-of-the-box dashboard that highlights the most relevant metrics for every service you’ve deployed—and you can correlate those metrics with application-level metrics.

  As your integration footprint grows, consolidate it with one set of IAM credentials

  AWS offers a wealth of services that allow easy access to core application requirements such as storage, networking, message queues, notifications, load balancing, and content distribution. This is a blessing in that no one wants to manage extra services. But it’s also a curse because you may have limited visibility into how the underlying hosts are performing.

  New Relic Infrastructure aims to solve that problem by using the same identity and access management (IAM) credentials you provide in the initial setup of any AWS integration to pull in data about any AWS services running under your account. Our integrations collect essential metrics and events data, and data about configuration changes to your services, and let you audit the individual configurations.

  These integrations are the cornerstone of our work to support your AWS journey.

  Control when and how your integrations gather data

  As we watch our customers use our AWS integrations, we’ve learned that while monitoring AWS services is a high priority, getting a focused view is equally important—as is avoiding significant increases in cloud-usage bills.

  With that in mind, we’ve made it easy to take granular control over how you monitor your AWS cloud services. More specifically, the ability to configure polling frequency and data collection for cloud integrations is designed to let New Relic users:

  • Reduce the polling intervals for metrics and inventory.
  • Set filters to narrow data fetching (for example, filter by region or by tag).

  You can filter on any custom tags you’ve created on AWS resources to monitor your environment as you see fit. For example, you can filter by tags that define production or development environments, or even application type.

  

  Fine tune polling frequency and filter data collection by AWS region.

  Further, you can configure your polling frequency and filters to understand:

  • How often New Relic gathers service metrics from AWS.
  • How often New Relic gathers cloud entity and service attributes from AWS.
  • Which AWS-specific locations or resource groups New Relic will monitor.
  • Which tag keys or tag values describe the AWS resources New Relic will monitor.
  • The names of the resources (such as AWS queues and application load balancers) that New Relic will monitor.

  By fine tuning your polling frequency and setting filters on data collection, you can prevent potentially excessive API polling and avoid usage rate limits that incur additional service charges.

  See our cloud polling documentation for more details.

  Of course, cost savings are essential

  As AWS partners, we’re dedicated to providing the best experience for our mutual customers, while understanding that cost controls are essential. Which is why earlier this year we partnered with AWS on the AWS getMetricData API, which bundles hundreds of metrics into a single request and significantly decreases the number of call requests made to AWS CloudWatch.

  The getMetricData API helps customers using our AWS Infrastructure integrations by providing a more scalable and cost-effective solution. It’s led to fewer API requests to our users’ accounts, and faster resolution of their AWS environment-related issues and degradations.

  

  This example chart shows a 75% decrease in API calls after implementing the AWS GetMetricData API.

  We’ve got you covered

  When you adopt AWS, we want you to do so with confidence—enjoying out-of-the-box visibility into the services you use. In the last year, we’ve released multi-account, multi-region, and multi-service monitoring capabilities for our 30+ AWS integrations, allowing you to control your cloud infrastructure on your terms.

  With polling data and API request enhancements, we’ve made it possible for you to optimize your cloud spend by identifying inefficient resource usage, freeing budget resources for further AWS investment.

  These capabilities just the tip of the iceberg—be sure to check out all of our other AWS integrations, including Amazon Elastic Container Service for Kubernetes (EKS) and AWS Billing and Amazon EC2 Container Service (ECS). No matter what size investment you’re making into AWS, our goal is to help you maximize your return.

   

  Planning to be at AWS re:Invent 2018 in Las Vegas? Be sure to visit both our locations in the Venetian (1220) and the Aria (Q200) for informative lightning talks featuring technical deep dives with New Relic experts and partners, as well as real-world customer stories. We’ll have plenty of information and ideas on how New Relic can help you optimize your AWS journey.

  
  
  
• 

  Introducing the New Relic Cloud Adoption Solution for AWS
  aws new relic news and produc partners cloud adoption • • sorangutan  

  1
  1
  Posts
  38
  Views

  

  Cloud migrations are seldom easy or inexpensive. We hear over and over from our customers about the many challenges they face in planning and executing their cloud adoption initiatives, whether that’s tracking the progress of the migration, determining the actual costs and savings involved, or understanding how a migration impacts their applications, end users, and business results.

  Introducing the New Relic Cloud Adoption Solution for AWS

  We believe that you should be able to track and monitor every aspect of your migration and its benefits, just like you would track any mission-critical development and infrastructure project. To help make that possible, and to make your adoption of AWS as successful as possible, we’re introducing the New Relic Cloud Adoption Solution (CAS) for Amazon Web Services (AWS).

  Our CAS is a unique combination of people, processes, and technology designed to manage complexity and give you a thorough understanding of the entire migration process from inception, through planning, and on to implementation and operation. The CAS can help you:

  • Plan and prioritize your migration more effectively.
  • Understand the scale of your migration.
  • Track the migration process in real time, and see its impact on your business performance and bottom-line results.
  • Determine if you’re meeting the business goals defined during planning—are your costs in line with expectations?
  • See how the migration affects your customers.
  • Discover whether the migration is helping your organization react quickly to market changes.

  The New Relic Cloud Adoption Solution for AWS: a framework for cloud success

  Put simply, New Relic and AWS provide the monitoring and cloud technology, while the AWS Migration Acceleration Program (MAP) and the New Relic CAS supply the methodology and a common language for everyone to use when dealing with these complex issues. We have also partnered with a community of software vendors and systems integrators that offer the personnel and hands-on expertise required to make your cloud adoption initiative as fast, smooth, and successful as possible.

  

  This diagram lays out the elements of New Relic’s Cloud Adoption Solution for AWS.

  As outlined in the diagram above, your cloud migration journey with MAP and CAS includes readiness and planning phases, as well as the actual migration; each of these phases includes a number of more detailed steps (more on that in a moment). With deep technology integration from our AWS and ISV partners, the New Relic CAS provides crucial insights into each phase of your cloud migration journey. Our systems integrator partners—listed at the bottom of the diagram—are trained to implement these integrations for our customers.

  Don’t miss: Helping Modern Organizations Achieve Success in The Cloud: New Relic Partner Momentum

  The CAS ecosystem brings together New Relic and New Relic Expert Services with AWS and AWS Professional Services, along with a carefully selected group of systems integrators and software vendors—including RISC Networks, TSO Logic, and Cloudamize—who help with portfolio discovery. Together, we do the hard work of integrating the technology, building an ecosystem and framework, creating a common language, and developing a content library so that you don’t have to stitch together a solution across multiple vendors and service providers.

  How New Relic CAS aligns with AWS MAP

  AWS created MAP to help enterprises realize the full business benefits of moving workloads to AWS as quickly and efficiently as possible. AWS MAP includes methodology, tools, services, and partners to apply best practices to cloud migration projects.

  AWS MAP consists of three phases:

  1. Migration Readiness Assessment (MRA): Assessing your current state and determining the foundations of your migration.
  2. Migration Readiness and Planning (MRP): Writing the business cases, prioritizing your workloads, and developing a detailed plan for the migration.
  3. Migration and Operations (M&O): Assisting in continuing operations and transformation once you’ve migrated your workloads to the cloud.

  New Relic connects monitoring of all types of applications, infrastructure, end-user experience, and business metrics to the final, M&O phase of a cloud migration. But the CAS framework’s tools, prebuilt content, and best practices offer essential visibility and actionable insights directly aligned to all three phases of the AWS MAP—all delivered via a “single pane of glass.”

  Let’s take a look at how the New Relic CAS works with each phase.

  Phase 1: New Relic CAS in the Migration Readiness Assessment (MRA)

  In the initial phase of a cloud adoption, you assess your current environment and prioritize which workloads you want to migrate first. Our infrastructure discovery partners in the New Relic CAS work with you to understand your existing infrastructure and identify dependencies. The key here is to monitor workloads at the infrastructure level so you have the information needed to “rightsize” your migration. For example, if an application server is running at a 10% utilization rate, you want to provision a cloud instance to match the actual usage rather than the original, over-provisioned hardware capacity.

  It is essential to include monitoring at the beginning of the MAP process to get full end-to-end visibility into your migration. The CAS ecosystem integrates our partner ISVs with the New Relic platform to make this possible. We’ve even created sample New Relic Insights dashboards—like the ones shown below—to jumpstart this step. Some are high-level executive dashboards that track the overall migration; others are more detailed, IT-level dashboards. Customers can easily adapt them to their own environments.

  

  The New Relic CAS includes sample dashboards designed to help New Relic customers jumpstart their migration to AWS.

  Phase 2: New Relic CAS in the Migration Readiness and Planning (MRP)

  During the second phase—Migration Readiness and Planning—the New Relic CAS provides in-depth analysis of dependencies in your applications and infrastructure. We then use this analysis to inform planning decisions and prioritize workload migrations. These detailed plans are essential to minimize risk during the migration process.

  As you develop your prioritization plan, it is important to monitor and establish baselines for each application before beginning the actual migration work. The New Relic CAS guides you through the application baselining process and helps create the detailed business case for your MRP. The baseline also serves as an essential comparison point to track changes in application performance before, during, and after the actual migration. It’s critical to understand, at a granular level, how the migration has affected your digital user experience. Without documenting both the before and after migration states, you have no way to tell what’s really changed.

  The CAS also includes establishing business KPIs during the MRP phase to help understand and measure the bottom-line impact of your migration. Typically, the ultimate goal of a migration is to save money or generate revenue. Pulling together performance and business data into New Relic gives you a single place to determine if you’re achieving these goals.

  

  We designed sample dashboards and service maps that make it easy to see application dependencies during a cloud migration.

  Phase 3: New Relic CAS in Migration and Operations (M&O)

  During the final phase—Migration and Operations—the New Relic CAS provides visibility into application performance and end-user experience after a migration. This capability enables you to quickly identify and resolve bottlenecks as well as to optimize workloads.

  Detailed examinations of the performance of your applications across the entire stack helps you determine if refactoring your applications could amplify the migration’s contribution to your business. These can help you determine, for example, whether to consider using AWS Lambda or AWS Auto Scaling for particular workload profiles.

  Finally, to reduce the impact on your business when something goes wrong, the CAS calls for defining alerts based on business and system metrics. This can help optimize incident response and lead to faster resolutions of performance and availability issues.

  

  The New Relic Cloud Adoption Solution (CAS) for AWS includes sample dashboards designed to help customers understand the progress of their cloud migration—and its business impact.

  The New Relic CAS puts it all together to bring quantifiable value to every step in the cloud adoption process.

  Just as important, New Relic enables you to extend the benefits of the CAS throughout your organization. IT teams, for example, can show the results of the migration to the rest of the business. Program owners can know exactly how they’re doing and enjoy data-driven predictability of further progress. Business owners can see the actual return on their investment. And executives can talk confidently to customers and shareholders about the cloud migration’s impact on the business.

  Getting started with the New Relic Cloud Adoption Solution for AWS

  To get started, all you need to do is tell us where you are in your cloud migration journey—and the most important goals you want to accomplish. To make the process of getting started even easier, you can begin with selections from a predefined catalog of best practices and dashboards that you can customize to fit your environment. New Relic and our CAS partners have figured out the technology, process, and people aspects to make it happen for you.

  Ready to get started? Ask your New Relic team (or complete the Contact Us form here) to tell you more about the Cloud Adoption Solution for AWS. Keep in mind that while you can activate the New Relic CAS at any point in your cloud migration, the impact is far greater when you deploy it as soon as you begin thinking about migrating to the cloud.

  Planning to attend AWS re:Invent 2018 in Las Vegas? Be sure to visit both our locations—in the Venetian (booth 1220) as well as in the Aria (booth Q200)—to catch informative lightning talks featuring technical deep dives with New Relic experts and partners, as well as real-world customer stories. We’ll have plenty of information and ideas on how New Relic can help you maximize the value of your AWS journey. 

   

  
  
  
• 

  Helping Modern Organizations Achieve Success in the Cloud: New Relic Partner Momentum
  aws aws reinvent new relic news and produc cloud migration cloud adoption • • sorangutan  

  1
  1
  Posts
  99
  Views

  

  At New Relic, we see a tremendous role for partners helping businesses transform towards modern software. New Relic is deeply entrenched with many customers shifting workloads to the cloud, which increasingly involves initiatives to modernize their software.

  Momentum in the New Relic partner ecosystem

  As more complex modernization projects come to the fore, New Relic partners—including cloud providers, systems integrators (SIs), and many other technology partners/independent software vendors (ISVs)—are increasingly positioned at the core of these initiatives. At our FutureStack18 events in San Francisco and London, we held summits for our key partners in this ecosystem and shared our vision of how New Relic is building a modern partner ecosystem built on three key themes: ease of engagement, a solutions approach, and flexible partnering.

  

  Advancing business initiatives in the cloud

  Now, as AWS re:Invent gears up in Las Vegas, I’m excited to highlight the momentum that New Relic is seeing with our partners around Amazon Web Services (AWS) migrations, the AWS Marketplace, and the ISV partners that together define the modern partner ecosystem.

  We are working with several systems integrators that use New Relic to deliver cloud migration services from planning all the way through to operational stability. We are speaking with dozens of ISVs whose capabilities help round out successful cloud migrations and who want to use the New Relic platform as their source of truth. Furthermore, the business model innovation driven by AWS and its AWS Marketplace is transforming the industry, making it easier to consume more cloud services and complementary ISV technologies like New Relic.

  Introducing New Relic’s Cloud Adoption Solution for AWS

  As we’ve talked about cloud adoption with customers, partners, and AWS over the past year, we gained new insight into the challenges of cloud migrations—and we found that New Relic is in a great position to help. Customers often use New Relic to troubleshoot migration problems (see, for example, our work with healthcare.gov), and of course they rely upon New Relic for daily monitoring and alerting. However, migration projects did not always utilize New Relic during the cloud migration planning process—where it is critical to assess readiness, establish performance baselines, define metrics and KPIs, and build dashboards that will monitor progress and success.

  Today at AWS re:Invent, we introduced a new program, the New Relic Cloud Adoption Solution (CAS) for AWS, with which we are advocating the following best practices for customers, SIs, and AWS Professional Services teams who are leading migration initiatives:

  1. Engage New Relic as the platform for migrations from beginning to end, and use consistent metrics across multiple phases of large migrations.
  2. Use a migration methodology that is aligned to AWS migration methodologies and tools such as AWS’s MAP (Migration Acceleration Program), including MRP (Migration Resource Planning), MRA (Migration Readiness Assessment), and Migration and Operations (M&O).
  3. Instrument all applications with New Relic prior to migration.
  4. Use New Relic migration dashboards to provide visibility to stakeholders and to keep projects on schedule.
  5. If there are other migration tools used, integrate their data via New Relic Insights, so that all migration metrics and KPIs are visible in one place.

  On the last point, we are happy to announce new partnerships with important AWS partners, RISC Networks, TSO Logic, and Cloudamize, with migration examples and a catalog of pre-built dashboards designed to make it seamless to get the most out of each of these tools.

  

  Don’t miss: Introducing the New Relic Cloud Adoption Solution for AWS

  As the next phase of cloud migrations are often more complex and involve application modernization, it is critical to have a visibility platform like New Relic in the mix from the very beginning—starting with the planning phase.

  Integrating migration data in one place

  Earlier this fall, New Relic announced a new developer program available at developer.newrelic.com. This secures the foundation for New Relic technology partners and ISVs to make it even easier to integrate data from multiple sources. As customers and integrators use multiple technology partners as part of their migration and cloud adoption services, the New Relic platform is ready to provide end-to-end visibility and help ensure each project is successful and on schedule. We encourage technology partners to contact us to learn more about the potential to integrate a wide variety of data into the New Relic platform and to engage in shaping our ISV partner program.

  Working with AWS Marketplace to accelerate cloud adoption

  As customers implement their cloud strategies and increasingly make multi-year commitments to cloud spending, they are also solidifying their plans to include related technologies such as New Relic. Working with AWS Marketplace teams, we are making it even easier to consume cloud services, promote successful migrations, bundle data from multiple ISVs, and provide end-to-end visibility by purchasing New Relic licenses through the AWS Marketplace.

  We’ve now worked with more than a dozen customers who purchased New Relic via AWS Marketplace and SaaS Private Offers. Our customers tell us there are tremendous benefits in combining budgets, unifying billing, and streamlining procurement processes by shifting technology spend towards AWS spend, which includes AWS Marketplace. We are excited to work with customers in this modern buying experience, and we look forward to future innovations from the AWS Marketplace team that will enable the bundling of New Relic with even more cloud technologies and services—including all types of partners in New Relic’s modern partner ecosystem.

  Adopt the cloud faster with New Relic

  Digital transformation is still in its infancy for many companies, and we are passionate about the impact we can have in accelerating these initiatives as customers use New Relic as the core platform for cloud adoption. As we continue to build the partner ecosystem that is leading these transformation projects, we look forward to aligning with more integrators on migration methodologies that feature New Relic as the core technology platform; to integrating data into our migration dashboards with more ISVs; and to making it seamless to procure New Relic via the AWS Marketplace. These initiatives together make a powerful impact on the industry’s transformation.

  To learn more about New Relic’s performance monitoring capabilities for AWS, visit https://newrelic.com/partner/aws-monitoring.

  Planning to be at AWS re:Invent 2018 in Las Vegas? Be sure to visit both our locations—in the Venetian (booth 1220) and the Aria (booth Q200)—for informative lightning talks featuring technical deep dives with New Relic experts and partners, as well as real-world customer stories. We’ll have plenty of information and ideas on how New Relic can help you optimize your AWS journey.

  
  
  
• 

  Getting Started With New Relic Browser: Best Practices That Set You Up for Success
  javascript new relic news and produc best practices ajax browser monitoring new relic browser single-page apps • • sorangutan  

  1
  1
  Posts
  87
  Views

  

  The following is adapted from a series of best practice guides that reflect the New Relic Community Team’s work with thousands of customers—identifying challenges and coming up with actionable solutions for organizations getting started with New Relic Browser. Also check out our guides to getting started with New Relic APM and New Relic Infrastructure, and discover the New Relic Community Team’s latest Best Practice Guide offerings.

  New Relic Browser is designed to be your first, and quite possibly your biggest, step toward understanding how your site’s performance impacts your customers. Whether you’re looking for improved insights into AJAX performance; trying to monitor, diagnose, and fix issues with a single-page application (SPA); working to untangle JavaScript errors; or performing a range of other tasks, Browser is packed with capabilities that help you deliver great digital customer experiences.

  In this guide, we’ll offer our most popular and useful tips for working with New Relic Browser. In particular, we’ll help you understand some key data resources you’ll encounter while using Browser and offer tips for how you can transform this data into actionable performance insights. We’ll also point the way to documentation and other resources you can use to continue your path to mastery with Browser and other New Relic applications.

  (If you’re completely new to the New Relic technology landscape, we suggest starting with this primer and series of short videos that give New Relic novices a quick but thorough introduction to our platform, the technology that powers it, and its place in modern software development.)

  

  Getting started with New Relic Browser: organizational tips

  Work smarter with a naming convention!

  When multiple applications run on the same account, and each application spans multiple environments (for example, development, test, pre-production, and production), it can be hard to find a specific application in your overview dashboard.

  We recommend establishing a naming convention for your apps and using labels to facilitate search and filter tasks. Use a naming convention like <environment>-<appname>-<language> to spot patterns in your data more easily.

  Learn more about application naming conventions, including how to rename your apps, in our guide to renaming Browser apps. Our blog post, “What’s in an App Name? How to Create an App-Naming Convention,” includes tips that can improve the way your team monitors all of its applications with the New Relic platform, especially in large deployments.

  Link APM and Browser apps for end-to-end visibility

  When a user sets up a Browser app, either using APM app auto-instrumentation or the copy/paste method with a Browser JS snippet, they get the ability to link to an APM application. This makes it possible to observe your site’s frontend performance statistics in relation to its backend performance. This is important because a problem in front-end performance may be caused by a back-end issue—and by linking apps, you get end-to-end visibility into such issues.

  We prefer that you create these links using the auto-instrumentation option in your APM app environment. For the copy/paste method (which can be useful for monitoring static sites or cached pages delivered by CDN), you’ll need to select the related APM app in the setup page. Then, from either the APM or Browser overview page, simply click the button above the response time chart that provides a direct link to the other back/frontend overview.

  Learn more in our New Relic Browser documentation about setting up and using APM auto-instrumentation, as well as the copy/paste method, to link your Browser and APM apps.

  Understanding your New Relic Browser data

  Use Session Traces for context around website user behavior

  Every user visit to your site is tracked as a session, and Browser captures some of those as detailed session traces. Session traces provide a detailed timeline of events, for up to 10 minutes, providing vital context into a user’s activities, and in many cases making the process of diagnosing and fixing problems faster and easier.

  Learn more about using session traces to explore the load and interaction events that represent the life cycle of a webpage.

  

  Diagnose performance problems with AJAX requests

  New Relic Browser tracks AJAX requests in your webpage to help you identify slow calls to external endpoints. This is a helpful tactic for troubleshooting performance problems: It allows you to determine whether a call to a particular third-party site is responding slowly, which in turn can tell you very quickly whether your own site or a third-party site is the source of a performance problem.

  Learn more about using AJAX requests to identify and diagnose time-consuming third-party website calls.

  URL whitelists: Discover the power of grouping browser metrics

  By default, New Relic will analyze Browser pageview metrics as it receives them. URL grouping can be done automatically, based on New Relic Browser’s analysis of the website’s URL space. This results in URL patterns such as www.foo.com/users/*/profile, which omit the varying user ID parameter and group similar “user profile” page views together.

  You can create your own URL groups to capture those parts of the URL that are similar across many different individual page views. This also provides information about the code path that generated the URL’s content.

  Learn more about creating, using, and managing whitelists in New Relic Browser, including how to create rules-based whitelists.

  Using Browser to make your data actionable

  Use NRQL queries to get the most from your Browser data

  New Relic Insights brings all of the data generated from your New Relic applications together in one place, and it provides a powerful set of tools to analyze and query your data. Perhaps the most powerful of these tools is New Relic Query Language: a query language, similar to SQL, used to make calls against the Insights event database.

  

  NRQL is essentially a language used to ask questions of your data (and to understand the answers). A simple NRQL query, for example, can be structured to find your slowest or most frequently visited pages.

  Working with NRQL in conjunction with Browser or any other New Relic product is necessarily a very big topic. The Level-Up posts below offer a good starting point for exploring the possibilities—focusing on how to set up Insights dashboards that you can use to visualize the results of NRQL queries and to get meaningful insights from your Browser data:

  • Insights Dashboard for Browser: Part 1 – Users
  • Insights Dashboard for Browser: Part 2 – JS Errors
  • Insights Dashboard for Browser: Part 3 – Ajax Request

  

  Use Browser sourcemaps to decode minified JS errors

  JavaScript error analysis is another popular and very effective way to use New Relic Browser to understand your website users’ experiences—giving you the visibility required to find and fix JS errors that may expose users to annoying performance and functionality glitches

  The process of decoding JS errors has its own challenges—for example, the presence of minified Javascript that obscures your code and makes errors more difficult to interpret and diagnose. New Relic Browser gives you the ability to upload sourcemaps to decode minified JS errors and to convert them into understandable stack traces.

  Learn more about using Browser Sourcemaps to “unminify” your site’s Javascript errors.

  

  Ready to learn more?

  Looking for more Browser best practices and tips? Check out the the Browser Level Up category pages in the New Relic Explorers Hub, and discover a wealth of community-generated resources on these and related topics. When you’re ready, test your Browser knowledge by taking our Browser Best Practices Quiz, and earn your proficiency badge!

  

  
  
  
• 

  Steal this Dashboard! Every Insights Chart Type in One Dashboard
  new relic news and produc new relic insights dashboards new relic explorers hub • • sorangutan  

  1
  1
  Posts
  245
  Views

  

  Your modern software team moves fast. To help keep up the momentum, you’re likely gathering all kinds of data about the performance of your team and its deliverables. One of the best ways to visualize that data is to use New Relic Insights dashboards.

  Dashboards tell visual stories about your team’s work. They offer an instant view into the health of your systems, and they help you identify areas that need attention before problems arise. You need to set these views to match your workflows, and that’s why we give you so many ways to visualize the data you capture in New Relic. From billboards to histograms to gauges—you choose the visualizations that best help your team to understand what’s really happening.

  To illustrate the capabilities of New Relic Insights dashboards, we’ve built one that includes every possible way to visualize your APM data and pageview data—what we call the All Chart Types dashboard. These visualizations, or charts, come in a variety of formats, or widgets, and they are built using New Relic Query Language (NRQL) queries.

  Re-create this dashboard in your own environment to learn how each widget works. It’s a simple process: We supply all the necessary queries, and you should have it up and running in minutes.

  Whether you’ve created dozens of dashboards or you’re just getting started, or even if you have never once looked at Insights, this is a dashboard you’re going to want to steal.

  Build the All Chart Types dashboard

  To reproduce the All Chart Types dashboard, you’ll need New Relic APM, New Relic Browser, and New Relic Infrastructure accounts. The dashboard works with the standard New Relic data models and does not require any custom attributes or events.

  The result will look something like the following screenshots:

   

   

  To get started, you need to create a new dashboard in Insights:

  1. Navigate to newrelic.com, and select the green plus (+) icon next to All dashboards.
  2. Name your dashboard.
  3. On the dashboard, click Edit and then click the gear icon Filter enabled.
  4. Configure the following settings:
     • Select Enable filter
     • For Event types select PageView
     • For Attributes set countryCode
  5. To add a widget and chart to your dashboard, run a NRQL query to populate the relevant data you want to visualize. For our All Chart Types dashboard, we’ve provided the relevant queries and an explanation of what each one does. Cut and paste them into your Insights query bar.

  Chart Type	Definition	NRQL query
  Comparison billboard	Compare the number of pageviews this week with last week.	SELECT count(*) FROM PageView SINCE 1 hour ago COMPARE WITH 1 week ago
  Attribute sheet	Display the total number of pageviews, unique sessions, and the maximum page-load duration from the past hour.	SELECT count(*), uniqueCount(session), max(duration) FROM PageView SINCE 1 hour ago
  Total page views billboard	Display the total pageviews in the last hour.	SELECT count(*) FROM PageView SINCE 1 hour ago
  Page load duration (per location) histogram	Display a histogram of the page-load duration for a specific location (in this example, California).	SELECT histogram(duration) FROM PageView where countryCode IN ('CA', 'US') SINCE YESTERDAY
  Unique sessions facet pie chart	Display a pie chart, which can be faceted, showing the number of unique sessions per country.	SELECT uniqueCount(session), average(duration) FROM PageView FACET countryCode LIMIT 10 SINCE YESTERDAY
  Total pageviews bar chart	Display a bar chart, which can be faceted, showing the total number of pageviews per country.	SELECT count(*) from PageView facet countryCode
  Pageload duration heatmap	Display a heatmap of page-load durations, faceted by page URL.	SELECT histogram(duration) from PageView facet pageUrl
  Pageview gauge	Display the total number of pageviews.	SELECT count(*) from PageView
  Related-events funnel	Display a funnel that evaluates a series of related events that are the steps toward a specified goal.	SELECT funnel(user, where name = 'Controller/applications/index' as 'App Index', where name = 'Controller/applications/show' as 'App Detail', where name = 'Controller/traced_errors/index' as 'Errors') from PageView
  Duration line-chart comparison	Compare yesterday’s duration times with duration times from today.	SELECT average(duration) FROM PageView SINCE yesterday TIMESERIES auto COMPARE WITH 1 day ago
  Timeseries-view area chart	Show a timeseries view of today’s average page-load durations.	SELECT average(duration) FROM PageView SINCE yesterday TIMESERIES auto
  Page-load line chart	Display average duration and percentiles from today’s page loads.	SELECT average(duration), percentile(duration, 50, 90) FROM PageView SINCE yesterday TIMESERIES auto
  Uniques list	Display a stacked chart of the total number of pageviews faceted by country.	SELECT uniques(pageUrl) FROM PageView
  Pageviews stacked chart	Display a stacked chart of the total number of pageviews faceted by country.	SELECT count(*) FROM PageView FACET countryCode TIMESERIES auto since yesterday
  Single pageview attributes chart	Display the available attributes for a single pageview event.	SELECT * FROM PageView limit 1
  Number of sessions and average duration facetable table	Display a facetable table showing the unique number of sessions and average duration per country.	SELECT uniqueCount(session), average(duration) FROM PageView FACET countryCode LIMIT 10 SINCE YESTERDAY
  Number of sessions and average duration multi-facetable table	Display a facetable table showing the unique number of sessions and average duration per country and city.	SELECT uniqueCount(session), average(duration) FROM PageView FACET countryCode, city LIMIT 10 SINCE YESTERDAY
  Pageview event table	Display a table of the most recent events captured by PageView.	SELECT * FROM PageView limit 10
  Maximum page load for a specified time period	Display the maximum page-load duration captured for the default time period.	SELECT max(duration) from PageView
  Event feed	Display events in a feed.	SELECT * FROM InfrastructureEvent
  Raw JSON	Display an event in its raw JSON format.	SELECT * FROM PageAction

  (Refer to the Insights chart types documentation for more about each chart type.)

  Share your dashboard with the community, and win!

  On November 26th, 2018, New Relic will kick off our Shared Dashboards contest. You’ll have two weeks to enter by sharing your most useful queries, Insights charts, and dashboards in the Explorers Hub.

  Something for everyone who shares

  There are two chances to win a New Relic branded Apple Watch, but everyone gets something for sharing:

  • One Apple Watch winner will be selected by you via a community vote.
  • A second Apple Watch winner will be selected by the New Relic team.
  • Everyone who shares a dashboard will earn a New Relic Developer Program t-shirt and a contest badge.

  To help get you started and provide more inspiration, our dashboard experts will be sharing a Dashboard of the Day, complete with the NRQL queries that you can use to create these same dashboards in your own environments.

  Get ready to tell your story and share your dashboards. You could win big!

  
  
  
• 

  Automate Your New Relic Tasks With the New Relic CLI From IBM
  open source software engineering new relic synthetics automation ibm cloud new relic alerts • • sorangutan  

  1
  1
  Posts
  96
  Views

  

  Editor’s note: The New Relic CLI tool was developed by IBM. It is open sourced under the Apache License 2.0.

  Helping our customers go faster with confidence is a key tenet of the New Relic ethos. We provide visibility into vital data, statistics, and key performance indicators (KPIs) to help teams increase their deployment speed and cadence. But modern software teams also see automation and continuous integration and continuous delivery (CI/CD) processes as must-haves to support their Agile practices and DevOps teams. Teams want to apply the same automation concepts and tools to operate New Relic as they do other parts of their pipeline.

  However, writing all the standard boilerplate code to work with New Relic’s REST API (read configuration files, connect to endpoints, send payloads, receive responses, and parse them) can be a toilsome burden and a needless distraction. Fortunately, the IBM Cloud Monitoring team, a New Relic partner, noticed that multiple internal teams were spending too much time managing boilerplate code to automate their New Relic workflows, so they created a solution to solve that problem—a New Relic CLI (command line interface) tool.

  Manage New Relic tasks and resources from the CLI

  New Relic CLI, open sourced and available on GitHub from IBM, is a command line tool you can use to manage New Relic resources, such as New Relic Synthetics monitors, New Relic Alerts policies and conditions, and user accounts. You can also use the CLI to backup your New Relic configuration data and restore it as needed.

  Currently, you can use the New Relic CLI to manage these resources:

  New Relic resource	Management action
  New Relic Synthetics	Create, edit, and delete Synthetics monitors
  	Back up and restore Synthetics monitors
  New Relic Alerts	Create, edit, and delete alert conditions
  	Create, edit, and delete alert policies
  	Create, edit, and delete notification channels
  	Back up and restore alert policies and conditions
  New Relic Insights dashboards	Get dashboards
  	Back up and restore dashboards
  Users	List users

  Example use case 1: Create a Synthetics monitor

  This example shows you how to use the New Relic CLI to create a Synthetics monitor:

  1. Set the New Relic admin API key (NEW_RELIC_APIKEY) for your environment. This will vary depending on your operating system, but in Linux, you’d use the export command:Export NEW_RELIC_APIKEY=xxxx-xxxxxxx-xxxxx-xxxxxx
     Tip: Refer to the New Relic docs for instructions on locating your admin API key.
  2. Create a basic definition of the monitor in JSON format (for example test.json).

     {
        "name": "Test monitorURI",
        "type": "SIMPLE"
        "frequency": 5,
        "uri": "monitorURI",
        "locations": [
          "AWS_AP_SOUTH_1",
          "AWS_EU_WEST_3",
          "AWS_US_WEST_1"
        ],
        "status": "ENABLED",
        "slaThreshold": 3,
        "options": {
     }

     Tip: See the documentation for a full list of public minion locations.

  3. Run a text substitution to replace the monitorURI with the actual URL you want to test, and generate a new file (in this example, result.json).

     .awk '{gsub(/monitorURI/,"<URL TO BE TESTED>")}1' test.json > result.json

  4. To create the new monitor, run ./nr-cli create monitor -f result.json.

  From this point, you can start working with the new monitor as needed.

  Example use case 2: Daily backup of a Synthetics monitor

  You can also use the NewRelic CLI to create daily backups of your Synthetics monitors. Using a simple shell script and a cron job, you can quickly set up a process to back up all your monitors in a safe repository.

  These four steps describe how to use the New Relic CLI to set up a daily backup job that will back up all monitors into a separate folder every day:

  1. Download the shell scripts file for backup monitors (backup_monitors.sh) from the New Relic CLI repo.
  2. Add a proper path to the script, and set it as an executable: $ chmod a+x backup_monitors.sh.
  3. Create a new cron job in your OS to schedule the shell script you just created. Use crontab -e to add new schedule job.

     0 0 */1 * * <YOUR NEW_RELIC_APIKEY="xxx-xxxx-xxx>" /<your_path>/backup-monitors.sh

     NOTE: Replace xxx-xxxx-xxx with your own NewRelic admin API key.

  4. (Optional) If you don’t want to set the NR API key in your cron job’s configuration, you can set the key inbackup_monitors.sh. Comment out the Export NEW_RELIC_APIKEY="xxx-xxxx-xxx" entry, replace the value with your API key.

  The cron job should now run and back up on your monitors based on the schedule you created.

  A great addition for your New Relic toolbox

  The New Relic CLI also lets you easily save New Relic settings to source-control tools like Github or BitBucket; and share central configuration and settings across multiple teams and projects. For example, if your target machine can’t connect to New Relic directly, you can configure the CLI tool to use a proxy. You can also configure retries to cope with timeouts. The CLI also includes return codes, which can be very useful for CI/CD automation.

  For more details on developing for the New Relic CLI, see the repo on Github.

  
  
  
• 

  Programming Pride: 10 LGBTQI+ Pioneers of Computer Science
  • sorangutan  

  1
  1
  Posts
  29
  Views

  

  Programming Pride: 10 LGBTQI+ Pioneers of Computer Science

  In honor of Gay Pride and the anniversary of Stonewall, we‘re highlighting a group of pioneers of computer science: people who were (or are) lesbian, gay, bisexual, or transgender. As it turns out, there are many LGBTQI+ pioneers beyond Alan Turing and Apple CEO Tim Cook. The 10 LGBTQI+ people profiled here are individuals whose life work and discoveries have played an integral role in the development of modern computer technology.

  Of course, many of these individuals lived and worked in an era when social pressures (and even laws) required them to hide their true orientation or identity—which makes it all the more fitting that we celebrate them today. We’ve listed them chronologically by birthdate.

  Sofia Kovalevskaya (1850-1891): Russian mathematician

  Born in Moscow, Sofia Kovalevskaya was the first major Russian female mathematician, the first woman to work as an editor for a scientific journal, and a contributor to the development of the Cauchy–Kovalevskaya theorem. Women at that time were not allowed to formally attend university, but Kovalevskaya was allowed to audit mathematics classes at the University of Heidelberg, Germany. In 1874 she presented papers on topics such as partial differential equations, the dynamics of the rings of Saturn, and elliptic integrals. Kovalevskaya became the first woman in Europe to earn a doctorate in mathematics. She later secured a position at Stockholm University with the help of Swedish mathematician Gösta Mittag-Leffler, whom she met through his sister, a woman with whom she had an intimate “romantic friendship” that lasted until Kovalevskaya’s death from influenza at the age of 41.

  Alan Turing (1912-1954): English computer scientist, mathematician, and cryptanalyst

  Generally regarded as the “father” of theoretical computing science and artificial intelligence, Alan Turing is the name that most often comes to mind when people think about an influential gay computer science pioneer. His life story become even more well known thanks to the acclaimed 2014 film The Imitation Game. A graduate of Cambridge and Princeton, Turing worked as a cryptanalyst during World War II, playing a key role in the development of a technique to decipher encrypted German messages, which helped the Allied forces defeat the Nazis. After the war he worked at the National Physical Library in London, where he contributed to the Automatic Computing Engine (ACE) and developed the blueprint for stored-program computers. In his later work at the University of Manchester he developed the idea of artificial computer intelligence, including proposing an experiment to test AI, which is still referred to today as the “Turing Test.” Turing’s life had a tragic ending: arrested and prosecuted for “gross indecency” when authorities discovered he was gay, he committed suicide by ingesting cyanide and died at the age of 41. Turing was named by Time magazine as one of the 100 most important people of the 20th century.

  Christopher Strachey (1916–1975): British computer scientist

  Christopher Strachey was born in Hampstead, England, and his father worked alongside Alan Turing as a cryptographer at Bletchly Park during World War II. Strachey studied mathematics and physics at Kings College, Cambridge, where he suffered a nervous breakdown during his third year (which his sister attributed to his struggles to come to terms with his homosexuality). After an early career as a research physicist and teacher, Strachey developed a program in 1951 that allowed the Pilot Ace computer at the National Physical Laboratory (NPL) and later the Manchester Mark 1 to play a game of draughts (checkers). He also wrote one of the first computer music programs, which played “Baa Baa Black Sheep” on the Ferranti Mark 1. Strachey is also remembered as one of the developers of Combined Programming Language (CPL), an early precursor to the influential C programming language.

  Peter Landin (1930–2009): British computer scientist

  Born in Sheffield, England, Peter Landin studied mathematics at Clare College, Cambridge University, and for a time worked as Christopher Strachey’s assistant. His insight that computer programs could be based on mathematical logic led to the development of programming languages that could be universally understood by different machines. He eventually became emeritus professor of theoretical computation at London’s Queen Mary College. Landin was married but was openly bisexual. In the early 1970s he became involved with the Gay Liberation Front (GLF), and in the later part of his life became more and more devoted to gay rights activism.

  Edith Windsor (b. 1929): IBM engineer and American LGBTQI+ rights activist

  Edith “Edie” Windsor is best known as a gay rights activist who was the lead plaintiff in the landmark Supreme Court Case United States v. Windsor, which overturned Section 3 of the Defense of Marriage Act (DOMA) and led to the legalization of gay marriage. What’s less well known is that Windsor was a computer programmer and an engineer, working with the UNIVAC at Combustion Engineering, Inc., and later at IBM in the 1950s and ’60s, eventually becoming a senior systems engineer.

  Lynn Conway (b. 1938): American computer scientist

  Lynn Conway is a pioneer of microelectronics chip design with an extraordinary life story. She attended both MIT and Columbia University, and in 1964 was recruited by IBM to work on a team building an advanced supercomputer. While at IBM she transitioned from male to female, and was subsequently fired by the company in 1968 after revealing her intention to live as a woman. Conway then began living with a new name and a new identity, and was forced to rebuild her career from scratch, going on to do important work at organizations including Memorex, Xerox PARC, and DARPA. In 2014 Time magazine named her one of the “21 Transgender People Who Influenced American Culture.” 

  Jon Hall (b. 1950): programmer, Executive Director of Linux International

  Jon “Maddog” Hall got his nickname from his students at Hartford State Technical College, where he was head of the computer science department. It was while working at Digital Equipment Corporation that Hall first became interested in Linux. He was also executive director of Linux International, a nonprofit that sought to promote the use of Linux-based operating systems. In 2012, Hall came out as gay in an article published in Linux Magazine.

  Sophie Wilson (b. 1957): British computer scientist

  Sophie Wilson studied computer science at Cambridge University, and while on summer vacation she designed a microcomputer used to control feed for cows. In the early days of her career she worked for Acorn Computers, where she contributed to the design of the Acorn System 1, an early 8-bit computer released in 1979, and later the BBC Micro, which proved hugely successful in the UK. Wilson is best known for her development of the Acorn RISC Machine (ARM) processor, still used today in 21st century smartphones. Wilson is a transgender woman.

  Mary Ann Horton (b. 1955): American Usenet and Internet pioneer

  Mary Ann Horton earned her Ph.D. in computer science from Berkeley in 1981, where she contributed to the development of Berkeley UNIX, which led to the growth of the Usenet in the 1980s. Horton is a transgender woman who, in addition to her contributions to technology, has also made significant contributions to transgender rights in the workplace. In 1997 she asked her then employer Lucent Technologies to include the language “gender identity, characteristics, or expression” in its Equal Opportunity (EO) nondiscrimination policy, which led to Lucent becoming the first company in the United States to add transgender-inclusive language to its EO policy.

  Audrey Tang (b. 1981): Taiwanese computer programmer

  Born in Taiwan, Audrey Tang is a self-taught programmer who was learning Perl at the age of 12, launching a startup at 15, and already working in Silicon Valley by 19. Something of a programming wunderkind, she's best known for leading the Pugs project to develop the Perl 6 language, starting the Perl Archive Toolkit (PAT), and her role as an outspoken advocate for free software and an open web. A transgender woman, Tang currently devotes most of her energy to political activism and social causes.

  If you are interested in learning more about this topic, be sure to check out the fascinating online series A Queer History of Computing by Jacob Gaboury, who is an Assistant Professor of Digital Media & Visual Culture at Stony Brook University.

  Rainbow flag image courtesy of Shutterstock.com. Photos of Sofia Kovalevskaya, Alan Turing, Mary Ann Horton, and Audrey Tang all in the public domain.

  admin Thu, 06/23/2016 - 08:39
  
  http://feedproxy.google.com/~r/NewRelic/~3/Fpf24WrpLgA/10-lgbt-computer-science-pioneers