DEV Community: Connor

Tracking Custom Metrics in Python with AppSignal

Connor — Thu, 18 Apr 2024 13:55:40 +0000

We have improved our custom metrics offering with two recent Python releases. In release 1.1.1 of our Python package, we added the add_distribution_value helper, and in version 1.2.0, we added support for minutely probes, so you can measure the distribution of key data points in your Python application.

In this blog post, we'll show you how to set up custom metrics in your Python application to gain valuable insights without sifting through logs or querying databases.

What Are Custom Metrics?

You can use custom metrics to track any data point alongside your core metric data. Custom metrics give you additional context into how your application performs: for example, an active user count or the processing time of critical tasks.

AppSignal treats custom metrics like any other metric data point; you can create dashboards to visually track them. You can also set up alerts for when custom metrics meet a specific threshold (for example, if a task has been running slowly for over 15 minutes).

Custom Metric Types in AppSignal for Python

While our latest change allows you to measure distributions with Python, AppSignal also has Python helper functions for measuring custom metrics as gauges and counters:

Measure	Function	Description
Gauge	`set_gauge`	A number that represents a particular value at a specific point in time that can frequently be overwritten, such as the count of an application's active users.
Counter	`increment_counter`	A number you can increment by any given value, such as the count of times a process has run.
Distribution	`add_distribution_value`	A collection of numbers from which we store an average, count, or percentile. You can use this to track a spread of values in a dataset - for example, the average user cart value of an e-commerce application, or the percentage of tasks completed within a desired time.

Using Custom Metrics for Deeper Context

You can leverage custom metrics to measure virtually any data point within your application. This is especially handy if your application has high-volume mission-critical flows.

As an example, consider the process of making a purchase. An issue with a third-party payment provider might prevent users from completing their purchase but wouldn't trigger an exception within your application, as it lies outside of your stack.

However, with custom metrics, you can utilize measurable key performance points to help you proactively monitor your application for exceptions beyond the boundaries of its codebase (by monitoring your order count, for example).

Custom metrics can help you quickly investigate and resolve an issue before it hurts your bottom line - e.g., if your app often processes dozens of orders per hour, but that count suddenly drops to zero:

Custom Metrics In Practice

For this article, let's imagine we've got a successful Django webshop that we're already monitoring with AppSignal. To broaden our understanding of our application's behavior, we're going to use custom metrics.

Gauge

While AppSignal makes it easy for us to know when and where our application is less performant, we can use the set_gauge function to track active_shoppers and help us understand how scale impacts our performance.

To do this, we'll create a minutely probe task to report the count of carts that were updated within the last minute:

# import helper probe and set_gauge functions
from appsignal import probes, set_gauge

def set_active_carts_gauge():
    one_minute_ago = django.utils.timezone.now() + datetime.timedelta(minutes=-1)
    active_carts_count = Cart.objects.filter(updated_at__gte=one_minute_ago).count()
    set_gauge("active_shoppers", active_carts_count)

probes.register("active_shoppers", set_active_carts_gauge)

Once our Celery task is configured and sending data to AppSignal, we'll be able to create a chart in AppSignal that tracks how many active_shoppers are using our Django app:

Counter

As our application's usage grows, so too does the usage of critical infrastructure, like tasks.

Our Django application runs an invoice task for every order made. We can use the increment_counter helper function when running that task to give us instant insights into how many tasks our Django application is processing:

# Import increment_counter helper function
from appsignal import increment_counter

def create_order_invoice(order_id):
    # task logic
    increment_counter("invoice_count", 1)

We can also use the increment counter to track additional metrics, such as order_count, and create graphs to monitor invoice_count and order_count alongside one another:

This graph gives us instant visual insights into our application's performance. For example, if we notice that the invoice_count value is flatlining against the order_count, we can proactively investigate to ensure there aren't any undetected issues preventing invoice tasks from running.

Distribution

Let's expand our tracking to include the distribution of item count per order. There are many reasons why this metric may be helpful. We may want to:

Be notified when purchasing trends become irregular - for example, when there are excessive numbers of cart items.
Ensure our app can scale with demand: large purchases may result in slow tasks and lead to bottlenecks.

To do this, we can use the new add_distribution_value helper function to track the item count of our app's orders:

# import add_distribution_value helper function
from appsignal import add_distribution_value

def confirm_order(order_id):
    order = Order.objects.get(id=order_id)

    # function logic

    item_count = order.items.count()
    add_distribution_value("order_item_count", item_count)

Once implemented, our application will report the order_item_count custom metric value, which we can track on a dashboard (and use to configure alerts):

Custom Metrics for Powerful Python Insights

Custom metrics provide high-impact insights into your Python application's performance, removing the need to analyze dozens of samples, search through thousands of log-lines, or painfully reproduce a problem.

When properly utilized, custom metrics can help you:

Quickly find the cause of an issue
Easily contextualize application performance
Reduce reproduction times
Save on unnecessary log storage

If you're interested in using custom metrics to level up your Python performance monitoring, you can read more in-depth information in our custom metrics documentation. We've also got in-depth documentation about our minutely probes helper functions.

AppSignal: Making Monitoring Simple

At AppSignal, we work hard to make monitoring your application feel like magic. We're here to help developers on projects of all shapes and sizes to get the most out of their applications.

That's why we're the only APM to offer:
Simple, straight-forward pricing
A flexible upgrade policy
Friendly, free dev-to-dev support
A 30-day free trial
Sweet, sweet stroopwafels for all new customers 🧇

Sign up today and join thousands of developers who use AppSignal daily to monitor, maintain, and enhance their applications.

AppSignal Expands Monitoring Capabilities with Vector

Connor — Wed, 10 Jan 2024 10:00:00 +0000

We're excited to announce AppSignal support for Vector logs and metrics!

AppSignal's Vector support allows you to expand your monitoring horizons beyond our standard language integrations, making it possible to leverage AppSignal to both monitor the performance and manage the logs of components of your stack that fall outside a standard application.

With Vector, you can use AppSignal to monitor how your databases and Kubernetes clusters perform and metrics from many other sources.

Automatic Dashboards for PostgreSQL and MongoDB

AppSignal's Automated Dashboards take the guesswork out of monitoring, giving you instant performance insights into core metrics.

We currently offer out-of-the-box Vector support for PostgreSQL and MongoDB Automated Dashboards.

Our PostgreSQL and MongoDB dashboards give you deep performance insights, helping you answer important performance questions at a glance, like:

PostgreSQL

What is the count of each query type: SELECT, INSERT, UPDATE, DELETE, COMMIT, and ROLLBACK?
How many queries were rolled back?
How many deadlocks occurred?
How many database clients are connected?
How many temporary files have been written to disk for queries?

MongoDB

What's the health of the databases? (memory usage, network usage, number of operations, open connections with clients)
How is the database performing? (number of bytes read and written, cache size, number of in-progress transactions)
Is database replication delayed? (network usage, buffer size, number of operations)

You can learn more about PostgreSQL and MongoDB Automated Dashboards in our Vector documentation.

Supported Vector Source Metrics

You can also create graphs and dashboards with Vector's sources. AppSignal currently supports metrics from the following sources:

Source	Source Name
Amazon Elastic Container Service	`aws_ecs_metrics`
Apache HTTPD Server	`apache_metrics`
EventStoreDB	`eventstoredb_metrics`
MongoDB	`mongodb_metrics`
NGINX	`nginx_metrics`
PostgreSQL	`postgresql_metrics`
Vector host metrics	`host_metrics`
Vector internal metrics	`internal_metrics`

You can also use Vector Remap Language to convert logs to metrics. Allowing you to extract and track valuable metrics like error type or user login count directly from your app's logs!

Getting Started with AppSignal and Vector

AppSignal makes monitoring your Vector sources a breeze.

Just make sure you're using Vector version 0.33.0 or higher, as older versions do not come with the sink required to send your monitoring data to AppSignal.

Sending Logs to AppSignal with Vector

You can use Vector to send logs from Vector sources like Docker or Kubernetes to AppSignal.

First, you need to add a new log source to your app in AppSignal.
Once you've created a new log source, configure Vector to send logs to AppSignal, for example:

# vector.toml config file example
[sources.my_kubernetes_logs_source]
type = "kubernetes_logs"

[sinks.appsignal]
type = "appsignal"
inputs = ["my_kubernetes_logs_source"]
push_api_key = "Your app-level Push API key"

Please note: Some Vector sources may require additional configuration; this will be outlined in the Vector's Source documentation.

Sending Metrics to AppSignal with Vector

To start sending Vector source metrics to AppSignal, you'll have to configure Vector to report metrics from your chosen source. For example, to send Apache HTTPD server metrics you'd write the following configuration:

# vector.toml config file example
[sources.my_apache_metrics_source]
type = "apache_metrics"
endpoints = ["http://localhost:8080/server-status/?auto"]

[sinks.appsignal]
type = "appsignal"
inputs = ["my_apache_metrics_source"]
push_api_key = "Your app-level Push API key"

To track custom metrics from a source like StatsD:

# vector.toml config file example
[sources.my_statsd_source]
type = "statsd"
address = "0.0.0.0:9000"
mode = "tcp"
path = "/path/to/socket"

[sinks.appsignal]
type = "appsignal"
inputs = ["my_statsd_source"]
push_api_key = "Your app-level Push API key"

Tracking metrics with AppSignal

You can track all of the Vector source metrics you send to AppSignal via Custom graphs. Simply create or navigate to an existing dashboard and select Add graph; you can then create a line, area, or relative graph:

Managing Logs with AppSignal

AppSignal's Log Management allows you to manage your vector source logs easily.

Gain deep insights into your code's performance by combining your APM and log management.

With AppSignal's intuitive UI, you can navigate from an error message to a log line in just a few clicks and query, filter, and share logs effortlessly.

Detecting Anomalies with AppSignal

Anomaly detection lets you define the boundaries of what you consider to be good performance in your application and notifies you when and where metrics go over their limits.

For example, you can create custom triggers to alert you if your MongoDB memory metric increases by a certain amount within a specific timeframe, giving you the time to solve problems before they become performance bottlenecks.

Ready to Power-up Your Performance Insights?

Once you've configured Vector to send source metrics and logs to AppSignal, you should be able to begin inspecting log lines and visualizing performance in a matter of minutes.

You can start with Vector by following the Vector configuration documentation!

AppSignal, The Awesome APM

AppSignal is built by developers for developers to give you the visibility and insights needed to manage and scale your application effectively. As well as Vector support AppSignal offers:

A 360-degree view of your application data.
An intuitive interface that's easy to navigate.
A clean approach to connecting errors, logs, and performance incidents.
The ability to monitor your Node.js, front-end JavaScript, Ruby, Elixir, and Python applications in one place.

If you're a new trial user, reach out to us once you've got your application set up with AppSignal, and we'll send a package of stroopwaffles to you 🍪!

Monitor Solid Cache in Rails with AppSignal

Connor — Wed, 06 Dec 2023 11:25:51 +0000

AppSignal now supports Solid Cache, giving you the same deep cache performance insights you'd get from other Rails cache stores.

In this blog post, we'll give you a quick tour of Solid Cache, and how you can benefit from monitoring your app's cache with AppSignal.

What is Solid Cache?

Plug and play, database agnostic remote disk storage cache, meaning unlike Redis or Memcached, which are memory stored, Solid Cache uses a SQL database through Active Record, keeping your cache on disk.

ㅤ	Local	Remote
Memory	MemoryStore	RedisCacheStore MemCachedStore
Disk	FileStore	SolidCacheEntries Table

Solid Cache might be a favorable caching method if you work with an application with a large quantity of relatively stable historical data, like Hey, 37Signal's email service, as besides new mail, previous emails aren't going to change suddenly.

Monitoring Solid Cache with AppSignal

AppSignal was born in the Netherlands, a country known for its windmills, canals, stroopwaffles, and of course, rain. So much rain. Knowing when it's going to rain is very important when a bike is your primary mode of transport, so we've created a Rails app called SkySignal.

SkySignal connects to APIs to consume weather data from across the Netherlands, letting people know if it will rain in their location and helping developers stay dry while being DRY 🥁.

Like Hey, we want to optimize our application's response times by using caching to serve the weather forecast to our users quickly. We will use Solid Cache to cache historic weather data in this case.

We're opting for Solid Cache here for the same reasons Hey did; it allows us to cache large amounts of data for a fraction of the cost of using an alternative cache, like Redis.

Installing Solid Cache

Installing Solid Cache is easy, we'll follow the steps outlined in Solid Cache's Readme:

First, we need to configure Solid Cache as our cache store in our desired env config files:

config.cache_store = :solid_cache_store

Then we need to add solid_cache to our gemfile.
Then we need to create, and run Solid Cache migrations to create our database cache:

rails solid_cache:install:migrations
rails db:migrate

In this case, we want to write our cache to our primary database, but if you want, you can also configure Solid Cache to shard your cache into different data stores. Sharding breaks down your cache into smaller parts and distributes them across different databases (shards).

Next, we want to install AppSignal to monitor our app.

Installing AppSignal

Installing AppSignal is simple; we've created an installation wizard to get you up and monitoring.

To start the wizard, you can click the "Add app" button on the AppSignal Applications overview page, or if you are signed in, you can use this link to start the wizard.

The wizard will let you know once AppSignal has successfully installed, and in the rare event things go wrong, hand you over to our support for some dev-to-dev assistance.

If you want to install AppSignal manually, follow our Installation Documentation.

Now we've installed AppSignal; we can begin monitoring the SkySignal app's performance.

Monitoring Solid Cache

AppSignal collects your application's performance metrics and translates them into actionable insights. AppSignal has a large toolkit of developer-friendly monitoring tools, but for this blog post, we'll focus on the following:

Metric dashboards: Visually track your app's performance data, like error rates and global response times. For SkySignal, we'll look at our cache size and performance times.
Anomaly detection: Create triggers to alert you when a metric exceeds a specific threshold, for example, when our cache size increases significantly within a short time frame.

Oh, and don't worry if you don't use Solid Cache; no matter your Rails cache store, you'll get the same great metrics in AppSignal!

Monitoring Solid Cache with Dashboards

AppSignal's graphs are a great way of visually monitoring your application's performance. You can add markers to share context about performance spikes and click anywhere on the graph to see a snapshot of your application's performance at that exact moment in time, making debugging a breeze.

Monitoring Response Times

Let's look at our app's performance now that we've configured Solid Cache:

In the graph above, we can see SkySignal has relatively fast response times, and we can also see response time spikes caused by SkySignal consuming batches of new weather data.

Monitoring Cache Size

We've opted to use caching as a stable, efficient way of enhancing our response times by storing large amounts of data in our remote disk cache.

To ensure our cache is optimal, we can track our cache size, see if it's spiking quickly, and use this data to fine-tune our cache configuration to ensure it's optimal for our application's needs.

See this blog post for more information on setting up a dashboard tracking your Solid Cache table size.

Detecting Cache Anomalies with AppSignal

While AppSignal's dashboards are an elegant and intuitive way to keep tabs on our application's performance. Sadly, we can't spend all day looking at AppSignal's beautiful graphs; this is where Anomaly Detection comes in.

AppSignal's Anomaly Detection allows you to create triggers that notify you to let you know if a specific metric threshold has been met, for example, the error rate has gone above 10%, or your cache storage is being used up too quickly.

Anomaly detection allows you to get on with your job. You can configure AppSignal to notify you via email or popular third-party collaboration platforms like Slack and Discord, giving you the peace of mind that you'll be alerted if a trigger is triggered, and monitor your application proactively, preventing bottlenecks before they impact the performance and scalability of your application.

Ready to Start Monitoring Your App's Cache?

At AppSignal, we strive to be awesome at everything we do; that's why we work hard to ensure we support all the latest Rails features and functionality.

When we ask our customers why they find AppSignal awesome, they tell us they like our:

An intuitively easy-to-navigate interface.
Simple and predictable pricing.
Developer-to-developer support.

If you're not already an AppSignal customer click here to create a new trial account. If you're a new trial user, reach out to us once you begin pushing monitoring data, and we'll send a package of Stroopwaffles to you 🍪!

Want to learn more about Solid Cache? We recommend watching Donal McBreen's Rails World talk on YouTube.

We've Levelled up Our Top Monitoring Features

Connor — Tue, 14 Nov 2023 12:57:44 +0000

We've improved our core features to help you debug issues more efficiently and effectively.

This article will walk you through the changes we've made to our Error Tracking, Performance Monitoring, Anomaly Detection, and Log Incidents features that enable you to gain the insights you need to dive deep into issues quicker than ever before.

A Beautiful Overview of Your Errors

We've created new, easy-to-read error overview pages with a summary of your error and the ability to explore its occurrences.

It is now even easier to dive into a new debugging session with all the vital information you need merely one click away.

Error Sample Search

You can now search and filter error samples to help you quickly find specific deployment occurrences, search for specific users, or for samples that include custom tags. It's never been easier to find the sample data you need!

Error Attribute Distributions

With the introduction of error attribute distributions, you can quickly figure out important details like who experiences this error, how often it occurs, and if it's unique to a particular browser.

New Logbook Features

You can now pin important comments to the top of the logbook, allowing you to ensure key knowledge is always at hand.

Performance Monitoring

AppSignal's Performance Monitoring helps you spot where and when your application is slow to respond.

We've added even more tools to Performance Monitoring to help you quickly identify slow queries and combat performance perils!

An Overview of the Latest Samples

The new overview tab provides a quick overview of the last saved performance samples, which includes a deploys table with an overview of the performance per deployment.

Performance Samples Table

Quickly query and filter performance samples with data such as creation date, duration, request ID, and hostname.

You can save time and easily find the information you need to evaluate performance issues.

Sample Page Redesign

We've re-vamped the entire sample page and added a more user-friendly event timeline featuring fullscreen mode, making it possible to monitor your application from your coffee machine or anywhere you can hang a screen!

Anomaly Detection

With AppSignal Anomaly Detection, you can create metric triggers to alert you when specific conditions are met. For example, when disk space rises above 90% or a queue has more than 1000 jobs.

We've enhanced our Anomaly incidents with additional layers of insights, providing you with the clarity needed to resolve them.

Anomaly update

Vidyard video

share.vidyard.com

Issues Layer

The new issues layer lets you quickly understand an alert's state, frequency, and urgency.

An issue is created per trigger occurrence. For example, if you set a trigger for when disk space exceeds 90%, we'll create a new issue for every server where this happens.

This change tidies up your anomaly detection table and doesn't bury important alerts. All trigger issue occurrences are saved and accessible under "Occurrences", which you can access by navigating to your Trigger, then to Multiple issues → Occurrences.

Alert Overview

The alert overview has been redesigned to allow you to quickly understand the state of all of your alerts.

The overview now features the metric data and tags that triggered the alert alongside each alert's most recent logbook activity.

Occurrence Detail

You can now view a more detailed overview of alert occurrences.

With an easy-to-understand timeline of events, you can quickly infer when the alert was triggered and how long it spent in each alert phase from warm up to cool down.

Log Incidents

With Log Triggers, you can be notified when specific logging activity occurs, for example, when a logline matches specific data.

Each log incident has a dedicated logging overview page with the same usability and data insights as you would with our performance incidents.

AppSignal, The Awesome APM

At AppSignal, we strive to be awesome at everything we do; that's why we work hard to ensure our core features are the best they can be. When we ask our customers why they find AppSignal awesome, they tell us they like our:

An intuitively easy-to-navigate interface.
Simple and predictable pricing.
Developer-to-developer support.

If you are a new trial user, you can also get a free box of stroopwafels. Once you start pushing some data, reach out to us, and we'll send a package to you 🍪!

AppSignal Monitoring Available for Python Applications

Connor — Tue, 07 Nov 2023 13:01:49 +0000

We're happy to announce that AppSignal now offers monitoring tools for Python projects.

AppSignal helps you get the most out of your Python application's monitoring metrics, with additional support for multiple Python frameworks and packages such as Django and Celery.

In this article, we'll walk you through some of our core features to show you how to power up your Python application with AppSignal.

Monitoring Support for Popular Python Libraries

AppSignal already supports various popular Python libraries, which will only expand with time! We currently offer support for:

Celery
Django
FastAPI
Flask
Jinja2
Psycopg2
Redis
Requests
Starlette
WSGI/ASGI

Is there a Python package we don't support? Reach out to us, and we'll investigate it further with you.

Error Monitoring

AppSignal is a tool that tells you when, why, and where errors occur in your application.

AppSignal can be configured to track errors per deployment, and tools like Time Detective give you a helicopter view of your application. When an error occurs, you can connect the dots and spend more time solving problems rather than speculating over them.

AppSignal gives you control of when and where you're notified about errors in your application, whether that's on Slack or Discord; you can even connect AppSignal to popular collaboration tools like GitHub and Jira and leave crucial contextual information about an error in the Logbook.

Performance Monitoring

AppSignal monitors your application and tells you when its performance is suboptimal. Spot and fix performance bottlenecks so you can scale your app with confidence.

Our intuitive UI helps you see where and when performance problems arise, with all the critical insights you need at your fingertips to choose the best resolution.

Anomaly Detection

Anomaly detection lets you define the boundaries of what you consider to be good performance in your application and notifies you when and where metrics go over their limits.

Create custom triggers to alert you when performance dips, background job count increases by 20%, or memory suddenly increases.

AppSignal gives you the data-driven confidence to act proactively instead of urgently reacting to issues in your application.

Host Monitoring

AppSignal also monitors your Python application's hosts, giving you at-a-glance access to CPU, disk, network, and memory metrics. This allows you to understand how your Python application is performing beyond just looking at its code. Effectively manage and monitor your hosts.

Python Dashboards

AppSignal's dashboards give you instant visual insights into your application's metrics, allowing you to track and trace performance metrics quickly.

If you see something you want to investigate further, click on that point on the chart, and you'll view the state of your application at that specific point in time. Add custom markers to help you and your team better understand how your application performs.

More Than Just Monitoring

AppSignal can ingest and store logs from popular platforms such as AWS Kinesis, Heroku, and Netlify or via our dedicated logging API endpoint. Gain deep insights into your code's performance by combining your APM and log management.

Our intuitive UI takes you from an error message to a log line in just a few clicks and lets you query, filter, and share logs effortlessly.

Effortless Setup, Immediate Impact

You can have your Python application push metrics to AppSignal in less time than it takes to drink a coffee.

Sign up for an AppSignal account and follow our installation wizard instructions. The installation wizard will walk you through all the steps needed to send metrics from your Python application to AppSignal!

Our Python documentation will also take you through all the steps required to get the metrics you need, including how you can install AppSignal manually.

AppSignal: Your Python APM Tool

AppSignal is built by developers for developers to give you the visibility and insights needed to manage and scale your Python application effectively. AppSignal offers:

A 360-degree view of your application data.
An intuitive interface that's easy to navigate.
A clean approach to connecting errors, logs, and performance incidents.
The ability to monitor your Node.js, front-end JavaScript, Ruby, Elixir, and Python applications in one place.

If you're a new trial user, reach out to us once you've got your Python application set up with AppSignal, and we'll send a package of stroopwafels to you 🍪!

Boost HTTP Client Monitoring in Elixir with AppSignal and Tesla Templates

Connor — Tue, 18 Jul 2023 11:05:41 +0000

When relying on data from external services, it's important for the retrieval to be accurate and timely. While we may not control how efficiently an external API responds to our requests, we can control how and when we request data from that API. However, over time as your application and the API that serves it change, once efficient requests may turn into bottlenecks.

In this article, we'll demonstrate how you can leverage AppSignal's new Tesla integration to monitor your Elixir application's HTTP client performance and use this data to positively influence its architecture.

Templating with Tesla

Note: To implement what is covered in the post, you will need AppSignal for Elixir 2.7.3 or higher and Tesla 1.4.3 or higher.

Let's imagine you manage an application that ships stroopwafels around the world. To do this, your application connects with a dedicated Stroopwafels courier, Strooperoo, using its API to create, update, and track deliveries, with requests structured as follows:

# Create a new delivery
POST https://strooperoo.com/deliveries/create/

# Update an existing delivery
POST https://strooperoo.com/deliveries/:delivery_id/update

# Retrieve the status of a delivery
GET https://strooperoo.com/deliveries/:delivery_id/status

Let's say you've noticed some issues in your application's performance, especially when retrieving a delivery status. Luckily, you're using AppSignal, so you can investigate this further by checking the application's slow API requests.

Typically, AppSignal will group slow API requests by their base URL. In our case, all of the following requests would be grouped under the base URL https://strooperoo.com/:

https://strooperoo.com/deliveries/create/
https://strooperoo.com/deliveries/1971/update
https://strooperoo.com/deliveries/1971/status

This is useful in deducing that the HTTP client is slow but doesn't help us immediately pinpoint which requests are problematic.

However, with Tesla, AppSignal can group your requests beyond their base URL. This is because Tesla allows you to use URL templates enabling AppSignal to understand how a request was built:

defmodule StrooperooAPI do
  use Tesla

  plug(Tesla.Middleware.Telemetry)
  plug(Tesla.Middleware.PathParams)

  def delivery_status(id) do
    params = [delivery_id: id]

    get(
      "https://strooperoo.com/deliveries/:delivery_id/status",
      opts: [path_params: params]
    )
  end
end

So, in the above example, we know you're making a request to the status endpoint, and can apply the appropriate grouping.

Which means that in AppSignal, instead of seeing slow API requests grouped like this:

You'll see requests grouped accurately like this:

Tesla makes your HTTP client monitoring data way more valuable as you can now quickly deduce how your application's HTTP client is performing on a request level.

Wait a Minute, Why Can’t You Do This with Other HTTP Clients!?

Good question. That's because Tesla's templating lets us understand how your request is built. With other HTTP clients, we get a URL string such as:

https://api.wow.com/api/versions/4/users/14383/comments/page/1

It's very tricky to understand, just from a string, what this request is doing and which elements of the request are parameters. Tesla's templating removes that guesswork for us and allows us to accurately group requests by telling us exactly what parameters are in the request URL. Neat, right?

Solving Slow Requests

Looking at our slow API requests, we can now see that requests to /status perform poorly. So let's investigate the application's delivery_status logic.

def delivery_status do
  deliveries = Repo.all(Delivery)

  Enum.each(deliveries, fn delivery ->
    StrooperooAPI.delivery_status(delivery.id)
  end)

  conn
  |> put_flash(:info, "Delivery status updated")
  |> redirect(to: "/deliveries")
end

Here, we are making many requests synchronously. When we first created the application, we were only managing a small number of deliveries, so we didn't experience any issues. But now, we're managing thousands of deliveries. This means that thousands of synchronous requests are being made every single time someone presses the "sync" button in the application.

One way we can better handle this is by running the code asynchronously in a scheduled background job using Oban:

defmodule DeliveryStatusJob do
  use Oban.Job

  @impl true
  def perform(_job, _) do
    deliveries = Repo.all(Delivery)

    Enum.each(deliveries, fn delivery ->
      StrooperooAPI.delivery_status(delivery.id)
    end)
  end
end

AppSignal supports Oban monitoring, so we'll be able to monitor the performance of our Oban job too!

More than Just Monitoring

This is just one of many examples of how monitoring your application with AppSignal can help you make data-driven decisions, in this case, thanks to Tesla's unique templating functionality. You can learn more about utilizing your Tesla HTTP client with AppSignal in our Tesla documentation.

AppSignal's slow API request monitoring is just one of our many developer-driven features that help you get the most out of monitoring your application. Developers also enjoy using our monitoring because we have:

An intuitive interface that is easy to navigate.
Simple and predictable pricing.
Developer-to-developer support.

If you experience any issues when using AppSignal for Elixir or Tesla, our support team is on hand to help! And remember, if you're new to AppSignal, we'll welcome you onboard with an exceptionally delicious shipment of stroopwafels 🍪 😋

Monitoring Your Elixir GraphQL API with AppSignal

Connor — Tue, 11 Jul 2023 10:51:18 +0000

While a GraphQL API may be less susceptible to the common REST API performance issues of under and over-fetching data, allowing users to request and receive a wide range of data in a single, nestable query can also come with performance risks.

AppSignal for Elixir now supports Absinthe out of the box, and automatically adds Absinthe spans to your app's metrics. AppSignal also automatically instruments Ecto, giving you insights into your application's queries. When combined, AppSignal can be used to gain insights into how queries passed to the GraphQL endpoint translate to the database.

This blog post will explore how you can use both AppSignal's Absinthe and Ecto integrations to monitor and fine-tune your GraphQL API.

From Request To Response

Unlike a REST API which has data-specific endpoints, the flexibility of a GraphQL API means requests must go through several steps to return the expected information:

Step	Description
Parsing and Validating	The server parses the request and checks that it is in a valid format.
Query Execution	Root and field resolvers fetch the requested data from the application's database.
Transforming and Responding	The fetched data is transformed, allowing your API to return an array of meaningful data rather than relational IDs. The transformed data is then structured according to the request query. Any errors that occurred while executing and transforming the query will also be included in the response.
Response Delivery	The requested data is delivered in JSON format to the client — it includes all requested data, appropriately formatted, as well as any error messages.

To take full advantage of the performance benefits of a GraphQL API, your application must be able to parse, query, and transform data efficiently, especially when receiving more complex requests that have nested queries or require higher levels of data transformation.

AppSignal's Absinthe and Ecto integrations assist in monitoring the performance of your application's parsing, querying, and data transformation. They provide clear insights, on an event level, of exactly how your API is responding to requests — enabling you to quickly identify areas where optimizations are needed for specific requests.

Monitoring GraphQL via Absinthe

AppSignal automatically recognizes operations executed by Absinthe and wraps them into a call.graphql event on your Event Timeline, allowing you to see how much time Absinthe spends parsing, querying, and transforming data:

If call.graphql is taking up a large portion of the event timeline, this could indicate it is having trouble parsing a request or transforming data. Often, this is due to deeply nested requests or querying modules that have high levels of relational data.

For example, let's say we have a GraphQL API that returns all courses, exam results, and lecturers for a student. This query requires nesting and several data transformations. If your application is taking a long time to execute GraphQL logic, it may be an indication that you need to take steps such as refactoring resolver logic, data fetching strategies, or implementing caching mechanisms for frequently requested data.

Monitoring Ecto

With AppSignal's Ecto integration, you can see how long it takes for Ecto queries to be executed in your application's requests, displaying them in the Event Timeline.

You can investigate Ecto's performance in slow requests and apply suitable strategies to enhance performance when necessary, such as caching, query optimization, and indexing for large nested data sets. You could also implement pagination, rate, and depth limiting to limit the amount of data requested within reasonable bounds and limit the frequency and complexity of incoming queries.

Get Going with GraphQL and AppSignal

Absinthe and Ecto are automatically instrumented and available in AppSignal 2.7.0 or higher. For Ecto, you need to ensure that the value of :otp_app in your appsignal.exs configuration matches your application's app name.

Once correctly configured, AppSignal will automatically display GraphQL and Ecto events in your Event Timeline, giving you effortless insights into two of your API's most important components.

You can learn more about configuring Absinthe and Ecto in our Elixir integration documentation.

Delve Deeper into Absinthe and Ecto

If you enjoyed this blog post, you'll enjoy some of our recent related blog posts on Absinthe and Ecto:

In the meantime, if you have any questions about AppSignal, please don't hesitate to get in touch! We offer dev-to-dev support, give free accounts to open-source projects, and if you're new to AppSignal, we'll welcome you onboard with a delicious shipment of stroopwafels 🍪 😋

How to Monitor Custom Metrics with AppSignal

Connor — Thu, 04 May 2023 15:01:13 +0000

Setting up custom metrics is an easy way to gain instant insights into the information you need (without sifting through log lines or struggling with complicated reporting tools). Supplement your application's critical monitoring data by tracking meaningful metrics to quickly identify and resolve potential issues.

In this blog post, we'll show you how to set up and use custom metrics to remove your monitoring blind spots. We'll demonstrate how you can use custom metrics alongside our suite of monitoring tools to better understand the performance of your application.

What Are Custom Metrics?

When it comes to metrics, AppSignal by default tracks critical data such as error rates, response times, and throughput. We use these metrics to monitor your application and notify you when your application is experiencing performance issues.

Custom metrics allow you to visualize and track any application data you want, providing deeper insights into your application's performance by relating additional contexts - such as active user counts or job-specific processing times. You can create dashboards in AppSignal to track custom metrics alongside critical metrics such as throughput or database size.

Measuring Your Metrics

When sending your metrics to AppSignal, it's important to consider how you wish to measure them. AppSignal offers three measurement methods:

Measure	Description
Gauge	A number that represents a particular value at a specific point in time that can frequently be overwritten, such as the count of an application's active users.
Counter	A number you can increment by any given value, such as the count of times a process has run.
Distribution	A collection of numbers from which we store an average, count, or percentile. You can use this to track a spread of values in a dataset - for example, the average user cart value of an e-commerce application, or the percentage of background jobs completed within a desired time.

AppSignal provides methods and functions to help you easily track your custom metrics using the appropriate form of measurement.

Let's imagine we're monitoring a webshop. We'll show how you can use gauge, counter, and distribution measurements to track specific data points.

Gauge

For context into why our application may be more or less performant than usual, let's see how many active shoppers are currently using our application. We'll use the gauge measure to report an active user count every time a new user session is created in our application.

To do this, we can create a minutely probe, a mechanism that sends custom metrics to AppSignal periodically. We can use this probe to record how many shopping carts have been updated within the last minute and send this information to AppSignal under the label active_shoppers using the set_gauge method. For example:

Ruby

Appsignal::Minutely.probes.register :active_shoppers_probe, lambda do
  active_carts_count = Carts.where(updated_at: 1.minute.ago..).count
  Appsignal.set_gauge("active_shoppers", active_carts_count)
end

You can read our Ruby documentation for more information on minutely probes.

Elixir

Appsignal.Probes.register(:active_shoppers_probe, fn ->
  query = from(c in Carts,
    where: c.updated_at ^DateTime.utc_now() - (60 * :second),
    select: count(c.id)
  )

  active_carts_count = Repo.one(query)
  Appsignal.set_gauge("active_shoppers", active_carts_count)
end)

You can read our Elixir documentation for more information on minutely probes.

Node.js

const meter = Appsignal.client.metrics();
const probes = meter.probes();

probes.register("activeShoppersProbe", () => {
  const oneMinuteAgo = new Date(Date.now() - 60000);

  // use MongoDB to query carts table
  const activeCartsCount = await Cart.countDocuments({
    updated_at: { $gte: oneMinuteAgo, $lte: Date.now() },
  });

  meter.setGauge("active_shoppers", activeCartsCount);
});

You can read our Node.js documentation for more information on minutely probes.

Once configured, we can create a chart in AppSignal to track how many active shoppers are using our application:

With this information, we are able to quickly infer how our webshop is performing based on the approximate number of people actively using the site. If we notice a particularly high count and anticipate performance issues, we can take measures to ensure our application remains available.

Counter

With counters, we can track how often something happens in our application. This feature is handy in scenarios where you need to monitor the frequency of certain events or actions over time - for example, how many times a user completes an action, like adding an item to their cart.

Let's say we'd like to understand how often our application is invoicing users. To do this, we need to increment our counter each time an invoice is created.

Use the increment_counter method in Ruby and Elixir:

Appsignal.increment_counter("invoice_count", 1)

And the incrementCounter function in Node.js:

const meter = Appsignal.client.metrics();

meter.incrementCounter("invoice_count", 1);

Once set up, we can track how many invoices our application is generating in AppSignal:

What if we track additional related data points, such as orders placed, and notice that our metrics aren't tracking against each other as expected? Then we can investigate our invoicing and ordering logic, and potentially locate and fix critical issues before they impact many of our customers.

Distribution

You can use custom metrics to record data measurements, such as response time or background job duration. Keeping track of such metrics can help you identify poorly performing background jobs or API endpoints, which can negatively impact user experience.

We want to see the average time it takes for our application to run its order confirmation job, as it's vital customers receive this email within minutes of making a purchase.

To do this, we use the add_distribution_value method:

Ruby

start_time = Time.now
Ordering::Confirm.new.run
duration = (Time.now - start_time) * 1000

Appsignal.add_distribution_value("order_confirmation_duration", duration)

Elixir

start_time = :os.system_time(:millisecond)
Ordering.Confirm.run()
duration = :os.system_time(:millisecond) - start_time

Appsignal.add_distribution_value("order_confirmation_duration", duration)

Node.js

const meter = Appsignal.client.metrics();

let confirmOrderStartTime = Date.now();
confirmOrder();
let confirmOrderDuration = Date.now() - confirmOrderStartTime;

meter.addDistributionValue("order_confirmation_duration", confirmOrderDuration);

Once that's done, we can track the average time our confirm order job is taking to complete in AppSignal. We'll notice if it is performing slower than expected before our users do, allowing us to proactively keep our application available and scalable.

Custom Dashboards for Custom Metrics

Thanks to our intuitive UI, you can start tracking your custom metrics in minutes.

You can use the "Add dashboard" button in the Dashboard navigation to create a new dashboard. Click the "Add graph" button to start building your graphs with our Graph Builder.

When creating a graph, you can select which metrics and tags you want to chart and configure your graph's legends and labels. Once that's done, you'll immediately see your graph display current metric data for the specified period of time.

Why Metrics Matter

While logging is a fantastic solution to help you debug and troubleshoot application performance issues after they've occurred, metrics can help you to prevent future issues before your customers notice anything. With custom metrics, you can:

Concentrate on what matters: Track specific data points in your application accurately and get focused insights without filtering through large amounts of logging metadata or incident lists.
Get down to business: Understand your application's performance from a business perspective and quickly track critical data such as active user counts, KPIs, or daily sales.
Streamline your logging: Logging 'everything everywhere all at once' is unsustainable. With custom metrics, you can track essential data efficiently and use your logs to investigate the cause of incidents, only logging data that's necessary for troubleshooting and debugging.
Work proactively, not reactively: Set custom triggers to warn you if your application takes too long to send invoices to users, for example, or is experiencing a higher volume of active users than usual. These warnings allow you to proactively investigate and resolve an issue before it impacts your customers.

Dive Deeper Into Custom Metrics

Ready to get the most out of your application's metrics? This blog post has covered just a small slice of what is possible with custom metrics in AppSignal. Our documentation on custom metrics outlines everything you need to know.

If you need help, have questions about metrics or anything else AppSignal or monitoring related, you can always contact us.

AppSignal: More Than Just an APM Tool

AppSignal's custom metrics are just one of our many developer-driven features that help you to monitor your application. Developers also enjoy using our monitoring because we have:

An intuitive interface that is easy to navigate.
Simple and predictable pricing.
Developer-to-developer support.

If you're new to AppSignal, remember to ask us for some free stroopwafels! They taste almost as good as it feels to have all of your application's metrics at your fingertips 😉🍪

Optimize Your Prisma Queries with AppSignal and OpenTelemetry

Connor — Tue, 25 Apr 2023 13:26:30 +0000

AppSignal integrates seamlessly with Prisma via OpenTelemetry to give you invaluable insights into how your application is performing.

In this blog post, we'll outline how you can use AppSignal to optimize your application's Prisma integration, mitigate inefficient database queries, spot anomalies, and improve your application's scalability.

Benefits of Monitoring Prisma

If your application handles multiple queries to fulfill a single request, it's important you ensure each query performs optimally (especially if your application has deeply nested object structures).

For example, imagine an authored blog post that also allows comments from other authors. This can lead to complex, inefficient, and slow database queries. As more and more people comment on a post, the query to retrieve the blog post and related objects can become unwieldy, negatively impacting your application's performance. Joins and subqueries can further exacerbate the issue and potentially retrieve redundant information.

With AppSignal's Event Timeline, you can identify poorly performing Prisma queries and remedy them before they cause bottlenecks or impact your application's availability as it scales.

Metrics That Matter with AppSignal

AppSignal provides the insights you need to help your application scale, not fail.

Find Timeline Anomalies

AppSignal's Event Timeline provides a clear overview of your application's performance on a request level. It shows what actions are executed by a request.

This example shows how our Event Timeline interprets your application's Prisma OpenTelemetry data:

Micro and Macro Metrics

Clicking on a Prisma event in your event log allows you to delve deeper into your database performance. You can view charts depicting your database's response time and throughput (the number of processed events) when an event occurs.

In the below graphs, multiple requests to view our blog post indicate slow database queries.

You can also see a handy list of other application actions that involve the same event. Use this list to identify where query optimization is needed, spot potential correlations between incidents, and avoid time-consuming debugging sessions.

Sending Prisma Data to AppSignal

Thanks to OpenTelemetry, it's easy to integrate AppSignal and Prisma. First, ensure your application uses Prisma 4.2 or higher and AppSignal for Node 3.0 or higher.

To automatically instrument Prisma with your AppSignal for Node.js package, enable the tracing preview feature in your Prisma schema, as shown below:

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["tracing"]
}

Once instrumented, the Prisma integration sends AppSignal a child span for each query (including child spans for the database connection and serialization process). Each query span shows the query that was performed and how long it took to complete.

AppSignal 💚 OpenTelemetry

Due to our adoption of OpenTelemetry, AppSignal instruments 16 libraries and frameworks out-of-the-box. Get the data you need to effectively and efficiently monitor and optimize your application.

Supported Libraries and Frameworks
Express
Fastify
fs module
GraphQL (Apollo, Yoga)
HTTP/HTTPs module
Knex (Bookshelf)
Koa.js
MongoDB
Mongoose
MySQL
NestJS
Next.js
PostgreSQL
Prisma
Redis
Restify

Try AppSignal and Get Stroopwafels 🍪

We look forward to introducing you to more open source-powered features and framework support in the future!