In AppView you define your application in terms of three essential elements which together describe how the world sees your app. They are: an endpoint; a series of actions to perform at the endpoint; and a location from which users access the endpoint and perform those actions. Select one or more of each of those elements for any given app. AppView will then generate all of the unique combinations of those three elements, and set up monitoring for each. The end result is that your AppView monitoring coverage will extend across all of your service instances and your geographically distributed user base. From there you’ll want to set up alerts so that you can passively monitor your applications, during non-business hours for example; and you’ll want to set up dashboards so you can watch application performance in real time. Finally, after establishing a baseline for performance, you might want to adjust your apdex thresholds.

  1. Address the prerequisites
  2. Assign licenses
  3. Set appliance locations
  4. Choose your global locations
  5. Add a wireless network interface
  6. Define a web app
  7. Script user actions
  8. Set up AppView alerts
    1. Applying a profile
  9. Update your notification profile
    1. SNMP notification
  10. Create a web dashboard
  11. Customize apdex thresholds

Address the prerequisites

Every AppNeta module has specific port and protocol requirements. Your appliance may have been set up with one of the other modules in mind, double-check that your firewall rules have been adjusted for AppView.

Adjust your firewall rules for AppView…

Assign licenses

To gain access to AppView you must have at least one appliance licensed for AppView (or a global location, which we’ll cover later). The quickest way to check this is by clicking on AppView in the left-side navigation panel: if you see a splash page with a blue ‘+web app’ button, you have at least one licensed appliance.

The other thing you need to know is that only appliances licensed for AppView can be monitoring locations. You want to make sure that you employ all of the appliances at your disposal so that at the end of deployment you have the most complete coverage of your user base.

All that said, regardless of whether you currently have access to AppView, make sure that all of the available AppView license have been assigned.

Assign licenses now…

Set appliance locations

AppView is designed to monitor the selected endpoints from multiple remote locations, which collectively should represent the geographic distribution of your user base. Setting the appliance location will help you set up monitoring correctly, and also interpret the data that AppView collects.

Set the appliance location now…

Choose your global locations

AppView Global subscribers have access to cloud-based appliances that we’ve deployed around the world so that you can monitor your web apps from places where you have users but nowhere to install an appliance. We should have already provisioned your organization with the number of licenses you purchased, so all that remains is for you to select which locations you want. To do this, click the green ‘+ global web monitor’ button. From there, simply check the location you want and the number of web monitors you want in that location. Notice the web monitor count at the bottom of the pop-over.

Every AppNeta subscription includes a free 14-day trial for one web monitor in any AppView Global location. Click the green button. From there you’ll be prompted to start your trial, and then choose a location. That location will become available to you immediately.

Add a wireless network interface

The wireless interface on the m25 and m35 can be used for AppView. You’ll need to create and configure the wireless interface. Apart from those instructions, there’s one other thing that’ll be useful when you get around to defining your first web app, which is discovering the IP address of the default interface.

  1. Find the name of the default interface by plugging the appliance hostname into this url, then under the interface resource open GET /interface/{interface_name}/.
  2. Enter ‘default’ as the interface name, and click submit.
  3. Look in the response body for the name of the default interface, it’s likely ‘eth0’.
  4. Enter the name of the default interface in the interface name field and click submit again.
  5. Note the IP address that’s returned.

Define a web app

In AppView you define your application in terms of three essential elements which together describe how the world sees your app. They are: an endpoint; a series of actions to perform at the endpoint; and a location from which users access the endpoint and perform those actions. Select one or more of each of those elements for any given app. AppView will then generate all of the unique combinations of those three elements, and set up monitoring for each. The end result is that your AppView monitoring coverage will extend across all of your service instances and your geographically distributed user base.

To define a new application:

  1. If you have global web monitor licenses, click the green ‘+ global web monitor’ button to choose your locations. If you want global web monitors but don’t have any, this same button will prompt you to start a trial.
  2. Navigate to web applications and click ‘+ web app’.
  3. Choose custom from the drop-down. All options other than ‘custom’ are deprecated.
  4. Enter one or more locations, targets, and actions.

    1. Where do you want to monitor from?—Choose an appliance based on its location. If you haven’t already, set appliance locations. If you want monitoring traffic to go through a web proxy, this where you set the proxy details.
    2. Which url do you want to monitor?—You can enter more than one url if you want to monitor multiple instances serving the same app.
    3. For user actions, see the next step.

Selenium—Not all locations support Selenium. AppView prevents you from creating unsupported combinations of location + language by either limiting your location choices or preventing you from selecting Selenium.

Script user actions

AppView is all about your end users, and they don’t just stop after hitting the endpoint: they log in, click links, search, etc. AppNeta lets you test how well your application responds to a series of user actions like these using a script. You’ll use a Firefox plug-in to record the base script, inevitably there’ll be some troubleshooting involved, then finally, you’ll logically divide your script into sections called ‘milestones’. AppNeta will return timing data, alerts, and an apdex score for both the web path and each milestone so that you know exactly when and which actions are holding things up.

Two scripting languages are supported: AppNeta and Selenium. While AppView currently supports mixing and matching both types of scripts within the same app definition, we encourage you to create all new scripts in Selenium if your monitoring point supports it. Currently Selenium is supported only on global monitoring points.

Script in either the AppNeta language or Selenium

Set up AppView alerts

An alert profile is a set of thresholds used to evaluate continuous monitoring results. They can be applied to an entire transaction and/or its individual milestones. Anytime a threshold is crossed, AppView marks the event on the time axis and logs it in the event log. You can receive emails if your notification profile has ‘path violation events’ enabled, and snmp traps if that’s enabled.

AppView has several system-defined profiles or you can create your own. Navigate to > manage alerts > web alerts. From there, click each template to see the conditions it contains. Alert profiles are comprised of one or more conditions which generally follow the format ‘condition A violates if B is present for C tests, and clears if B is not present for D tests.’ You can see that the basic components are a violation clause, a clear clause, and an evaluation period. The violation clause describes poor performance, the clear clause describes acceptable performance, and the evaluation period confirms that the condition is persistent before declaring violation or clear event. If you’d like to create your own custom alert profile.

Connectivity
AppView cannot obtain any http status from the web path target.
HTTP status
The web path target returns an http status code other than the value specified.
HTTP errors
The web path target returns an http status code between 400 and 505, inclusive.
Script errors
AppView returned an error because a scripted transaction did not run to completion.
Total time
The entire test or specific milestone takes longer than the specified amount of time.
Apdex
The minimum tolerable apdex score for the test, not the web app.

Setting good alert thresholds: What should your total time/threshold be? Let AppView run for a bit to establish a baseline and then set your thresholds around that. Read more…

Applying a profile

Alert profiles are applied to scripts rather than the web app itself. From AppView > web applications, click ‘configure’ for the web app you want to edit, and then select the script that you want to apply the alert profile against. You can apply a profile to the entire transaction, and/or one to each milestone:

Overall
A violation event occurs if any milestone violates any condition in either its profile or the overall profile, with one exception: a total time condition in the overall profile applies only to the to the sum of all milestones.
Milestone X
A violation event occurs if a milestone violates any condition in its profile, including a total time condition if one is included.

If an alert profile is applied, status icons are used throughout AppView to tell you at a glance something about the current state of the web monitor, including when it is currently in violation. is OK and is violation. Alert threshold violations and clears are also logged as events on the test timeline page and in the event log.

  • Events are marked on the time axis of the end user experience chart: a red diamond indicates a condition violated; a green diamond indicates the condition cleared.
  • Events are logged. Navigate to AppView > events to display all web monitor events for all web monitors in an organization; click on the events tab on the test timeline page to display events for a particular web monitor.
  • Events trigger notifications based on your notification profile.

Overloaded appliances: Missing data, grey charts, or purple diamonds could be symptomatic of an overloaded appliance. Read more…

Update your notification profile

Event notices are emails about changes in appliance availability and app performance. The set of rules which determine when notices are generated and sent are called profiles. There is a default profile which applies to all paths, but you can add exceptions to it by creating additional profiles. Within a profile you can specify the organization, paths, and events that trigger notices; the addresses to which notices are sent; and the frequency of notices.

  1. Navigate to > update notification options.
  2. ‘Default email addresses’—applies to all profiles that don’t have their own address list. Click the email address link to edit the default list.
  3. ‘Enable service bulletins’—Support occasionally needs to send service related emails. Emails are sent to the default addresses specified in your account settings.
  4. For profiles that should not use the default list, add addresses through the profile action menu.
  5. The following events can be selected to trigger a notification. If you choose ‘digest summary’, all notices triggered during the digest period are aggregated into a single email, so that addressees receive fewer emails.

    Violation event
    Notices are triggered by alert threshold violation and clear events. Notifications are triggered based on path violation events in PathView and AppView.
    Appliance availability
    Notices are triggered whenever the appliance loses its connection or reconnects to AppNeta . For time windows, enter times according to appliance timezone.

SNMP notification

You can configure appliances to generate SNMP traps upon violation and clear events from > manage SNMP. Traps are generated for all paths in the organization, but only one appliance is responsible for sending the traps to the NMS. The appliance designated the ‘trap sender’, must have an SNMP trap license. Appliances with an SNMP NMS license may be polled for violation events in the last 15 minutes. Only violations on paths for which the appliance is the source are reported; the associated objects are in the ‘pathview’ table of the MIB. The default community string is ‘public’; this can be changed from web admin.

Beta feature: PagerDuty is a popular tool used by teams to centrally manage alerts from multiple services and systems. You can optionally integrate AppNeta with PagerDuty so that our alerts can also be managed from there. Open a support ticket if you’d like us to enable this feature.

Create a web dashboard

Too many apps on your web applications page? An application dashboard is a custom view of just the apps you’re interested in. They offer the same at-a-glance insight into app health, but in a form that helps you and your team stay focused. Dashboards are updated in real-time so you can pin this browser tab and have updates roll in while you work.

  1. Create your dashboard by clicking ‘create dashboard’ on the dashboards page. If you don’t yet have any dashboards, you will get a brief text introduction to dashboards, but the button will be the same.
  2. Name your dashboard. Give it a meaningful name, and press ‘enter’ to commit.
  3. Add an app by clicking ‘add an app’.
  4. Define the app. In the context of the dashboard, an app is a combination of an AppView application and one of its user actions. Select an application, and then a user action associated with that application.
  5. Select web monitors. All web monitors associated with that combination of application and user action will be listed. Deselect any you don’t want displayed on the dashboard.
  6. Complete dashboard creation. Return to the top of the page and click ‘Done’. You will be taken to your completed dashboard.

    A
    When you go to the web dashboard, you will be taken to the last dashboard you selected via this dropdown. The dropdown is populated by all dashboards in your org.
    B
    Each application on the dashboard is a combination of a web app and one of its user actions. Choose these combinations when creating or editing your dashboard.
    C
    The apdex is based on current scores and will not change based on the zoom level.
    D
    The number next to the graph indicates the average time it takes to complete the selected user action during the time range shown.
    Service quality history
    The color of the bar under the graph is determined by the worst status from among the app’s web monitors, provided at least 5% are in that status for the given time slice.
    Script completion time
    From worst to best: disabled, failed, connectivity loss, violated, OK.

appview-dashboard.png

Customize apdex thresholds

Apdex is an industry-standard method for reporting and comparing application performance in terms of end user experience. Apdex uses a simple formula to represent user satisfaction as a single number, your Apdex ‘score’, which AppView returns as an easy-to-read, color-coded percentage.

Apdext = (Satisfied Count + Tolerating Count / 2) / Total Samples

In AppView, ‘count’ is the number of milestones that can be classified as ‘satisfied’ or ‘tolerating’ based on the time they take to complete. Apdex scores always represent the time period over which the samples were collected, as indicated by the subscript ‘t’, and in AppView, the sample period is 2 hours. This means that every Apdex score you see is calculated based on milestone completion times from the last two hours. Apdex scores are calculated for every milestone, web monitor, and web application. Let’s run through each one:

Milestone Apdex
On the ‘edit user actions’ page you’ll see ‘apdex thresholds’ which by default states: ‘The user is satisfied when a milestone completes in 4 seconds or under, and will tolerate completion times 16 seconds or over.’ These thresholds will be applied to each milestone in the script unless you select ‘per milestone’. You might want to do this if your milestones prove to take significantly different amounts of time to complete. Notice that the value of tolerating is 4 times the value of satisfied; the Apdex formula assumes this ratio, keep this in mind if you decide to customize your thresholds. So to calculate the Apdex score for a milestone, collect its completion times from all transactions within the last 2 hours, categorize each of them into ‘satisfied’ or ‘tolerating’, ignore any ‘unsatisfied’, and then compute the Apdex score using the formula above.
Web monitor Apdex
To calculate the Apdex score for a web monitor, collect the completion times for each milestone from all transactions within the last 2 hours, categorize each of them into ‘satisfied’ or ‘tolerating’, ignore any ‘unsatisfied’, and then compute the Apdex score using the formula above.
Web app Apdex
To calculate the Apdex score for a web app, collect the completion times for each milestone from all transactions within the last 2 hours for all paths in the application definition, categorize each of them into ‘satisfied’ or ‘tolerating’, ignore any ‘unsatisfied’, and then compute the Apdex score using the formula above.

Setting good apdex thresholds: There’s no one-size-fits-all for setting thresholds, but here are a few tips.