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.

About this post

Posted: 2016-11-16
By: dwirch
Viewed: 1,763 times

Comments

No comments have been added for this post.

You must be logged in to make a comment.