Friday, December 9, 2011

Monitoring - Our Basic Principles

So, we decided we'd create our own monitoring tool, to consolidate our monitoring of various systems in one convenient location and to allow our team to be more proactive rather than reactive. I am no expert in this field and as in my current gig -this has been the first time I received the responsibility for maintaining large scale distributed apps (ERP packages, which I worked with before are much simpler).

We had some very simple design goals. What we did not wish to do, was to spend time creating an application from scratch and getting into very complex monitoring scenarios in which we would have to manage an in-house monster. Our desire was to monitor for the 20% most common failures that were causing the 80% of the headaches. This being our idea, I took some time to talk to our OAS app specialist, who outlined the symptoms of the most common failures and how clients see these failures reflected in specific reports. On his suggestion, we decided that the simplest policy would be to monitor specific reports which let you know whether specific components have failed.

So what reports would we look at and what would it tell us?*

  1. Site - Day of Month Delivery Information --> Are base transformers running?
  2. Site - Hour of Day Delivery Information --> Are the base transformers running in real-time?
  3. Site - Browser Delivery Information -> Because information summary tables are dependent on Nightly execution (one phase at least), looking at this report for the current day can give us hints of whether Nightly executed or not -it could execute partially, but we are only doing a general health check.
  4. Inventory - Site Detail Forecast --> Like the previous report, this also gives us clues about Nightly's execution
  5. Reach & Frequency - Site Reach by Date --> Are UV transformers running?
  6. Last RLC --> Failure in RLC can have many causes, so it is just a good place to monitor.
*Bear in mind that we are aware that most of the monitoring can be done with tools such as Nagios. However, our situation is we do not have access to our client's monitoring tools and we have many environments to monitor.
This monitoring that we are doing allows us to get a sense of whether all is fine, using more "junior" staff, if there are problems we then escalate. This saves us valuable time! In our tool, we also decided to collect information from other sources (non-API).

Thursday, December 8, 2011

Monitoring tool using the API

Looooong time no post! Was extremely busy with projects and issues here at work. However, I am extremely excited about a project I developed with help from a work buddy.

A little background, we have about 15 clients that have their box installation of OAS (with over 200 servers). We have an extremely compact team, relative to the size of our clients and yet we are responsible for maintaining proper functioning of all these servers. OAS does offer some rich set of monitoring options which send e-mails, that gives status updates on key components, but our experience has been that receiving around 100-150 e-mails a day has caused overload and made this type of monitoring not too effective.

We decided to create a very simple monitoring system, looking at OAS from the client perspective and making our frontend team responsible for proactive support -and they are much larger in number.

In my next few posts I will outline our concept as well as upload the tool and code.

Saturday, September 10, 2011

The OAS AdXML Kit: What is it for, how to install & use

I have developed a simple DLL, to facilitate code development in Excel. Without this component it would be necessary to write some extra code in Excel to develop our examples. As I have mentioned before, I am trying to avoid focusing too much on code (but we will need quite a bit) and focus more on getting results -this is really what matters. The DLL is available through SourceForge (click here to download) and the installation follows a standard Windows installation routine. I will make the source code of this DLL available through GitHub, for those who prefer to see what is under the hood.

Once it is installed, it is quite simple to activate for use in VBA (MS-Office macro language). You will, in VBA screen, click on Tools > References and select OAS Integration Module as in the image below.


This will allow you to reference the OAS API by simply creating an object. An example of this follows, using VBA;



The worksheet associated with the code.

PHP code for automatic RLC

As a curiosity, I developed the following code to execute RLC. In terms of process, the main way I use it, is after I have executed all modifications to my campaigns I execute this code for RLC.



Monday, August 15, 2011

MS-Excel: Defending my choice

The examples I have outlined (see old post) have opted to develop using primarily Excel + VBA (we will use some PHP as well). Some of you may cringe at this choice -given that many in this industry are proficient in languages such as PHP, Ruby and Java... But my reasoning is simply that I wanted to develop examples using a tool that is available to most end-users.

Also this is not really a blog about coding, but more about showing with practical examples what can be done with OAS API. Additionally, Excel will allow us to avoid side issues such as some basic math -which we will not have to code for, we can simply use the spreadsheet. To avoid a lot of overhead in learning how to use SOAP through Excel, I have made available through SourceForge (link) a DLL which should facilitate access to the API.

Wednesday, July 27, 2011

Let's get started!

To get started we have to create our API user... I could bore you to death with a text explanation, but I have decided instead to post a YouTube video (much easier!)


This is really the easiest [booooring!] part, but if you have difficulties write me, I will try to help. The next step is for us to

Sunday, July 24, 2011

So, what exactly can we do with the OAS API?

Lots, sky is the limit! This is the short answer, but let's get into specifics. My idea here is to give some of the interesting macro areas I have identified as very promising (added value) and then in the following posts we will work through developing these examples.

Which areas are interesting to extend OAS?
  1. Operational Improvements;
    • Traffic Automation
    • Client Self-Service Pages
  2. Process Improvements;
    • Integrate Billing Information
    • Integrate with Sales Process
  3. Ad Operations Enhancements
    • Advanced Inventory Management
    • Automatic Campaign Optimizations
    • Automatic Offload of Excess Inventory
  4. Back-end Process Improvements
    • Systems Resizing Monitor
    • Automatic RLC execution
Maybe not all that I have written is self-explanatory, do not worry we will develop these with examples. The idea is to do basic code to demonstrate these concepts, which could later be developed into full products.

Friday, July 22, 2011

Motivations for this Blog

As an IT professional I have greatly benefited from the Internet. If I were to tally up the countless hours of "free" consulting I have received over the years, well, the bill would be probably be a very scary number! So this is in part about giving back to the community.

But this is not just about the latter, it is also about two subjects that really excite me, software integration, which I have worked with most of my professional life and about leveraging the OpenAdStream (OAS), my current gig. My job does put me in contact with quite large number of content publishers in Latin America and I always come away with a sense that there is so much more that can be done with this software, especially through the use of the API. So this blog is in part about collaborating with other professionals to achieve excellence in the use of OAS.

So... Cheers! Here's to hoping for a very fruitful collaboration.