PSMetrics Part 3: A simple ASP ingestor

Welcome to part 3 in the PSMetrics series. In this part, I’ll be building a simple ingestor to receive and process data from the collectors, and send the data on to the database.

For the code on this, I’ll be using classic ASP. Why? Because that is what I know. If you are more of a .Net person, or even a PHP connoisseur, this basic chunk of code can be translated very easily. The five things that are happening in this script are:

• Create database connectivity
• Set defaults
• Retrieve inbound values from collector
• Process/validate inbound values
• Send to database

This code will be running on an IIS 10 webserver, on Windows 2016. If you are using this code directly, you’ll need to enable classic ASP on your IIS server before using these snippets. Also, be sure to watch for line wrap on these snippets. Some of them are a little long!

The first section of the script will set up our database connectivity. In this example, I am reusing a MS SQL server in my lab, but you can just as easily use MySQL, with some minor twiddling of the SQL string.

CFG_Conn="Driver={SQL Server};Server=sqllab01.psmetricslab.local;Database=PostMet;Uid=PostMet;Pwd=P@$$Word;"
Set objConn = server.CreateObject("ADODB.Connection")
objConn.ConnectionString=CFG_Conn

Next, default values will be defined. For this example, there is only one default I want to set, ErrorOccurred. This is a simple boolean value (0 or 1) that tells an If/Then comparison if an error has occurred with the values.

ErrorOccurred=0

Now the grab the values from the collector.  The PowerShell collector is simply making an HTTP post to our ASP page, utilizing a querystring to pass the values. Since spaces are included in the timestamp, some modification is also needed to convert the HTML code for space (%20) to an actual space.

Tree=trim(request.querystring("tree"))
SubTree=trim(request.querystring("subtree"))
Metric=trim(request.querystring("metric"))
CValue=trim(request.querystring("cvalue"))
TimeStamp=trim(request.querystring("ts"))
TimeStamp=Replace(TimeStamp,"%20","")

As I have mentioned, this is a basic script. So here is basic error checking.  All that is going on here is checking to see if the retrieved variables do indeed contain values. This can be expanded upon greatly.  For example, you could assign a different value for each error, so you could report back what exactly was wrong.

if Len(Tree)=0 or Len(SubTree)=0 or Len(Metric)=0 or Len(CValue)=0 or len(timestamp)=0 then
 ErrorOccurred=1
end if

Now some action. If all the variables contain values, this is where we poke them into the database. We need to do one more massage to the data, though, in that the actualy counter value needs to be converted from a string to a double precision numeric value. The database doesn’t like it when you try to put a string into a numeric field!

Next, through the magic of string concatenation, the SQL string is put together, the connection is opened, the string is executed, and the connection is closed.

As this sits, there could stand to be some error checking on the database operation. I am claiming Alpha/debugging mode for this script however, since I want to see all the errors. Anyway, this assumes the data was successfully written to the database, and simply returnes success to the remote end.

If ErrorOccurred=0 then
 dblValue=cdbl(CValue)
 strSQL="insert into tblmain (tree,subtree,metric,cvalue,datestamp) values('" & Tree & "','" & SubTree & "','" & Metric & "'," & CValue & ",'" & TimeStamp & "')"
 objConn.Open
 objConn.Execute(strSQL)
 objConn.close
 response.write "success"
else
 response.write "error - check IIS logs for complete error information"
end if

The tail end of the script, or the second half of the If/Then test, simply displays an error message if there are missing fields. It also invites you to review the IIS logs for complete info.

Short, simple, and to the point. This receives the data from the collectors, checks for presence of data, and sends it off to the database. I envision that the final version will look a little closer at the data, and give more meaningful responses. Perhaps better logging as well.

Stay tuned for Part 4, where the database definition is defined and explained.