What's up with Appchkr?

Today Appchkr release 1.20 was published on the website.  This release contains the new Appchkr type "Inetchkr" to track performance of various paths thru the public Internet.  Performance here means connect time latency primarily, with uptime a secondary factor.  Since this release represents a significant step up in functionality the release number has been jumped from 1.10 to 1.20, with the intervening release numbers left unused, as is done for all such releases.

 

Internet performance tracking uses many of the native features of the leading Appchkr types, with a couple small changes, and one very significant addition:  A selection of pre-configured cfg files covering all the major areas of the Earth is being provided to get new users tracking immediately, without effort.  Selection of the targets for these files requires some thought and testing. To assess a geographical area the targets should be as uniformly distributed throughout that area as possible.  From a practical standpoint this means selecting the major cities in that area, as uniformly distributed as feasible.  In addition the targets should be ones whose server(s) are at a single point, or several very nearby points, so as to define a single shortest path from that Inetchkr to the target.  Large organizations have servers and DNS distributed throughout the area they serve so that no client has to wait long for a response.  Good for them and their users but this arrangement generally makes them unsuitable as targets.  Even though headquarters may be at a defined physical point on the Earth their Internet presence is spread throughout. 

So choosing a site with a presence at only one point or a few close by is the important second step.  This supposition can then be tested by checking DNS records, whois, and traceroute for each selected site.  Although one or the other of these may be partially or totally blocked the others can help to work around that.

The third factor is to use sites with sufficient power to well tolerate the additional load of the performance polling packets, and to have a very high uptime and stable latency. This requirement implies selecting sites from what might be termed the second tier of the Internet:  Those which are large and powerful enough, but not so large as to need and use a distributed server/DNS system.  In a sense this translates into targeting sites of sizeable organizations whose focus is primarily local rather than regional or global, such as a city government (but avoiding any distributed travel promotion site of the city. These may sometimes be handled by separate organizations.)

These are the considerations going into the creation of those pre-configured cfg files, which will be ongoing thru the next several releases.   One world-wide file of 10 tracking targets for free mode starts things off in this release and will help refine the selection concepts by actual use and testing over the next few weeks.  

Of course there is nothing that requires the performance tracking to attempt to cover any specific geographic area.  That is simply a convenient starting point.  It could just as well target any group of endpoints desired, on either the public Internet or on any private network using IP/TCP. 

And likewise it needn't use only web sites.  They happen to be a convenient starting point as well.  Any Appchkr checkable endpoint can be used for one, many or all endpoints in a tracking cfg file.  The key factor is just high uptime and low latency variation of that endpoint.

Some users may have a bit of difficulty finding the SMTP or 'send' URL of the mailserver that hosts the 'mailfrom' account they wish to use for alerting in their Appchkr.   We're adding a simple, quick aid to solve this problem for those users.  All it needs is the email address of the account.  This feature then searches all the likely URLs for that account and prints out the correct ones for the user, for easy copying into the cfg file.  It uses the native capabilities of Appchkrs so runs relatively quickly and smoothly, either from the commandline or the User Web Interface.  Unusual SMTP URLs will still have to be to ferreted out in others ways, but fortunately, with recent trends on the Internet, the use of non-standard naming is becoming rare.  This little boost, coming out in release 1.04 shortly, should help speed setup for those for whom this would otherwise have been a stumbling block.  If you have been trying unsuccessfully to crack this nut for a prior release update your Appchkr with the chkr_update_1.04 file from http://www.appchkr.com/download-chkr.html and run the search .  And, needless to say, this new function will work for any reason that you need to find an SMTP URL from an email address, not just for configuring an Appchkr.   :-)   Happy checking, and, as always, comments are welcome. 

Release 1.01, just out today, upgrades connect time logging to the millisecond/microsecond level and adds connect time latency alerting and reporting based on this new level of detail.  As a major functionality addition the release number has been bumped to 1.01 from the previous release of 0.91.   Releases 0.92-1.00 have been skipped. 

Warning alerts at both the absolute time level and % increase level have been incorporated with minimum fuss to accommodate the wide range of connect times possible among Appchkr users.  There is the usual wide range of flexibility provided by Appchkrs for special cases.

The Latency Summary report gives a quick, simple, one-page text summary across all connecting targets.  A Latency History graphical report similar to the Uptime History report is in the works and should appear sometime in the next few releases.  Adding a latency spike alert in the near future is also under consideration due to a few such events observed during testing.   We welcome your comments on these plans, as well as in any other areas.     

The Uptime History Report, alluded to in an earlier post, is now available as part of release 0.90, just out.  This is a graphical report intended to be used interactively to zero in on areas of downtime of interest for rapid troubleshooting.   It makes it possible to quickly establish that there is a pattern of repeated downtime at a uniform interval for a target or group, or that simultaneous downtime is occurring on some set of targets, suggesting a common cause, among many other possible uses.   There is one up/down histogram per target or group with a common time scale, and with multiple targets on one page.  One simply narrows the time period around an area of interest to expand the scale and see more detail, until the question at hand is answered by the graphs, in almost no time.  The raw data for the report is updated in realtime, like all the other Appchkr reports, so the uptime history can also be followed graphically in realtime if desired. 

This report, and the raw data file it uses, are a substantial addition to Appchkr functionality, so the release number has been bumped from 0.82 to 0.90 to reflect that fact.   Releases 0.83 - 0.89 have been skipped.   The report and raw data file are available in the three leading Appchkr types (appchkr, networkchkr, and serverchkr), but not in the five specialty types.  As always, any Appchkr type may easily be upgraded to a higher type, at any time, with little effort.

Having the file of the raw uptime data also makes it possible to keep long term uptime records in a database or file if desired.  Custom uptime/downtime reports can also be generated from the file using spreadsheets or other reporting programs.  The details of the raw data format are given in the 'Advanced' part of the Appchkr documentation incorporated into the release, under the topic 'Uptime Raw Data Format'. 

The report can be run from either the command line or the User Web Interface (UWI) or both, like almost all of Appchkr.   This version does not handle AlertOnUp targets ideally though, but the fix for that has been postponed since those are rather uncommon.  It can be fixed in the future if there is enough demand, along with a few other minor enhancements that are under consideration.  Let us know your preferences.   :-)

Integrating any Appchkr with either Slack or PagerDuty is quick and simple.  Both of these apps will accept alert emails from an Appchkr and act upon them.  The details are outlined in the Appchkrs Knowledge Base topics on Slack Integration and PagerDuty Integration in release 0.90, to come later.  Access the Appchkr Knowledge Base with the -kb option at the command line or from the 'Info' menu in the User Web Interface (UWI) in the installed program. The general idea in both cases is simply to tell those apps what you want them to do with the alert, and to create an email address in the app for the alerts to be sent to.  Then you  enter that email address as a receipient into one or more of the pertinent email address lists in your Appchkr cfg file.   That's really all there is too it.  Take those two steps and you're all done.  

The PagerDuty configuration can be a little more involved than that for Slack since there are more possible actions.  Some of these possibilities involve regular expressions to be applied against the Appchkr emails.  If you reach that point and want some help with creating those regexs let us know with a comment here, or in the support forum.  We'll be happy to offer some possibilities and to make them available to all users.  Let us know with a comment here if there are other integrations with other apps that you'd like to have, to help get more value out of your Appchkr. 

Work is advancing for the next release, 0.80, which should be out soon.  We're adding the ability to put in a custom title and subtitle for the status and uptime summary report pages so that those who wish can display these pages directly to the public, with their own brand at the top.  There seems to be a growing trend to do this, particularly for server monitoring, to build public confidence in a site a bit, and perhaps, incidentally, to reduce support calls and questions as to whether a site is up or down.    Both good things, and certainly well worth having in the more advanced Appchkrs.   The group reports are included - all four reports will have this. 

Later we'll add a some more sizzle by providing an html template to frame the reports, the ability to put logos and other images into it,  and for some degree of reformatting of the data, for an even greater level of customization and branding.   The self-refreshing branded reports served up by the UWI should ultimately provide practically everything that could be imagined and needed in this area. 

The other major thing going on is the addition of an interactive uptime history report.  This report will greatly aid and speed detecting and diagnosing recurring downtime incidents.  The interactive feature will help drilling down from a broad view to specific brief incidents in a narrow time frame.   The first stage of this report may make it into 0.80.  If not, then one of the releases shortly after that.    As with the branding it will take several releases to build the full level of functionality. 

We welcome your comments on these plans, as well as any others you'd like to contribute.