Written by Douglas McPherson
Solutions Consultant at Juniper
This is part 5 of 6 of On-Box Storage.
Previous Article: On-Box Storage: Option 3 - Utility MIB as a Data Store
Next Article: On-Box Storage: Choosing a Solution
This applies to SLAX version 1.0 and higher.
Description
Suppose that your script needs to keep a local history of some counter or gauge over time – possibly with the intent of “peeking” into it for some local analysis, or maybe eventually exporting it off-box so that it can be imported into another application. This is precisely the function that JUNOS accounting files provide.
JUNOS accounting files allow you to save (and read) data on-box using a CSV (comma-separated value) format. The JUNOS accounting file format includes the data that you put there plus special “layout” lines which describe the fields for your records. Each accounting file record begins with 2 fields: the layout name (which identifies your record layout) and a timestamp. Any fields after that are the fields that you list in your “layout” record, separated by commas. With this approach, a single JUNOS accounting file can contain multiple data layouts. For example, while all the records in a given accounting file may contain “interface” data, the records in the file may co-mingle interface “counter” layout records with “rate” layout records for the same interfaces.
JUNOS accounting files are defined in the JUNOS configuration in the accounting-options stanza. There you can specify the file name as well as the parameters that JUNOS applies to provide functions like maximum file size, how many versions to maintain and off-site export of the archives.
JUNOS accounting file creation, update and reading is fully supported via JUNOS XML APIs. This means you can programmatically create, read and write whatever data you need, directly from your own JUNOS automation – with the caveat that the file was first defined in the JUNOS configuration accounting-options.
Pros
- Flexible. You can read/write whatever you want.
- Record layout is contained within the file – no need to maintain separate definitions
- Performance is pretty good, since JUNOS underlying OS handles file caching pretty well.
- Accounting files make it easy to request and process multiple time-series samples with a single read operation. Just specify “how far back” in time to go for data, and you’ll get all the data for than time period in one tidy XML nodeset, ready for you to examine.
Cons
- You still need to handle your own data mirroring/backup when using multiple Routing Engines. Although JUNOS will still create the accounting file for you on the other RE (e.g. via a commit sync), there is no automatic synchronization of the accounting file contents.
- Use of the JUNOS Accounting file via JUNOS XML APIs is sparsely documented. We are trying to remedy that, so please don’t allow that to be a deterrent if it looks right for your situation.
Gotchas
- There is no CLI option to create/update/show accounting file data. Although the files are easily readable via a “file show” CLI command (they’re ASCII files), you can only update them via API calls.
- When reading data from an accounting file, identifiers are returned with an extra “newline” character appended. It may not be immediately visible, but it will cause string comparisons to fail. As of this writing, I don’t know if this is by design or a bug, since documentation is sparse.