
The continuation of "experienced trifles." Previous parts:
one ,
two ,
three ,
four ,
five .
In this post I will talk about a small, but in my own interesting experience using the SNMP protocol to collect print statistics in an organization.
In the company in question, they print quite a lot. There are large, powerful printers (such as the HP 9000) and medium-sized ones, and very much Home class. Fortunately, they are all networked, and the range of manufacturers is narrow, only two: HP and Ricoh (in different guises, from NRG to MB). And then one fine spring day, looking at the accounts for the office, the careful management was given the task: to regularly collect print statistics,
“so that they could be analyzed later” . And they didn’t bother much:
“All printers are networked, they have a statistics page, in the morning they got around by a list, recorded digits in Excel, that's all - business !
”')
Naturally, in our opinion, it was uninteresting, stupid and "tiring", because There are a lot of printers in the organization. And we began to think "how to make it work itself." In general, it seems to me that this desire (“so that it works itself”) is key and necessary for each system administrator, and those who succeed over and over again always make me feel good, white envy.
With the move rejecting the web page parsers (this is wrong, and, for example, Ricoh pages were dynamic, there was no hard URL where to go), we turned to the good old SNMP. And that's what came out of it.
Here you should probably make a small digression for those for whom the abbreviation SNMP does not mean anything yet. Gentlemen, you are missing a lot! I urgently recommend that you spend the evening different and study the question at least at a basic level. In short, SNMP is a management and monitoring protocol based on UDP. The overwhelming majority of devices (if not all) that have a network interface support this protocol and allow using it not only to collect data on the operation of the device, but also to control the device itself. Data (objects) that are available via the SNMP protocol, the so-called OIDs are organized hierarchically. On the domestic plan, this means that if you ask the device for the OID value with a “number” .1.3.6.1.4.1.11, the device will respond and transmit this value. And knowing which OID corresponds to the value we need, you can write a small script that will poll the devices and collect their answers into the database. You can interrogate devices, for example, with the help of these wonderful and free
utilities . Looking ahead, I’ll say that
Snmpget and
SnmpWalk were useful in our particular case.
The algorithm as a whole was clear, the utilities were at hand, the only thing left was to understand which OIDs mean what we need: a counter of printed pages. Full description of device variables, so-called. MIB-base is quite difficult to find (you can try to search
here ), but you can go the other way.
With the help of the
SnmpWalk utility, once having interrogated the device, you get ALL the OID from it with their values, which it is able to issue. For our part, we clearly know what exactly the VALUES we need (after all, we can find out their current status on the web page). Next is the case for small:
- We assemble a complete device map into a text file using SnmpWalk .
- We learn via the web interface the current number of printed pages that we need
- We are looking for the number of printed pages in the file, and thus find out the OID code.
- Use the received OID in our script.

A few notes
- Each manufacturer in the same type of device almost always adheres to a single MIB structure. Accordingly, the OID number corresponding to, for example, the Total Pages Number counter will be the same for all HP printers (with rare exceptions). This allows you to write a "survey template", which will correspond to many printers from the same manufacturer.
- Sometimes in the process of analyzing a snmpwalk file there are several desired values. Here you can either print another page and, once again collecting data, determine which OID contains the counter we need, or simply choose a little thought logically (remember the hierarchy of the structure!).
- Some printers do not show certain counters on a web page, however, they allow them to be collected via SNMP. For example, on a web page there is only Total page count, but with the help of SNMP you can get more detailed values (duplex, A3, number of “print requests”, etc.)
- It is better to collect data right away somewhere in the database "for further analysis." In our case, at the insistence of business executives, I wrote everything into a text file, which was then automatically opened in Excel, and decomposed into cells using a macro. Business executives were easier to work with Excel than with SQL, but I personally didn’t mind.
- With the help of this simple method for several months we have built quite good print statistics in the company, it is reasonable, with the numbers on hand we got the budget for more powerful printers in a number of departments, and found out the relationship with the company of the cartridge refiner, when it turned out that a number of their products 15,000 pages gives out at a single charge of 6000.
As a bonus, I will cite the text of the
script , the
Excel macro, and give a few explanations:
- At the beginning of the script code, the settings are described (a pool of IP addresses of the equipment, and polling templates).
- despite the fact that manufacturers usually have a single MIB structure, in some cases, equipment of a different class still has different OIDs for the same data (for example, for HP printers below 2XXX OID series for obtaining a serial number - one and above - another .
- for more powerful printers, we collect not only TotalPagesCount, but also all sorts of other counters (copier, A3, duplex, etc.)
- HP has such a concept TotalpagesCountEquivalent - this is the number of exactly the printed pages, i.e. completely passed along the printing path. While just TotalPagesCount for HP is the number of sheets taken from the paper feeder. The difference between them is actually equal to the jams.
- the script collects the serial numbers of the printers so that they can then bind to them in Excel, as well as the IP, the date and the network name - this is just so for clarity.
- at the end, the script starts the Excel file next to it, which, in turn, when opened, launches a macro, which already scatters everything. Quite a messy system, but this is the result of the division of labor, because I wanted naked data from me, but we will write “analytics ourselves”. So they wrote. In it, I will not be able to explain something in detail, but I will try.
- The macro works like this: opens a file with statistics, takes all the data from it, copies statistics numbers to the required columns of the table, attaches to the serial number of the equipment, renames today's statistics file to * .bak, closes Excel.
- The macro had to be signed with an internal certificate, since I didn’t want to disable macro security in Excel, and without this, the macro will not automatically start. And, by the way, it was a natural quest, because how and what to sign the macro, neither I nor its authors at that time had a clue :)
To
be continued